Proposal: two generic transcript extension points — a user-bubble body chain and prose inline directives

[lamost423]

Hi team — while building a community plugin (Codex-style answer annotations, dsh-plugin topic) we ran into two places where the transcript is closed to plugins, and ended up carving generic seams for them. The full implementation ships in that repository as one additive patch against current master (293 lines, annotation-agnostic, with tests passing under both touched packages' suites). Sharing the design here in case it fits the official roadmap.

The use case

The plugin lets a user select passages in an assistant answer, attach comments, and send them as one structured batch (a tagged JSON block in the message text). The model is instructed to cite each annotation inline in its reply (:dsh-annotation{index="1"}). Two rendering problems follow:

1. The user bubble cannot be presented by a plugin. The sent message text is the durable record, so it carries the machine-readable block — but the bubble renders it as literal prose. There is no seat inside the user bubble; the only alternative is taking over the whole conversation.chat.node user renderer and re-implementing images, reference chips, timestamps, and icon actions.
2. Assistant prose cannot carry plugin-rendered inline UI. The model's inline citations stay literal text. The markdown renderer is deliberately closed (DOM pinned by parity fixtures, untrusted-output policy), which we think is correct — but that also closes the door on any structured back-reference vocabulary.

The two seams we ended up with

Both are generic — the core never learns what an "annotation" is:

1. conversation.chat.user-body (chain slot). Dispatched by the chat view for every user bubble body, durable and pre-admission steering alike. Currency is { text: string } — the sent text only. An entry's selector parses the text and elects; all-decline falls through to the existing plain projection. One dispatch line in the bubble; everything else is plugin-side.

2. MarkdownInlineDirectives + an optional chatInlineDirectives service. The markdown renderer parses :name{key="value"} runs in prose text nodes and asks an owner-supplied resolver; unresolved directives stay literal, directives inside links stay literal, and the whole mechanism only applies to settled renders (same gate as inline-code file mentions, so streaming caches never bake in stale handlers). The conversation package resolves the vocabulary lazily per directive through ctx.get, mirroring the existing chatFileMentions pattern.

Why we think these generalize

• The pattern "feature encodes structure into sent text, expects structure back" is not annotation-specific — quoting, forms, and any structured-prompt feature hit the same two walls.
• Both seams follow existing house patterns (chain slots with fallback; optional service vocabulary à la chatFileMentions), degrade to exactly today's behavior when nothing registers, and are additive — in our fork the whole change to existing core files is three one-line touchpoints; the rest is new code with per-file test coverage.

Would this direction be of interest? The patch above is the concrete proposal; we're happy to adapt naming/shape to your preferences, or describe the edge cases we hit (chain election vs. streaming, steering projections, directive parsing limits) in more detail.

[brunogsystem]

+1, we hit the same wall from a different use case: rendering inline code and fenced code blocks in user bubbles (backticks only, everything else stays literal), without changing the text that is sent to the model.

Shadowing conversation.chat.node (keys user and steering) works for durable nodes. But in 0.2.0-rc.2 three surfaces bypass the slot:

• the pending submission echo (PendingSubmissionBubble, which renders UserStyleBubble directly);
• pre-admission steering (PendingSteeringBubble, same);
• the queue preview in QueueDock, which builds its own flattened one-line text (previewOf).

So a formatted bubble flashes back to plain text on every send. A conversation.chat.user-body chain dispatched from inside UserStyleBubble, as proposed here, would cover the durable bubble and both pending ones with a single seam. It would be great if the queue preview could take part too, perhaps with a variant: "preview" in the currency, so a plugin can return a one-line projection.