A milestone request

rhiza: step pr-green: pass
rhiza: step rebase: entered, visit 1
Rebased cs/a-milestone-request onto origin/main at 2d35aca.
Pushed b11ab4e.
rhiza: step rebase: pass
rhiza: step wait-rebased: entered, visit 1
rhiza: step wait-rebased: pass
rhiza: step rebased-green: entered, visit 1
PR #286 at b11ab4e: 1 check passed
rhiza: step rebased-green: pass
rhiza: step merge: entered, visit 1
Merged PR #286 at b11ab4e as 1af795e.
rhiza: step merge: pass
rhiza: step close-out: entered, visit 1
Removed worktree /home/rhiza/code/rhiza.a-milestone-request.
Rex tab window:01a1a9e8-32ca-75f3-982a-9d9fb4c960b1 was already closed.
Rex tab window:01a1a9ea-40cc-747b-89fa-baa5b7d699cf was already closed.
Rex tab window:01a1a9ed-de65-7629-8bb3-a5a6a0a7743f was already closed.
Rex tab window:01a1a9ef-da35-7412-a2de-738a310ecf2d was already closed.
Rex tab window:01a1a9f0-7a16-7d76-86e2-3e175744db4a was already closed.
Rex tab window:01a1a9f1-9477-765a-bf05-d320fd69b244 was already closed.
Rex tab window:01a1a9f3-9645-7034-8c12-c59cc7ff2fe5 was already closed.
Rex tab window:01a1a9f4-a0f9-7e9a-959d-c321242bae81 was already closed.
Rex tab window:01a1a9f6-2239-7a7b-9eb6-2a43365e6bad was already closed.
Rex tab window:01a1a9f7-9ee6-707c-a43c-0af19f32e9e4 was already closed.
Deleted branch cs/a-milestone-request.
Deleted origin/cs/a-milestone-request.
Updated main in /home/rhiza/code/rhiza.
rhiza: step close-out: pass
rhiza: run 01M6MYFEQA4BMVVMXPXY7J24XQ succeeded
Run 01M6MYFEQA4BMVVMXPXY7J24XQ succeeded

- Workflow: plan
- Change set: 01M6MYFH4QYGSKDATBH509SEJF: A milestone request
- Worktree: /home/rhiza/code/rhiza.a-milestone-request
- Autonomous: yes
- Started: 2026-11-05T04:11:53Z

## Steps

- interview (visit 1): pass, then milestone-check, session a7e31117-48f2-4f83-8965-01a1a9e80a6a: said done and until held
- milestone-check (visit 1): pass, then review: exit 0
- review (visit 1): pass, then critic, session ca69e34b-cf2b-4b03-a7fe-01a1a9edcb08: said done and until held
- critic (visit 1): pass, then check, session 7596f11a-8df2-41fd-88bf-01a1a9efc5cf: said done and until held
- check (visit 1): fail, then revise: exit 1
    rhiza: run review-check: review round 1 of run 01M6MYFEQA4BMVVMXPXY7J24XQ has 1 confirmed finding(s); revise the plan and review it again:
    - f1 missing-acceptance on milestone-interview-waiting-at-launch: The acceptance check cannot be run as written. It names neither its testscript ('new or extending plan-workflow', then 'go test ... -run TestScripts/<that script>') nor its unit test ('the internal/api unit test of the launch report'), so a verifier cannot tell which tests make up the gate. Name the script (e.g. cmd/rhiza/testdata/script/milestone-interview-waiting.txtar) and the Go test (e.g. go test -trimpath ./internal/api -run TestMilestoneInterviewLaunchNotice) the way the sibling leaves do. — confirmed: The leaf's acceptance runs 'TestScripts/<that script>', a placeholder, and 'the internal/api unit test of the launch report', which names no test; the script may be new or plan-workflow.txtar, so nothing can run it as written. The sibling leaves in this change set name their exact script and -run pattern (daemon-milestone-request, 'Inbox|DaemonNotify', Usage).
    next: rhiza run status 01M6MYFEQA4BMVVMXPXY7J24XQ
- revise (visit 1): pass, then review, session 21ed7b87-ca70-4867-852c-01a1a9f061dd: said done and until held
- review (visit 2): pass, then critic, session 0a3c3746-c832-48c2-9031-01a1a9f1792b: said done and until held
- critic (visit 2): pass, then check, session e8378fcf-7183-4ead-a185-01a1a9f37cd6: said done and until held
- check (visit 2): fail, then revise: exit 1
    - f2 contradiction on milestone-request-past-usage-hold: The existing capability usage-hold (under usage-governor) says the daemon 'holds everything it would launch (picks, resumes of interrupted runs, queued starts and continues, plan requests)'. This leaf exempts milestone plan requests from that hold, so usage-hold's statement becomes false for them, and the plan doesn't revise it to name the exception. — confirmed: usage-hold (01M6HJ10G74HCGZ37HH47P4ABP) states the daemon holds 'everything it would launch (..., plan requests)' under a usage-reserve hold; the plan's change set has no op revising it, while milestone-request-past-usage-hold exempts milestone plan requests from that hold. Landing both leaves the usage-hold statement false for milestone requests.
    next: rhiza run status 01M6MYFEQA4BMVVMXPXY7J24XQ
- revise (visit 2): pass, then review, session a7e14ea8-8b9f-4db0-bbdd-01a1a9f48d57: said done and until held
- review (visit 3): pass, then critic, session 99f5b85c-5614-42a5-b398-01a1a9f60e55: said done and until held
- critic (visit 3): pass, then check, session cf435457-70ec-44be-ace6-01a1a9f78df8: 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 26 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 26 checks
- rebased-green (visit 1): pass, then merge: exit 0
- merge (visit 1): pass, then close-out: exit 0
- close-out (visit 1): pass, then end: exit 0

## Accepted in the owner's place

- 2026-11-05T04:29:38Z accepted change set 01M6MYFH4QYGSKDATBH509SEJF (log entry 01M6MZGCGW51BY4PSM5YTFJCBB)

## Questions put to the arbiter

- question-a7e31117-1 (01M6MYM641F6JEE2SKH35DXQGH): When does the daemon start a queued milestone request's plan run? Today every request waits for a free run slot (max runs), oldest first, so a milestone interview can sit behind build runs. / How is the owner told a milestone interview waits on them? Today a notification goes out only when the agent's first AskUserQuestion blocks, which can be minutes after the tab opens, and the inbox lists nothing before that. / Does a usage-reserve hold (the governor holding new launches) also hold a milestone interview's start? — decision milestone-interview-starts-at-once

## Review rounds

- Round 1: 1 finding, 1 confirmed
  - f1 missing-acceptance on milestone-interview-waiting-at-launch: The acceptance check cannot be run as written. It names neither its testscript ('new or extending plan-workflow', then 'go test ... -run TestScripts/<that script>') nor its unit test ('the internal/api unit test of the launch report'), so a verifier cannot tell which tests make up the gate. Name the script (e.g. cmd/rhiza/testdata/script/milestone-interview-waiting.txtar) and the Go test (e.g. go test -trimpath ./internal/api -run TestMilestoneInterviewLaunchNotice) the way the sibling leaves do. — confirmed: The leaf's acceptance runs 'TestScripts/<that script>', a placeholder, and 'the internal/api unit test of the launch report', which names no test; the script may be new or plan-workflow.txtar, so nothing can run it as written. The sibling leaves in this change set name their exact script and -run pattern (daemon-milestone-request, 'Inbox|DaemonNotify', Usage).
- Round 2: 2 findings, 2 confirmed
  - f1 contradiction on milestone-request-starts-at-once: The plan's sibling capability request-queue (under plan-requests, in the model) still says the daemon starts a plan run for the oldest queued request only 'when not paused and a slot is free', and request-slot-kept / queued-start-request-slot-kept keep a slot for any waiting plan request (daemonRequestWaits counts milestone requests too). The new leaf starts the milestone request first and without a slot, so request-queue's statement becomes false for milestone requests. The plan doesn't revise it, and doesn't say whether a waiting milestone request still keeps ship picks and queued starts one slot back (it no longer needs one). — confirmed: request-queue (01M6D4SYDB1P7NX7DGKT0D19HM, a sibling under plan-requests) still states the daemon starts the oldest queued request only 'when not paused and a slot is free'; the plan's change set holds no op on it, and milestone-request-starts-at-once starts a milestone request ahead of older requests and without a slot, so the model would hold two contradictory statements. The code agrees with today's statement: daemonPoll1 runs daemonPlanRequests in the slots left after picks, and daemonRequestWaits (internal/api/daemon.go:546) counts any queued request, milestone included, for request-slot-kept's kept slot, which the plan also leaves unaddressed.
  - f2 contradiction on milestone-request-past-usage-hold: The existing capability usage-hold (under usage-governor) says the daemon 'holds everything it would launch (picks, resumes of interrupted runs, queued starts and continues, plan requests)'. This leaf exempts milestone plan requests from that hold, so usage-hold's statement becomes false for them, and the plan doesn't revise it to name the exception. — confirmed: usage-hold (01M6HJ10G74HCGZ37HH47P4ABP) states the daemon holds 'everything it would launch (..., plan requests)' under a usage-reserve hold; the plan's change set has no op revising it, while milestone-request-past-usage-hold exempts milestone plan requests from that hold. Landing both leaves the usage-hold statement false for milestone requests.
- Round 3: 1 finding, 0 confirmed
  - f1 contradiction on inbox-milestone-interview: The statement says the daemon 'sends one Rex notification' for the interview item, but daemonNotify (internal/api/daemon.go:320) only runs the owner's notify command once per new inbox item through daemonHook (internal/api/daemon_hook.go, RHIZA_INBOX_TITLE=inboxNotice(...)); Rex has no notify API and its notifications come only from a terminal's OSC 7501 status (decision rex-notice-by-program-status, and this change set's own decision milestone-interview-starts-at-once says so). The leaf should say the daemon runs the notify command once for the item (with its notice as RHIZA_INBOX_TITLE), leaving the Rex notification to milestone-interview-waiting-at-launch. — dropped: The code contradicts the finding. daemonNotify (internal/api/daemon.go:313-358) sends one Rex notification for each new waiting inbox item by writing a working report and then a blocked OSC 7501 report (rexReport, with inboxNotice as its text) to the terminal Rex shows the daemon in (ctx.Rex). It also runs the owner's notify command through daemonHook. That matches rex-notice-by-program-status: the notification comes from the daemon program's status, not from a notify API. So 'the daemon sends one Rex notification for it' describes today's mechanism correctly, and the leaf's acceptance ('daemonNotify notifies it once with that text') tests it. A run's own blocked notice next to the daemon's is how the current design already works (see the daemonNotify doc comment), so the two leaves do not contradict each other.

## Sessions

- interview, session a7e31117-48f2-4f83-8965-01a1a9e80a6a: tokens input 56, output 12910, cache creation 71754, cache read 2065032; helper tokens input 0, output 0, cache creation 0, cache read 0
- arbiter, session 91acfcc7-af97-4f8f-bcef-01a1a9ea2df9: tokens input 18, output 3475, cache creation 33150, cache read 452499; helper tokens input 0, output 0, cache creation 0, cache read 0
- review, session ca69e34b-cf2b-4b03-a7fe-01a1a9edcb08: tokens input 26, output 7057, cache creation 48021, cache read 760177; helper tokens input 0, output 0, cache creation 0, cache read 0
- critic, session 7596f11a-8df2-41fd-88bf-01a1a9efc5cf: tokens input 12, output 1129, cache creation 22710, cache read 272264; helper tokens input 0, output 0, cache creation 0, cache read 0
- revise, session 21ed7b87-ca70-4867-852c-01a1a9f061dd: tokens input 20, output 1988, cache creation 25202, cache read 489391; helper tokens input 0, output 0, cache creation 0, cache read 0
- review, session 0a3c3746-c832-48c2-9031-01a1a9f1792b: tokens input 36, output 5973, cache creation 50960, cache read 1115848; helper tokens input 0, output 0, cache creation 0, cache read 0
- critic, session e8378fcf-7183-4ead-a185-01a1a9f37cd6: tokens input 16, output 2042, cache creation 32156, cache read 404299; helper tokens input 0, output 0, cache creation 0, cache read 0
- revise, session a7e14ea8-8b9f-4db0-bbdd-01a1a9f48d57: tokens input 16, output 3259, cache creation 34775, cache read 411676; helper tokens input 0, output 0, cache creation 0, cache read 0
- review, session 99f5b85c-5614-42a5-b398-01a1a9f60e55: tokens input 26, output 5103, cache creation 45390, cache read 782063; helper tokens input 0, output 0, cache creation 0, cache read 0
- critic, session cf435457-70ec-44be-ace6-01a1a9f78df8: tokens input 10, output 1423, cache creation 28555, cache read 232107; helper tokens input 0, output 0, cache creation 0, cache read 0

Totals: tokens input 236, output 44359, cache creation 392673, cache read 6985356; helper tokens input 0, output 0, cache creation 0, cache read 0