Inbox app on the modal shell

    - f5 nit at internal/tui/inboxapp/inboxapp_test.go:90 on inbox-app-pick-list: The loop in TestEnterOpensActionPerKind skips every index (i <= 2 always), so its body is dead code; only the accept case after it runs.
  - round 2 (cycle 2): 1 finding, 0 confirmed
    - f1 minor at cmd/rhiza/testdata/script/run-send-back.txtar:46 on run-send-back: Acceptance says no signoff is journaled; send-back journals a 'changes' signoff (status line 'signoff (visit 1): changes'). No approval is journaled, which is likely the intent, but the wording is not met literally.
- quality (step review/review): passed after 3 cycles
  - cycle 1: failed, check session f8c8572c-92eb-43c4-9aa5-01a1aac46f31 pass (said done), critic session d074ea48-1ce4-4818-bb0a-01a1aacc261d pass (said done)
  - cycle 2: failed, check session 3154db84-17e5-4edf-b947-01a1aad2815c pass (said done), critic session a4ec495c-ca49-4cd6-abc5-01a1aadbef7a pass (said done)
  - cycle 3: passed, check session b7ce18db-75b5-4787-91bc-01a1aaf0b8af pass (said done)
  - round 1 (cycle 1): 4 findings, 1 confirmed
    - f1 major at internal/tui/inboxapp/inboxapp.go:222 on inbox-app-pick-list: Enter on an accept item or an open (gate) item goes to the Open hook, but nothing in production sets Model.Open: cmd/rhiza/tui.go's inboxModel builds the model without it, and only the tests set it. So in the real app, picking an accept or open item does nothing and gives no feedback. The tests pass only because they install their own Open. Either wire these kinds to a real action (accept via change.accept, answering a gate's open questions) or show their detail as the other kinds do. — confirmed: choose() (inboxapp.go:210-227) sends open (gate) and accept items to m.Open, and cmd/rhiza/tui.go's inboxModel (lines 118-130) never sets Open; no non-test code assigns it. In the real app Enter on a gate or accept item returns nil and does nothing, against inbox-app-pick-list's statement (answer for gates, accept for an accept item).
    - f2 minor at internal/tui/inboxapp/inboxapp.go:294 on inbox-app-signoff: When run.send-back fails, sendBack reopens a fresh note form, which throws away the note the owner typed; they must type it again to retry.
    - f3 minor at cmd/rhiza/testdata/script/run-send-back.txtar:154 on run-send-back: The fake claude's findings probe matches only the leaf-scoped header ('The owner requested these changes on leaf thing:'), but a send-back finding has no leaf, so the probe never fires. The script shows that a fixer runs but never shows that the owner's note reaches the fixer's prompt.
    - f4 nit at internal/tui/inboxapp/inboxapp.go:197 on inbox-app-pick-list: Esc on a non-actionable item's detail panel quits the whole app instead of going back to the list (the key handler quits on esc whenever the list is not shown).
  - round 2 (cycle 2): 2 findings, 1 confirmed
    - f1 major at internal/tui/inboxapp/inboxapp.go:278 on inbox-app-pick-list: answerGate sets m.note = "answered; resume failed: ..." and then calls m.show(it), but show() starts with m.note = "" and only sets it again if inbox.open fails. So when run.resume fails after the gate's answers were written, the panel shows the item's plain detail and no error: the owner is not told that the run was not queued. show() also calls inbox.open as a side effect on this path. No test covers a resume failure (TestGateAnswersEachThenResumes covers success only). Fix: build the InfoPanel without clearing the note (or set the note after show), and add a test where the fake runner fails run.resume and the view shows the note. — confirmed: answerGate (inboxapp.go:303-305) sets m.note to the resume failure and then calls m.show(it), whose first line (inboxapp.go:242) resets m.note to ""; it only sets it again if inbox.open fails. So a failed run.resume after the answers were written shows the plain detail with no error, and the owner is not told the run was not queued. No test fails run.resume (the inboxapp tests only cover a resume that succeeds).
    - f2 minor at internal/tui/inboxapp/inboxapp.go:251: When the gate's second question.answer fails, the form reopens with only qs[i:]. The answers already written are not shown again, which is right, but the subtitle doesn't say that the earlier questions were answered, so the owner can't tell that a partial write happened.
  - round 3 (cycle 3): 2 findings, 0 confirmed
    - f1 minor at internal/api/question.go:194 on inbox-app-pick-list: gateAnswerCtx sets c.ChangeRef to the plan change set but leaves c.ChangeSet as the caller gave it; an API caller (not the CLI, which sets only ChangeRef) passing ChangeSet with --run gets 'set either ChangeSet or ChangeRef, not both' from effectiveChangeSet instead of the documented '--change is ignored'. Clearing c.ChangeSet (and c.Record) would match the field's doc.
    - f2 nit at internal/api/question.go:188 on inbox-app-pick-list: The found/gate-stop check relies on || binding looser than && (!found || !A && !B); parentheses would make the intent plain.
- qa (step review/review): passed after 3 cycles
  - cycle 1: failed, check session f41a81b4-e3b7-413c-835b-01a1aac498f4 pass (said done), critic session c95de32a-88c6-4eda-91d4-01a1aacc4d02 pass (said done)
  - cycle 2: failed, check session 3293f9c2-babc-457d-9fac-01a1aad2a73f pass (said done), critic session 7579ba36-dc43-4262-9b83-01a1aadc0fa0 pass (said done)
  - cycle 3: passed, check session f6175daa-775b-4cca-a9f4-01a1aaf0e5cf pass (said done)
  - round 1 (cycle 1): 3 findings, 2 confirmed
    - f1 major at internal/tui/inboxapp/inboxapp.go:352 on inbox-app-answer: Hands-on with the built binary in tmux: on a question item, pressing Enter on an empty answer (or submitting when the send fails, e.g. session.message errors) leaves the answer form frozen: the TextArea's input disappears and typed keys, Enter and shift+tab are ignored; only Esc quits. rexuikit's Form sets status to submitted on Enter and drops every key after (form.go Update: status != FormPending returns), and send() returns nil (empty) or only rewrites the subtitle (line 366) on the same submitted form instead of opening a fresh one as sendBack/openNote does. So an accidental empty Enter, or any send error, means the owner must quit and reopen the app to answer. — confirmed: rexuikit v0.2.0 ui/form.go submit() sets status=FormSubmitted and Update drops every KeyPressMsg once status != FormPending. inboxapp.send() returns nil on an empty answer and on a send error only calls m.form.WithSubtitle on that same submitted form, so the TextArea is dead; only Esc/ctrl+c (caught by Model.Update) quits. sendBack/resolveForm build a fresh form instead, which shows the intended pattern. A failed session.message leaves the owner unable to retry without reopening the app.
    - f2 major at internal/tui/inboxapp/inboxapp.go:222 on inbox-app-pick-list: Hands-on with the built binary: Enter on an accept item (autonomous plan gate, 'waiting for acceptance') and on an open item ('open questions: ...' stop) does nothing at all: no action opens, no tab, no note. choose() opens a form only for question/blocker/signoff/resolve and otherwise calls the Open hook, which cmd/rhiza/tui.go:119 never sets. The leaf says Enter opens the item's action, 'accept for an accept item' and answer for questions; in the shipped binary both kinds are dead rows (the unit tests only pass with a fake Open hook). — confirmed: choose() opens views only for question/blocker, signoff and resolve; accept items (ActionAccept) and open items (InboxOpen, ActionFor gives ActionAnswer but choose only opens the answer form for InboxQuestion/InboxBlocker) fall through to m.Open, and nothing outside the tests sets Model.Open (cmd/rhiza/tui.go inboxModel never assigns it). So in the binary Enter on those rows does nothing, against the leaf statement 'accept for an accept item' and 'answer for questions and gates'.
    - f3 nit at internal/tui/inboxapp/inboxapp.go:198: When the inbox load fails (e.g. getwd error), the app shows only the error line and Esc does not quit; it took ctrl+c.
  - round 2 (cycle 2): 3 findings, 1 confirmed
    - f1 major at internal/tui/inboxapp/inboxapp.go:299 on inbox-app-pick-list: Hands-on with the built binary on a real plan run stopped at its gate (plan-workflow-open fixture): Enter on the open item opens the per-question form, but submitting 'Exports go on the ssd' always fails with 'answer failed: no question "park-disk"'. answerGate calls question.answer with it.Change (the plan run's record change set) and cmd/rhiza/tui.go:119-125 runs it in the main checkout, while gates exist only in the builtin plan workflow and the parked question lives only in the run's worktree, in the planned change set. Even there question.answer refuses it ('not an open question blocking this change set'), since a parked question blocks nothing. So the gate action can never succeed in the shipped app; TestGateAnswersEachThenResumes passes only because the fake runner accepts any call. — confirmed: answerGate calls question.answer with it.Change, the run's record change set, and cmd/rhiza/tui.go:119-125 runs it from the app's checkout. plan-workflow-open.txtar shows the parked question lives in the planned change set inside the run's worktree (repo.plan-reports, --change $WORK/cs), so the main checkout cannot resolve 'park-disk'. Even resolved, runQuestionAnswer with a change set requires questionBlocks (a blocks link to that change set), and a parked question has none, so it refuses. The gate action can never succeed in the shipped app; the unit test passes only through a fake runner.
    - f2 minor at internal/tui/inboxapp/inboxapp.go:462 on inbox-app-answer: After a failed send the reopened answer form is empty: the owner's typed answer is lost and must be retyped.
    - f3 nit at internal/tui/inboxapp/inboxapp.go:272 on inbox-app-pick-list: The gate form labels each field with the question's handle (park-disk), not its statement, so the owner does not see what is asked.
  - round 3 (cycle 3): 1 finding, 0 confirmed
    - f1 nit at internal/tui/inboxapp/inboxapp.go on inbox-app-pick-list: While the gate's answer form is open, the inbox list (filter line and the open row) stays drawn above it, so the form reads as part of the list.
- scope (step review/review): passed after 1 cycle
  - cycle 1: passed, check session 2042e84d-ce74-4748-a808-01a1aac4cc92 pass (said done)
  - round 1 (cycle 1): 1 finding, 0 confirmed
    - f1 minor at .rhiza/rendered/capability/rhiza/inbox-app-actions.md: The intent says the change set retires the capabilities of the old inbox app it replaces (e.g. inbox-app-actions: take the advisor's recommendation, nudge, request-changes via c), but none of its log entries retire a node; the code removes those behaviours (actions_test.go deleted) while the model still claims them. All code changes otherwise stay inside the leaves: internal/tui/inboxapp (pick-list, answer, signoff, retry-abandon), run.send-back in internal/api/run_signoff.go with a small shared changesChecks extraction from run.request-changes, its testscript and the regenerated describe golden.
- model (step review/review): passed after 2 cycles
  - cycle 1: failed, check session 52a17fd4-39eb-4442-b1c7-01a1aac4f520 pass (said done), critic session b36e20a5-82eb-4208-8229-01a1aacc7577 pass (said done)
  - cycle 2: passed, check session 1a68aa3f-799b-4a3c-8cb0-01a1aad2d25b pass (said done)
  - round 1 (cycle 1): 3 findings, 2 confirmed
    - f1 major at internal/tui/inboxapp/inboxapp.go:1: The intent says to retire the capabilities of the old inbox app it replaces, but the change set retires none. inbox-app-list (cursor list grouped by kind, an advisor recommendation per question, reload every few seconds and on r), inbox-app-actions (o opens the tab, t takes the recommendation, y/c approve or ask for changes, R/x) with its child inbox-app-answer-question, and inbox-nudge-stalled (n nudges a stalled session, removed from inboxapp in this diff) are all still live. The model now claims behaviour the rewritten app no longer has, alongside the new inbox-app-* leaves that contradict it. Retire them (or move any surviving parts into the new leaves) in this change set. — confirmed: The intent says the change set retires the old inbox app's capabilities, but its log (.rhiza/log/01M6MYN9GRWHRJSHA31D9S838H/) holds only node.create and link.create ops, with no retire. inbox-app-list, inbox-app-actions, inbox-app-answer-question and inbox-nudge-stalled are still live in .rhiza/rendered and describe keys (r, o, t, y/c, n) and grouped-list behaviour that the rewritten internal/tui/inboxapp/inboxapp.go no longer has.
    - f2 major at cmd/rhiza/tui.go:119 on inbox-app-pick-list: inbox-app-pick-list says Enter opens 'accept for an accept item', but no leaf builds an accept action and nothing wires it in. choose() (internal/tui/inboxapp/inboxapp.go:222) passes ActionAccept to m.Open, and cmd/rhiza/tui.go never sets Open, so in the real app Enter on an accept item does nothing. The same happens for the 'open' question kind: ActionFor maps it to ActionAnswer, but choose() opens the answer form only for question and blocker. So the claim is false for the built binary. Either add a leaf that accepts through the accept operation (and answers 'open' items), or narrow the statement and acceptance to what is built. — confirmed: choose() (internal/tui/inboxapp/inboxapp.go:206-226) opens forms only for question/blocker, signoff and resolve. ActionAccept, and ActionAnswer for the InboxOpen kind, fall through to m.Open, and nothing outside tests sets Open (cmd/rhiza/tui.go:118-130 builds the model without it). So in the built binary Enter on an accept item or an 'open' gate does nothing, which contradicts inbox-app-pick-list's statement that Enter opens accept and gate answers.
    - f3 minor at .rhiza/rendered/capability/rhiza/orchestration/daemon/run-continue-through-daemon.md: Other live capabilities still describe the old app's keys: run-continue-through-daemon names 'the inbox app's retry/resume, approve and request-changes keys', and the new app has no request-changes key (it sends back through run.send-back). Their statements are stale against the rewritten app.
  - round 2 (cycle 2): 3 findings, 0 confirmed
    - f1 minor at internal/tui/inboxapp/inboxapp.go:272 on inbox-app-answer: The gate path (open-kind item) is unmodelled: it opens one TextArea per open question parsed from the stop detail, answers each through question.answer into the run's change set, then queues run.resume and quits. inbox-app-answer covers only questions and blockers with one TextArea, and inbox-app-pick-list only says Enter opens the gate's answer; no leaf states the per-question form or the resume.
    - f2 minor at internal/tui/inboxapp/inboxapp.go:311 on inbox-app-pick-list: The accept action (a Confirm 'Accept this change set?', then accept on the item's change set under the owner rule, closing the app; declining quits with nothing called) is built and tested but no leaf states it; inbox-app-pick-list only says Enter opens 'accept for an accept item'.
    - f3 minor at .rhiza/rendered/capability/rhiza/orchestration/daemon/run-continue-through-daemon.md:11: Still names the inbox app's retry/resume, approve and request-changes keys; the rebuilt app has no keys and sends back through run.send-back instead of request-changes. Carried over from cycle 1 f3.

## Change-set fixes

- cycle 2 (step review/review): fixer session cd9c8766-b5dd-4788-a40f-01a1aad0ee23: pass, commit 433db4955be1 (said done)

## Code checks

- step review/code: pass

## Sign-offs

- signoff (visit 1): approved by rule autonomous

## Sessions

- build/build, session 5d4fe3e0-9886-48b8-a684-01a1aaa06c55: tokens input 24, output 10621, cache creation 65974, cache read 800090; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 19373354-8ef9-4b6e-b433-01a1aaa3d4c0: tokens input 18, output 3682, cache creation 45105, cache read 539795; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session d79e71c7-5e42-4c83-a8e3-01a1aaa40b86: tokens input 20, output 7394, cache creation 44131, cache read 568802; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 7b679c48-f78a-4bf9-a735-01a1aaa64e04: tokens input 26, output 3700, cache creation 39038, cache read 678154; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session a0d77e89-ba8d-449f-9595-01a1aaa691ef: tokens input 20, output 5849, cache creation 44493, cache read 595783; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session b15f6e7a-a43a-4d92-bb63-01a1aaa90fc2: tokens input 32, output 4420, cache creation 38929, cache read 849689; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 8c516de6-b181-430c-a4ab-01a1aaa99cf2: tokens input 24, output 5880, cache creation 44420, cache read 741511; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session bfbdcb88-78af-43a6-9b13-01a1aaaed64d: tokens input 16, output 2739, cache creation 30518, cache read 409970; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session c8d0e210-46c0-4683-bb21-01a1aaaf0bdf: tokens input 50, output 9602, cache creation 57382, cache read 1785805; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 890f797f-4433-4645-9ea7-01a1aabcb4d2: tokens input 30, output 4440, cache creation 38002, cache read 795776; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 2d2db471-b2c6-4d76-bb66-01a1aac44f71: tokens input 32, output 6003, cache creation 55544, cache read 1093930; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session f8c8572c-92eb-43c4-9aa5-01a1aac46f31: tokens input 42, output 8689, cache creation 53380, cache read 1486974; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session f41a81b4-e3b7-413c-835b-01a1aac498f4: tokens input 142, output 26531, cache creation 84399, cache read 6308599; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 2042e84d-ce74-4748-a808-01a1aac4cc92: tokens input 30, output 4977, cache creation 41228, cache read 912112; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 52a17fd4-39eb-4442-b1c7-01a1aac4f520: tokens input 38, output 7972, cache creation 51615, cache read 1223180; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 5d4203ef-fe80-4a4b-9e40-01a1aacbff91: tokens input 12, output 2330, cache creation 29442, cache read 299132; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session d074ea48-1ce4-4818-bb0a-01a1aacc261d: tokens input 14, output 2108, cache creation 26372, cache read 336335; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session c95de32a-88c6-4eda-91d4-01a1aacc4d02: tokens input 20, output 3282, cache creation 31639, cache read 513857; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session b36e20a5-82eb-4208-8229-01a1aacc7577: tokens input 20, output 3273, cache creation 31339, cache read 515979; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session c5cc25d0-0535-4d0e-8178-01a1aacd4880: tokens input 34, output 10017, cache creation 54786, cache read 1141258; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session d74cf4df-2767-470a-916a-01a1aacf15b2: tokens input 20, output 3683, cache creation 35543, cache read 553574; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 13e07b1e-ad0e-4b8c-a109-01a1aacf34a6: tokens input 18, output 3630, cache creation 30015, cache read 462124; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session d362bf4b-75e2-46a6-8618-01a1aacff5eb: tokens input 16, output 2688, cache creation 32833, cache read 421862; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 471f6650-45b2-40b6-8509-01a1aad013b4: tokens input 12, output 1447, cache creation 22849, cache read 279617; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 72088211-10dc-487e-b598-01a1aad0cfc8: tokens input 12, output 1932, cache creation 24869, cache read 285718; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session cd9c8766-b5dd-4788-a40f-01a1aad0ee23: tokens input 20, output 2665, cache creation 34765, cache read 557366; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 668de09b-d235-4901-92a1-01a1aad259b4: tokens input 20, output 3368, cache creation 54644, cache read 648083; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 3154db84-17e5-4edf-b947-01a1aad2815c: tokens input 36, output 5462, cache creation 61265, cache read 1237381; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 3293f9c2-babc-457d-9fac-01a1aad2a73f: tokens input 112, output 22814, cache creation 79723, cache read 4617295; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 1a68aa3f-799b-4a3c-8cb0-01a1aad2d25b: tokens input 22, output 3292, cache creation 48907, cache read 701449; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session a4ec495c-ca49-4cd6-abc5-01a1aadbef7a: tokens input 20, output 2699, cache creation 27487, cache read 493920; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 7579ba36-dc43-4262-9b83-01a1aadc0fa0: tokens input 20, output 3020, cache creation 33017, cache read 521673; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 1a40be51-c76b-4900-838e-01a1aadce6f1: tokens input 56, output 14271, cache creation 67906, cache read 2135337; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session caba7722-1324-465c-9fb5-01a1aadfca5b: tokens input 28, output 5364, cache creation 47292, cache read 887425; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session b7ce18db-75b5-4787-91bc-01a1aaf0b8af: tokens input 20, output 4790, cache creation 50274, cache read 646206; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session f6175daa-775b-4cca-a9f4-01a1aaf0e5cf: tokens input 40, output 7745, cache creation 54313, cache read 1426929; helper tokens input 0, output 0, cache creation 0, cache read 0

Totals: tokens input 1116, output 222379, cache creation 1613438, cache read 37472690; helper tokens input 0, output 0, cache creation 0, cache read 0