Chinesezjc a4d4404708 feat(ui-tool): render read_image results as the image

A settled top-level `read_image` call printed its raw attachment object as
literal text in the tool card — `{"type":"image","attachment":{…}}` —
instead of the image, because no presentation metadata told a client card
how to present the reference and the tool-card layer had no image concept.

Host: `read_image` declares an `output.presentationMeta` persisting
`{ path }` only. The attachment reference deliberately lives in the
settled result content — the single record a `tools/post-execute`
replacement rewrites — not in `meta`; the id is opaque and
provider-owned, checked for existence only.

Client: `imageCardModel` derives the card from the call head, the meta
path, the result's own image block, and a shape-matched envelope. ToolRow
gains an `image` card slot; the `read_image` toolview declares the
Tool-owned `tool.call.images` slot as its child and dispatches the
gallery through it. ui-chat down-threads the session-authorized loader
(`ChatNodeOwnerProps.loadImage`), so the tool layer supplies only derived
references plus the loader and never imports an attachment
implementation; ui-attachment fills the slot with its message gallery
renderer. The card keeps the envelope text below the gallery for the
no-attachment-plugin deployment. An image-bearing tool registers a keyed
toolview; the generic fallback keeps its flattened text. `read_image`
joins the read variant with its own locale title key; both rows share
`read-family-row.tsx`.

Verification: `read-image.spec.ts` (metadata projection, envelope by
shape, reference narrowing, real-execution round trip, rejection
branches incl. non-digest ids), `image-card.client.spec.tsx` (derivation,
row render site dispatching the slot, keyed registration with the
child-slot declaration, empty-slot fallbacks, media-type enum), keyless
snapshots (`read-image-gif` added; read-image/-dimension/-reencode
updated to the `{path}` meta), five injected-defect negative controls,
and a demo GIF recorded from this PR's head through the official
image-capable model.

2026-08-29 17:41:05 +08:00

2.3 KiB

Raw Blame History

Agent Note: Port tool-owned render into current DSH APIs

Status: proposed

English | 中文

Problem

The dsh-tool-owned-render prototype (Chinesezjc/dsh-tool-owned-render) ships tool-owned render registrants for read, bash, write/edit, grep/glob, and web_search/web_fetch, written against an older API where ToolCallBlock exposed callView / resultView and the client received host presentResult output. Current master derives client cards from raw block.call / block.content / block.meta, and ctx.slots requires the @deepseek-ai/dsh-client-ui-renderer/client module augmentation. A direct merge of the prototype does not typecheck, so its registrants cannot ship without a port.

Proposal

Add packages/client/tool-owned-render as a workspace package.
Port the read, bash, write/edit, grep/glob, and web_search/web_fetch registrants to derive from current ToolCallBlock fields.
Add a read_image registrant using the same ToolCard/Segment primitives.
Wire ctx.slots type augmentation through dsh-client-ui-renderer.
Keep PR #2828 mergeable while this port proceeds separately.

Alternatives considered

Merge the prototype and fix its type errors in place — rejected: every registrant would have to be re-derived from the current ToolCallBlock fields anyway, so the port is the same work with the obsolete callView / resultView contract already gone.
Fold the port into PR #2828 — rejected: the image card is one feature with a defined scope, and a second package plus five more registrants would enlarge the review surface of an already large PR.

Acceptance criteria

packages/client/tool-owned-render exists as a workspace package.
The ported registrants derive card state from current ToolCallBlock fields and typecheck on master.
A read_image registrant renders through the same primitives as read.
The ctx.slots type augmentation resolves through dsh-client-ui-renderer.
PR #2828 merges independently of this port.

Risks

The port may not reproduce the prototype's exact visual output, because the current card primitives differ from the old callView / resultView contract.
API drift while the port proceeds can stale this proposal; the acceptance criteria are re-checked against master at port time.

2.3 KiB Raw Blame History