Q & Hermes
Round A — Items & Q Populate
Q was confidently claiming to have added tasks it never wrote. A directive protocol, a unified composer, and loop sub-items fix that and three related feedback items.
Situation
Four related on-device-feedback items, all about adding and managing items across surfaces — including letting Q do it. The important one (#4): asking Q in conversation to "add tasks for the main items" produced a confident reply but wrote nothing, because the Talk-to-Q conversation just relays chat to Hermes, which has no tool to write the backlog. The others: the add control is inconsistent across R&D/Loops/Intel (#2); loops can't add a sub-item or undo a delete (#3); and Q's own activity feed is computed but never rendered (#7).
The fix keeps the edge as the sole writer of q_tasks even though Q proposes items: Q ends a reply with a fenced directive, the Tower gateway parses it out (never spoken/shown) and sends a frame over the existing socket, and the edge Durable Object does the actual insert.
Key decisions
Hybrid backlog (Q1 = C)
Q-created tasks default to a passive backlog status in the Queued lane; saying "…and start planning them" promotes them to awaiting_plan. A backlog task never auto-drains to Hermes.
Structured directive (Q2 = A)
Q creates tasks by emitting a fenced `q-tasks block (one title per line, optional plan flag); a pure parseQTasksDirective on the Tower gateway lifts it out and sends a create_tasks frame — the edge stays the sole writer of q_tasks.
One context-aware composer everywhere (Q3 = B)
The shared Composer lands on Intel and Loops too; what's focused (an expanded dig, a focused loop) scopes what it does, with a gold context chip showing the active scope.
Focus model for Loops
Tapping a loop reveals its add/delete affordances and a left gold accent; unfocused loops stay clean (preserves PR #48's de-clutter).
Backlog reads distinct
A dashed BACKLOG pill with an inline Plan promote button distinguishes conversationally-added items from delegated ones.
Architecture
The #4 spine is a directive→frame→DO-insert pipeline; the other three items are additive UI work reusing the same Composer and lane-rendering machinery.
backlog QStatus in the Queued lane; excluded from drainFrames; new backlog → awaiting_plan/cancelled transitions.q-tasks block to add backlog items; plan header flag creates them awaiting_plan instead.parseQTasksDirective(reply) strips the block before it's spoken/shown and emits a create_tasks frame down the socket.create_tasks frame; on receipt, insertQTask per title (capped ~50, trimmed to 120 chars) and fan-out so the Queued lane updates live.composerContext(surface, focused) maps to placeholder/chip/action per surface and focus state.sitrep.activity (already computed by buildSitRep, previously unrendered) below the Done lane — pure render, no new data.Risks & guardrails
Investigations lineage/seeding unconfirmed
The Intel "extend to v2" flow needs the dig-seeding plumbing verified at plan time (how investigate.sh consumes a claim); a v1 fallback (reference the prior report's correlation_id, skip a formal FK) is named if lineage proves heavy.
Directive must never leak into voice/screen
The fenced block has to be reliably stripped from the spoken/displayed reply in every case, including junk after the fence.
Backlog must never auto-drain
A regression here would silently start executing conversationally-mentioned items without approval — the core invariant the whole design protects.
Delivery
P1 — the #4 spine
Status model + directive parse + DO frame + gateway (Worker + Tower).
P2 — R&D UI
Backlog pill + Plan button + activity feed render (#4 UI + #7).
P3 — context-aware Composer + Intel
Unified composer; Intel new-investigation / extend-to-v2 flows.
P4 — Loops focus + sub-items
Focus model, scoped composer, per-item add/delete + undo.
P5 — polish + verify
Design/a11y/copy pass and on-device verification.
Out of scope
docs/superpowers/specs/2026-06-19-round-a-items-and-q-populate-design.mdplan ·
docs/superpowers/plans/2026-06-19-round-a-items-and-q-populate.md