Fix The inbox takes 30-40 s

PR #331 at 7ed1381: 10 checks passed
rhiza: step rebased-green: pass
rhiza: step merge: entered, visit 2
Merged PR #331 at 7ed1381 as d000ae0.
rhiza: step merge: pass
rhiza: step close-out: entered, visit 1
Removed worktree /home/rhiza/code/rhiza.fix-the-inbox-takes-30-40-s.
Rex tab window:01a1b1d9-ea91-7cb8-8336-05ad58156ac0 was already closed.
Rex tab window:01a1b1dc-6376-7bb9-bd33-65a7ac34b300 was already closed.
Rex tab window:01a1b1df-76a4-7559-9bb2-98d40ceaca19 was already closed.
Rex tab window:01a1b1e1-2195-7217-9c47-3173550b6b26 was already closed.
Rex tab window:01a1b1e2-07b0-7a4b-82c4-705137265bf1 was already closed.
Rex tab window:01a1b1e3-f5fb-7dc8-bf45-bb35c6859d77 was already closed.
Rex tab window:01a1b1e5-cec6-7f32-870c-62fdd80448bb was already closed.
Rex tab window:01a1b1e7-1f50-7413-8799-f07170f2444e was already closed.
Rex tab window:01a1b1e8-4a20-7329-a3d4-990154d25689 was already closed.
Rex tab window:01a1b1e9-5e27-718b-bbde-75381ad648ec was already closed.
Rex tab window:01a1b1ea-346f-79ab-a33e-b104e5ee227b was already closed.
Deleted branch cs/fix-the-inbox-takes-30-40-s.
Deleted origin/cs/fix-the-inbox-takes-30-40-s.
Updated main in /home/rhiza/code/rhiza.
rhiza: step close-out: pass
rhiza: run 01M6RXK0J8R80MVRSY08PN9G41 succeeded
Run 01M6RXK0J8R80MVRSY08PN9G41 succeeded

- Workflow: plan
- Change set: 01M6RXK2SB0M12FXVEGXER022R: Fix The inbox takes 30-40 s
- Worktree: /home/rhiza/code/rhiza.fix-the-inbox-takes-30-40-s
- Autonomous: yes
- Started: 2026-11-06T17:13:15Z

## Steps

- interview (visit 1): pass, then milestone-check, session fa508624-2462-49e9-98cd-01a1b1d9c450: said done and until held
- milestone-check (visit 1): pass, then review: exit 0
- review (visit 1): pass, then critic, session 20e54cff-2776-45f5-920b-01a1b1df509b: said done and until held
- critic (visit 1): pass, then check, session 97b9e5c9-e776-4ef2-ba7f-01a1b1e0fa19: said done and until held
- check (visit 1): fail, then revise: exit 1
    - f2 contradiction on inbox-app-gate-scroll: For the fallback that inbox-gate-questions-kept adds (questions with empty statements), the acceptance says the form 'still opens the form by handle'. inbox-app-answer-shows-question says the gate form shows each question's full text, 'never a handle as the label'. And asked() (inboxapp.go:577) would show a blank line for an empty statement. The plan never says what the form shows for an empty-statement question. Showing the handle breaks inbox-app-answer-shows-question, and showing nothing leaves the owner answering blind. Name the fallback text (e.g. say the question's text could not be read, and give the handle only as a reference) and amend or carve the exception out of inbox-app-answer-shows-question. — confirmed: inbox-app-gate-scroll's acceptance has the empty-statement fallback (from inbox-gate-questions-kept) 'still open the form by handle', while the accepted capability inbox-app-answer-shows-question says the gate form shows the full question, 'never a handle as the label'. asked() (inboxapp.go:577-582) returns the empty Statement, so the plan leaves the shown text for that case undefined and its acceptance points to the handle, which contradicts the existing capability.
    next: rhiza run status 01M6RXK0J8R80MVRSY08PN9G41
- revise (visit 1): pass, then review, session 59f897a0-28d0-4eae-a1b7-01a1b1e1c91b: said done and until held
- review (visit 2): pass, then critic, session 0e5b0051-4c72-4e1f-9f8e-01a1b1e3a8de: said done and until held
- critic (visit 2): pass, then check, session 30bfc965-d002-4c8c-af1b-01a1b1e58995: said done and until held
- check (visit 2): fail, then revise: exit 1
    rhiza: run review-check: review round 2 of run 01M6RXK0J8R80MVRSY08PN9G41 has 1 confirmed finding(s); revise the plan and review it again:
    - f1 contradiction on inbox-app-gate-scroll: The leaf (and Decision inbox-gate-questions-cheap part 4) shows a question whose statement is empty with its handle on a 'ref: <handle>' line in the Inbox app, and its acceptance tests for that line. The constraint owner-surfaces-no-ids says no owner-facing surface (the Rex apps included) shows a node's handle, and inbox-app-answer-shows-question's acceptance requires 'no handle in the view'. The fallback must not show the handle: show 'This question's text could not be read.' alone, or a non-ID reference such as its position or what it blocks. — confirmed: inbox-app-gate-scroll's statement and acceptance (and Decision inbox-gate-questions-cheap part 4) show an empty-statement question's handle on a 'ref: <handle>' line in the Inbox app and test for it. The constraint owner-surfaces-no-ids says no owner-facing surface, the Rex apps included, shows a node's handle; only the CLI keeps handles. inbox-app-answer-shows-question's acceptance also requires 'no handle in the view'. Moving the handle off the label onto a reference line is still showing it, so the plan contradicts the constraint.
    next: rhiza run status 01M6RXK0J8R80MVRSY08PN9G41
- revise (visit 2): pass, then review, session 64d1d339-a7da-41a1-86e4-01a1b1e6e510: said done and until held
- review (visit 3): pass, then critic, session 98cd3fb2-ee75-45f3-9a79-01a1b1e8263e: said done and until held
- critic (visit 3): pass, then check, session 32689a09-5521-4b85-8f1f-01a1b1e944f6: said done and until held
- check (visit 3): pass, then gate: exit 0
- gate (visit 1): pass, then open-pr: exit 0
- open-pr (visit 1): pass, then wait-pr: exit 0
- wait-pr (visit 1): pass, then pr-green: held after 12 checks
- pr-green (visit 1): pass, then rebase: exit 0
- rebase (visit 1): pass, then wait-rebased: exit 0
- wait-rebased (visit 1): pass, then rebased-green: held after 12 checks
- rebased-green (visit 1): pass, then merge: exit 0
- merge (visit 1): fail, then rebase: exit 1
    Not merged: origin/main has moved past PR #331's checked head 24142ff; rebase and check again.
- rebase (visit 2): pass, then wait-rebased: exit 0
- wait-rebased (visit 2): pass, then rebased-green: held after 11 checks
- rebased-green (visit 2): pass, then merge: exit 0
- merge (visit 2): pass, then close-out: exit 0
- close-out (visit 1): pass, then end: exit 0

## Accepted in the owner's place

- 2026-11-06T17:32:12Z accepted change set 01M6RXK2SB0M12FXVEGXER022R (log entry 01M6RYNY64BBVYKBNGKWDQ52B4)

## Questions put to the arbiter

- question-fa508624-1 (01M6RXQVR420SBRR5BA8PYARFG): Change set 01M6RXK2 (inbox takes 30-40 s at a gate; Inbox app can't act on the gate item) serves no intent yet. Which intent should it serve? / How should the inbox read a gate's open questions cheaply (today inboxGateQuestions opens the run worktree with no index, decoding the full 11,400-entry log, and folds a model per question × per planned change set)? / What proves the inbox stays fast at a gate? / In the Inbox app, what should a gate ('open') item do when picked? — decision inbox-gate-questions-cheap
- review-01m6rxk0-r3-f1 (01M6RYKX4E14KYYST0X8X5AJMP): Plan review round 3 left finding f1 (missing-acceptance on inbox-gate-questions-kept): The acceptance check mixes two cases into one setup and does not add up: 'a plan run stopped at its gate on two questions whose worktree does not read (and one whose handle resolves in no planned change set) gets an inbox open item listing both handles'. If the worktree does not read, no handle can resolve, so the second case cannot happen in the same run, and 'both' contradicts the three questions named. A builder cannot tell what the test should set up or assert. Split it into two runnable cases: (a) the worktree does not read, so every stop-detail handle is listed with an empty statement; (b) the worktree reads but one handle resolves in no planned change set, so that handle is listed with an empty statement and the others keep their statements. The critic confirmed it: inbox-gate-questions-kept's acceptance asks for one test where the run worktree does not read and also one handle resolves in no planned change set. In inboxGateQuestions (internal/api/inbox.go:1066-1071), a worktree that does not open returns before any handle is resolved, so both cases cannot happen in one run. It also names three questions but expects 'both handles' listed. As written, the setup can't be run as stated and leaves unclear which fallback path gets tested. Each of the leaf's two fallbacks needs its own runnable case. How should it be settled? — decision inbox-gate-questions-two-cases, not yet delivered

## Review rounds

- Round 1: 2 findings, 2 confirmed
  - f1 contradiction on inbox-app-gate-scroll: It says 'a failed answer or resume shows a scrollable detail with the error', and the Decision inbox-gate-questions-cheap says submitting works 'as answerGate does today'. But answerGate today (internal/tui/inboxapp/inboxapp.go:300-303) reopens the gate form on the questions not yet answered, with 'answer failed: <err>', so the owner can retry. Only a failed run.resume shows the detail panel. The leaf silently drops that retry path and contradicts its own Decision. Say that a failed answer reopens the form on the remaining questions with the error, and that only a failed resume shows the scrollable detail. — confirmed: answerGate (internal/tui/inboxapp/inboxapp.go:300-303) reopens the gate form on qs[i:] with 'answer failed: <err>' when question.answer fails; only a failed run.resume goes to m.panel. inbox-app-gate-scroll's statement says a failed answer OR resume shows a scrollable detail, which drops the retry path and contradicts its own Decision inbox-gate-questions-cheap ('as answerGate does today').
  - f2 contradiction on inbox-app-gate-scroll: For the fallback that inbox-gate-questions-kept adds (questions with empty statements), the acceptance says the form 'still opens the form by handle'. inbox-app-answer-shows-question says the gate form shows each question's full text, 'never a handle as the label'. And asked() (inboxapp.go:577) would show a blank line for an empty statement. The plan never says what the form shows for an empty-statement question. Showing the handle breaks inbox-app-answer-shows-question, and showing nothing leaves the owner answering blind. Name the fallback text (e.g. say the question's text could not be read, and give the handle only as a reference) and amend or carve the exception out of inbox-app-answer-shows-question. — confirmed: inbox-app-gate-scroll's acceptance has the empty-statement fallback (from inbox-gate-questions-kept) 'still open the form by handle', while the accepted capability inbox-app-answer-shows-question says the gate form shows the full question, 'never a handle as the label'. asked() (inboxapp.go:577-582) returns the empty Statement, so the plan leaves the shown text for that case undefined and its acceptance points to the handle, which contradicts the existing capability.
- Round 2: 1 finding, 1 confirmed
  - f1 contradiction on inbox-app-gate-scroll: The leaf (and Decision inbox-gate-questions-cheap part 4) shows a question whose statement is empty with its handle on a 'ref: <handle>' line in the Inbox app, and its acceptance tests for that line. The constraint owner-surfaces-no-ids says no owner-facing surface (the Rex apps included) shows a node's handle, and inbox-app-answer-shows-question's acceptance requires 'no handle in the view'. The fallback must not show the handle: show 'This question's text could not be read.' alone, or a non-ID reference such as its position or what it blocks. — confirmed: inbox-app-gate-scroll's statement and acceptance (and Decision inbox-gate-questions-cheap part 4) show an empty-statement question's handle on a 'ref: <handle>' line in the Inbox app and test for it. The constraint owner-surfaces-no-ids says no owner-facing surface, the Rex apps included, shows a node's handle; only the CLI keeps handles. inbox-app-answer-shows-question's acceptance also requires 'no handle in the view'. Moving the handle off the label onto a reference line is still showing it, so the plan contradicts the constraint.
- Round 3: 1 finding, 1 confirmed
  - f1 missing-acceptance on inbox-gate-questions-kept: The acceptance check mixes two cases into one setup and does not add up: 'a plan run stopped at its gate on two questions whose worktree does not read (and one whose handle resolves in no planned change set) gets an inbox open item listing both handles'. If the worktree does not read, no handle can resolve, so the second case cannot happen in the same run, and 'both' contradicts the three questions named. A builder cannot tell what the test should set up or assert. Split it into two runnable cases: (a) the worktree does not read, so every stop-detail handle is listed with an empty statement; (b) the worktree reads but one handle resolves in no planned change set, so that handle is listed with an empty statement and the others keep their statements. — confirmed: inbox-gate-questions-kept's acceptance asks for one test where the run worktree does not read and also one handle resolves in no planned change set. In inboxGateQuestions (internal/api/inbox.go:1066-1071), a worktree that does not open returns before any handle is resolved, so both cases cannot happen in one run. It also names three questions but expects 'both handles' listed. As written, the setup can't be run as stated and leaves unclear which fallback path gets tested. Each of the leaf's two fallbacks needs its own runnable case.

## Sessions

- interview, session fa508624-2462-49e9-98cd-01a1b1d9c450: tokens input 52, output 10352, cache creation 69294, cache read 1844030; helper tokens input 0, output 0, cache creation 0, cache read 0
- arbiter, session ef2a3690-572b-485d-8d61-01a1b1dc26ac: tokens input 40, output 7309, cache creation 53964, cache read 1250696; helper tokens input 0, output 0, cache creation 0, cache read 0
- review, session 20e54cff-2776-45f5-920b-01a1b1df509b: tokens input 30, output 4868, cache creation 35233, cache read 815217; helper tokens input 0, output 0, cache creation 0, cache read 0
- critic, session 97b9e5c9-e776-4ef2-ba7f-01a1b1e0fa19: tokens input 10, output 992, cache creation 27061, cache read 228401; helper tokens input 0, output 0, cache creation 0, cache read 0
- revise, session 59f897a0-28d0-4eae-a1b7-01a1b1e1c91b: tokens input 14, output 2694, cache creation 31867, cache read 351429; helper tokens input 0, output 0, cache creation 0, cache read 0
- review, session 0e5b0051-4c72-4e1f-9f8e-01a1b1e3a8de: tokens input 14, output 2307, cache creation 36506, cache read 364683; helper tokens input 0, output 0, cache creation 0, cache read 0
- critic, session 30bfc965-d002-4c8c-af1b-01a1b1e58995: tokens input 10, output 1105, cache creation 28683, cache read 233343; helper tokens input 0, output 0, cache creation 0, cache read 0
- revise, session 64d1d339-a7da-41a1-86e4-01a1b1e6e510: tokens input 16, output 2470, cache creation 28568, cache read 398948; helper tokens input 0, output 0, cache creation 0, cache read 0
- review, session 98cd3fb2-ee75-45f3-9a79-01a1b1e8263e: tokens input 16, output 3565, cache creation 35702, cache read 408148; helper tokens input 0, output 0, cache creation 0, cache read 0
- critic, session 32689a09-5521-4b85-8f1f-01a1b1e944f6: tokens input 14, output 1405, cache creation 27294, cache read 335430; helper tokens input 0, output 0, cache creation 0, cache read 0
- arbiter, session e2e16f7a-91a5-4b14-9013-01a1b1ea109e: tokens input 8, output 1253, cache creation 24424, cache read 127635; helper tokens input 0, output 0, cache creation 0, cache read 0

Totals: tokens input 224, output 38320, cache creation 398596, cache read 6357960; helper tokens input 0, output 0, cache creation 0, cache read 0