frame the context / thinking / agent-prompt meta cards (T-306)

The injected context block and the thinking / agent-prompt blocks
rendered as frameless `bare` cards, reading as unfinished `> context …`
rows next to the framed tool cards. Switch them to the bordered variant —
same panel border + left chevron + label as the surrounding cards — while
keeping the D-78 de-emphasis (muted accent, collapsed by default,
first-line summary; thinking gains a summary for parity). Adds a
conversation_card_meta golden.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

governance/decisions/architecture.md

@@ -460,3 +460,13 @@ Core, rendering, IPC, kernel, panel manager.
 - **Raised by:** 2026-06-09 — user, on reviewing the T-56 passthrough: "put a heavy blocklist with do-you-want-this prompts on it (a paranoid allowlist)." Spotted that routing clide:// through the CLI path is "incredibly extensible" and that extensibility is exactly the risk for an external vector.
 
 ---
+
+### D-91: Unified conversation drawing card backed by a canvas renderer
+- **Date:** 2026-06-10
+- **Decision:** The conversation pane gets ONE drawing card — a clide-owned canvas renderer driven by a JSON document — instead of a growing set of one-off renderers (image card, icon card, …). The mental model is the **HTML `<canvas>`**, not Obsidian's `.canvas` (Obsidian naming its feature "canvas" does not make its schema our pattern). The card's JSON can express raw **primitives** (rects/lines/text/etc. at coordinates — "draw a box at x,y, a line from x,y to x,y" works), but in the common case it runs in **template mode**: the JSON names a predefined component and the card grabs it — `image` (display + lightbox-on-click), `icon` (the multi-size glyph set, D-78/T-313), `compare-images` / before-after (two paths side by side), and — added incrementally — `svg`, `graph`, and more. Every drawn object may carry an optional **label + description**, rendered as a widget beneath it only when those fields are present in the JSON. Templates lower onto the same primitive scene the raw API accepts (hybrid: scene-graph core + high-level block sugar). The card stays **display-only** per [D-78] — selection/interaction happens in the interaction zone, not on the card. The same renderer is intended for **reuse as the `.canvas` viewer** elsewhere: a `.canvas` file is converted into this JSON rather than the card adopting Obsidian's schema natively. The already-shipped image card (T-249/T-252) is left in place for now and migrated onto this canvas once the canvas layer lands.
+- **Rationale:** Each new "show X in the conversation" need was trending toward another bespoke message type + widget + CLI verb. A single canvas that dispatches templates (and falls back to primitives) collapses that into one surface to build, test, and drive — new visuals become a new template/JSON shape, not a new renderer. Anchoring on HTML `<canvas>` rather than `.canvas` keeps the model general (arbitrary drawing) instead of bending features to a third-party document schema, while still letting us ingest `.canvas` via conversion. Hybrid (templates over primitives) is the pragmatic middle: the common cards ship without hand-placing coordinates, but nothing is locked out of the primitive layer. Honors "own the rendering stack" — canvas is explicitly a clide-owned `CustomPaint`, not a packaged widget.
+- **Cost:** A real renderer with a JSON schema is more up-front design than another one-off widget, and the schema must stay coherent across the primitive and template layers as templates accrue. Templates expand over time ("we will expand the templates as we go") so the schema is deliberately open-ended; that flexibility is a standing maintenance surface. The `.canvas`→JSON converter is additional scope, deferred. Migrating the shipped image card is follow-up churn on working code.
+- **Relationship:** Narrows [Q-4](../questions/architecture.md#q-4-canvas-schema-compatibility-with-obsidian) — clide's canvas is its own HTML-canvas-inspired JSON; Obsidian `.canvas` is an *import* format via conversion, not the native schema. Consumes the stdin/`--file` JSON input plumbing (T-315). Subsumes the standalone icon card (T-313) and image-annotation work (T-316) as templates of this card.
+- **Raised by:** 2026-06-10 — user, while refining the icon-preview card (T-313): "make it all into one drawing card that receives a json input and selects based on the context inside the json what to draw … pull the entire thing closer to a dynamic canvas than a bunch of one-off renderers." Clarified the model is HTML `<canvas>` (not Obsidian's), templates-over-primitives, per-object label/description, and reuse as the `.canvas` renderer; before/after comparisons, SVGs, icons, and graphs all become things you send into the card.
+
+---

governance/questions/architecture.md

@@ -29,9 +29,10 @@ ticket persistence.
 - **Source:** ADR 0006 (migrated to [D-6](architecture.md)).
 
 ### Q-4: `.canvas` schema compatibility with Obsidian
-- **Status:** Open
+- **Status:** Open — narrowed by [D-91](../decisions/architecture.md#d-91-unified-conversation-drawing-card-backed-by-a-canvas-renderer)
 - **Question:** Clide's canvas (Tier 5) should read/write something — either Obsidian's `.canvas` JSON schema verbatim, a compatible-ish superset, or our own format. Each has trade-offs.
 - **Context:** Obsidian's canvas users might want their canvases portable; conversely, bending to Obsidian's schema constrains our canvas features.
+- **Narrowed (2026-06-10):** D-91 sets the direction — clide's canvas uses its OWN HTML-`<canvas>`-inspired JSON (the unified drawing-card schema), not Obsidian's `.canvas` natively. Obsidian `.canvas` is treated as an **import** format, ingested by converting it into clide's JSON, so the same renderer can display it. What remains open here: the exact converter mapping and how lossless/round-trippable `.canvas` interop needs to be.
 - **Source:** CLAUDE.md "Open questions" footer.
 
 ### Q-5: IPC wire-format stability + `schema_version:`