fix: make @deuce's questions answerable again

[clintberry]

Summary

@deuce can ask you a question again, and your answer reaches it. That path was broken end to end: the agent would ask, the task would sit at "working" until a ten-minute timeout killed it, and there was no way to answer. Yes/no questions were worse than unanswerable — they were delivered to the agent as "no" regardless of which button you clicked.

The cause was that Deuce's ask_user implementation was written against a guessed Pi RPC wire format, and the tests then asserted that same guess. The suite stayed green while all three question styles were broken in production. The decoder's own source admitted it: "The exact extension_ui_request shape is pinned when the ask-user extension lands; decode best-effort." This branch reads Pi 0.84.0's published types and corrects the extension, the decoding, and the answer shape against them.

What was actually broken

Three independent defects, one per layer:

Layer	Defect	Symptom
Extension	select(title, question, options) against Pi's real select(title, options, opts)	Pi emitted options as a string; Go's unmarshal failed and dropped the whole line, so awaiting_input never fired and the active-work timeout was never suspended — the ten-minute hang
Decoder	Read prompt / params.*, keys no Pi arm carries	Every question rendered with an empty prompt
Response	Answers sent under a response key	Pi accepts it, correlates it, then resolves to its parser fallback — undefined for text, false for confirm. Every answer discarded

Beyond the reported bug

• A second latent bug is closed. Deuce treated every Pi UI call as a blocking question. npm:pi-subagents is installed in every workspace, so any progress notification it emitted would have wedged that task in "needs your input" until the ceiling killed it. Five of Pi's nine UI methods are fire-and-forget and now decode to ignore.
• Rollout skew is handled. The extension is baked into prebuild images keyed on the devcontainer hash, so a stale image can run the old extension against the new decoder. The decoder recovers the question from where the old extension misplaced it, for both select and input.
• A timeout ordering invariant is now enforced, not just documented. Pi's dialog timeout must fire after Deuce's 30-minute ceiling, or Pi resolves the dialog with its own default and hands the model a fabricated answer while the drawer still shows the question as answerable. That was two comments pointing at each other; the contract fixture is now the single source of truth and tests on both sides assert against it.

Design decisions worth review

• Truncation moved onto the flex item, not the inline span. overflow/text-overflow do not apply to non-replaced inline boxes, so the existing declarations on the argument span were inert — adding min-width: 0 alone would have let the text spill and keep scrolling the thread. Prose the user must read to answer (the pending-question block, the choice buttons) wraps instead of truncating.
• An unrecognized yes/no reply defaults to "no", logged at warn. An unparsed answer must never read as approval — "not sure" cannot authorize a force-push — and it matches Pi's own confirm fallback, so a mis-decode degrades identically on both sides of the wire.
• The extension owns its own no-answer deadline. Pi resolves a timed-out confirm to false, which is exactly what a real "No" produces, so the resolved value can never distinguish them.

Known accepted gap

Answering stays in the agent thread drawer. An @deuce message sent while a question is pending is enqueued behind the blocked task — the running-task lookup counts awaiting_input as busy — so it cannot run until the question resolves. A user who answers in the main chat therefore still hits the original symptom. This is accepted here because the fix belongs to the chat surface, not the protocol; a session-notice mitigation is recorded as follow-up.

Validation

Go suite (all 13 packages), 97 frontend tests, tsc -b --force, and lint all pass. Each unit was implemented against a red test observed first — including the exact cannot unmarshal string into Go struct field .options of type []string failure that is the reported hang — and the yes/no mapping was mutation-tested to confirm a whole-string match fails the "yes, go ahead" case.

Live verification against a real Pi is still outstanding and a green suite does not substitute for it: the suite proves Deuce agrees with the fixture, not that Deuce agrees with Pi. Rebuild the workspace (not restart — the extension is baked into the prebuild image), then confirm each question style end to end and that clicking No is received as a negative.

Residual review findings, deferred items, and the full verification checklist are recorded in docs/residual-review-findings/fix-ask-user-question-protocol.md.

Session-settled decisions carried from planning: repair the hand-rolled ask-user extension rather than adopting npm:pi-ask-user (user-approved, over adopting the published package).

New concepts

Counterparty-derived contract fixtures. When you integrate with a process you don't own over an informally-typed wire (JSONL over stdio, a CLI, an exec channel), the tempting move is to hand-write a decoder and then write fixtures beside it asserting what you expect to see. Those fixtures can only ever confirm the decoder's own assumptions — they cannot catch them. That is precisely how this bug shipped green for all three question styles.

The fix is to derive the fixture from the other side's published contract and check it in. server/internal/agent/pirun/testdata/pi-ui-protocol.json transcribes all nine arms of Pi's request union and all three arms of its response union from @earendil-works/pi-coding-agent's own .d.ts declarations, records the version it came from, and is read by both the Go decoder tests and the TypeScript extension suite. A completeness test fails if the fixture grows an arm nothing asserts.

Why here rather than the obvious alternative: a recorded golden stream (which this repo already has for the general event flow) only captures shapes that actually occurred during capture — extension_ui_request never appeared in it, which is why the gap went unnoticed. Published types cover arms you have not exercised yet.

When not to use it: if the counterparty publishes no types, docs, or readable source, a transcribed fixture is just a differently-located guess — record a real captured stream instead and say so. And a transcribed fixture is diffed against itself, not against a live counterparty, so it needs re-verifying on their upgrades.

---