Cross-project CLI

## Leaves

- inbox-across-projects (step build/build): passed: attempt 1: verifier passed
  - attempt 1 builder, session 11949226-61b4-4a6d-adcd-01a1b35c075b: pass (said done)
  - attempt 1 verifier, session e025624b-c9f0-4cef-9f26-01a1b3758fe9: pass (Evidence written by the verifier)
- roadmap-across-projects (step build/build): passed: attempt 1: verifier passed
  - attempt 1 builder, session 65504ebc-0d1b-47b4-9322-01a1b375c581: pass (said done)
  - attempt 1 verifier, session 51ab7b84-c2f7-4979-a3d3-01a1b388271e: pass (Evidence written by the verifier)
- health-across-projects (step build/build): passed: attempt 1: verifier passed
  - attempt 1 builder, session f556f3bf-af95-4341-8244-01a1b3885033: pass (said done)
  - attempt 1 verifier, session 3121443a-82af-4301-90ef-01a1b38aab14: pass (Evidence written by the verifier)
- daemon-status-across-projects (step build/build): passed: attempt 1: verifier passed
  - attempt 1 builder, session a032d5f2-03e5-4f2a-8dd3-01a1b38ae01a: pass (said done)
  - attempt 1 verifier, session 29a430a5-6d71-4d99-a3f2-01a1b38f66bf: pass (Evidence written by the verifier)
- inbox-across-projects (step review/review): open
  - attempt 2 fixer in cycle 2, session 047d95fa-aafc-42df-a9f8-01a1b3afb972: pass (said done)
  - attempt 2 verifier in cycle 2, session d6355a26-e9a9-4d9a-8138-01a1b3c79497: pass (Evidence written by the verifier)
- health-across-projects (step review/review): open
  - attempt 2 fixer in cycle 2, session 6f357d65-0f5c-458a-a6d9-01a1b3c7c67f: pass (said done)
  - attempt 2 verifier in cycle 2, session ea498c12-29cc-47f9-8f29-01a1b3d8dc14: pass (Evidence written by the verifier)
- daemon-status-across-projects (step review/review): open
  - attempt 2 fixer in cycle 2, session 58239a55-f27d-4ce1-8acb-01a1b3d905d4: pass (said done)
  - attempt 2 verifier in cycle 2, session 4e4a3ac7-ef0e-4f2b-a55f-01a1b3da6dd0: pass (Evidence written by the verifier)

## Checks

- compliance (step review/review): passed after 2 cycles
  - cycle 1: failed, check session e9eb1773-d934-4f38-864c-01a1b3a6833f pass (said done), critic session 69a84d76-7fca-4c30-847b-01a1b3ae2714 pass (said done)
  - cycle 2: passed, check session 37b7fc12-fad9-42e6-942e-01a1b3e7f004 pass (said done)
  - round 1 (cycle 1): 1 finding, 1 confirmed
    - f1 major at cmd/rhiza/testdata/script/daemon-status-projects.txtar:52 on daemon-status-across-projects: The acceptance requires the testscript to get, at the root, each project's live runs and skip reasons. In the script every project's part has "runs": [] and "skipped": [] (its only start is detached and leaves no live run, and nothing is skipped). The only skip it asserts is the bare project's 'not initialised'. So no per-project live run or change-set skip reason is ever shown under a project's name. The verifier checked skips by hand and never checked live runs. Add a second accepted change set per project that is skipped (for example for no-milestone), plus a live run fixture in each project's state, and assert them under projects[].runs and projects[].skipped. — confirmed: The acceptance names each project's live runs and skip reasons in the root status. daemon-status-projects.txtar asserts per-project last_started (count=2) and the bare project's 'not initialised' skip only. No project has a live run or a skipped change set, and nothing asserts projects[].runs or projects[].skipped. So the copy loops in runDaemonStatus (internal/api/daemon.go, the st.Runs and st.Skips loops into each part) are never exercised. Of the per-project fields, the script only shows last starts.
  - round 2 (cycle 2): no findings
- quality (step review/review): passed after 2 cycles
  - cycle 1: failed, check session 189729f1-38c5-48b6-8f6d-01a1b3a6b533 pass (said done), critic session e89f8543-58f8-41c0-be28-01a1b3ae59ce pass (said done)
  - cycle 2: passed, check session dd6e65b0-e518-4c5e-bb75-01a1b3e81f9f pass (said done)
  - round 1 (cycle 1): 4 findings, 1 confirmed
    - f1 major at internal/api/inbox.go:645 on inbox-across-projects: inboxScopes lacks the 'a root folder that holds a model of its own is read as that one project' rule that runRoadmap (plan.go), runHealth (health.go) and runDaemonStatus (daemon.go) each apply. Reproduced with a scratch binary: a root that is itself an initialised Rhiza repo with rhiza.toml registering alpha; at the root `rhiza inbox --json` lists alpha's question tagged project alpha instead of the root's own (empty) inbox, while roadmap/health/daemon status there read the root's own model. inbox open/approve/request-changes at that root likewise search the registered projects, not its own runs. A regression for that layout (before, inbox at such a root read its own journals) and inconsistent with the three sibling commands; untested in inbox-projects.txtar. — confirmed: inboxScopes (internal/api/inbox.go:625-657) goes to the merged, every-project branch whenever the wd is at the root and in no registered project, with no projectInitialised(ctx.Wd) check. runRoadmap (plan.go:1572-1578), runHealth (health.go:133-139) and runDaemonStatus (daemon.go:1471-1474) all read a root that holds its own model as that one project first. On origin/main runInbox read gitCommonDir(ctx) of the caller unconditionally, so at such a root inbox (and open/approve/request-changes via findInboxItem/inboxScopes at inbox.go:1028) now cover the registered projects instead of the root's own runs: a regression, inconsistent with the siblings, and not covered by inbox-projects.txtar.
    - f2 minor at internal/api/health.go:143 on health-across-projects: health --all outside a Rhiza root is silently dropped (r.All && haveRoot) and reports the one project, while inbox --all and daemon status --all outside a root are usage errors ('--all needs a Rhiza root'). Roadmap needs the fallback because --all also means every change set there; health has no such second meaning.
    - f3 minor at internal/api/daemon.go:1467 on daemon-status-across-projects: With --project or from inside a project, the top-level runs/skips are narrowed to that project but skipped_projects still lists every root-wide project skip, so the one-project view still carries other projects' state.
    - f4 nit at internal/api/inbox.go:89 on inbox-across-projects: Doc comment still says 'InboxRequest takes nothing.' though it now takes --project and --all.
  - round 2 (cycle 2): 1 finding, 0 confirmed
    - f1 minor at internal/api/health.go:150 on health-across-projects: With --project <name> at the root, scopes is that one project but mctx stays the root's context, and healthDaemon(ctx, mctx, false) calls runDaemonStatus at the root, which merges every project; the new loop over s.Projects then counts all projects' runs. Reproduced with health-projects' fixtures (alpha 1 run, beta 2): 'rhiza health --project alpha' at the root reports '3 live runs', while from inside alpha it reports alpha's only. The machine parts also read through the root's context rather than a project checkout there. --project at the root and inside the project should agree (pass the scope's ctx, or DaemonStatusRequest{Project: r.Project}).
- qa (step review/review): passed after 2 cycles
  - cycle 1: failed, check session 8ba077ae-c07d-454a-9c83-01a1b3a6f222 pass (said done), critic session 1b914e40-4ecf-433b-b94d-01a1b3ae91c0 pass (said done)
  - cycle 2: passed, check session fea95113-a32b-45c4-8c7c-01a1b3e85aac pass (said done)
  - round 1 (cycle 1): 3 findings, 1 confirmed
    - f1 major at internal/api/health.go:152 on health-across-projects: At the root, health's machine parts are read through scopes[0] only (the first project by name). On the real root ~/code (nebari, rhiza) rhiza health reports 'daemon running, 0 live runs' while rhiza daemon status at the root lists 2 live runs under rhiza (and health inside ~/code/rhiza says 2). The root daemon's machine-wide part must count every project's live runs; the usage part likewise reads only nebari's daemon state. — confirmed: internal/api/health.go:150-160: at the root mctx = scopes[0].ctx, and healthDaemon(mctx) calls runDaemonStatus(mctx, DaemonStatusRequest{}) from inside that first project, which (daemon.go:1476-1510, unmerged single scope) returns only that project's st.Runs. The root daemon's 'N live runs' summary so omits every other project's runs (0 shown while rhiza has 2), and healthUsage reads only the first project's daemon state. Wrong output for the machine-wide daemon part the leaf says is reported once.
    - f2 minor at internal/api/daemon.go:1413 on daemon-status-across-projects: At the root the human text prints a top-level 'Live runs: none' above the per-project sections, even when a project lists live runs (real root: Project rhiza shows 2). Reads as if nothing runs; omit the top-level line when the status is merged.
    - f3 minor at internal/api/inbox.go:659 on inbox-across-projects: At the root the machine-wide usage-reserve (and disk-low) item is listed once with no project field, while the acceptance says a project field on every item. The untagged machine item is a sensible choice, but it departs from the acceptance as written and no testscript covers a machine-wide item in the merged list.
  - round 2 (cycle 2): 2 findings, 0 confirmed
    - f1 minor at internal/api/health.go:149 on health-across-projects: The machine-wide daemon part depends on how health is scoped. On the real root ~/code, rhiza health --project nebari at the root reports 'running, 2 live runs', but rhiza health run inside ~/code/nebari reports 'running, 0 live runs' for the same root daemon. That daemon is machine-wide and runs 2 (in rhiza). Inside a project under a root, the daemon part should count every project's runs, as it does with --project.
    - f2 minor at internal/api/inbox.go:477 on inbox-across-projects: At the real root, rhiza inbox lists two untagged usage-reserve items with different windows: 54a9b50, reset 05:06 from nebari's daemon state, and 153af18, reset 07:17 from rhiza's. The machine-wide item is meant to appear once, as health does by reading only the root daemon's home project. Without a project field, the owner cannot tell which one is current.
- scope (step review/review): passed after 1 cycle
  - cycle 1: passed, check session acb70a4d-60ee-49a9-ac00-01a1b3a73340 pass (said done)
  - round 1 (cycle 1): no findings
- model (step review/review): passed after 1 cycle
  - cycle 1: passed, check session 8e5f19f9-2016-41ea-9dff-01a1b3a7774c pass (said done)
  - round 1 (cycle 1): 4 findings, 0 confirmed
    - f1 minor at internal/api/inbox.go:477 on inbox-across-projects: The leaf's statement ('each item tagged with its project') and acceptance ('a project field on every item') say every item carries a project, but mergeInbox lists the daemon's machine-wide items (disk-low, usage-reserve) once with no project. That matches usage-hold-reported ('one usage-reserve item'), so the code is right and the leaf's wording needs the exception, as health-across-projects already states it for the machine parts.
    - f2 minor at internal/api/plan.go:754 on roadmap-across-projects: roadmap-paged still says --all only returns every change set, ignoring --limit and --cursor. The code now also widens --all to every registered project under a root, from inside a project too, and the cursor carries the project. roadmap-paged is not amended, and no Decision records that one flag now means both things. Callers that read every change set of one project need the new internal local flag (health, web milestones) to keep the old meaning.
    - f3 minor at internal/api/inbox.go:445: daemon status, health and roadmap read a root folder that holds its own initialised model as that one project (the 'own' check). inboxScopes, which inbox, inbox open/approve/request-changes use, has no such check and merges every project there. The four leaves have identical statements, the code applies them differently, and the model records neither rule.
    - f4 minor at internal/api/health.go:336 on health-across-projects: At the root, the daemon machine part runs healthDaemon through scopes[0], the first project by name, and DaemonStatusRequest{} there scopes the status to that one project. So 'N live runs' counts only that project's runs, but the part is shown once, untagged, as machine-wide. health-command says health reports the daemon's live runs.

## Code checks

- step review/code: pass

## Sign-offs

- signoff (visit 1): approved by rule autonomous

## Sessions

- build/build, session 11949226-61b4-4a6d-adcd-01a1b35c075b: tokens input 52, output 15320, cache creation 71189, cache read 1995584; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session e025624b-c9f0-4cef-9f26-01a1b3758fe9: tokens input 30, output 3650, cache creation 40497, cache read 914619; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 65504ebc-0d1b-47b4-9322-01a1b375c581: tokens input 68, output 20130, cache creation 74958, cache read 2920895; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 51ab7b84-c2f7-4979-a3d3-01a1b388271e: tokens input 44, output 7968, cache creation 44245, cache read 1245383; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session f556f3bf-af95-4341-8244-01a1b3885033: tokens input 22, output 7905, cache creation 57878, cache read 747885; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 3121443a-82af-4301-90ef-01a1b38aab14: tokens input 30, output 4078, cache creation 31958, cache read 818740; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session a032d5f2-03e5-4f2a-8dd3-01a1b38ae01a: tokens input 30, output 9756, cache creation 56434, cache read 985627; helper tokens input 0, output 0, cache creation 0, cache read 0
- build/build, session 29a430a5-6d71-4d99-a3f2-01a1b38f66bf: tokens input 48, output 11943, cache creation 54372, cache read 1628179; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session e9eb1773-d934-4f38-864c-01a1b3a6833f: tokens input 16, output 2498, cache creation 44049, cache read 470043; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 189729f1-38c5-48b6-8f6d-01a1b3a6b533: tokens input 30, output 7352, cache creation 62139, cache read 1106943; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 8ba077ae-c07d-454a-9c83-01a1b3a6f222: tokens input 80, output 22029, cache creation 80348, cache read 3251466; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session acb70a4d-60ee-49a9-ac00-01a1b3a73340: tokens input 12, output 1254, cache creation 35658, cache read 313931; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 8e5f19f9-2016-41ea-9dff-01a1b3a7774c: tokens input 48, output 9224, cache creation 74544, cache read 2027313; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 69a84d76-7fca-4c30-847b-01a1b3ae2714: tokens input 12, output 1768, cache creation 32589, cache read 297058; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session e89f8543-58f8-41c0-be28-01a1b3ae59ce: tokens input 10, output 1691, cache creation 29027, cache read 241211; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 1b914e40-4ecf-433b-b94d-01a1b3ae91c0: tokens input 14, output 3058, cache creation 29020, cache read 344300; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 047d95fa-aafc-42df-a9f8-01a1b3afb972: tokens input 52, output 6593, cache creation 38359, cache read 1417988; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session d6355a26-e9a9-4d9a-8138-01a1b3c79497: tokens input 18, output 2408, cache creation 30028, cache read 471433; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 6f357d65-0f5c-458a-a6d9-01a1b3c7c67f: tokens input 58, output 11111, cache creation 57732, cache read 1998937; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session ea498c12-29cc-47f9-8f29-01a1b3d8dc14: tokens input 36, output 6504, cache creation 38692, cache read 1056400; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 58239a55-f27d-4ce1-8acb-01a1b3d905d4: tokens input 26, output 5301, cache creation 44633, cache read 782244; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 4e4a3ac7-ef0e-4f2b-a55f-01a1b3da6dd0: tokens input 16, output 3219, cache creation 35377, cache read 422710; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session 37b7fc12-fad9-42e6-942e-01a1b3e7f004: tokens input 20, output 2332, cache creation 44458, cache read 623291; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session dd6e65b0-e518-4c5e-bb75-01a1b3e81f9f: tokens input 58, output 8690, cache creation 57218, cache read 1911964; helper tokens input 0, output 0, cache creation 0, cache read 0
- review/review, session fea95113-a32b-45c4-8c7c-01a1b3e85aac: tokens input 32, output 9814, cache creation 49451, cache read 1026959; helper tokens input 0, output 0, cache creation 0, cache read 0

Totals: tokens input 862, output 185596, cache creation 1214853, cache read 29021103; helper tokens input 0, output 0, cache creation 0, cache read 0