Fix The Inbox app's question

  - attempt 2 fixer in cycle 2, session a8903525-57ee-4833-b180-01a1adb1fc28: pass (said done)
  - attempt 2 verifier in cycle 2, session 62f69d10-b826-49e4-a11e-01a1adb39a34: pass (Evidence written by the verifier)
- inbox-notices-by-title (step review/review): open
  - attempt 2 fixer in cycle 2, session fa0d85fd-f67a-40e5-99c2-01a1adb3c325: pass (said done)
  - attempt 2 verifier in cycle 2, session af44f6f9-aabb-4ea6-96a6-01a1adb8c613: pass (Evidence written by the verifier)

## Checks

- compliance (step review/review): passed after 2 cycles
  - cycle 1: failed, check session a76691f0-a7a8-4b16-a655-01a1ad8ca107 pass (said done), critic session e1eb8927-48d8-44bf-83e4-01a1ad97946e pass (said done)
  - cycle 2: passed, check session 49630fa4-9108-40cc-a1bc-01a1adbd0769 pass (said done)
  - round 1 (cycle 1): 3 findings, 2 confirmed
    - f1 major at internal/tui/inboxapp/inboxapp_test.go:572 on inbox-app-answer-shows-question: Acceptance asks for a test that a question's answer form shows its full statement and recommendation above the TextArea. No test does: TestBlockerShowsEveryWordWrapped checks the statement and 'Your answer' but no recommendation and no ordering, and the existing question-kind tests (TestAnswerQuestionSendsSessionMessage etc.) never assert 'Recommended:'. Only the gate form's recommendation is tested. The code (askLines, inboxapp.go:572-578) does render it; the test the acceptance names is missing. — confirmed: The acceptance names a test that a question's answer form shows its full statement and recommendation above the TextArea. No test in inboxapp_test.go checks this for a question or blocker form. 'Recommended:' is asserted only in the gate tests (lines 613, 681). TestBlockerShowsEveryWordWrapped (572) checks the words and 'Your answer', but no recommendation and no order. TestAnswerQuestionSendsSessionMessage checks only 'Your answer'. The verifier checked this with a throwaway test it then deleted, so the test the acceptance asks for is not in the branch.
    - f2 major at internal/api/inbox.go:349 on inbox-app-question-rows: The leaf says a blocker row shows the question's restatement (else its full statement), and inbox-app-answer-shows-question says the form shows the advisor's restatement and recommendation once written. The advisor now runs on leaf-failed and cycle-cap questions (leaves.go:793, cyclecap.go:143) and journals advice with Asker = the question node's ID, but those questions surface as blocker items, and blocker items never read run advice: InboxItem has no restatement field and only question items copy AdviceFor (inbox.go:349). Only gate (open) questions get restatement and recommendation (inbox.go:1066). So for a failed leaf or a cycle-cap question, the owner never sees the advisor's plain-words restatement or recommendation on any surface. — confirmed: Leaf-failed and cycle-cap questions go to the advisor (leaves.go:793, cyclecap.go:143). They are not gate questions: inboxGateQuestions reads only a plan run stopped with run.OpenStop. They reach the owner as blocker items, through the model's blocks link. blockerItems (inbox.go:701-704) builds the item from the statement and never reads st.Advice, and InboxItem has no restatement. Only InboxQuestion (inbox.go:349) and gate questions (inbox.go:1068) carry advice. So the restatement and recommendation the advisor writes for these questions appear on no owner surface. That misses inbox-app-question-rows ('a ... blocker ... row shows the question's restatement') and owner-question-advisor ('rhiza inbox --json then shows them on the question's item'). The advisor testscript covers only a gate question.
    - f3 minor at internal/tui/inboxapp/inboxapp.go:631 on inbox-app-question-rows: The list row is one line: row() joins the detail with strings.Fields, and rexuikit's List truncates Detail (list.go:338). A gate row shows only its first question plus '(+N more)' and never what each one blocks. The full, wrapped text appears only after Enter (form or detail panel), which is what TestGateRowShowsQuestionsAndWhatTheyBlock checks for the blocks. That is a loose reading of 'a gate row shows its questions' text and what each blocks'.
  - round 2 (cycle 2): no findings
- quality (step review/review): passed after 2 cycles
  - cycle 1: failed, check session e0e51b4c-19f6-4778-bcc4-01a1ad8cc34c pass (said done), critic session 1c93e76a-4de1-4960-a43f-01a1ad97cccb pass (said done)
  - cycle 2: passed, check session 54963a96-e26b-4620-9132-01a1adbd387b pass (said done)
  - round 1 (cycle 1): 4 findings, 1 confirmed
    - f1 major at internal/api/inbox.go:704 on owner-question-advisor: The advisor now starts on leaf-failed and review-cycle-cap questions (leaves.go endLeaf, cyclecap.go capped), but its restatement and recommendation reach no surface for them: those runs end failed rather than stopping at the gate with OpenStop, so inboxGateQuestions (the only reader of State.Advice with Restatement) never sees them, and inboxBlockers builds the blocker item from the model alone, with no Recommendation, Reasons or restatement. The owner of a failed leaf still sees only the template text, which is exactly what the intent set out to fix. Only the plan-review gate path is tested end to end (inbox-question-advisor.txtar). Join the run's Advice (Asker = question node ID) onto blocker items (and give InboxItem a restatement field the Inbox app uses in waits/askLines), with a test for a leaf-failed question. — confirmed: Verified: endLeaf (leaves.go) and capped (cyclecap.go) now call adviseQuestion, journalling Advice with Asker = question node ID, but the only reader matching Advice by node ID/handle is inboxGateQuestions (inbox.go:1016), which runs only for runs stopped with run.OpenStop, a stop only a command step's StopExit (the plan gate) produces. Leaf-failed and cycle-cap questions surface as InboxBlocker items from inboxBlockers (inbox.go:644), built from node statements alone with no Recommendation, Reasons or Restatement, so the owner never sees the advisor's plain-language text for them; intent names leaf-failed questions explicitly.
    - f2 minor at internal/api/daemon.go:365: daemonNotify now opens each gate-stopped run's worktree workspace and folds its plan (inboxGateQuestions) on every notify tick, only to read the first question's text for the notice; with several runs parked at gates this is repeated full reads per tick. Consider computing it only when the item is newly hooked (not already in state.Hooked).
    - f3 nit at internal/tui/inboxapp/inboxapp.go:709: questionView.View mutates the form (q.form.Update with a WindowSizeMsg) inside View when no size has arrived yet; size the form in Init/NaturalSize or on the first WindowSizeMsg instead of from a render.
    - f4 nit at internal/tui/inboxapp/inboxapp.go:677: wrap2 does not wrap anything: it appends a separating blank line. A name like withGap would say what it does.
  - round 2 (cycle 2): 2 findings, 0 confirmed
    - f1 nit at internal/api/inbox.go:127: The blocker's Human text prints 'reasons:' whenever there is a recommendation, even when the advisor gave no reasons, leaving an empty 'reasons: ' line; print it only when Reasons is set.
    - f2 nit at internal/tui/inboxapp/inboxapp.go:433 on inbox-app-question-rows: idLike keeps a handle that has no digit, '-', '_' or '.' (e.g. 'leafq'), so text that names such a handle still shows it on an owner surface. It is a deliberate trade-off against cutting prose words, but no test pins the behaviour, and owner-surfaces-no-ids is only partly met for such handles.
- qa (step review/review): passed after 2 cycles
  - cycle 1: failed, check session 4df78838-db7a-43b2-b232-01a1ad8ceb61 pass (said done), critic session 1a3412e8-4d87-41ee-8b65-01a1ad980531 pass (said done)
  - cycle 2: passed, check session 12e7dc02-30fa-47e9-88d1-01a1adbd734f pass (said done)
  - round 1 (cycle 1): 5 findings, 3 confirmed
    - f1 major at internal/tui/inboxapp/inboxapp.go:706 on inbox-app-answer-shows-question: Hands-on with the built binary (rhiza tui app inbox in tmux at 60, 80, 90 and 160 columns): a blocker's answer form shows its 300-char question on one line cut at the pane edge, not wrapped. The questionView is made after the app's WindowSizeMsg, so q.w stays 0 and View() falls back to NaturalSize(), whose width comes from the Form's subtitle (title + the full question), so the text wraps wider than the pane. Resizing the pane after the form opens makes it wrap properly. In a Rex modal sized by NaturalSize the modal would be as wide as the question. The owner still can't read the full question. Fix: give the new view the last known size when it opens (or cap NaturalSize at qvMinWidth instead of the subtitle width), and keep the full question out of the one-line subtitle. — confirmed: Model keeps no window size: openAnswer/answerForm and openGate make a new questionView with w=0, and nothing re-sends a WindowSizeMsg, so View() falls back to NaturalSize, whose width comes from the Form card. The card's subtitle carries title + waits(it), which is the full question, so the text wraps at the subtitle width, not the pane width. This matches what QA saw hands-on. The fix is to remember the last size and apply it to new views, and to keep the full question out of the subtitle.
    - f2 major at internal/tui/inboxapp/inboxapp.go:501 on inbox-app-question-rows: scrub uses strings.ReplaceAll of handles in prose, so a handle that is an ordinary word gets cut out of the question text. With a blocker on capability 'store', the row, answer form and Blocks line showed 'Which disk should hold the … when ...' and 'Blocks: Kept … reachable' (from 'Kept store reachable'). Gate questions' handles (it.Questions[].Handle) are scrubbed the same way, and the root capability's handle is 'rhiza', so any question blocking it loses every 'rhiza' in its text. This damages the full question text the change set is meant to show. Fix: scrub only whole tokens that look like IDs/handles (ULIDs, short IDs, kebab handles at word boundaries), or don't scrub statements and titles written for the owner at all. — confirmed: scrub (inboxapp.go:500) uses strings.ReplaceAll on it.Handle, it.Blocks and every gate question handle, with no word boundaries. A handle that is an ordinary word ('store', or 'rhiza' for the root capability) is cut out of the question text and titles the owner reads, even inside other words ('restore'). That breaks the full-text promise of inbox-app-question-rows and inbox-app-answer-shows-question.
    - f3 major at internal/tui/inboxapp/inboxapp.go:631 on inbox-app-question-rows: The leaf says a question, blocker or gate row shows the question 'wrapped over as many lines as it needs, its change set title and what it blocks by title'. In the built app, every list row is one line truncated with '…' ('Which disk should hold the … when the machin…', 'Where should nightly exports be wri…'), and no row names what it blocks. Only the forms and detail panel show wrapped text. — confirmed: The statement of inbox-app-question-rows says a question, blocker or gate row shows the question 'wrapped over as many lines as it needs, its change set title and what it blocks by title'. row() (inboxapp.go:631) puts waits() through strings.Fields onto one Detail line, which the List truncates, and leaves out what the item blocks. The statement is not met as written. Either the rows or the statement must change.
    - f4 minor at internal/api/daemon.go:383 on inbox-notices-by-title: Not exercised hands-on: notices need a live daemon and notify hook, which QA didn't start here, so only the TestInboxNotice table test was run (passes). No QA evidence written for this leaf.
    - f5 nit at internal/api/run_recommend.go on owner-question-advisor: rhiza run recommend on a template question prints 'Recommended an answer to the question session <question node ID> asked in run ...': there is no session; the asker is a question node.
  - round 2 (cycle 2): no findings
- scope (step review/review): passed after 1 cycle
  - cycle 1: passed, check session 2c436a5e-1491-40e4-8133-01a1ad8d1ad2 pass (said done)
  - round 1 (cycle 1): 1 finding, 0 confirmed
    - f1 nit at internal/api/daemon.go:417 on inbox-notices-by-title: inboxNotice gains new texts for accept and stalled items (they fell to the 'daemon gave up on a run' default before). This is a small behaviour fix next to the leaf, not asked for by it, though it is defensible under its 'one case per inbox kind' acceptance.
- model (step review/review): passed after 2 cycles
  - cycle 1: failed, check session f882f7f9-f66c-4c3e-afbd-01a1ad8d4915 pass (said done), critic session bdf591f7-c36f-4140-8267-01a1ad984758 pass (said done)
  - cycle 2: passed, check session 5aaae45d-1467-46e6-8928-01a1adbdbbbd pass (said done)
  - round 1 (cycle 1): 4 findings, 3 confirmed
    - f1 major at internal/tui/inboxapp/inboxapp.go:631 on inbox-app-question-rows: The leaf's statement says a question, blocker or gate row shows the question wrapped over as many lines as it needs, plus its change set title and what it blocks by title. But row() puts waits() on a single line (strings.Join(strings.Fields(...))) and leaves out what the item blocks. The full wrapped text and the 'Blocks:' line appear only after the item is opened (askLines/detail). Either the statement should say that rows stay one line and the full text with blocks shows once the item is opened, or the rows should do what the statement says. — confirmed: inbox-app-question-rows says a question, blocker or gate row shows the question wrapped over as many lines as it needs and what it blocks by title. row() (inboxapp.go:631) flattens waits() to one line with strings.Fields and never includes blocksOf; the wrapped text and 'Blocks:' appear only in askLines/detail after opening. Statement and code disagree.
    - f2 major at internal/tui/inboxapp/inboxapp.go:543 on inbox-app-question-rows: The existing capability inbox-overlap-items says the inbox app lists each overlap 'naming both change sets and the target'. waits() now shows the fixed text 'two change sets write the same part of the plan', so the app names neither the other change set nor the target, even though the item carries OtherTitle. This change set does not amend inbox-overlap-items, so the model and the code now disagree. Either show OtherTitle (and the target by statement) or change that capability's statement. — confirmed: The diff replaced the overlap waits text 'with <other> · <target> <detail>' with the fixed 'two change sets write the same part of the plan' (inboxapp.go:543-544). The app now names neither the other change set nor the target, though InboxItem carries OtherTitle; inbox-overlap-items still says the app names both change sets and the target, and this change set does not amend it.
    - f3 major at internal/api/daemon.go:378 on inbox-notices-by-title: inbox-notices-by-title and the constraint owner-surfaces-no-ids both say notifications never name a change set by ID. daemonNotify fills titles only from run journals and falls back to it.Change, the full change set ID. An overlap item between in-flight change sets that have no run (the usual case) therefore gets a notice beginning with the first change set's ID. The fold, which daemonNotify already reads for OtherTitle, could give the title instead. Otherwise the statement needs an explicit exception for this fallback. — confirmed: daemonNotify (daemon.go:356-381) builds titles only from run journals and falls back to it.Change; daemonHook (daemon_hook.go:49-51) does the same. Overlap items from fold.overlaps get OtherTitle but no ChangeTitle, and in-flight change sets without runs are not in titles, so the notice starts with a full change set ID, contrary to inbox-notices-by-title and owner-surfaces-no-ids.
    - f4 minor at internal/tui/inboxapp/inboxapp.go:358: The capability inbox-app-signoff still says the sign-off Dialog is 'naming the run'. The run ID was removed from the dialog body to satisfy owner-surfaces-no-ids, so the run is now named only by its change set title in the dialog title. The statement should say it names the run by its change set's title.
  - round 2 (cycle 2): 1 finding, 0 confirmed
    - f1 minor at internal/tui/inboxapp/inboxapp.go:375: Carried from cycle 1 (f4), still open: the capability inbox-app-signoff still says the sign-off Dialog is 'naming the run', but the run ID was removed from the dialog body (owner-surfaces-no-ids), so the dialog names the run only by its change set's title in its title. The statement could say it names the run by its change set's title. The cycle 1 majors are resolved: inbox-app-question-rows now says rows are one line cut to fit and the wrapped text and blocks show once opened; overlap rows name the other change set and the target statement (inbox-overlap-items holds again); daemon notices take a change set's title from the fold and fall back to 'a change set', never the ID; blocker items carry the advisor's restatement and recommendation, as owner-question-advisor and inbox-question-text say.

## Code checks

- step review/code: pass

## Sign-offs

- signoff (visit 1): approved by rule autonomous

## Sessions

- build/build, session b52f0a4f-fcf3-420b-8b40-01a1ad617df9: tokens input 56, output 13323, cache creation 76072, cache read 2269859; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 6038ba9d-666f-43af-8ac5-01a1ad665b87: tokens input 22, output 3938, cache creation 37768, cache read 633925; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 46e88f93-aeee-4ae2-85cc-01a1ad667a76: tokens input 46, output 9929, cache creation 59762, cache read 1627604; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session fc17e941-4197-4bb0-a566-01a1ad74a804: tokens input 26, output 4031, cache creation 44297, cache read 788856; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 0e49d30c-9727-40a8-9fe0-01a1ad74c6f1: tokens input 32, output 14877, cache creation 78145, cache read 1286003; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 5b09a2c5-4de0-40e4-b68f-01a1ad7738ec: tokens input 16, output 3465, cache creation 38585, cache read 452503; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session a7cf2559-df2a-457d-9823-01a1ad7757c8: tokens input 40, output 11031, cache creation 66260, cache read 1488766; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 654cd4ce-832d-4b75-b23a-01a1ad7b5e73: tokens input 38, output 4643, cache creation 43885, cache read 1051591; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 2ef27bc9-11ba-4883-bd1e-01a1ad7b7c85: tokens input 14, output 2381, cache creation 34586, cache read 359545; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session b25460f6-12aa-4ed5-9bfe-01a1ad7c449f: tokens input 18, output 3708, cache creation 35523, cache read 482776; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session ebdece6c-971b-444c-86f2-01a1ad7c712d: tokens input 42, output 5850, cache creation 40617, cache read 1171183; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 0b9e5254-abac-4411-9f4b-01a1ad86a6ba: tokens input 16, output 3167, cache creation 30583, cache read 410894; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session beddc8ec-664a-44c4-969f-01a1ad87fe47: tokens input 32, output 5393, cache creation 39652, cache read 962597; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 67f73741-d77c-403c-8d04-01a1ad8b2ecb: tokens input 16, output 2414, cache creation 31919, cache read 419054; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session a76691f0-a7a8-4b16-a655-01a1ad8ca107: tokens input 32, output 7162, cache creation 65217, cache read 1076577; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session e0e51b4c-19f6-4778-bcc4-01a1ad8cc34c: tokens input 24, output 5913, cache creation 62214, cache read 854425; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 4df78838-db7a-43b2-b232-01a1ad8ceb61: tokens input 52, output 15323, cache creation 63533, cache read 1832141; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 2c436a5e-1491-40e4-8133-01a1ad8d1ad2: tokens input 16, output 2747, cache creation 47666, cache read 460826; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session f882f7f9-f66c-4c3e-afbd-01a1ad8d4915: tokens input 26, output 5138, cache creation 70911, cache read 986060; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session e1eb8927-48d8-44bf-83e4-01a1ad97946e: tokens input 28, output 4945, cache creation 47941, cache read 865948; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 1c93e76a-4de1-4960-a43f-01a1ad97cccb: tokens input 24, output 2831, cache creation 37957, cache read 680969; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 1a3412e8-4d87-41ee-8b65-01a1ad980531: tokens input 14, output 2318, cache creation 36620, cache read 379680; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session bdf591f7-c36f-4140-8267-01a1ad984758: tokens input 20, output 3672, cache creation 35162, cache read 539611; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 00e8113b-55ae-4a7e-aed4-01a1ad996a84: tokens input 62, output 11342, cache creation 69783, cache read 2253522; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 97098653-d748-41c5-b83a-01a1ada95ab8: tokens input 34, output 4143, cache creation 40221, cache read 891056; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session d20d15b8-7f66-40dc-a0d4-01a1ada993f6: tokens input 86, output 15091, cache creation 84079, cache read 3642074; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session ad45ddcc-7912-4fbe-b999-01a1adb1c7a2: tokens input 38, output 5237, cache creation 47723, cache read 1094871; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session a8903525-57ee-4833-b180-01a1adb1fc28: tokens input 28, output 6245, cache creation 39262, cache read 819912; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 62f69d10-b826-49e4-a11e-01a1adb39a34: tokens input 14, output 1975, cache creation 29518, cache read 354233; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session fa0d85fd-f67a-40e5-99c2-01a1adb3c325: tokens input 34, output 5716, cache creation 35587, cache read 962784; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session af44f6f9-aabb-4ea6-96a6-01a1adb8c613: tokens input 18, output 3076, cache creation 37060, cache read 496999; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 49630fa4-9108-40cc-a1bc-01a1adbd0769: tokens input 20, output 2996, cache creation 59177, cache read 667316; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 54963a96-e26b-4620-9132-01a1adbd387b: tokens input 48, output 5749, cache creation 65845, cache read 1677257; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 12e7dc02-30fa-47e9-88d1-01a1adbd734f: tokens input 50, output 12210, cache creation 57075, cache read 1768865; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 5aaae45d-1467-46e6-8928-01a1adbdbbbd: tokens input 28, output 4212, cache creation 52941, cache read 959900; helper tokens input 0, output 0, cache creation 0, cache read 0
- ci-fix, session 072b3b07-0cfc-4026-b1eb-01a1aded29ff: tokens input 34, output 5693, cache creation 42457, cache read 1028502; helper tokens input 0, output 0, cache creation 0, cache read 0

Totals: tokens input 1144, output 221884, cache creation 1785603, cache read 37698684; helper tokens input 0, output 0, cache creation 0, cache read 0