Files
deepseek-harness/docs/rfc/rejected/simplification/2026-06-20-generic-tool-rendering.md
Tianyi Cui e6fad266a6 docs(rfc): define and enforce a uniform RFC format; adopt it across the corpus
Define the in-file RFC contract in docs/rfc/README.md § The file format:
the header block (`# RFC: <title>` plus a dateless Status enum
cross-checked against the lifecycle folder), the per-lifecycle body
skeleton (a Problem opener everywhere; Proposal/Alternatives considered/
Acceptance criteria/Risks in proposed/; present-tense Decision/
Consequences with proposal-era headings banned in implemented/; the
frozen proposal shape in rejected/), and a mandatory Alternatives
considered section with a date-fenced grandfather comment for pre-format
RFCs whose alternatives are not reconstructible from the record.

Enforce it with a new doc-sync gate, scripts/verify-rfc-format.ts, and
normalize all 112 RFCs to it: ~15 Status-line spellings collapse to the
enum, 29 Context openers become Problem, the 39 legacy-format XXX debt
markers are resolved and banned from reappearing, proposal-era sections
in implemented RFCs are rewritten to shipped reality (including the
web/fs/subagent seam RFCs' migration plans and test checklists, closing
the doc-tiers deferred-work item on the web seam), every RFC gains an
Alternatives considered section or the grandfather comment, and the
bilingual pair is re-mirrored and re-recorded.

Move the generated index tables out of README.md into a fully generated
docs/rfc/INDEX.md — gen-rfc-index now writes the whole file, and
verify-rfc-classification checks its freshness and rejects index-shaped
rows in the curated README — which makes room for the format contract to
live in the README front door instead of a separate FORMAT.md.

The decision record, and the first RFC written in the new format, is
docs/rfc/implemented/process/2026-07-05-uniform-rfc-format.md.
2026-07-05 22:58:25 +08:00

2.6 KiB

RFC: Collapse tool-owned UI presentation

Status: rejected — tool-owned presentation should wait for more real tools before being generalized or deleted. Bash and ACP currently need the existing richer presentation path.

Problem

Tools can define presentCall() and presentResult() callbacks that return ToolCallPresentation, ToolResultPresentation, and optional ToolTerminal fields. The code itself flags the design as muddy: title, kind, raw input, content, terminal cwd, terminal output, exit code, and signal grew incrementally into a bag of optional fields. ACP then maintains pending call state to pair a result with the original args, creates replay-only presenters on session/load, and maps terminal subfields into Zed-specific _meta. dsh-tool-bash even parses exit status back out of rendered text because the pure replay-safe presenter no longer has the structured BashRunResult.

The real first-party use is bash presentation for ACP. That is too little evidence to freeze a cross-package UI presentation API.

Proposal

Remove tool-owned UI presentation callbacks for now. The canonical tool events already carry the tool name, raw argument string, result content, and error state. UIs render a generic tool card from those fields. Tool-specific rich rendering can return later as a tagged render-intent union after there are at least two real tools and two real consumers to validate the vocabulary.

Alternatives considered

As a smaller alternative, replace the current optional-field bag with one explicit union in a single PR; but if the goal is simplification, the stronger move is to delete the callbacks and keep the generic path.

Acceptance criteria

  • ToolDefinition drops presentCall and presentResult.
  • ToolCallPresentation, ToolResultPresentation, ToolTerminal, and ToolCallKind disappear unless a minimal generic UI type still needs one.
  • ACP no longer keeps presenter pending state or calls tool callbacks during live streaming/load replay.
  • dsh-tool-bash no longer parses rendered text to recover exit status for a UI pill.
  • Snapshot goldens show generic tool cards and text results.

What we give up

Bash loses its custom terminal-looking card and model-written description placement. The fallback remains reasonable: the command appears as tool input, and the output appears as text. Rich rendering should be designed when the product has enough UI/tool variety to justify a stable presentation contract.

This is the broad version of dropping ACP terminal metadata. If this RFC is accepted, that narrower RFC becomes unnecessary.