Fix Run drivers burn CPU while

PR #298 at 18d7864: 1 check passed
rhiza: step rebased-green: pass
rhiza: step merge: entered, visit 2
Merged PR #298 at 18d7864 as 63cdebd.
rhiza: step merge: pass
rhiza: step close-out: entered, visit 1
Removed worktree /home/rhiza/code/rhiza.fix-run-drivers-burn-cpu-while.
Rex tab window:01a1aae1-1875-7622-b500-1c5c35f8d511 was already closed.
Rex tab window:01a1aae5-834b-7ef7-b11d-ea22f89cd46d was already closed.
Rex tab window:01a1aae7-e5c4-7c55-b32d-1ed4aa09cbb4 was already closed.
Rex tab window:01a1aaeb-264c-75d1-905d-656d4a0e73a7 was already closed.
Rex tab window:01a1aaed-4588-7430-8d23-474c6b273a6c was already closed.
Rex tab window:01a1aaee-db2e-782b-af56-8e084b61166d was already closed.
Rex tab window:01a1aaf0-df4a-7170-8c90-bf4d0d5ccf35 was already closed.
Rex tab window:01a1aaf2-e22e-78c8-bb58-8240f79473e0 was already closed.
Rex tab window:01a1aaf4-02db-7380-b422-81422fb04d6a was already closed.
Rex tab window:01a1aaf6-049a-7f23-bc1e-cdf90f84e8fd was already closed.
Rex tab window:01a1aaf8-0f45-78a0-87d9-21b3ce8189ee was already closed.
Deleted branch cs/fix-run-drivers-burn-cpu-while.
Deleted origin/cs/fix-run-drivers-burn-cpu-while.
Updated main in /home/rhiza/code/rhiza.
rhiza: step close-out: pass
rhiza: run 01M6NE0VS5KQHZ11RD6SNVY871 succeeded
Run 01M6NE0VS5KQHZ11RD6SNVY871 succeeded

- Workflow: plan
- Change set: 01M6NE0XK2H70R52C5JAPWK71M: Fix Run drivers burn CPU while
- Worktree: /home/rhiza/code/rhiza.fix-run-drivers-burn-cpu-while
- Autonomous: yes
- Started: 2026-11-05T08:43:33Z

## Steps

- interview (visit 1): pass, then milestone-check, session a750dc81-b9fe-4c2e-904f-01a1aae0d697: said done and until held
- milestone-check (visit 1): pass, then review: exit 0
- review (visit 1): pass, then critic, session d4a798b5-2cbe-43ff-8036-01a1aaeb087a: said done and until held
- critic (visit 1): pass, then check, session 72c99d35-8143-4109-bb3a-01a1aaed1a2b: said done and until held
- check (visit 1): fail, then revise: exit 1
    next: rhiza run status 01M6NE0VS5KQHZ11RD6SNVY871
- revise (visit 1): pass, then review, session a6f92327-27b3-4002-ae6c-01a1aaeeb72b: said done and until held
- review (visit 2): pass, then critic, session 1f2c0bb8-835e-4c6f-a8fc-01a1aaf0c408: said done and until held
- critic (visit 2): pass, then check, session c98fa7a9-7955-401d-b01b-01a1aaf2c86d: said done and until held
- check (visit 2): fail, then revise: exit 1
    - f3 contradiction on apply-validates-from-index: The statement (and decision model-reads-go-through-the-index) says 'only rhiza check and rhiza render still read the whole log', but internal/api/status.go, inbox.go, change_diff.go, carve.go, notes_show.go and daemon_fold.go also read it through workspace.log()/store.ReadLog, and no leaf of this change set moves them to the index. Either narrow the claim to the commands this change set covers or add leaves for the rest. — confirmed: The statement (and the decision model-reads-go-through-the-index) claims only rhiza check and rhiza render still read the whole log, but internal/api/status.go:122, inbox.go:417, notes_show.go:154, daemon_fold.go:139, carve.go:148 and change_diff.go:90 all call w.log()/ws.log(), and no leaf of this change set moves them to the index. The claim contradicts the code the plan leaves in place; narrow it or add leaves.
    - f4 contradiction on index-catchup-refolds-incrementally: The leaf has no @parent, so it lands as a second root capability beside 'rhiza'; every capability in the model hangs under the single 'rhiza' root. It belongs under fast-reads (01M5SWS1V2VF3MF5R7A78C6JQA, 'from an index kept per worktree and caught up incrementally'), where its two sibling leaves already sit. — confirmed: rhiza show of index-catchup-refolds-incrementally in this change set's view gives an empty path: it has no parent and would land as a second root beside 'rhiza'. Its siblings change-show-ship-check-from-index and apply-validates-from-index sit under rhiza/views/fast-reads, which is where it belongs.
    next: rhiza run status 01M6NE0VS5KQHZ11RD6SNVY871
- revise (visit 2): pass, then review, session 517bcc8f-c94c-4ef1-92dd-01a1aaf3e2dd: said done and until held
- review (visit 3): pass, then critic, session 88d58f10-e705-4965-aba2-01a1aaf5e9f8: said done and until held
- critic (visit 3): pass, then check, session 292acc87-f21d-42f4-925a-01a1aaf7eac2: 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 28 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 24 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 #298's checked head a7e2116; rebase and check again.
- rebase (visit 2): pass, then wait-rebased: exit 0
- wait-rebased (visit 2): pass, then rebased-green: held after 22 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-05T09:09:49Z accepted change set 01M6NE0XK2H70R52C5JAPWK71M (log entry 01M6NFHCDB3HG57VYR595N9G9M)

## Questions put to the arbiter

- question-a750dc81-1 (01M6NEAK07BMQRE64NCYGHYF5Z): Change set 'Fix Run drivers burn CPU while they wait' serves no intent yet. Which intent should it serve? Earlier fix change sets (e.g. Fix Test temp folders leak) served milestone-25, the backlog intent. — decision cpu-drivers-fix-serves-milestone-25
- question-a750dc81-2 (01M6NEFDS6ZHEKC2RFK7QRFPEE): Profiling 'rhiza change show' on this repo (2,539 log entries) shows ~5 s of CPU spent reading the log (each entry decoded and re-canonicalized) and ~1.5 s folding it, every time. Drivers run in-process polls plus a 'rhiza ship check --settled' subprocess every 10 s, and 'rhiza apply' pays the full read per call. How should model reads be made cheap? — decision model-reads-go-through-the-index

## Review rounds

- Round 1: 1 finding, 1 confirmed
  - f1 contradiction on model-reads-go-through-the-index: The decision says the index's 'stored canonical bytes and folded change sets are reused rather than decoded and re-canonicalized again' and that only an unchanged fingerprint is cheap, but internal/index/catchup.go refold() runs foldStored() on every catch-up that reads anything new: it entry.Decode()s every stored entry and runs changeset.FoldLog over the whole log (index.go:55-57 documents this). So any poll after another run, session or agent appends one entry still pays a whole-log decode plus fold, which is the cost the change set's intent measured; with 5-7 live runs writing entries, drivers rarely see an unchanged fingerprint. Also the change_sets table (index.go:347) stores only id/state/kind/intent/open/superseded/terminal, not History or entries, so change show's changeNotes (s.History, entriesOf) and apply's validation cannot 'take the change sets from the index' as it stands. No leaf makes catch-up's refold incremental or stores folded history, so the decision's claim and the leaves' cost goals contradict the code they rely on; a leaf (or the decision's wording) must cover incremental refold / per-change-set fold from index entries (index.EntriesOf exists) and the acceptance must cover a poll after an unrelated entry is appended. — confirmed: Checked against the code. internal/index/catchup.go refold() (line 293) runs foldStored() (line 344) on every catch-up that reads a new entry. foldStored calls the full entry.Decode, which runs canon.Check, not the cheaper DecodeCanonical, on every stored entry, then runs changeset.FoldLog over the whole log. index.go:55-57 documents this. Any poll after another run appends one entry therefore pays a whole-log decode, canonical check and fold, which contradicts the decision's claim that stored canonical bytes and folded change sets are 'reused rather than decoded and re-canonicalized again'. The change_sets table (index.go) and ChangeSetInfo hold only id/state/kind/intent/open/superseded/terminal, with no History, so change show cannot take its change sets from the index as it stands. No leaf makes refold incremental, and no acceptance check covers a poll after an unrelated entry is appended. Both the leaves' zero-log-read checks and the 50 ms budget pass on an unchanged fingerprint.
- Round 2: 4 findings, 4 confirmed
  - f1 missing-acceptance on change-show-ship-check-from-index: The acceptance runs 'go test -trimpath ./cmd/rhiza -run TestReadBudget', but TestReadBudget lives in internal/api/budget_test.go:246; cmd/rhiza has no such test, so that command runs nothing and passes vacuously. The budget part of the check should name 'go test -trimpath ./internal/api -run TestReadBudget' (and the testscripts it relies on by TestScripts/<name>). — confirmed: TestReadBudget is defined only in internal/api/budget_test.go:246; cmd/rhiza has no such test, so 'go test -trimpath ./cmd/rhiza -run TestReadBudget' matches nothing and passes. The acceptance's second command (./internal/api/...) does run TestReadBudget, but the check as written points its budget step at the wrong package and names no testscripts for 'the existing change show and ship testscripts', so it should be corrected to ./internal/api -run TestReadBudget plus TestScripts/<name> filters.
  - f2 missing-acceptance on apply-validates-from-index: The acceptance names no command or package: it describes a counting-reader test, a property test and a budget test but not where they live or how to run them (e.g. 'go test -trimpath ./internal/api/...' for the zero-read and property tests and the -run filter of the budget test), unlike the other three leaves. — confirmed: The acceptance of apply-validates-from-index describes a counting-reader test, a property test and a 200 ms budget test but names no command, package or -run filter, unlike its three sibling leaves; a builder or verifier cannot tell what to run.
  - f3 contradiction on apply-validates-from-index: The statement (and decision model-reads-go-through-the-index) says 'only rhiza check and rhiza render still read the whole log', but internal/api/status.go, inbox.go, change_diff.go, carve.go, notes_show.go and daemon_fold.go also read it through workspace.log()/store.ReadLog, and no leaf of this change set moves them to the index. Either narrow the claim to the commands this change set covers or add leaves for the rest. — confirmed: The statement (and the decision model-reads-go-through-the-index) claims only rhiza check and rhiza render still read the whole log, but internal/api/status.go:122, inbox.go:417, notes_show.go:154, daemon_fold.go:139, carve.go:148 and change_diff.go:90 all call w.log()/ws.log(), and no leaf of this change set moves them to the index. The claim contradicts the code the plan leaves in place; narrow it or add leaves.
  - f4 contradiction on index-catchup-refolds-incrementally: The leaf has no @parent, so it lands as a second root capability beside 'rhiza'; every capability in the model hangs under the single 'rhiza' root. It belongs under fast-reads (01M5SWS1V2VF3MF5R7A78C6JQA, 'from an index kept per worktree and caught up incrementally'), where its two sibling leaves already sit. — confirmed: rhiza show of index-catchup-refolds-incrementally in this change set's view gives an empty path: it has no parent and would land as a second root beside 'rhiza'. Its siblings change-show-ship-check-from-index and apply-validates-from-index sit under rhiza/views/fast-reads, which is where it belongs.
- Round 3: no findings

## Sessions

- interview, session a750dc81-b9fe-4c2e-904f-01a1aae0d697: tokens input 86, output 14540, cache creation 66548, cache read 2994027; helper tokens input 0, output 0, cache creation 0, cache read 0
- arbiter, session b02ed7dc-209a-410e-a43b-01a1aae568e6: tokens input 12, output 1792, cache creation 28043, cache read 234030; helper tokens input 0, output 0, cache creation 0, cache read 0
- arbiter, session deb16192-9594-4caf-b3a1-01a1aae7cd09: tokens input 20, output 3820, cache creation 32744, cache read 466525; helper tokens input 0, output 0, cache creation 0, cache read 0
- review, session d4a798b5-2cbe-43ff-8036-01a1aaeb087a: tokens input 24, output 5695, cache creation 40368, cache read 646457; helper tokens input 0, output 0, cache creation 0, cache read 0
- critic, session 72c99d35-8143-4109-bb3a-01a1aaed1a2b: tokens input 16, output 2307, cache creation 35878, cache read 415933; helper tokens input 0, output 0, cache creation 0, cache read 0
- revise, session a6f92327-27b3-4002-ae6c-01a1aaeeb72b: tokens input 16, output 3836, cache creation 36658, cache read 422104; helper tokens input 0, output 0, cache creation 0, cache read 0
- review, session 1f2c0bb8-835e-4c6f-a8fc-01a1aaf0c408: tokens input 24, output 4619, cache creation 35670, cache read 637684; helper tokens input 0, output 0, cache creation 0, cache read 0
- critic, session c98fa7a9-7955-401d-b01b-01a1aaf2c86d: tokens input 16, output 2364, cache creation 29207, cache read 385458; helper tokens input 0, output 0, cache creation 0, cache read 0
- revise, session 517bcc8f-c94c-4ef1-92dd-01a1aaf3e2dd: tokens input 18, output 3226, cache creation 33615, cache read 462992; helper tokens input 0, output 0, cache creation 0, cache read 0
- review, session 88d58f10-e705-4965-aba2-01a1aaf5e9f8: tokens input 30, output 5247, cache creation 37058, cache read 848535; helper tokens input 0, output 0, cache creation 0, cache read 0
- critic, session 292acc87-f21d-42f4-925a-01a1aaf7eac2: tokens input 12, output 618, cache creation 21229, cache read 272072; helper tokens input 0, output 0, cache creation 0, cache read 0

Totals: tokens input 274, output 48064, cache creation 397018, cache read 7785817; helper tokens input 0, output 0, cache creation 0, cache read 0