@feigi/fleet-ctl 3.82.13 → 3.82.15

package/agents/fleet-implementer-slow-high.agent.md

@@ -1,6 +1,6 @@
 ---
 name: fleet-implementer-slow-high
-description: A `/skill:run-team` implementer at cell slow-high. Dispatched by the controller in phase 2, never invoked directly; the body is byte-identical across every fleet-implementer-* definition.
+description: A `/skill:run-team` implementer at cell slow-high. Dispatched by the controller at the Pull's dispatch, never invoked directly; the body is byte-identical across every fleet-implementer-* definition.
 model: "@slow:high"
 ---
 

package/agents/fleet-implementer-slow-medium.agent.md

@@ -1,6 +1,6 @@
 ---
 name: fleet-implementer-slow-medium
-description: A `/skill:run-team` implementer at cell slow-medium. Dispatched by the controller in phase 2, never invoked directly; the body is byte-identical across every fleet-implementer-* definition.
+description: A `/skill:run-team` implementer at cell slow-medium. Dispatched by the controller at the Pull's dispatch, never invoked directly; the body is byte-identical across every fleet-implementer-* definition.
 model: "@slow:medium"
 ---
 

package/agents/fleet-implementer-smol-high.agent.md

@@ -1,6 +1,6 @@
 ---
 name: fleet-implementer-smol-high
-description: A `/skill:run-team` implementer at cell smol-high. Dispatched by the controller in phase 2, never invoked directly; the body is byte-identical across every fleet-implementer-* definition.
+description: A `/skill:run-team` implementer at cell smol-high. Dispatched by the controller at the Pull's dispatch, never invoked directly; the body is byte-identical across every fleet-implementer-* definition.
 model: "@smol:high"
 ---
 

package/agents/fleet-implementer-task-high.agent.md

@@ -1,6 +1,6 @@
 ---
 name: fleet-implementer-task-high
-description: A `/skill:run-team` implementer at cell task-high. Dispatched by the controller in phase 2, never invoked directly; the body is byte-identical across every fleet-implementer-* definition.
+description: A `/skill:run-team` implementer at cell task-high. Dispatched by the controller at the Pull's dispatch, never invoked directly; the body is byte-identical across every fleet-implementer-* definition.
 model: "@task:high"
 ---
 

package/agents/fleet-implementer-task-max.agent.md

@@ -1,6 +1,6 @@
 ---
 name: fleet-implementer-task-max
-description: A `/skill:run-team` implementer at cell task-max. Dispatched by the controller in phase 2, never invoked directly; the body is byte-identical across every fleet-implementer-* definition.
+description: A `/skill:run-team` implementer at cell task-max. Dispatched by the controller at the Pull's dispatch, never invoked directly; the body is byte-identical across every fleet-implementer-* definition.
 model: "@task:max"
 ---
 

package/commands/review-and-fix.md

@@ -13,8 +13,9 @@ argument-hint: [pr-number]
 2. Plan the actions. Split explicitly into **apply now** / **defer**. A finding is deferred, never dropped. **Every `suggestion` — the review's `severity`, the plugin's *Suggestions* bucket — arrives unchecked: the review budgets that band 0 refuters, so nothing has looked at it yet.** Checking it is now your job, not nobody's. So split it by SCOPE first, and check it in either scope. Out of the PR's ticket scope → defer and file, but **the claim bar runs first:** a suggestion whose claim is about shape — step 5's worth-a-claim bar, recorded `claimKind: shape` — gets no refuter and goes to the closed `PR #<pr> review: the suggestion band, checked` record, and every other out-of-scope suggestion gets the same refuter an in-scope one does, dispatched the same way, before it is filed. In scope → dispatch one refuter against it, biased to refuse, and hand it this instruction verbatim with one substitution: resolve `<scratch>/pr<N>/<finding>/` in it to an absolute path under your own run root — `mktemp -d` once per round for `<scratch>/pr<N>/fix-XXXXXXXX/`, never bare `pr<N>`, since finding ids restart at 1 each round too — and write that absolute path into the refuter's prompt in its place; a refuter never derives its own path, and tell it your step-3 `testCmd`, which its rules call `<testCmd>`: *Try to REFUTE this finding. Default to refuted=true if uncertain. Verify by RUNNING something — compile it, run the test, apply the mutation. Do not reason your way to agreement. Observe that run synchronously — run the command, wait for it, read its exit code. Never poll a log file for a completion marker: prefer ONE blocking run to a poll loop, and treat its return as permission to look, never as the answer. Reading a log the run has already finished writing is fine; waiting on one is not. If you match a test reporter's own output, accepting both `ℹ` and `#` is necessary but NOT sufficient — strip SGR escapes first as well. node's prefix moves with the node version and with whether stdout is a TTY, and color wraps the whole line so it begins with ESC and no prefix anchor matches at all, which returns empty at exit 0 — indistinguishable from a hung run and from a run of zero tests. For an uncolored baseline use `env -u FORCE_COLOR`; `FORCE_COLOR=` empty still enables color, so it is not a control. State your search scope AND what your pattern would have missed. A grep over one ref does not support a claim about history; a pattern built from the token a diff removed does not support a claim that the category is empty. When your check scores a mutant killed or a test red, run only in your own copy of the tree, and these rules decide it and nothing else: Valid red: a run that completed — the command returned on its own, with no signal and no timeout, deadline or kill having fired — in which the test the claim names is reported failing. An exit ≠ 0 with no failing test is not red, and a different test failing is not red for this claim. A red in the full suite only triggers a narrowed run; it is never evidence on its own. Narrowed run: the Test entrypoint with arguments appended, `<testCmd> <args>`. That appended arguments reach the Test entrypoint is all that is promised about them, so a narrowed run counts only if it reports `tests` > 0 and its output names the claimed test. If no narrowing can be proven, run the full `<testCmd>` and read the named test's own result from its output. Kill: the mutant produced a valid red in a narrowed run, and the same narrowed command, in the same tree with the mutant reverted, ran a valid green with the named test passing — completed, exit 0, `tests` > 0, `cancelled` 0. A completed exit ≠ 0 with the named test not failing is not a kill, and no kill stands without that green run on the unmutated tree. The result is inconclusive, never a kill, when the red does not reproduce in the narrowed run, when the unmutated tree is red too, or when no usable run exists. Evidence line: every kill and every valid red you claim carries one line in the claim's own free-text field: `red: <cmd> → exit N, fail K incl <test>; baseline: <cmd> → exit 0, <test> pass`. A failing-test finding filed off the review's shared run carries the `red:` half alone. This refuter has no abstain: a run that could not decide — neither a valid red nor a valid green — is no kill and no refutation, so name the runs in `reason`, each with its evidence line, and leave `refuted` true, so the suggestion defers on the record instead of applying on a check that decided nothing. A failure injection with no positive control has produced NO result, never a negative one. Before you read an injected fault — an env var, an argv word, a mutant — as having had no effect, prove the injection reached the child: one run whose output differs with it present versus absent, or the child echoing the injected value back. Uncontrolled, the cell is unrun — say so in your verdict instead of reporting a no-effect result. Build such an invocation as an array expanded braced and quoted — `cfg=(SETB=1 BADJ=1); env "${cfg[@]}" sh ./probe.sh` — or inline the assignments literally — `env SETB=1 BADJ=1 sh ./probe.sh`; NEVER from an unquoted scalar — `cfg="SETB=1 BADJ=1"; env $cfg sh ./probe.sh` — which under zsh passes ONE argument, sets a variable literally named `SETB` to `1 BADJ=1`, never sets `BADJ` at all, and still exits 0. `env $cfg[@]` is not the portable spelling either: measured, bash word-splits it into `SETB=1` and `BADJ=1[@]`, so the injection variable is set to a corrupted value, while zsh behaves exactly as with the bare `$cfg` — `BADJ` never set, exit 0. Everything you write — mutants, fixtures, scratch repos — goes under `<scratch>/pr<N>/<finding>/` and nowhere else; the checkout and any worktree are never write targets, though `git show`/`git archive` at a pinned ref read fine anywhere. Chain the directory change into the command, `cd "$D" && git …`, never `cd "$D"; git …`, so a failed `cd` cannot leave a `git` command running in the checkout — and bracket a fixture's own git with `git rev-parse --show-toplevel`: before `git init` it must NOT resolve to the host repository, and `fatal: not a git repository` (exit 128) is the usual pass, not a failure — an outer repository whose ignore rules cover your scratch dir is a pass too; before any `git commit` it must resolve to your scratch path, which catches a forgotten `git init` under any enclosing repository — compare resolved forms (`realpath`), since `--show-toplevel` can report a symlinked parent such as `/tmp` or a symlinked `$HOME` under its resolved name.* That last clause is the whole mechanism — a refuter left to reason its way to agreement rubber-stamps, and "apply only what survives" silently degrades into "apply everything in scope". Apply only what survives; a refuted one defers with the refutation in its body. **Out of scope the refuter decides only where the suggestion is filed — it defers either way, never applied.** Refuted → the closed `PR #<pr> review: the suggestion band, checked` record, never an open issue. Survived, or its refuter crashed or abstained → its own open issue labelled `needs-triage`, citing the verdict, or the run that crashed, in the body. There is no cap on these refuters; your final verdict (step 4) says how many you dispatched against out-of-scope suggestions. "In scope" means the ticket's scope, not merely the same files — and applying one still never licenses editing a file the ticket has no business in. **A finding in `unverified` whose refuters ran and crashed or abstained always defers, whatever its severity** — and which it is, you read off the finding's **`refutersDispatched`** and **`refutersInconclusive`**, never off severity and never off an empty vote list: `refutersDispatched` above zero with nothing decided means every refuter dispatched against it died or abstained, and `refutersInconclusive` counts the ones that abstained. Only a `survived` finding has been checked; severity says how much a finding would matter if true, never whether anything looked. **Deferring a crash is your move, and re-running it is not** — the review already re-dispatched every crashed refuter pair once, in-run, so a crash that reaches you crashed twice, and the result's `resume` field names the one move left, which is not yours: nothing replays a review that ran in a runner's kernel — it is reported, not acted on. So say *in the deferral* that its refuters crashed rather than that it went unchecked, and re-run nothing for it. **An abstention is not a crash** — a refuter that abstained ran and could not decide: defer and file the finding, citing the inconclusive runs each abstaining refuter named in its `reason`, and never describe its refuters as crashed. **A `suggestion` is also in `unverified`, for a different reason — `refutersDispatched` of zero, the 0-refuter budget the workflow gives that band by policy, so nothing looked *there* — and the scope split above, not this rule, covers it.**
    **Write every ruling to `<scratch>/dispositions-<your name>.json`, `<your name>` the `fix-pr-<pr>[-x]` you were dispatched as (standalone, `fix-pr-<pr>`) — the disposition record `dispositions-check.mjs` judges against the review result file before any finisher is dispatched.** It is `{"head": "<the review file's head>", "run": "<the run root's name in the review path>", "entries": [ … ]}` — `run` the `<run>` of the review path your prompt names, which the check holds against the one the PR's latest `reviewed=` names, so a record written against an earlier review of the same PR, a same-head one included, is a mismatch (standalone, with no ledger naming a run, leave it out): one entry per `survived` finding and per `unverified` finding, plus one per `refuted` finding you reverse. Each entry carries `bucket` (`survived|unverified|refuted`), `index` (its position in that bucket of the review file — stable, since a round's file never changes), `scope` (`in|out`), `claimKind` (`behavior|shape`) and `disposition` (`apply|defer`), and where they apply `reason`, `issue` (the number you filed it to or commented on), `verdictPath` (a suggestion's refuter verdict file, in scope and, above the claim bar, out of scope) and `remedyFiles` (the files its remedy names). A `refuted` entry carries `scope`, `claimKind` and `disposition` like every other entry, and a non-empty `reason` holding the evidence that reverses it; a missing or blank `reason` is a mismatch. The check reads scope off the diff before it reads your entry: a finding with no `line`, or on a line `git diff` touches from the PR's merge-base with `origin/main` to the review's `head`, is in scope whatever `scope` says, and only otherwise does the declared one stand. An in-scope `survived` finding deferred passes only with `reason` `false-rationale`, `mutual-exclusion`, `remedy-worse` or `remedy-outside-diff`. `remedy-outside-diff` — the remedy would edit a file the PR's diff does not touch — also needs `remedyFiles` to name at least one file absent from `git diff` from that merge-base to the review's `head`: none named, or every one in that diff, is a mismatch. A `critical` or `important` finding deferred for it goes to a human instead of passing: the script exits 1 with verdict `escalate`, `ledger.mjs dispatch` refuses the PR's finisher, and nothing retries it; a `suggestion` deferred for it passes. Any other reason, none, or a `survived` or `unverified` finding with no entry is a mismatch: the script exits 1 naming each violating entry's bucket, index and rule, and `ledger.mjs dispatch` refuses the PR's finisher. `disposition` has no `dismiss`: an in-scope `survived` finding verified correct, needing no change, is deferred with `reason` `false-rationale` and filed on the closed suggestion-band record — step 5's `PR #<pr> review: the suggestion band, checked`.
 3. **Run `checkCmd` and `testCmd` before you commit**, from the worktree, each copied verbatim — not a runner you picked. `checkCmd` is the Recipe's Check step and `testCmd` is the command your dispatcher handed you; **standalone, with no dispatcher to hand you them, they are the repo's own Check step and Test entrypoint**, read off the repo's Recipe cache (`derive-testcmd.sh <repo> check` prints the first, `derive-testcmd.sh <repo> test` the second). Read them off the repo, never invent one: "not a runner you picked" is what this step forbids, and on the standalone path nothing else defines the referent. With no usable Recipe cache (`derive-testcmd.sh` refuses), run the Recipe derivation step first — dispatch a `task` member, agent `fleet-recipe-deriver`, its prompt naming the main checkout's absolute path as `<repo>` and a scratch directory of its own; it proves all three commands in a throwaway worktree and writes the cache only on proof, and its `RECIPE NOT PROVEN` is a stop, reported with its reason. Never fall back to a runner of your own choosing. `tests 0` is a FAILED run, not a pass: a glob matching nothing still exits 0. **Zero is not the only no-work count.** A run reporting **0 passes with no failures** skipped everything it collected, and a count **materially below the whole suite** means you ran a partial tree — this suite reported `tests 937` when this line was written, so compare what you get against a full run rather than against zero. The number drifts; that is the safe direction, because a stale one produces a loud false red while its absence produces a silent false green. Red, zero-test, or either no-work count → fix it or move the finding to defer; never commit over it. Then commit and push — `~/.fleet/bin/fleet-run push-sync.mjs --branch <branch>`, which pushes the explicit refspec `HEAD:refs/heads/<branch>` and then moves the worktree holding `<branch>` to the pushed SHA, or names why it did not and exits 3 with the push landed: this step also runs from a `--detach` worktree (`run-team/SKILL.md`'s worktree-recreation form), where a bare `git push` exits 128 (`fatal: You are not currently on a branch`), any push whose destination is `HEAD` rather than a full or branch refname (`-u` or not, forced or not) exits 1 (`error: The destination you provided is not a full refname`), and a refspec push alone leaves the claim worktree's `refs/heads/<branch>` at its old tip — and report the test result alongside the SHA. **Then reconcile the PR body with what you actually did.** It merges into the permanent record and nothing downstream re-derives it: your commit messages are yours to fix and usually get fixed, the body is neither. Removing a change, or reversing one, leaves the body asserting work the diff no longer contains. Measured twice in one run — one body kept asserting a calibration its own fix had just deleted as false, another kept claiming a hunk the fix had removed as "this diff owns it" — both caught by a finisher's reading rather than by any rule, and both would otherwise have merged intact. `gh pr edit <pr> --body-file <path>`, and re-read the body against the final diff rather than against your memory of it. **Never `--no-verify` on a commit you push, or on the push itself.** The fleet runs in repos it knows nothing about: it must not assume a pre-commit hook exists, and must never bypass one that does on what reaches the branch — a hook that fails is a finding to report, not an obstacle. Nothing re-reviews what you commit here, so this run is the only gate between your edit and a merge.
+   **Under the fleet, run the two through `recipe-check.mjs`, not one by one:** from the worktree, after `git add` and before the commit, `~/.fleet/bin/fleet-run recipe-check.mjs --member <your name> --testCmd "<testCmd>" --reports <scratch>/reports` — `<your name>` the `fix-pr-<pr>[-x]` you were dispatched as, and `<testCmd>` the whole command you were handed, one quoted argument. It runs the Recipe's Check step, which is `checkCmd`, then `<testCmd>` exactly as handed, against the staged tree, and records both results beside your report. The record is keyed to the tree, so run it again after any content change or rebase — a message-only amend keeps it valid — and the controller refuses an `applied` report whose head's tree has no green record. A non-zero exit is red; exit 75 is no test result — no slot was free and nothing ran — so run it again. **Standalone, with no report to settle against,** run `checkCmd` and `testCmd` yourself, each copied verbatim.
 4. **Under the fleet, do not hold this wait.** The controller owns a persistent CI Monitor and dispatches a finisher once your report has arrived and CI is green — so push, then report to the controller a **final verdict** (every specialist you dispatched + its outcome + your apply/defer adjudication + how many refuters you dispatched against out-of-scope suggestions + the pushed SHA) and stop. A specialist that has not reported to you is not a verdict line — `hub send` it by name for its report, then ask the controller, before ruling; see **Specialists**. The controller keys "review complete" on that verdict, **never on you merely going idle** — a slow specialist can still be running when your turn ends, and finishing off idle-alone ships a premature label (observed: a PR labelled while its contract-test specialist was still running and about to surface a vacuous pin). A turn-based reviewer re-reading `gh pr checks` each idle cycle rebuilds its whole context for nothing the Monitor lacks. **Standalone (no controller): watch** the run until the diff-validating jobs are green (bind via `ci-state.mjs` below); fix a **genuine** failure and repeat from 3. **Staleness is not a failure:** a `rebase-check` red or heavy jobs `skipped` **solely from a non-zero behind-count** never clears by waiting and must not be rebased away here — see **`skipped` is not `passed`** and **Do NOT rebase to label** below for what it looks like and why. Stop watching and go to 6. A turn-based reviewer that "waits for green" on a behind PR stalls forever and ends its turn without labelling. **`ci-state.mjs` returns `verdict: "no-ci"`** → there is no run to watch, so don't: go straight to 6 and let that step's `--declare-no-ci` branch decide.
-5. File each deferred finding: `gh issue create --label needs-triage` with the finding, `file:line`, why deferred, `Deferred from PR #<pr> review`, and **the finding's `dimension` in the issue body** — the review returns it on every finding, and a backlog that does not carry it cannot be attributed to the specialist that generated it. **The body also carries the evidence triage needs: the refuter's verdict — the `verdictPath` reason, or the review's votes — and the candidate remedy.** **Every issue you create is labelled `needs-triage`; only triage sets `ready-for-agent`** — and the label is never omitted; an unlabelled issue is invisible to both `candidates.mjs --require-label` and the cockpit's pool query, reachable only by a human. **A confirmed defect does not settle its remedy**, so confirming one earns it no other label: a confirmed defect with the remedy still open files `needs-triage`, and so does a finding you are unsure is broken at all. **A finding a refuter CHECKED and did not survive is neither** — it is not a confirmed defect, and you are not unsure whether anything is broken: you measured that nothing is. Refutations go as **one issue per review, titled `PR #<pr> review: the suggestion band, checked`, labelled `wontfix`, and CLOSED** — a run that files them open instead has to be corrected afterwards, as one was on 2026-08-27. Left open they read as queued agent work and rot into filing artifacts; a measured triage pass found a quarter of its `needs-triage` backlog was refuted records, bulk-closable by title shape. Closed is still a durable home — `check` reads the tracker at `--state all`, so a future run re-deriving the finding lands on the evidence rather than re-litigating it. Split the band only where an entry is **not** a refutation: a residual the refuter surfaced, or an out-of-scope finding its refuter let survive or never decided, is real deferred work — and real deferred work earns its own open issue only past a second bar. **Worth a claim: a finding whose own claim is that correct code could be shaped better — style, naming, layout, redundancy, a micro-simplification — never gets its own open issue.** **Neither does a gap in a prose guard — a test holding prose to its wording — unless something acts on the guarded text: an agent follows it as an instruction (a skill, a command, an agent definition, a script's header or usage text, `AGENTS.md`), or a program other than its own guard reads it.** Whether anything does is your judgement, as `claimKind` is, and a gap below this bar is recorded `claimKind: shape`. A gap in a guard's own code — a slow pattern, a dead branch, an unchecked spawn result — takes the stakes of the prose it guards, and a helper several guards share takes the highest of theirs. A missed wording already in the tree is no guard gap — that prose is wrong — and neither is an input already in the tree that trips a guard's code; each files on its own merits. Once the prose is corrected, the observed wording may join the guard's literal ban, never a reader built to catch wordings nobody has written. A below-bar finding's only open question is "is this worth doing?", which answers itself under the repriced triage bar: measured 2026-08-15→31, 133 issues were triage-closed `wontfix` in sixteen days, 121 of them review deferrals, mostly this shape. Append it to the same closed record issue under a `Below the claim bar` heading — `file:line`, dimension, the claim, and a re-open trigger per entry. Closed is a durable home for these too: `check` reads `--state all`, so a run re-deriving the finding lands on the record instead of re-filing — and a later review returning the same finding as `survived`, or a maintainer hitting it, is the promotion signal: file it open then, citing the record. **An in-scope rediscovery step 2 applied is that same promotion signal, and it files nothing** — so the record carries no mark unless you write one: run `check` over each finding step 2 applied as well, and where its tracker rows put one on a `Below the claim bar` entry, comment on that record issue, opening `Promoted — applied, not filed`, and name the entry, that its refuter let it through, and the commit carrying the fix. That comment is the promotion mark this path leaves, and it is **not** a cross-reference — measured on this tracker, a comment mints `cross-referenced` on the issue its own text *names*, never on the issue it sits under (a comment citing a second issue landed on that issue's timeline and nowhere else), so the fixed opening is what carries the signal instead. **The bar reads the finding's claim, never its review band** — a finding that alleges wrong behavior, whatever band it sat in, `unverified`-with-crashed-refuters included, is above this bar and files open, `needs-triage`, which is why a band cannot carry this decision. Do **not** reach for phase 0's **decided?** test here. That is a *consumption* gate, and whether a filed issue is decided enough to reach it is triage's call, never the filer's. **The cost of this rule is watched:** open `needs-triage` issues citing `Deferred from PR` above 40 on 3 consecutive run dates send the filing rule back to the maintainer — batch triage, a fleet triage role, or a different bar. **Dedupe through `~/.fleet/bin/fleet-run ledger.mjs check "<subject>"`, never a bare `gh issue list --search`** — the duplicate class that guard exists to catch was filed from *here*: the ledger row for the finding rediscovered five times in one measured run carries a reviewer's own source tag, `(review-pr-108)`. `check` reads this run's filed list *and* the tracker at `--state all`, so a closed duplicate still counts. Exit **1** is already filed in this run; exit **3** is a clean ledger with matching tracker rows that score against the subject — read the ones it prints and comment on the existing follow-up rather than filing a second issue. **Exit 0 is not automatically "safe to file"**: it covers `clean`, `soft-hit` and `unverified` alike, and an unreachable `gh` degrades to a ledger-only answer that says `TRACKER NOT CHECKED`, so read the stdout `verdict` to tell a tracker that was searched and clean from one nobody read — under `unverified`, search it yourself before filing — or, for the applied-promotion comment above, before treating a tracker nobody could read as a reason to skip it. **`soft-hit` is the answer that costs most to misread**: it means related rows were found and none of them was established as a duplicate — a near-miss above the floor, or tracker rows the scorer rates 0.00 — so read the rows it printed and decide, and never treat that exit 0 as permission. Exit **2** is a usage error, meaning nothing was checked at all: fix the invocation and re-run, never read it as a duplicate. Full exit-code and `verdict` semantics live in `$(~/.fleet/bin/fleet-run --root)/skills/run-team/references/ledger.md`, which `SKILL.md`'s **Run ledger** section points at — read them there rather than restating them here. **The guard dedupes, it never drops:** a duplicate becomes a comment on the issue that already covers it, never a dropped finding. **Record every issue you create, at once:** immediately after each `gh issue create`, run `~/.fleet/bin/fleet-run ledger.mjs filed <N> "<subject>"` — `<N>` the number `gh issue create` printed, and **the same subject string you passed to `check`**, so the next `check` for that finding meets it in the filed list instead of scoring a rewording. Without it the guard's ledger half never holds a row, and its exit **1** can never fire. If `filed` fails, retry it once; if it fails again, leave the issue alone — it exists and is correct — and report it as `unrecorded: #N <subject>`, so the controller runs `filed` for it. Report `filed: #N <subject>` for every issue you created — under the fleet, in your report to the controller. **The one window the guard cannot see:** `check` → `gh issue create` → `filed` is three commands, and the ledger's lock covers each alone, so two filers can both read `clean` in the seconds before either records. That gap is accepted, never a reason to skip `filed`. Post the numbers as one PR comment.
+5. File each deferred finding: `gh issue create --label needs-triage` with the finding, `file:line`, why deferred, `Deferred from PR #<pr> review`, and **the finding's `dimension` in the issue body** — the review returns it on every finding, and a backlog that does not carry it cannot be attributed to the specialist that generated it. **The body also carries the evidence triage needs: the refuter's verdict — the `verdictPath` reason, or the review's votes — and the candidate remedy.** **Every issue you create is labelled `needs-triage`; only triage sets `ready-for-agent`** — and the label is never omitted; an unlabelled issue is invisible to both `candidates.mjs --require-label` and the cockpit's pool query, reachable only by a human. **A confirmed defect does not settle its remedy**, so confirming one earns it no other label: a confirmed defect with the remedy still open files `needs-triage`, and so does a finding you are unsure is broken at all. **A finding a refuter CHECKED and did not survive is neither** — it is not a confirmed defect, and you are not unsure whether anything is broken: you measured that nothing is. Refutations go as **one issue per review, titled `PR #<pr> review: the suggestion band, checked`, labelled `wontfix`, and CLOSED** — a run that files them open instead has to be corrected afterwards, as one was on 2026-08-27. Left open they read as queued agent work and rot into filing artifacts; a measured triage pass found a quarter of its `needs-triage` backlog was refuted records, bulk-closable by title shape. Closed is still a durable home — `check` reads the tracker at `--state all`, so a future run re-deriving the finding lands on the evidence rather than re-litigating it. Split the band only where an entry is **not** a refutation: a residual the refuter surfaced, or an out-of-scope finding its refuter let survive or never decided, is real deferred work — and real deferred work earns its own open issue only past a second bar. **Worth a claim: a finding whose own claim is that correct code could be shaped better — style, naming, layout, redundancy, a micro-simplification — never gets its own open issue.** **Neither does a gap in a prose guard — a test holding prose to its wording — unless something acts on the guarded text: an agent follows it as an instruction (a skill, a command, an agent definition, a script's header or usage text, `AGENTS.md`), or a program other than its own guard reads it.** Whether anything does is your judgement, as `claimKind` is, and a gap below this bar is recorded `claimKind: shape`. A gap in a guard's own code — a slow pattern, a dead branch, an unchecked spawn result — takes the stakes of the prose it guards, and a helper several guards share takes the highest of theirs. A missed wording already in the tree is no guard gap — that prose is wrong — and neither is an input already in the tree that trips a guard's code; each files on its own merits. Once the prose is corrected, the observed wording may join the guard's literal ban, never a reader built to catch wordings nobody has written. A below-bar finding's only open question is "is this worth doing?", which answers itself under the repriced triage bar: measured 2026-08-15→31, 133 issues were triage-closed `wontfix` in sixteen days, 121 of them review deferrals, mostly this shape. Append it to the same closed record issue under a `Below the claim bar` heading — `file:line`, dimension, the claim, and a re-open trigger per entry. Closed is a durable home for these too: `check` reads `--state all`, so a run re-deriving the finding lands on the record instead of re-filing — and a later review returning the same finding as `survived`, or a maintainer hitting it, is the promotion signal: file it open then, citing the record. **An in-scope rediscovery step 2 applied is that same promotion signal, and it files nothing** — so the record carries no mark unless you write one: run `check` over each finding step 2 applied as well, and where its tracker rows put one on a `Below the claim bar` entry, comment on that record issue, opening `Promoted — applied, not filed`, and name the entry, that its refuter let it through, and the commit carrying the fix. That comment is the promotion mark this path leaves, and it is **not** a cross-reference — measured on this tracker, a comment mints `cross-referenced` on the issue its own text *names*, never on the issue it sits under (a comment citing a second issue landed on that issue's timeline and nowhere else), so the fixed opening is what carries the signal instead. **The bar reads the finding's claim, never its review band** — a finding that alleges wrong behavior, whatever band it sat in, `unverified`-with-crashed-refuters included, is above this bar and files open, `needs-triage`, which is why a band cannot carry this decision. Do **not** reach for phase 0's **decided?** test here. That is a *consumption* gate, and whether a filed issue is decided enough to reach it is triage's call, never the filer's. **The cost of this rule is watched:** open `needs-triage` issues citing `Deferred from PR` above 40 on 3 consecutive run dates send the filing rule back to the maintainer — batch triage, a fleet triage role, or a different bar. **Dedupe through `~/.fleet/bin/fleet-run ledger.mjs check "<subject>"`, never a bare `gh issue list --search`** — the duplicate class that guard exists to catch was filed from *here*: the ledger row for the finding rediscovered five times in one measured run carries a reviewer's own source tag, `(review-pr-108)`. `check` reads this run's filed list *and* the tracker at `--state all`, so a closed duplicate still counts. Exit **1** is already filed in this run; exit **3** is a clean ledger with matching tracker rows that score against the subject — read the ones it prints and comment on the existing follow-up rather than filing a second issue. **Exit 0 is not automatically "safe to file"**: it covers `clean`, `soft-hit` and `unverified` alike, and an unreachable `gh` degrades to a ledger-only answer that says `TRACKER NOT CHECKED`, so read the stdout `verdict` to tell a tracker that was searched and clean from one nobody read — under `unverified`, search it yourself before filing — or, for the applied-promotion comment above, before treating a tracker nobody could read as a reason to skip it. **`soft-hit` is the answer that costs most to misread**: it means related rows were found and none of them was established as a duplicate — a near-miss above the floor, or tracker rows the scorer rates 0.00 — so read the rows it printed and decide, and never treat that exit 0 as permission. Exit **2** is a usage error, meaning nothing was checked at all: fix the invocation and re-run, never read it as a duplicate. Full exit-code and `verdict` semantics live in `$(~/.fleet/bin/fleet-run --root)/skills/run-team/references/ledger.md`, which `SKILL.md`'s wake section points at — read them there rather than restating them here. **The guard dedupes, it never drops:** a duplicate becomes a comment on the issue that already covers it, never a dropped finding. **Record every issue you create, at once:** immediately after each `gh issue create`, run `~/.fleet/bin/fleet-run ledger.mjs filed <N> "<subject>"` — `<N>` the number `gh issue create` printed, and **the same subject string you passed to `check`**, so the next `check` for that finding meets it in the filed list instead of scoring a rewording. Without it the guard's ledger half never holds a row, and its exit **1** can never fire. If `filed` fails, retry it once; if it fails again, leave the issue alone — it exists and is correct — and report it as `unrecorded: #N <subject>`, so the controller runs `filed` for it. Report `filed: #N <subject>` for every issue you created — under the fleet, in your report to the controller. **The one window the guard cannot see:** `check` → `gh issue create` → `filed` is three commands, and the ledger's lock covers each alone, so two filers can both read `clean` in the seconds before either records. That gap is accepted, never a reason to skip `filed`. Post the numbers as one PR comment.
    **A duplicate that should hold an open deferral is a comment, never a relabel.** Where the guard lands a finding whose home is an open issue on an existing one that is open, cite the refuters' verdict — or the review's votes — in the comment you leave there, and change no label. Never relabel `ready-for-agent` down to `needs-triage`: a `ready-for-agent` issue already holds a `needs-triage` finding, because triage already promoted it, and a later run's crashed refuters are no reason to send it back. A closed one cannot hold it: file a new open issue citing it, as the promotion rule above does for the closed record.
    **Name where each deferral went, in the disposition record.** Every entry you defer carries `issue`: the number of the issue you filed it to, commented it onto, or appended it to — the closed `PR #<pr> review: the suggestion band, checked` record included. A `suggestion`'s entry — an `unverified` finding with `refutersDispatched` of zero — also carries `verdictPath`, applied or deferred, in scope and, above the claim bar, out of scope: the absolute path of a file holding its refuter's verdict as JSON, `{"refuted": <boolean>, "reason": "<string>"}`, under your own `<scratch>/pr<N>/fix-XXXXXXXX/<finding>/` run root. An out-of-scope one whose refuter crashed before any verdict reached you still names the path its verdict would have taken there; out of scope, that file missing or holding no decision files the finding open `needs-triage`, while in scope it is a mismatch. `dispositions-check.mjs` reads each named issue back through `gh issue view --json labels,state,title` and each verdict file off disk; a mismatch names the row of its filing table the entry broke, so move or relabel that filing to the home the row names and run the check again. With `gh` unreachable, or an issue it cannot read, that filing goes unchecked: with nothing else broken the verdict is `unchecked` — never `ok`, and it exits 1 — so run the check again once `gh` answers.
 6. Diff-check green (run-bound per `ci-state.mjs`; under staleness see **`skipped` is not `passed`** for what the label then rests on) **and** deferrals filed **and** the PR carrying exactly one release label (`patch`/`minor`/`major`, counting only those three; **required on every PR** — `release-label.yml` auto-adds `patch` when none is present and hard-fails on more than one, so this never needs to check whether the repo defines the gate at all, and `gh label list` settles nothing here any more) **and** `dispositions-check.mjs --member fix-pr-<pr> --scratch <scratch>` run over your own record exiting 0 (standalone that is yours to run, from the worktree, after step 2 writes `<scratch>/dispositions-fix-pr-<pr>.json`; `--review <path>` names the review file, which you write yourself from the findings step 1 collected, in the shape **The review result file** describes — `pr`, `head`, `snapshot`, `counts` and the `survived`, `refuted` and `unverified` buckets; standalone you pass `--no-ledger` with it, so it writes no token and the exit status is the verdict — a `.fleet/ledger.md` the repository already holds is a previous run's, and without the flag it exits 2 for a ledger with no row for you; under the fleet `ledger.mjs dispatch` has already refused a finisher without it) → `gh pr comment <pr> --body "ready-to-merge-head: <prHead>"`, `prHead` being the full SHA your green `ci-state.mjs` reading reported, which the merge bot reads as the head the label was applied to, then `gh pr edit <pr> --add-label ready-to-merge`. Do not merge. A non-zero dispositions exit halts you before the label, and you report the violations it printed. Zero or more than one release label halts you before the label, naming which you found — a timed-out `gh pr create` opens the PR with its `--label` unapplied and no exit status to react to, and nothing after this step re-derives the release label. **Under the fleet a finisher does this** — a fresh small agent the controller dispatches (after your final verdict, never on your bare idle). Gate it on the diff-validating **`check`** job, **not** on `ci-state --quiet` exit 0, which a behind PR — the normal case once any sibling merges — never reaches: a `rebase-check` red or heavy jobs `skipped` off the behind-count hold it short of full green, so an exit-0 gate strands every behind PR unlabelled. Label when `check` is present and green **and no heavy job (the diff-validating suites — *not* the `rebase-check` currency gate) is in `failure`** — a `skipped` heavy job is behind-count staleness and fine — **solely** off that count, which is a condition to establish rather than infer, see the five-condition note in `$(~/.fleet/bin/fleet-run --root)/skills/run-team/SKILL.md`'s fix-applier prompt block. A `failure` is the diff's own fault and blocks the label, else a genuinely broken PR gets labelled off a green `check` and burns a merge-bot rebase+CI cycle before the failure resurfaces. Read per-job state for this: run `ci-state.mjs` **without** `--quiet`, or read its `jobs` — the `--quiet` payload drops the per-job `jobs`/`missing` and the `dropped` list, keeping `reasons` (which still distinguishes `is failure` from `is skipped`). You reach step 6 yourself only when green is already in hand at push time.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@feigi/fleet-ctl",
-  "version": "3.82.13",
+  "version": "3.82.15",
   "description": "Agent fleet: run-team controller, merge bot, PR reviewer, and the ticket pipeline they share",
   "license": "Apache-2.0",
   "repository": {

package/scripts/ledger.mjs

@@ -56,7 +56,7 @@ import { deriveRun, LedgerError, labelOffMember, HELD, CONFLICT_HOLD } from "./f
 import { stateFileIn, readState, writeState, assessBeat, stallsAt } from "./fleet-state.mjs";
 import { processSource, ancestry, controllerOf, judgeController, ProcUnreadable } from "./proc.mjs";
 import { attemptLock, releaseLockFile, reapPathOf } from "./pid-lock.mjs";
-import { readReportIn, reportsDir, reportFamily, defaultScratch } from "./report-files.mjs";
+import { readCheckRecordIn, readReportIn, reportsDir, reportFamily, defaultScratch } from "./report-files.mjs";
 
 const NAME = "ledger";
 // The plugin's own agent definitions — the directory tier-check.mjs reads
@@ -2250,9 +2250,12 @@ function recordFiled(id, subject) {
 // checked before anything is written:
 //
 //   impl-N=PR#M               verify-sha.sh <branch> <head> exits 0; PR M
-//                             reads OPEN and its closingIssuesReferences name N
+//                             reads OPEN and its closingIssuesReferences name N;
+//                             the Check-step record (below) holds for <head>
 //   impl-N=bailed             bailCause is not null; the receipt names it
-//   fix-pr-M=applied:<head>   origin's refs/heads/<branch> is <head>
+//   fix-pr-M=applied:<head>   origin's refs/heads/<branch> is <head>, fetched
+//                             by verify-sha.sh; the Check-step record (below)
+//                             holds for <head>
 //   fix-pr-M=no-op            origin's refs/heads/<branch> is the head PR M's
 //                             latest reviewed= names, as the tick folds it
 //   finisher-pr-M=labelled    PR M's labels carry ready-to-merge, and so does
@@ -2261,6 +2264,16 @@ function recordFiled(id, subject) {
 //                             evidence is not empty
 //   merge-bot-n=done          every merged[].pr reads MERGED
 //
+// THE CHECK-STEP RECORD, for `impl-N=PR#M` and `fix-pr-M=applied:<head>`:
+// recipe-check.mjs writes `<reports>/<member>.check.json` on the member's
+// staged tree, and settle requires that it exists and parses, that the Check
+// step and the Test entrypoint both exited 0 in it, and that its `tree` is
+// `<head>^{tree}`, so a message-only amend keeps it valid while any content
+// change or rebase does not. Settle runs neither command: the record is the
+// member's word, at the trust level of its report. A repository whose Recipe
+// cache derive-testcmd.sh refuses has no gate. A `<head>^{tree}` git cannot
+// read is "could not look", never a tree mismatch.
+//
 // A `failed` report claims no state, so it settles `=failed` unchecked. A
 // fix-applier's `refuted` deferral claims one more thing: that its disposition
 // record gives the reversal a reason, which is the text `## Ruled` gets.
@@ -2298,6 +2311,7 @@ function mismatch(msg) {
 async function runSettleFromReport() {
   const usage = "usage: ledger.mjs settle <member> --from-report [--reports <dir>]";
   const verifySha = join(dirname(fileURLToPath(import.meta.url)), "verify-sha.sh");
+  const deriveTestcmd = join(dirname(fileURLToPath(import.meta.url)), "derive-testcmd.sh");
   const ready = "ready-to-merge";
   // The bound on each child a check runs: generous, because verify-sha.sh
   // fetches, and still a bound, because the child may never answer at all.
@@ -2370,6 +2384,7 @@ async function runSettleFromReport() {
     }
     return r;
   };
+  const verifyShaOf = (branch, sha) => look(`verify-sha.sh ${branch} ${sha}`, "sh", [verifySha, branch, sha], [0, 1]);
   // A `gh pr view --json <fields>` answer: an object whose every requested
   // field has the type that field has. Anything else was not what was asked
   // for, so it could not look.
@@ -2405,6 +2420,32 @@ async function runSettleFromReport() {
     checks.push({ name, ok });
     return ok;
   };
+  // The Recipe gate, for the two reports that name a pushed head: the member's
+  // Check-step record must show the Recipe's Check step and the Test
+  // entrypoint both exited 0 against the very tree `head` holds. Nothing here
+  // runs either command — the record is the member's word, at the trust level
+  // of its report. A repository whose Recipe cache derive-testcmd.sh refuses
+  // (exit 1: absent, unproven, invalid) has no Check step to have run, so no
+  // gate applies; any other answer from it could not look. `head`'s commit
+  // object must be local when the tree is read: `fetchHead`, when given, puts
+  // it there, and runs only once a gate applies.
+  const recipeGate = (head, fetchHead) => {
+    for (const field of ["check", "test"]) {
+      if (look(`derive-testcmd.sh . ${field}`, "sh", [deriveTestcmd, repoDir(), field], [0, 1]).status === 1) return;
+    }
+    const rec = readCheckRecordIn(reports, member);
+    const label = rec.state === "absent" ? `a Check-step record exists at ${rec.path}`
+      : rec.state === "ok" ? `Check-step record ${rec.path} exists and parses`
+      : `Check-step record ${rec.path} parses: ${rec.violation}`;
+    if (!check(label, rec.state === "ok")) return;
+    const { check: step, test, tree } = rec.record;
+    const exited = (c) => (c.exitCode === null ? "not run" : `exit ${c.exitCode}`);
+    check(`the recorded Check step exited 0 (recorded: ${exited(step)})`, step.exitCode === 0);
+    check(`the recorded Test entrypoint exited 0 (recorded: ${exited(test)})`, test.exitCode === 0);
+    fetchHead?.();
+    const headTree = look(`git rev-parse --verify ${head}^{tree}`, "git", ["rev-parse", "--verify", `${head}^{tree}`]).stdout.trim();
+    check(`the recorded tree ${tree} is ${head}'s tree ${headTree}`, tree === headTree);
+  };
   const ruledLines = [];
   let outcome;
   if (live.family === "impl") {
@@ -2412,8 +2453,9 @@ async function runSettleFromReport() {
       if (report.pr === null) invalid('$.pr: null is not a PR number, with outcome "pr"');
       if (report.head === null) invalid('$.head: null, with outcome "pr"');
       outcome = `PR#${report.pr}`;
-      const sha = look(`verify-sha.sh ${report.branch} ${report.head}`, "sh", [verifySha, report.branch, report.head], [0, 1]);
+      const sha = verifyShaOf(report.branch, report.head);
       check(`verify-sha.sh ${report.branch} ${report.head} exits 0`, sha.status === 0);
+      recipeGate(report.head);
       const pr = prView(report.pr, "state,closingIssuesReferences");
       check(`PR #${report.pr} reads OPEN`, pr.state === "OPEN");
       check(`PR #${report.pr} closes #${live.number}`, pr.closingIssuesReferences.some((c) => c?.number === live.number));
@@ -2426,6 +2468,12 @@ async function runSettleFromReport() {
       outcome = `applied:${report.head}`;
       const head = remoteHead(report.branch);
       check(`origin refs/heads/${report.branch} is ${report.head}`, head === report.head);
+      if (head === report.head) {
+        // verify-sha.sh is the fetch that puts the head's commit object here,
+        // which the tree read needs; its exit 2 is a fetch that failed or an
+        // object that is not there, so it could not look.
+        recipeGate(report.head, () => verifyShaOf(report.branch, report.head));
+      }
     } else if (report.outcome === "no-op") {
       outcome = "no-op";
       let fold;

package/scripts/recipe-check.mjs

@@ -0,0 +1,260 @@
+#!/usr/bin/env node
+// Run the Recipe's Check step and the Test entrypoint against the staged tree,
+// and record that both passed — the record `ledger.mjs settle --from-report`
+// requires before it settles an implementer's or a fix-applier's report.
+//
+//   recipe-check.mjs --member <name> --testCmd <command> [--reports <dir>]
+//
+// Run from the member's worktree, after `git add` and before the commit and
+// push, and again after any content change or rebase. Reached through the
+// Resolver: `~/.fleet/bin/fleet-run recipe-check.mjs ...`.
+//
+// `--member` is the `impl-<N>[-x]` or `fix-pr-<M>[-x]` name the member was
+// dispatched as. `--testCmd` is the Test entrypoint exactly as the member was
+// handed it, a shell command run from the worktree root: the member's runner
+// already goes through the suite-slot wrapper, so this script adds none of its
+// own and never runs the suite a second time. The Check step is not an
+// argument: it is read off the repository's Recipe cache, through
+// derive-testcmd.sh, the one reader of it. `--reports` is the directory the
+// member's report is written to, `<scratch>/reports`; omitted, the default
+// scratch root's.
+//
+// Steps, in this order:
+//
+//   1  read the Check step and the Test entrypoint off the Recipe cache. A
+//      worktree with no usable Recipe has no Check step to run: exit 2,
+//      nothing run, nothing written. Settle reads the same cache from the
+//      ledger's repository, where derive-testcmd.sh's probes of the Test
+//      entrypoint can answer otherwise, so it skips its gate only where its
+//      own read refuses.
+//   2  `git write-tree`: the tree id of the staged index. The commands run in
+//      the working tree, so it must hold exactly that tree: an unstaged change
+//      to a tracked file, or an untracked file no ignore rule covers, is a
+//      refusal, exit 2 — a green record would otherwise name a tree that never
+//      ran. Then the reports directory is created, before anything runs.
+//   3  the Check step, `sh -c` from the worktree root. A Check step of
+//      `true` is recorded as green without being run.
+//   4  the Test entrypoint, the same way — only when the Check step passed.
+//
+// The commands' own output passes through on stdout and stderr as it arrives.
+//
+// THE RECORD is `<reports>/<member>.check.json`, beside the member's report
+// (report-files.mjs names the path and reads it back), written whole and
+// atomically once both commands have settled:
+//
+//   { member, tree, check: {command, ran, exitCode, pass, fail},
+//                   test:  {command, ran, exitCode, pass, fail} }
+//
+//   tree       the `git write-tree` of step 2. Settle compares it with the
+//              reported head's own tree, so a message-only amend keeps the
+//              record valid and a rebase onto a moved base, or any content
+//              change, does not.
+//   ran        false for a Check step of `true`, and for a command skipped
+//              because the Check step failed (its exitCode is then null).
+//   exitCode   the command's status, a signal's number plus 128.
+//   pass, fail the counts the runner's summary printed — a `# pass N` /
+//              `ℹ fail N` line, or `N passed`/`N failed`/`N passing`/`N
+//              failing` — null where it printed none.
+//
+// A record is written whenever a command ran and failed, so a red run
+// replaces an older record rather than leaving it standing; it records the
+// failure, and settle refuses on it. A record is a claim, no attestation: the
+// member produces it, and nothing here stops a forged one.
+//
+// Exit status: 0 both commands passed and the record is written; 1 a command
+// failed — the record says which, and the script's stderr names it; 2 a
+// refusal that ran nothing and wrote nothing (usage, no usable Recipe, git
+// could not be read, a working tree that is not the staged tree, a reports
+// directory that could not be created); 75 the Test entrypoint printed exit
+// 75 — the suite wrapper found no slot and launched nothing, which is no test
+// result — so no record is written, and the same command is to be run again.
+
+import { spawn, spawnSync } from "node:child_process";
+import { mkdirSync, renameSync, rmSync, writeFileSync } from "node:fs";
+import { constants as osConstants } from "node:os";
+import { dirname, join } from "node:path";
+import { fileURLToPath } from "node:url";
+import { makeDie, defineFlags, writeAll } from "./arg.mjs";
+import { FleetDirUnresolvable } from "./fleet-dir.mjs";
+import { gitEnv } from "./git-env.mjs";
+import { isCLI } from "./is-cli.mjs";
+import { parseMember } from "./ledger-grammar.mjs";
+import { checkRecordPathIn, defaultScratch, reportsDir } from "./report-files.mjs";
+
+const NAME = "recipe-check";
+const USAGE = "usage: recipe-check.mjs --member <name> --testCmd <command> [--reports <dir>]";
+const DERIVE = join(dirname(fileURLToPath(import.meta.url)), "derive-testcmd.sh");
+const GIT_TIMEOUT_MS = 30_000;
+// What the suite wrapper exits with when it found no slot and launched nothing.
+const NO_SLOT = 75;
+// The tail of a command's output kept for the counts: a runner prints its
+// summary last.
+const TAIL_BYTES = 256 * 1024;
+
+const ANSI = /\x1b\[[0-9;]*[A-Za-z]/g;
+
+/** `{pass, fail}` the output's summary printed, each null where it printed no
+ * count. The last count of a kind wins: a summary follows the lines it sums. */
+export function parseCounts(output) {
+  const text = output.replace(ANSI, "");
+  const last = (patterns) => {
+    for (const re of patterns) {
+      const all = [...text.matchAll(re)];
+      if (all.length > 0) return Number(all.at(-1)[1]);
+    }
+    return null;
+  };
+  const count = (word, loose) => last([new RegExp(`^[ \\t]*(?:#|ℹ)[ \\t]+${word}[ \\t]+(\\d+)[ \\t]*$`, "gm"), loose]);
+  return {
+    pass: count("pass", /\b(\d+)[ \t]+(?:passed|passing)\b/g),
+    fail: count("fail", /\b(\d+)[ \t]+(?:failed|failing)\b/g),
+  };
+}
+
+async function cli() {
+  const die = makeDie(NAME);
+  const { arg, sweep, stray } = defineFlags(die, { flags: { member: "value", testCmd: "value", reports: "value" } });
+  sweep();
+  stray();
+  const member = arg("member");
+  const testCmd = arg("testCmd");
+  let reports = arg("reports");
+  if (member === null || testCmd === null) die(USAGE);
+  const parsed = parseMember(member);
+  if (parsed === null || (parsed.family !== "impl" && parsed.family !== "fix-pr")) {
+    die(`--member '${member}' is not an impl-<N>[-x] or fix-pr-<M>[-x] name — ${USAGE}`);
+  }
+  if (testCmd.trim() === "") die(`--testCmd is empty — ${USAGE}`);
+  if (reports === null) {
+    try {
+      reports = reportsDir(defaultScratch());
+    } catch (e) {
+      if (!(e instanceof FleetDirUnresolvable)) throw e;
+      die(`no --reports, and the scratch root could not be resolved — ${e.message}`);
+    }
+  }
+
+  const env = gitEnv();
+  // A reader that did not answer: the refusal names it, its exit status and
+  // its own reason.
+  const noAnswer = (what, r) => {
+    const why = (r.error?.message ?? r.stderr ?? "").trim();
+    die(`${what} did not answer${r.status === null ? "" : ` (exit ${r.status})`}${why ? `: ${why}` : ""}; nothing run, nothing written`);
+  };
+  const gitOut = (what, args) => {
+    const r = spawnSync("git", args, { encoding: "utf8", env, timeout: GIT_TIMEOUT_MS });
+    if (r.status !== 0) noAnswer(what, r);
+    return r.stdout.trim();
+  };
+  const top = gitOut("git rev-parse --show-toplevel", ["rev-parse", "--show-toplevel"]);
+
+  // 1: the Recipe. Exit 1 is derive-testcmd.sh's refusal about the cache; any
+  // other failure is a reader that could not run.
+  const field = (name) => {
+    const r = spawnSync("sh", [DERIVE, top, name], { encoding: "utf8", env, timeout: GIT_TIMEOUT_MS });
+    if (r.status === 0) return r.stdout.replace(/\n$/, "");
+    if (r.status === 1) {
+      die(`this worktree has no usable Recipe, so there is no Check step to run; settle reads the Recipe from the ledger's repository and gates the report wherever that read finds one; nothing run, nothing written — ${(r.stderr ?? "").trim()}`);
+    }
+    noAnswer(`derive-testcmd.sh ${name}`, r);
+  };
+  const checkCmd = field("check");
+  field("test");
+
+  // 2: the staged tree, and a working tree that holds exactly it.
+  const tree = gitOut("git write-tree", ["write-tree"]);
+  const strays = [
+    ...gitOut("git diff --name-only", ["-C", top, "diff", "--name-only"]).split("\n"),
+    ...gitOut("git ls-files --others --exclude-standard", ["-C", top, "ls-files", "--others", "--exclude-standard", "--directory"]).split("\n"),
+  ].filter((p) => p !== "");
+  if (strays.length > 0) {
+    const shown = strays.slice(0, 10).join(", ") + (strays.length > 10 ? `, and ${strays.length - 10} more` : "");
+    die(`the working tree is not the staged tree — unstaged or untracked: ${shown}. The commands run in the working tree and the record names the staged tree, so stage, remove or ignore these first; nothing run, nothing written`);
+  }
+  try {
+    mkdirSync(reports, { recursive: true });
+  } catch (e) {
+    die(`could not create ${reports}: ${e.code ?? e.message}; nothing run, nothing written`);
+  }
+
+  // 3 and 4: the commands. A reader that closes this script's stdout or
+  // stderr early stops only the passthrough: the commands still run to their
+  // end and the record is still written. Any other stream error stays fatal.
+  for (const stream of [process.stdout, process.stderr]) {
+    stream.on("error", (e) => {
+      if (e.code !== "EPIPE") throw e;
+    });
+  }
+  const check = checkCmd.trim() === "true"
+    ? { command: checkCmd, ran: false, exitCode: 0, pass: null, fail: null }
+    : await runCommand(checkCmd, top, env);
+  const test = check.exitCode === 0
+    ? await runCommand(testCmd, top, env)
+    : { command: testCmd, ran: false, exitCode: null, pass: null, fail: null };
+
+  // process.exitCode, never process.exit(): the command's own output is still
+  // draining through async pipe writes, and exit discards what is queued.
+  const say = (line) => writeAll(2, `\n${NAME}: ${line}\n`);
+  if (test.exitCode === NO_SLOT) {
+    say(`the Test entrypoint exited ${NO_SLOT}: no suite slot was free and nothing was launched — run the same command again; no record written`);
+    process.exitCode = NO_SLOT;
+    return;
+  }
+
+  const path = checkRecordPathIn(reports, member);
+  const tmp = `${path}.${process.pid}.tmp`;
+  try {
+    writeFileSync(tmp, `${JSON.stringify({ member, tree, check, test })}\n`);
+    renameSync(tmp, path);
+  } catch (e) {
+    rmSync(tmp, { force: true });
+    die(`could not write ${path}: ${e.code ?? e.message}`);
+  }
+
+  if (check.exitCode !== 0) {
+    say(`the Check step exited ${check.exitCode}; red record written to ${path}, so settle refuses it — fix the cause and run again`);
+    process.exitCode = 1;
+  } else if (test.exitCode !== 0) {
+    say(`the Test entrypoint exited ${test.exitCode}; red record written to ${path}, so settle refuses it — fix the cause and run again`);
+    process.exitCode = 1;
+  } else {
+    say(`green on tree ${tree}; record written to ${path}`);
+  }
+}
+
+if (isCLI(import.meta.url)) await cli();
+
+// One command, `sh -c` from `cwd`, its output passed through and its tail kept
+// for the counts. A signal that stops it is its number plus 128.
+function runCommand(command, cwd, env) {
+  return new Promise((resolve) => {
+    let tail = "";
+    const keep = (chunk) => {
+      tail = (tail + chunk).slice(-TAIL_BYTES);
+    };
+    const child = spawn("sh", ["-c", command], { cwd, env, stdio: ["ignore", "pipe", "pipe"] });
+    const handlers = ["SIGTERM", "SIGINT", "SIGHUP"].map((sig) => [sig, () => child.kill(sig)]);
+    for (const [sig, h] of handlers) process.on(sig, h);
+    child.stdout.setEncoding("utf8");
+    child.stderr.setEncoding("utf8");
+    child.stdout.on("data", (d) => {
+      keep(d);
+      process.stdout.write(d);
+    });
+    child.stderr.on("data", (d) => {
+      keep(d);
+      process.stderr.write(d);
+    });
+    const done = (exitCode) => {
+      for (const [sig, h] of handlers) process.off(sig, h);
+      const { pass, fail } = parseCounts(tail);
+      resolve({ command, ran: true, exitCode, pass, fail });
+    };
+    // A spawn that never started (a missing `sh`) is the command not passing.
+    child.on("error", (e) => {
+      process.stderr.write(`${NAME}: could not start sh: ${e.message}\n`);
+      done(127);
+    });
+    child.on("close", (code, signal) => done(code ?? 128 + (osConstants.signals[signal] ?? 0)));
+  });
+}

package/scripts/report-files.mjs

@@ -9,6 +9,10 @@
 // SCHEMAS. The review runner and every member outside those four families
 // have no schema, so no file to look up.
 //
+// The Check-step record beside a report, `<reports>/<member>.check.json`, is
+// looked up here the same way: recipe-check.mjs writes it, and this module
+// only names where it lives and reads it back.
+//
 // This module only looks files up: it writes none, and creates no scratch
 // root.
 
@@ -32,6 +36,66 @@ export const reportsDir = (scratch) => join(scratch, "reports");
 
 export const reportPath = (scratch, member) => join(reportsDir(scratch), `${member}.json`);
 
+/** Where `member`'s Check-step record sits in reports directory `dir`: the
+ * sibling of its report, `<dir>/<member>.check.json`. recipe-check.mjs writes
+ * it, `ledger.mjs settle --from-report` reads it. */
+export const checkRecordPathIn = (dir, member) => join(dir, `${member}.check.json`);
+
+const HEX_TREE = /^(?:[0-9a-f]{40}|[0-9a-f]{64})$/;
+const isObject = (v) => v !== null && typeof v === "object" && !Array.isArray(v);
+
+// One command's half of a record: the command string, whether it ran (a Check
+// step of `true` is recorded as green without running), the exit status it
+// ended with — null when it never ran because an earlier one failed — and
+// the pass/fail counts its output printed, null where the runner printed none.
+function commandViolation(path, c) {
+  if (!isObject(c)) return `${path}: not an object`;
+  if (typeof c.command !== "string" || c.command === "") return `${path}.command: not a non-empty string`;
+  if (typeof c.ran !== "boolean") return `${path}.ran: not a boolean`;
+  if (c.exitCode !== null && !Number.isInteger(c.exitCode)) return `${path}.exitCode: not an integer or null`;
+  for (const k of ["pass", "fail"]) {
+    if (c[k] !== null && !(Number.isInteger(c[k]) && c[k] >= 0)) return `${path}.${k}: not a non-negative integer or null`;
+  }
+  return null;
+}
+
+// A file's text as `{text}`, or the answer both readers below give for a file
+// that is not there (`absent`) or cannot be read (`invalid`).
+function readAt(path) {
+  try {
+    return { text: readFileSync(path, "utf8") };
+  } catch (e) {
+    if (e.code === "ENOENT" || e.code === "ENOTDIR") return { state: "absent", path };
+    return { state: "invalid", path, violation: `$: unreadable (${e.code ?? e.message})` };
+  }
+}
+
+/** The Check-step record of `member` in reports directory `dir`, the way
+ * readReportIn() answers for a report: `{state: "ok", path, record}`,
+ * `{state: "invalid", path, violation}` for a file that exists and is
+ * unreadable, not JSON, or the wrong shape, or `{state: "absent", path}`.
+ * The record is `{member, tree, check, test}`, `tree` the `git write-tree`
+ * of the index the two commands ran against and `check`/`test` each
+ * `{command, ran, exitCode, pass, fail}`. */
+export function readCheckRecordIn(dir, member) {
+  const path = checkRecordPathIn(dir, member);
+  const read = readAt(path);
+  if (read.text === undefined) return read;
+  let record;
+  try {
+    record = JSON.parse(read.text);
+  } catch (e) {
+    return { state: "invalid", path, violation: `$: not JSON (${e.message})` };
+  }
+  if (!isObject(record)) return { state: "invalid", path, violation: "$: not an object" };
+  if (record.member !== member) return { state: "invalid", path, violation: `$.member: ${JSON.stringify(record.member)} is not ${member}` };
+  if (typeof record.tree !== "string" || !HEX_TREE.test(record.tree)) {
+    return { state: "invalid", path, violation: "$.tree: not a full lowercase hex tree id" };
+  }
+  const violation = commandViolation("$.check", record.check) ?? commandViolation("$.test", record.test);
+  return violation === null ? { state: "ok", path, record } : { state: "invalid", path, violation };
+}
+
 /** The report file of `member` under `scratch`, read and checked against its
  * family's schema: `{state: "ok", path, report}`, `{state: "invalid", path,
  * violation}` for a file that exists and is unreadable, not JSON, or the
@@ -46,14 +110,9 @@ export function readReportIn(dir, member) {
   const family = reportFamily(member);
   if (family === null) throw new Error(`no report schema for '${member}'`);
   const path = join(dir, `${member}.json`);
-  let text;
-  try {
-    text = readFileSync(path, "utf8");
-  } catch (e) {
-    if (e.code === "ENOENT" || e.code === "ENOTDIR") return { state: "absent", path };
-    return { state: "invalid", path, violation: `$: unreadable (${e.code ?? e.message})` };
-  }
-  const parsed = parseReport(text);
+  const read = readAt(path);
+  if (read.text === undefined) return read;
+  const parsed = parseReport(read.text);
   const violation = parsed.violation ?? validate(SCHEMAS[family], parsed.value);
   return violation === null ? { state: "ok", path, report: parsed.value } : { state: "invalid", path, violation };
 }