fix(pi): ask_user_question single-select questions render as a structured card#32125

Evidence 1/2: captures and recordings. Before = 6577c6b618 (main), after = a1e4f49419. The final head 99b5102304 only adds interleaved-dialog handling for custom answers, which changes no rendering. Each side ran its own web dev server (Chromium, DPR 2, no device emulation) and Android dev client (Pixel 9 emulator, DPR 2.625, font scale 1.0) on a fresh database, with Pi 1.4.0, @juicesharp/rpiv-ask-user-question 2.15.0 and Claude Sonnet 5.5. The clock was frozen and reduced motion forced, and every still was taken only after two frames 500 ms apart matched exactly. Images are attached in this order:

A grey box covers one agent reasoning line in the conversation, outside the question card, in images 1-8 (equally on both sides) and in the first 4.25 s of recording 12. That line named an environment-specific tool alias.

Evidence 2/2: diff images of the question-card region, before 6577c6b618 vs after a1e4f49419, with ImageMagick compare -metric AE. Magenta marks changed pixels and black marks equal ones. Each row has a diff at -fuzz 0% and one at -fuzz 1%, attached in this order: A web 1440 light, A web 1440 dark, A web 390 dark, A Android light, B, C (final reply frame), D.

What else changed:

• Everything outside the card and the "Working for …" timer: zero changed pixels at 0% for A web 1440 light and dark, B and D. Narrow, Android and C are not claimed equal outside the card.
• Generated agent text and the worked-duration labels differ between runs.
• The card's height and top edge change because the 3. Type something. row is gone, so more or less of the conversation fits at the same scroll position.
• On Android, the custom-answer field and Submit contents shift by about one physical pixel from native layout rounding.

Approvability

Verdict: Needs Human Approval

Macroscope's review found this PR requires human approval — The change renders matching Pi single-select questions as structured cards and handles custom answers through a follow-up prompt. It also adds a lint suppression for extension-compatible option formatting, which requires human review.

^{You can add or adjust custom eligibility rules. Learn more.}

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Baseline: 9cd7a04 · PR result: f5bf75d · Source CI: success

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

Explain Change →

No actionable comments were generated in the recent review.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Usage-based review receipt

• Mode: Continue automatically
• Reviewed files: 2
• Charged: $0.50
• View usage details

External image Recent review info

External image Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: fix/issue-32092
• File: .coderabbit.config.ts
• Commit: f5bf75d
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Team
• Run ID: 501e9c4f-75c2-40df-ad68-3adcc0db0eb1

External image Commits

Reviewing files that changed from the base of the PR and between e09c11dbbd652dc610aebeedd235a93138600a9f and f5bf75d41f9211f93369ace712d64f944626e05e.

External image Files selected for processing: 2

• packages/provider-pi/src/server/adapter.test.ts
• packages/provider-pi/src/server/adapter.ts

Limit details: You’ve used all 10 included reviews currently available.

@coderabbitai on your two outside-diff findings for d323746:

• Multi-select inputs consuming a queued answer (adapter.ts:1493-1506): fixed in c1c9f34981. A queued custom answer is now consumed only by an input with an empty placeholder, which is what the extension's follow-up sends (ui.input(title, "") in 2.13 and 2.15; Pi's RPC forwards placeholder as given). Its multi-select input uses 1,3; custom answer. The custom-answer test now interleaves a same-question multi-select input before the follow-up, and that input surfaces as its own card.
• Completed calls and — label/description collisions (adapter.ts:3676-3725): leaving as is. A match needs the same header and question, the same option count and byte-identical option lines. If two calls ever split those lines differently on —, the answer is still the right option, because each option's value is the extension's original line, which the extension maps back by position. Only the label/description split on the card could differ. Tracking which calls are still live is not worth that.

@coderabbitai on the title-only FIFO finding for c1c9f34 (adapter.ts:1505-1506): leaving as is. Even with parallel tool execution, the follow-ups for one title come out in the order their selects were answered:

• In the extension's askSingleSelect, await ui.select(...) is followed synchronously by ui.input(...).
• Pi's RPC mode resolves dialog responses in the order it reads them from stdin.
• Each continuation writes its follow-up request before the next response is handled.

The queue is filled in the order T3 sends those responses, so the two stay paired. A per-call correlation is not available: the follow-up input request carries no reference to the select or the tool call it belongs to.

@juliusmarminge Thanks for the explanation. The adapter queues each answer and sends its select response under the same sessionEventPermit. Given the Pi ordering you described, the follow-ups preserve that order, so I withdraw the FIFO finding.

I did not independently verify the Pi and extension ordering.

_{You are interacting with an AI system.}

@juliusmarminge Thanks. The source supports your explanation.

• Multi-select inputs: The empty-placeholder guard addresses the queued-answer issue. The updated test asserts that the same-question multi-select remains a separate card and that subsequent follow-ups receive the queued answers.
• Completed calls and — collisions: I accept leaving this unchanged. Matching requires the exact title, option count, and option lines. Each option retains the matching original line as its value. The remaining ambiguity affects the displayed label/description split, not the returned option value. I withdraw the answer-routing concern.

I verified the code and test assertions by inspection. I did not run the tests.

_{You are interacting with an AI system.}

Evidence

Environment for every capture: real web app, Linux Chromium, 1280×900 CSS viewport, DPR 2, dark theme, separate worktrees and fresh databases, identical synthetic question payloads, Pi extension 2.15.0. Recordings crop unrelated chrome and mask private provider controls.

Steps on both commits:

1. Ask the Area question with Docker/Compose and Home Assistant labels and descriptions; inspect the card.
2. Select Docker/Compose and submit.
3. Repeat, type literal 2 in the custom-answer field, submit, and expand the actual tool output.
4. Repeat with a Compose YAML preview and a second question sharing the first title's prefix but ending in Next task; type 2 for the first and select Docker/Compose for the second.

Observed: base renders Question, flattened numbered strings, and Type something. Head renders Area and two separate labels/descriptions. Selecting Docker/Compose returns it on both. Typed 2 returns Home Assistant on base and literal 2 on head without another visible prompt. Head preserves the preview and full second title; actual tool output contains first answer 2 and second answer Docker/Compose. Some agent final replies misquoted answers; expanded tool output is authoritative in these captures.

Shared seed script · Recording export script

AI-assisted; verified with the tests and tools listed above.

Not shown:

• Desktop and mobile clients were not exercised; this proof covers the real web client and Pi server adapter.
• JSON-encoded nested arguments, CRLF normalization, localized sentinel text, malformed-input fallback, and concurrent follow-up routing were not exercised; the reproduction used ordinary English JSON arguments and sequential questions.