FE-1789: Steer Brunch Voice through Draft, Check and Experiment

[kostandinang]

🌟 What is the purpose of this PR?

First slice of "Draft steering" from the Brunch Voice RFC: give GPT-Live-1 quiet, accurate context about how far Brunch's Ledger (its record of settled facts) has got, so the voice can describe progress truthfully instead of guessing. This uses the third GPT-Live-1 steering event, session.thinking.append, which the Live bridge did not use before (it used commentary for Brunch's answers and instructions for failures only).

The slice is browser-only. Brunch itself is unchanged; the note is derived deterministically in the client from the latest applied mutate_workpiece revision already present in the conversation snapshot. GPT-Live-1's prompt keeps Brunch as the only author of substantive questions; this note does not let the voice choose what to ask.

🔗 Related links

• RFC: Brunch Voice — let the person watch the model run and correct it by talking (internal, Notion): https://app.notion.com/p/3e53c81fe02481c9ae86da9bc81299de
• GPT-Live delegation and steering events: https://developers.openai.com/api/docs/guides/live-delegation
• Retirement of the sweep tool that interview-coverage.ts read: libs/@hashintel/brunch-agent/docs/evidence/design/provenance-and-tooling-decision-log-2026-09-04.md, item C9 (removed from main with FE-1652: Keep Brunch planning protocols outside the product repository #9810; the file this PR deletes was already dead)

🚫 Blocked by

• Nothing.

🔍 What does this change?

• live-brunch-bridge/ledger-coverage-note.ts (new): selectAppliedWorkpieceRevision finds the latest mutate_workpiece result whose output binds its own call (revisionId === toolCallId; refused, pending or unbound inputs are not state, same rule as brunch-workpiece-history.ts). describeLedgerCoverage renders a note from the workpiece headings: which level-3 sections hold claims, which carry an open annotation (Not yet asked, Unknown, Assumed, Deferred, Conflict, Declined), which are empty, and how many cross-cutting issue entries exist. Fenced code is ignored. The note stays under 1,400 characters (GPT-Live allows 500 tokens per append), dropping the least useful sentences before truncating.
• live-brunch-bridge.ts: new appendThinking dependency; update() offers the note once per applied revision, before #settle() so quiet context precedes any spoken answer from the same update. A note is re-offered only if the local send failed.
• live-conversation.ts: appendThinking, "thinking" in LiveAppendResult["kind"], session.thinking.appended acknowledgement. A thinking ack does not close an open delegation (only commentary or instructions answer one).
• live-conversation-control.tsx: wires appendThinking; re-runs bridge.update() once the Live channel connects, because the first update() happens before the data channel opens; suppresses the user-facing warning for a failed thinking send (best effort, retried on the next update).
• openai-live-session.ts: one prompt addition telling GPT-Live-1 what quiet context notes are and that they are not a questionnaire or licence for its own follow-up questions.
• Deletes interview-coverage.ts and its test (dead code reading the retired sweep tool).

Pre-Merge Checklist 🚀

🚢 Has this modified a publishable library?

This PR:

• does not modify any publishable blocks or libraries, or modifications do not need publishing

📜 Does this require a change to the docs?

The changes in this PR:

• are internal and do not require a docs change

🕸️ Does this require a change to the Turbo Graph?

The changes in this PR:

• do not affect the execution graph

⚠️ Known issues

• The note is a heading heuristic, not Brunch's judgement. A section whose only body is template guidance text counts as "settled". If that proves too weak, the RFC's follow-up is an elicitor-authored steer_voice tool writing a data-* part through Flue's useDataWriter.
• Not yet exercised against a real GPT-Live-1 session in this PR; behaviour is covered by unit tests against the documented event shapes.

🐾 Next steps

• Try it in Labs with the support-desk scenario and check GPT-Live-1 describes progress accurately when asked "what have you got so far?".
• RFC §3 (Experiment relay) and §1 (Check) follow separately.

🛡 What tests cover this?

• live-brunch-bridge/ledger-coverage-note.test.ts (new): settled/open/empty classification, nested case content, fenced headings ignored, budget trimming order, revision selection (latest bound revision; skips refused, unbound, non-markdown, dispatch-role and non-mutate_workpiece parts).
• live-brunch-bridge.test.ts: one note per revision, not re-sent on re-render, thinking precedes commentary in the same update, retried only while the local send fails, refused/unbound revisions ignored.
• live-conversation.test.ts: session.thinking.append wire shape, acknowledgement correlation only on session.thinking.appended, delegation stays open after a thinking ack.
• yarn lint:tsc, yarn lint:eslint (no new warnings) and the full voice-interview + server/voice vitest suites pass for @apps/petrinaut-website.

❓ How to test this?

1. Checkout the branch, run yarn dev for @apps/petrinaut-website, open the AI assistant and switch to Brunch Voice.
2. Describe an operation until Brunch applies a workpiece revision; in DevTools look for [Petrinaut Live trace] ... "event":"brunch.coverage" with sent: true.
3. Ask the voice "what have we covered so far?" and confirm it reflects the settled sections without inventing model changes.

📹 Demo

None yet; audio session.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
hash	Ready	Preview	Sep 24, 2026 11:56am UTC
petrinaut	Ready	Preview	Sep 24, 2026 11:56am UTC
petrinaut-docs	Ready	Preview	Sep 24, 2026 11:56am UTC

1 Skipped Deployment

Project	Deployment	Actions	Updated
hashdotdesign-tokens	Ignored	Preview	Sep 24, 2026 11:56am UTC

[kostandinang]

Superseded by #9826 on the Linear-named branch kostandin/fe-1789-brunch-voice-steering (same commit).