@feigi/fleet-ctl 3.82.14 → 3.82.16

package/commands/review-and-fix.md

@@ -15,7 +15,7 @@ argument-hint: [pr-number]
 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.14",
+  "version": "3.82.16",
   "description": "Agent fleet: run-team controller, merge bot, PR reviewer, and the ticket pipeline they share",
   "license": "Apache-2.0",
   "repository": {

package/skills/run-team/SKILL.md

@@ -59,8 +59,8 @@ phase, or in any later one, asks the maintainer which tickets to take.
    one stopped; before it, a re-run runs every step again.
 
    The `tier-roles` step runs `~/.fleet/bin/fleet-run tier-roles.mjs --check
-   --in-flight <B>`, `<B>` being the `--in-flight` given, else the default
-   **Defaults** (**Queue depth**) states. What it checks is in the header of `scripts/tier-roles.mjs`, under
+   --in-flight <B>`, `<B>` being the `--in-flight` given, else the default.
+   **Default: In-flight bound 5, fixed for the run.** See references/pull.md. What it checks is in the header of `scripts/tier-roles.mjs`, under
    the tier routes. A line it prints on a pass about omp's `task.maxConcurrency`
    is a notice in the step's output and never holds: read it, report it, and
    go on — the fleet never writes that setting.
@@ -151,8 +151,7 @@ phase, or in any later one, asks the maintainer which tickets to take.
    `REFRESHED shortlist: <n> entries; <k> lifted`. A head whose Pull ended
    this run is not counted, unless on a lifted exclusion. Phase 0 runs it by hand
    once because a dead run's shortlist is stale by definition.
-   None of those triggers runs while `HOLD (in-flight <n>/<B>)` stands
-   (**Queue depth**).
+   None of those triggers runs while `HOLD (in-flight <n>/<B>)` stands.
 
 **No multi-select, no maintainer tick.** Selection and ordering are batched —
 one scan, oldest first; admission never is. The invariant this replaces — one
@@ -185,7 +184,7 @@ it prints. There are no hand-run
 refill or dispatch edges left. Record first, because the tick reads the run off
 `.fleet/ledger.md` and nothing else of yours: a wake you have not written down is
 one it cannot see, and it names the same dispatch again. Every record goes
-through `ledger.mjs` (**Run ledger**), which `fleet-event.mjs` drives — never a
+through `ledger.mjs` (references/ledger.md), which `fleet-event.mjs` drives — never a
 hand edit. What each kind writes is in the header comment of `fleet-event.mjs`.
 See references/ci-and-staleness.md.
 
@@ -283,9 +282,22 @@ owes beyond its call:
   context exhaustion caused (references/close-out.md).
 - **The finisher-gate wakes** — a CI run reaching a terminal state, a fix-applier reporting `no-op`, a `no-ci` verdict → each is a bullet of **The finisher gate**.
 
+Write each state change through `ledger.mjs` before you act on it, never by hand: a wake is done when no row, filing or ruling lives only in your context.
+
+Compaction parks every in-flight member and nothing reports it, so on resume take the registry census first (**Member unaccounted**, in **Failure handling**) before you trust a live token.
+
+Token additions go through `ledger.mjs token`. `ledger.mjs token <key> <token>…` adds a token and keeps every token already on the row. Re-typing the row with `row` replaces the whole line, so it drops the tokens you do not restate. Write member tokens and `review=` tokens only through `ledger.mjs`, never by hand.
+
+Never rotate the ledger mid-run: it is phase 0's step alone.
+
+Record each ruling with `ledger.mjs ruled <pr> <decision>`, one line with its reason. Gate on the `ledger.ok` field of `check`, not on the stderr warning. The writer policy, the gap the lock does not close, and `check`'s exits: See references/ledger.md.
+
+**Write the ledger line before dispatching, not after.** Record the member with `ledger.mjs dispatch`, or `review` for a review, before its `task` call.
+
 ### Dispatching the members a wake names
 
 - **The reviewer.** **Dispatch the review, never wait on it, and act when its result lands. That is the default path.** `DISPATCH review PR#<M>`: a `task` member named `review-pr-<pr#>`, agent `fleet-review-runner`, its prompt the five args `pr`, `branch`, `worktree`, `testCmd` and `scratch`. Record `review=member:review-pr-<pr#>` on the PR's row before the call. `scratch` is the scratch root itself, never a `pr<N>` partition (`references/reviewers.md`). Write the `review=` token with `ledger.mjs review <pr> <token>`; `ledger.mjs` refuses a bad grammar. The tick names every PR owed one, oldest first, and each gets one review, once per PR. The tick counts in-flight reviews off the ledger and nowhere else, so a review you launched and never recorded is one it names again. The runner writes the result file and reports its path and `reviewed=` token.
+A row with `review=` and no `reviewed=` is a review in flight, and the tick counts it as a live review unit unless gh reports its PR MERGED or CLOSED.
 - **The fix-applier.** `DISPATCH fix-pr PR#<M>` on a `reviewed=` count that survived or unverified findings, with no fix-applier live: name `fix-pr-<pr#>` (the next suffix if that name is on record), never the PR's implementer; render with `dispatch-prompt.mjs render fix-applier --kind review --member fix-pr-<pr#> …`, then record `ledger.mjs dispatch <pr#> fix-pr-<pr#>` before the call. Its brief carries the PR number, the worktree abs path, the PR's branch, the same `testCmd` you passed the review, and the **path** `<scratch>/pr<pr>/<run>/review.json`, `<run>` off the PR's latest `reviewed=` — never the findings. Every `<scratch>` in that brief is the absolute path `scratch-root.mjs` printed. Its rulings are the fix-applier body's (`agents/fleet-fix-applier.agent.md`); you hold none. It holds every finding and you hold none, so there is nothing for you to rank, relay or pre-rule — and a report from a refuter it spawns that surfaces to you is its to retrieve, never yours to scan or pass on. It answers the hold and nothing else: survived or unverified findings of a returned review the row also carries stay unanswered through its settle, so the tick prints `DISPATCH fix-pr PR#<M>` again once it lands, and that one is a review fix-applier, dispatched as above. On a PR carrying `ready-to-merge`, the push moves the head after the label, so the next merge bot refuses it `head-moved-after-label-#<M>`: a fresh finisher, per **Failure handling**.
 - **The conflict hold.** `DISPATCH fix-pr PR#<M>` on a conflict hold: the row carries an unresolved `conflict-hold:#<M>`, the merge bot's or one you recorded off the tick's `CONFLICT` line. It is the same slot with a different job, and no review file to hand over. Name it `fix-pr-<M>`, or the next suffix (`-b`, `-c` …) when that name is on record; render with `dispatch-prompt.mjs render fix-applier --kind conflict --member <name> …`; dispatch with the `agent` `ledger.mjs dispatch` printed, in the PR's existing worktree. Read the definition off that output (`fleet-fix-applier` whatever the row's `tier=`), never recall it. Settle `applied:<head>`, or `no-op` if no conflict was left, which lifts the merge hold; a dispatched-but-live one does not, and `failed`/`killed` leave the PR fix-due for a replacement.
 - **Then dispatch a red-check fixer** — on a `check`-job `failure` bound to the PR's current head that is not **solely** staleness: a `rebase-check` red, or heavy jobs `skipped`, that comes only off the behind-count gets no fixer (the five-condition note in `agents/fleet-fix-applier.agent.md` establishes that). Name `fix-pr-<M>`, or the next free suffix; render with `dispatch-prompt.mjs render fix-applier --kind red-check --member <name> …`, record with `ledger.mjs dispatch <pr#> <name>` before the call, and dispatch with the printed `agent` in the PR's existing worktree. While a review or a review fix-applier on the PR is live or still owes its report — a dispositions mismatch awaiting its retry and a conflict hold awaiting its fix-applier included — the red-check fixer does not fire: their push starts a new run, and a fixer racing them would work on a SHA that is still moving. The common case, the implementer's own first CI firing turning red before any review exists, still dispatches the review against that head as normal. The tick prints no `DISPATCH` for it, so you reconcile it yourself, and it always goes after the review, never before. It is told outright not to watch, poll or wait for CI: your persistent Monitor owns the next run on the pushed head, and the finisher gate — review returned AND fix-applier report sent — applies to this member the same way. Settle it `applied:<head>` once a fix is pushed. Settle it `no-op` only when the red turns out not to be this member's to fix — a flake that passes on rerun, or staleness — with nothing pushed; `no-op` counts as landed, so it never stands for "could not fix". Settle it `failed` when it cannot reach green, which the **Failure handling** row "Reviewer, fix-applier or red-check fixer cannot reach green" covers. Its three dispatch edges are under **The finisher gate**; their rationale is in `references/member-lifecycle.md` (The red-check fixer's three edges).
@@ -373,6 +385,29 @@ treat as a live scratch write until you have checked it.
 
 **A refutation resting on an injection nothing proved landed is not a refutation — it is a cell that never ran.** See references/reviewers.md.
 
+**Guard: accumulate per PR, never conclude inside one run.** **Append one row to
+`docs/metrics/tier-outcomes.tsv` when you rule each PR's review, with
+`~/.fleet/bin/fleet-run tier-outcomes.mjs append <pr> --closed-own-ticket yes|no --minted-false-claim yes|no --note "<text>"`,
+never by hand** (that file's header carries the column meanings). The script
+fills `run_date`, `pr`, `ticket` and `tier` itself — `tier` from what actually
+ran, off the implementer's `tier-ok=` ledger verdict or else its one
+member-outcomes row (a `tier-unverifiable=` member has no ledger verdict, so
+its one member-outcomes row decides), and BLANK with a WARNING naming why
+when neither settles
+it; never type a tier in over that. That append is the whole duty. See references/pull.md.
+
+The row's last four fields are the ticket's difficulty, and they are what lets a
+tier comparison condition on the thing that swamps it. `sizing` is the
+**member's** own `light`/`heavy` verdict from its dispatched `sizing-a-ticket`
+run, which `append` reads itself off the member's report file
+(`<scratch>/reports/impl-<ticket>[-x].json`, its `sizing.verdict`, the highest
+retry letter's when there are several), so you pass no `--sizing`; the member
+also puts it in the PR body's `Sizing:` line, with the signal it turned on;
+`profile`, `loc` and `files` all come from `diff-stats.mjs` over the merged
+diff.
+
+**A verdict is a measurement only if it post-dates the run that produced it.** See references/reviewers.md.
+
 ### Nothing to do: arm the beat
 
 - **Nothing to do right now** → **do not end your turn.** Arm the heartbeat
@@ -450,6 +485,18 @@ Act on each line the tick prints as its row reads here, then stop: the next wake
 ~/.fleet/bin/fleet-run fleet-tick.mjs --apply [--in-flight <n>]
 ```
 
+Read the depth off the tick and never derive it by hand: act on the row it prints, and when it prints `SUGGEST /triage, hold idle`, hold the implementer row idle and suggest `/triage` in the report. See references/tick-rows.md.
+
+**The review backlog never gates, and the merge-queue depth is still no
+signal.** The only gate on a Pull is the In-flight count. A deep backlog is a
+`DISPATCH review` on the same tick, never a reason to idle an implementer.
+A starved implementer queue never stalls the review or merge side.
+For the merge queue, see references/pull.md.
+
+**Reconcile, do not wait for an event.** With the shortlist empty the tick's rows
+govern — refresh, and never Pull a ticket the shortlist does not hold.
+See references/pull.md.
+
 It reads the run itself, and nobody states a count. The In-flight count —
 every open PR that closes an issue off `gh`, plus every claimed ticket whose
 newest implementer is live or owed a replacement and has no such PR yet, off
@@ -469,12 +516,11 @@ row with `ledger.mjs row` and tick again. The In-flight bound defaults to 5
 and is fixed for the run: pass `--in-flight` on every tick when `$ARGUMENTS`
 set it, and never otherwise.
 
-It prints `actual/target` and a named ACTION per role, with the whole **Queue
-depth** guard table applied in code. Act on each line as it reads:
+It prints `actual/target` and a named ACTION per role. Act on each line as it reads:
 
 - `PULL #<N> …` — one Pull per named ticket, in the order printed: `pull.mjs next --head <N>`, or the `pull.mjs answer` the row names (phase 1), then the dispatch under **Dispatching the Pull's member**.
 - `REFRESHED shortlist: <n> entries; <k> lifted` — the tick refreshed the shortlist itself, and its `PULL` row already reads the result; `REFRESH FAILED` is yours, since `shortlist.mjs` could not run.
-- `SUGGEST /triage, hold idle` — nothing is admissible after the refresh: suggest `/triage` in the report, never run it.
+- `SUGGEST /triage, hold idle` — nothing is admissible after the refresh: suggest `/triage` in the report, never run it. The suggestion is a report, not a blocking prompt.
 - `specs-dropped=#<N> …` — never actionable: log those tickets as specs awaiting to-tickets, not as no work.
 - `DISPATCH fix-pr PR#<M> …` — a fix-applier for that PR (review findings, a dispositions mismatch no retry has answered, or a conflict hold): render its brief with `dispatch-prompt.mjs render fix-applier --kind <kind>`, `ledger.mjs dispatch <M> fix-pr-<M>` (the next suffix when that name is already on record), then the `task` call.
 - `DISPATCH review PR#<M> …` — a review per PR, oldest first, off your turn: record `review=member:review-pr-<M>` with `ledger.mjs review <M> …`, then dispatch `review-pr-<M>`.
@@ -824,7 +870,7 @@ merge. `review-and-fix.md` states them; the body says they apply.
 
 **Once the label is on, take it off before you approve any push.** Write `label-off=<latest finisher attempt>` onto the PR's row first
 (`ledger.mjs token <PR number> label-off=<latest finisher attempt>`, which keeps
-every token the row already has — **Run ledger**), then
+every token the row already has, see references/ledger.md), then
 remove `ready-to-merge`, then approve. Then
 dispatch a **fresh** finisher against the new head; the first audit does not
 transfer, since it verified a different tree. The merge bot refuses that head on
@@ -1006,6 +1052,16 @@ report recovery, never the exit code alone.
 
 Each rule here is a judgement a driver stops for: answer it by the cause it names, then run the tick, and report to the maintainer what the evidence cannot settle.
 
+### A member's claims
+
+**Cross-check what members report about their environment.**
+
+**Distrust negative claims hardest.** Make members state their search scope. Negative claim
+vs specific finding with paths → paths win. See references/reviewers.md.
+
+Suspect a neighbour before a member's own diff — for unexplained failures, and
+equally for any **finding** that came from reading source.
+
 ### Relabel causes
 
 - **Implementer bails before implementing** → `fleet-event.mjs impl-report impl-<N>`
@@ -1231,224 +1287,20 @@ this section's dispatch recipe — the cwd recipe above, the isolated-workspace
 measurement, or the teardown scoping — moves
 where the controller itself runs from.
 
-## Queue depth
-
-Read the depth off the tick and never derive it by hand: act on the row it prints, and when it prints `SUGGEST /triage, hold idle`, hold the implementer row idle and suggest `/triage` in the report.
-
-- **shortlist** — `.fleet/shortlist.json`'s entries with no `impl-` row and no
-  live `excluded` row: admissible, not yet pulled. The tick's `unclaimed=`.
-  Not after a refresh at unclaimed < B (below). A head whose Pull ended this
-  run is not counted, unless on a lifted exclusion.
-- **supply** — `scanned`, the open `ready-for-agent` tickets `shortlist.mjs`'s
-  candidate scan returned, before any filter. Only a Pull's full read judges
-  decided?, so a shortlist of undecided tickets is supply that every Pull
-  relabels away — and relabelling is what stops it being counted next scan.
-- **review backlog** — PRs owed a review. `fleet-tick.mjs` counts every
-  open PR without `ready-to-merge` **that closes an issue** and carries no `review=`
-  token on the ledger — one settled `=failed` is owed a review again, and so is
-  one whose latest finisher halted `past-pin` past its latest `reviewed=` head
-  (**Resolving a finisher halt**) — and it
-  prints them as `review-due=`. Exact, not a wider read: the ledger records
-  which PRs are under review or reviewed, so nothing about it is guesswork. The
-  closing-issue test is what keeps it from widening: a PR that closes no issue
-  — one you author yourself, for instance — is left unlabelled for the
-  maintainer, so no member of the fleet will ever review it, and counting it
-  floors the backlog at a depth nothing in the run can drain — the reviewer
-  row would then report a review owed for the rest of the run.
-  GitHub's own linked-issue set decides that, not a keyword regex over the body.
-  **That exemption is for a PR THIS run authors, never one a PRIOR run left
-  open** — step 0 folds those into this run's review queue, so count one when
-  you reason about backlog BY HAND. **The `fleet-tick.mjs` number still
-  excludes it**: nothing in its filter distinguishes an inherited PR from this
-  run's own, since a PR closing no issue fails the closing-issue test either
-  way — folding one in cannot reach the count. So the by-hand judgement and
-  the script's output differ here, and such a PR's review is dispatched by
-  hand.
-- **In flight** — a ticket between its Claim and its PR's merge: an implementer
-  live or owed a replacement on it, or an open PR closing it. A PR closing
-  nothing is never in flight, and a ticket whose newest implementer settled
-  `blocked` is not either. The tick's `n`; the implementer row's counts read it
-  as `implementers=<i> prs=<p>`, n being i + p.
-- **In-flight bound** — the most tickets a run lets be In flight at once, fixed
-  for the run, set by `/run-team`'s one argument. Reaching it holds every Pull
-  until a merge brings the count below it; reviewers, finishers and the merge
-  bot never slow for it. The tick's `B`.
-
-**Default: In-flight bound 5, fixed for the run.** See references/pull.md.
-
-**The review backlog never gates, and the merge-queue depth is still no
-signal.** The only gate on a Pull is the In-flight count. A deep backlog is a
-`DISPATCH review` on the same tick, never a reason to idle an implementer.
-For the merge queue, see references/pull.md.
-
-**Reconcile, do not wait for an event.** With the shortlist empty the table
-below governs — refresh, and never Pull a ticket the shortlist does not hold.
-See references/pull.md.
-
-**Do not re-derive this by hand — `fleet-tick.mjs` computes it.** One invocation
-prints per-role `actual/target` and an explicit ACTION with the backlog gate
-above and every row of the table below already applied; every wake
-ends in it. The deficit is then *computed, not remembered*, which is
-the whole point: a table you must remember to consult is one you will not
-consult under a merge-side event storm, and that is how implementers reached
-0/target with ~57 `ready-for-agent` in supply while nobody
-noticed (#3). What follows stays here as the explanation of what the script decides —
-never as a second, hand-run copy of it. The table's shortlist counts no head
-whose Pull ended this run, unless on a lifted exclusion. A refresh at unclaimed < B leaves `unclaimed=` at
-that count, so `SUGGEST /triage` can print it above 0.
-
-| shortlist (unclaimed) | implementer row prints |
-|---|---|
-| ≥ 1 | `PULL #N …`, one head per free slot — a Pull each (phase 1) |
-| below the In-flight bound, missing or empty | the tick refreshes first — `REFRESHED shortlist: n entries; k lifted` — and Pulls from what it found |
-| 0 after that refresh | `SUGGEST /triage, hold idle` |
-
-### Specs, the refresh bound and the holds
-
-Whatever the row prints, a `specs-dropped=#<N> (…)` at the end of its counts
-names the tickets the to-spec filter kept out of the shortlist — specs
-awaiting to-tickets, so an empty shortlist carrying one is not "no work".
-
-The refresh runs at unclaimed < B and, with every other refresh trigger, never
-while the bound holds: a refresh then cannot feed a Pull, and the first tick
-back under the bound refreshes and Pulls in the same tick. Unclaimed there
-counts no head whose Pull ended this run, unless on a lifted exclusion.
-
-Four holds outrank every row: `HOLD (draining)` once `ledger.mjs drain` has
-recorded the drain, `HOLD (tier mismatch impl-<N>)` until a replacement is
-dispatched at the right tier, `HOLD (tier unchecked impl-<N>)` until
-`tier-check.mjs` has written its verdict on the newest implementer —
-`tier-ok=`, `tier-mismatch=` or `tier-unverifiable=` — and
-`HOLD (in-flight <n>/<B>)` when n tickets are between Claim and merge and
-n ≥ B — refreshing to enable a Pull you are holding buys nothing.
-
-`HOLD (in-flight <n>/<B>)` ranks last of the four: the other three print in
-its place. Its detail is the implementer row's counts, `implementers=<i>
-prs=<p> unclaimed=<k> supply=<s>`. It is quiet — a merge brings n below B and
-the next tick Pulls — except for a ticket whose newest implementer settled
-`killed` or `tier-mismatch`: it counts as In flight with no PR that could
-merge, so the row asks for the replacement's dispatch and names it in the
-detail. The reviewer row reads `<units>/<B>`, its live review units against
-the same bound, and never holds on it.
-
-A main checkout that is not `clean` against its Phase 0 baseline outranks all
-of them, and every dispatching row besides: `HOLD (main checkout dirty)`,
-`HOLD (main checkout unknown)` or `HOLD (main checkout no baseline)` on the
-implementer, reviewer and merge-bot rows alike, beside the `MAIN-CHECKOUT-*`
-line that says why.
-
-`/triage` is user-invoked only — suggest, never run. The suggestion is a report,
-not a blocking prompt. Counts come from cheap `gh issue list --search`, no bodies.
-A starved implementer queue never stalls the review or merge side.
-
-## Tier outcomes guard
-
-This guard is done when you have run `tier-outcomes.mjs append` once for each PR whose review you rule; never conclude a tier result inside one run.
-
-**Guard: accumulate per PR, never conclude inside one run.** The unit is the PR —
-supply is one Pull per free slot, so there are no implementer batches. **Append one row to
-`docs/metrics/tier-outcomes.tsv` when you rule each PR's review, with
-`~/.fleet/bin/fleet-run tier-outcomes.mjs append <pr> --closed-own-ticket yes|no --minted-false-claim yes|no --note "<text>"`,
-never by hand** (that file's header carries the column meanings). The script
-fills `run_date`, `pr`, `ticket` and `tier` itself — `tier` from what actually
-ran, off the implementer's `tier-ok=` ledger verdict or else its one
-member-outcomes row (a `tier-unverifiable=` member has no ledger verdict, so
-its one member-outcomes row decides), and BLANK with a WARNING naming why
-when neither settles
-it; never type a tier in over that. A PR that already has a row is left
-untouched, so re-running it is safe. That append is the whole duty.
-
-The row's last four fields are the ticket's difficulty, and they are what lets a
-tier comparison condition on the thing that swamps it. `sizing` is the
-**member's** own `light`/`heavy` verdict from its dispatched `sizing-a-ticket`
-run, which `append` reads itself off the member's report file
-(`<scratch>/reports/impl-<ticket>[-x].json`, its `sizing.verdict`, the highest
-retry letter's when there are several), so you pass no `--sizing`; the member
-also puts it in the PR body's `Sizing:` line, with the signal it turned on;
-`profile`, `loc` and `files` all come from `diff-stats.mjs` over the merged
-diff. **Phase 0 does not size anything** — it shortlists, a Pull claims, and
-the sizing run happens inside the member after both, which is why the verdict
-has to travel in the member's report rather than being something you already hold.
-
-**A verdict is a measurement only if it post-dates the run that produced it.** See references/reviewers.md.
-
-The member-facts scrape, the drain of the pending ticket-features rows and the
-commit of the metrics files are steps of `closeout.mjs finish`, which **End of
-run** (**What a wake owes beyond its call**) drives. See references/close-out.md.
-
-**Why not decide inside one run.** A run holds 2-3 implementer PRs, and ticket
-difficulty swamps the tier effect — a gojq parity harness and a two-statement
-shell reorder are not comparable units. Finding-counts are not comparable either:
-`selectDimensions` trims the fan-out by diff profile, so one PR fields 29 agents
-over six dimensions and its sibling fields 8 over three. And the fleet is not
-stationary — this prompt gets edited mid-run when a defect earns it. Hence a
-binary outcome per PR, accumulating, rather than a per-run verdict.
-
-**Why the rows this guard fired on could not answer the tier question, and this
-is the load-bearing part.** Until the 2026-08-16 revert, `class` and `tier` were
-perfectly confounded: routine always ran `sonnet`, correction always ran top
-tier. So the comparison the file invites — routine-at-sonnet against
-correction-at-top-tier — measures **class, not tier**, because those classes fail
-in different ways by construction: corrections ship false claims in prose,
-routines ship incomplete or regressing code. A run that "mixes both" does not fix
-it. **Only a same-class comparison across tiers is informative**, and the old
-rule could not produce one, since no routine ticket ever ran at top tier.
-
-**That last sentence is no longer true, and this is the part to re-read.** Since
-the revert every routine ticket runs at top tier, so the file now holds 55
-`routine`/`opus` rows against 11 `routine`/`sonnet` (as of 2026-08-28, 103 rows
-— recount before citing). The same-class comparison the paragraph above calls
-the only informative one therefore EXISTS now. It is still not clean: the two
-groups are split almost entirely by calendar date, so it measures prompt
-evolution at least as much as tier. The counter-evidence paragraph earlier in
-this section carries the split and the three rows that cut against it. Recount
-both, and every other figure in this section, with:
-
-```bash
-grep -vc '^#' docs/metrics/tier-outcomes.tsv
-awk -F'\t' '!/^#/ && $4=="routine" {n++; d[$1]=1; if($6=="no") no++} \
-  END{print n, length(d), no+0}' docs/metrics/tier-outcomes.tsv
-awk -F'\t' '!/^#/ && $4=="routine" {t[$5]++; if($6=="no") f[$5]++} \
-  END{for(k in t) print k, t[k], f[k]+0}' docs/metrics/tier-outcomes.tsv
-```
-
-**These rows are the historical corpus, and nothing appended to them fixes the
-confound.** What fixes it is the exploration draw in the dispatch rule above:
-one implementer in every five — every one, during burn-in — runs at a drawn
-cell beside the policy cell's, against the same prompts on the same day, so
-the comparison stops depending on which tier history happened to leave in
-which week. Read each cell's comparisons, not the whole-file split, once there
-are enough of them.
-
-**So read what the guard actually established: routine tickets sometimes fail to
-close their own ticket. Not that `sonnet` caused it.** The revert is the
-pre-committed rule being honoured, not a measurement. Restoring a cheap tier is
-still the maintainer's call and still a change to the dispatch rule — but the
-deliberate control it used to require is no longer something anyone has to
-authorize one ticket at a time: the exploration draw above produces one in
-every five Pulls by construction. **Do not read a cell early.** A cell's
-comparison is one session holding an admissible row at that cell — its tier
-check passed and its resolved effort is the cell's level — and one at
-`slow-high` whose resolved model and effort differ. Count them per cell, never
-pooled across cells, and stop until
-there are at least ten of them across five or more distinct `run_date`s; below
-that, a comparison count is a number, not evidence, and the last guard fired
-with n=1 on the control side. **Report the count the per-cell readout prints,
-never one from any other query:** `~/.fleet/bin/fleet-run cell-readout.mjs`
-prints `<cell> <comparisons> <run_dates> <resolved models>` for each cell past
-that floor and a cell below it only as a count on stderr; a `mixed (…)` models
-column means the cell's history spans more than one model behind its role.
-The pre-cell pair query counted pairs that are no cell's comparisons, and the
-query before that one counted every session whose implementers merely
-differed, so it cleared this floor by an order of magnitude while the
-controlled comparison did not exist yet.
-
 ## Why the implementer body carries what it does
 
 Read this before you edit any `fleet-implementer-<cell>` file, and stop editing when every cell's body is byte-identical again.
 
 Why the agent body carries what it does — read this before editing any `fleet-implementer-<cell>` file, and keep every cell's body byte-identical. See references/pull.md.
 
+- **Every implementer body carries the claim discipline, because tickets that restate facts ship new wrong claims** — inherited from the ticket, and minted in prose nobody asked for. See references/correction-tickets.md.
+- **The settling command for "which files read X" must never be a literal-path
+  grep.** Replace the file with `MUTATED` in a throwaway copy, run the suite, and read off
+  which suites red: that answers which ones **depend on its contents**, which is
+  the question a coverage claim actually needs, and it returns a different set
+  from any spelling of the grep. See references/correction-tickets.md.
+- **A settling command over literal text uses `grep -F`, and its zero counts only after the same command finds a line known to match.** See references/correction-tickets.md.
+
 **Prose-first** and **wrongly-REFUSE** are not padding — they are the case
 which shipped with **enumerate-and-declare** already in its prompt. It missed a
 shape its own ticket named in passing, because it enumerated from the mechanism
@@ -1508,213 +1360,6 @@ hold the old text — re-brief only if it changes what they do *now*.
 
 Plan it as a PR the run's own merge queue lands, never as an edit-and-continue. See references/merge-bot.md.
 
-## Run ledger
-
-Write each state change through `ledger.mjs` before you act on it, never by hand: this section is done when no row, filing or ruling lives only in your context.
-
-One git-ignored `.fleet/ledger.md` per run, updated at **every** state change via
-`~/.fleet/bin/fleet-run ledger.mjs` subcommands (`row`, `filed`, `ruled`,
-`check`, `read`, `dispatch`, `settle`, `review`, `drain`, `rotate`). Your context is the least
-durable thing in the run: it compacts, and a controller that loses the dispatch
-map or the filed list redoes finished work. Two duplicate tickets shipped in one
-run from exactly that.
-Compaction parks every in-flight member and nothing reports it, so on resume
-take the registry census first (**Member unaccounted**, in **Failure
-handling**) before you trust a live token.
-
-**The file lives one run.** Phase 0 rotates it before anything reads it, so
-no exclusion, filing, ruling or drain marker outlives the run that wrote it,
-and no row does either — except, when the previous run was this session's
-own, a row still carrying a live token, which rotate carries forward with
-its live `## Dispatched` entries (phase 0). Never rotate mid-run: it is
-phase 0's step alone.
-
-One line per ticket, rewritten in place (`ledger.mjs row <ticket> <text>`; `ledger.mjs token <key> <token>…` adds a token and keeps every token already on the row):
-
-```
-#<t1> impl-<t1>=PR#<p1> → PR#<p1> → MERGED 73b356de
-#<t2> impl-<t2>=PR#<p2> → PR#<p2> · fix-pr-<p2> · ports=16<t2> · ruled:6-applies · held-behind:#<t3>
-#<t3> impl-<t3> · tier=task-high
-#<t4> excluded · behind-pr:#<p2>
-#<t5> excluded · behind-issue:#<t3>
-```
-
-**A member's token is `<member>` while it is live and `<member>=<outcome>` once
-it settles** — the grammar is `ledger-grammar.mjs`'s, and the tick derives every
-live count from it, so nobody states one. Write neither by hand:
-
-- **`ledger.mjs dispatch <ticket|pr> <member>`** — before the dispatch call,
-  marks the member live on its row and appends it to `## Dispatched` with
-  `brief=<first 8 hex of its brief's sha256>`. `dispatch
-  merge-bot` names the next bot itself. It prints `{member, agent, ticket,
-  line, created, total, brief}`, `brief` the `{path, sha256}` of the rendered
-  brief the `task` call is handed; `agent` is the definition the `task` call names — an
-  implementer's comes off its row's `tier=` (the tier check under **Dispatching the Pull's member** states the
-  mapping), a finisher's and a merge bot's are their own definitions, and a
-  fix-applier's is `fleet-fix-applier` for every kind of work. It
-  refuses a member whose `briefs/<member>.json` beside the ledger is missing,
-  names another role or carries no sha256, a brief file beside it that is missing or does not hash to that sha256, a name this session already used — on the ledger or in its
-  `## Retired` — and names the replacement (`-b`, `-c` …), a
-  second live member on one ticket or PR, any implementer once the run is
-  draining, an implementer whose row's `tier=` names no single definition
-  or one with no file under `agents/`, and a finisher on a ledger the tick
-  itself refuses.
-- **`ledger.mjs settle <member> <outcome>`** — rewrites the token to
-  `<member>=<outcome>` in both places. Outcomes: `impl-N` = `PR#M | bailed |
-  released | killed | tier-mismatch | blocked`; `fix-pr-M` = `applied:<head> | no-op |
-  failed | killed`; `finisher-pr-M` = `labelled | failed | killed |
-  halted:<cause>`, `<cause>` one of `live-editor | rebase | past-pin |
-  unreadable | missing | absent | other` (**Resolving a finisher halt**);
-  `merge-bot-n` = `done | killed`. A settled member stays settled. `settle
-  impl-N=PR#M` also folds a `#M` row a PR-bound dispatch or a `review` made
-  before the settle into `#N`'s row, so the PR's row is the one row naming
-  each PR from then on — but only when `#N`'s row named no PR before this
-  write (a second `PR#` on it would misattribute the fold, or bury `#N`'s own
-  fresher `review=` state under an older one) and no implementer claims `#M`'s
-  row as its own. `settle impl-N=PR#M` refuses a settle after which a PR maps
-  to more than one row when it did not before, judged after the fold — a PR
-  has one row, the PR's row; a split already on disk is carried.
-- **`ledger.mjs settle <member> --from-report [--reports <dir>]`** — the
-  settle for a member that wrote a report: reads `<dir>/<member>.json`
-  (`<dir>` defaults to `<scratch>/reports`), derives the outcome from it and,
-  before writing, checks what that outcome claims — `PR#M`: `verify-sha.sh`
-  on the report's branch and head, and PR M OPEN and closing N; `bailed`: a
-  `bailCause`, which the receipt names; `applied:<head>`: origin's branch at
-  that head; `no-op`: origin's branch at the head the PR's latest
-  `reviewed=` names; `labelled`: `ready-to-merge` on the PR and in the
-  read-back; `halted:<cause>`: a cause and non-empty evidence; `done`: every
-  PR the bot merged reads MERGED. `PR#M` and `applied:<head>` also need a
-  green Check-step record (`SETTLE`). It then records each `unrecorded` filing in
-  **filed** and, for a fix-applier, each refutation the report defers in
-  **ruled**, once however often it runs, and prints `{member, outcome,
-  checks, filed, ruled}`. Exit 3: a check failed — the member's claim and the
-  world disagree — and nothing is written; you rule. Exit 2: the report is
-  absent or invalid, or a check could not look, and nothing is written; a
-  check that could not look is run again once `gh` and `git` answer. The bare
-  form above, for an outcome a report carries, warns `settled without
-  --from-report` on stderr.
-- **`ledger.mjs review <pr> <token>…`** — the only writer of `review=` and
-  `reviewed=` (below): appends each to the PR's row — the ticket row once
-  `settle impl-<N>=PR#M` has run, else `#M`, created when neither exists —
-  and prints `{pr, row, line, created, next}`, `row` the key written and
-  `next` the runner name the PR's next launch takes, null with every letter
-  taken. A
-  `review=<launch>=failed` whose `review=<launch>` the row holds settles that
-  launch in place, alone or with the next launch in the same call. Any other
-  token is refused.
-- **`ledger.mjs drain "<reason>"`** — at most one standing drain marker; supply
-  stops, the review and merge sides keep going. It lives in this run's
-  ledger, so the next run's rotation retires it with everything else.
-- **`ledger.mjs undrain "<reason>"`** — clears the drain marker and refuses when
-  no marker is set. `closeout.mjs reopen` runs it.
-- **`ledger.mjs rotate`** — phase 0's first ledger write, every run: moves
-  the file as-is to `ledger.<UTC YYYY-MM-DDTHHMMSSZ>.md` beside it under the
-  same `<file>.lock`, and the next write starts the empty skeleton — unless
-  the previous run was this session's own, when it first writes the rows and
-  `## Dispatched` entries still live into a new ledger, and every other
-  settled name, or name given an out-of-vocabulary outcome, into its
-  `## Retired` (references/phase-0.md, "Rotate the ledger", says which). Refused
-  while the recorded controller is alive and not this run's ancestor, ledger
-  or none — or, with no record and a ledger to move, while the heartbeat mark
-  is still beating, or a tick or ledger write is inside its window with no
-  beat — or when the archive name already exists, the process
-  table cannot be read, or `.fleet/heartbeat.json` exists but cannot be used
-  (unreadable, not JSON, not an object, or a `controller` it cannot judge);
-  with no ledger and no such refusal it moves nothing and exits 0. Then it
-  records this run's controller in `.fleet/heartbeat.json`. The guard is
-  stated in references/phase-0.md, "Rotate the ledger".
-
-`row` refuses a malformed member token anywhere in its text — one whose outcome
-is outside the vocabulary above, e.g. `merge-bot-1=dispatched` — at exit 2,
-naming the token and writing nothing, because every reader would take it as a
-permanent settle. It refuses a write that adds a `review=`/`reviewed=` token
-(one the row already holds is carried), and one after which a PR maps to more
-than one row when it did not before — `row <M>` creating `#M` for a PR a ticket
-row maps, or a rewrite adding a `PR#M` mention to another row — naming the
-PR's row (`settle impl-N=PR#M` applies the same rule after its fold).
-
-`→ PR#M` stays as the human-readable arrow; the tick reads only the `=`
-tokens. `tier=<cell>` marks an Exploration Pull's cell and `route=<REASON>` a router fallback (the dispatch's CELL line), and `excluded ·
-behind-pr:#M | behind-issue:#M` is an Exclusion (phase 1) — a ticket row like
-any other, never a section of its own.
-
-A PR's review is not a member, so it carries its own pair of row tokens,
-written with `review` onto the PR's row (**The reviewer**): `review=wf:<runId>` |
-`review=member:<name>` at launch, `<name>` being
-`review-pr-<n>` for the PR's first runner and the next letter its rows do not
-carry yet (`review-pr-<n>-b`, `-c`, …) for every later one,
-settled dead as `…=failed`, then `reviewed=<head>:<survived>/<refuted>/<unverified>:<run>`
-when the result lands, `<run>` the review's `run-XXXXXXXX` run root under
-`<scratch>/pr<n>/`, which holds its `review.json`. A row with `review=` and no `reviewed=` is a review in
-flight, and the tick counts it as a live review unit unless gh reports its PR
-MERGED or CLOSED. `ci=<run-id>:<attempt>:<conclusion>`
-and `held-behind:#<lower>` are row tokens the same way, and so is
-`conflict-hold:#<pr>` — written by the merge bot itself (`run-merge-bot.md`
-step 1), or by you off the tick's `CONFLICT` line, naming the row's own PR. It
-is not an Exclusion: that gates a ticket's claim, this a PR's merge. `label-off=<finisher-pr-M[-x]>`
-is yours, written before you take `ready-to-merge` off PR M on purpose (taking
-it off before you approve a push, or clearing one left on a moved head),
-naming that PR's latest finisher attempt: the tick reads a missing label as a
-finisher's miss only after the last attempt a `label-off=` names, so without
-it your own removal reads as one. `row` and `token` refuse a `label-off=` naming no
-`finisher-pr` member that `## Dispatched` or some row already carries.
-
-`review` holds a PR's review record to these rules, read across every row that
-maps to the PR — its settled `impl-<N>=PR#<M>` token, else its first `PR#`
-mention, else its key — in ledger order. Every `reviewed=` answers the nearest
-earlier launch that is neither answered nor `=failed`. A launch identity (a
-workflow's runId, or a runner's name, `=failed` aside) appears once, and no launch takes a runner name the
-ledger's `## Retired` holds — an earlier run of this session launched it —
-naming the next free reviewer name instead. No launch appears
-while an earlier one is open — unanswered and not `=failed`. Every
-`review=`/`reviewed=` parses. `row` holds the rest: a launch open before the
-write is still on one of the PR's rows after it, `=failed` allowed, and a
-member name appears once on the line, whatever its outcome. A write that adds
-a violation is refused, exit 2, nothing written; one already on the ledger and
-carried forward is not. A second launch refused for an open one waits for
-that one's `reviewed=`, or — once the Member-killed row confirms its runner
-dead — settles it `=failed` in the same `review` call as the new launch.
-
-Plus two append-only lists:
-
-- **filed** (`ledger.mjs filed <issue> <subject>`, checked with `ledger.mjs check
-  <subject>` before every `gh issue create`) — so a finding already recorded
-  this run is not filed twice. That is not a guarantee against duplicates at
-  large; the tracker query below is what covers those. The FILER writes this
-  one, not you: `review-and-fix.md` step 5 and finisher duty 2 each run `filed`
-  immediately after their own `gh issue create`, with the subject they passed
-  to `check`, and report `filed: #N <subject>`. A filer whose `filed` failed
-  twice reports `unrecorded: #N <subject>` instead — an `unrecorded` entry of
-  its report file — and `settle <member> --from-report` runs `filed` for it.
-- **ruled** (`ledger.mjs ruled <pr> <decision>`) — PR + decision + one-line reason,
-  so a replacement controller does not re-litigate a settled call.
-
-**Writer policy: the controller owns run state (`row`/`token`/`settle`/`dispatch`/`review`/`drain`/`ruled`); filers append filings with `filed`; all writes are serialized by `<file>.lock`.** See references/ledger.md.
-
-**The suite slots wedge the same ways, and clear the same way.**
-`~/.fleet/suite-slots/<i>.lock` is built on the ledger's lock primitive, so an empty or
-unparseable `<i>.lock` and a leftover `<i>.lock.reap` are permanent, a zombie
-holder is transient, and a dead holder is taken over. A wait that expired with
-exit 75 names each wedged file — remove it by hand once no suite run is
-running, the way references/ledger.md removes `<file>.lock`.
-
-**The gap the lock does not close:** `check` → `gh issue create` → `filed` is three commands, and the lock covers each one alone, so two filers can both read `clean` in the seconds before either records. See references/ledger.md.
-
-`check` exits **0** clean, **1** already in this run's filed list, **2** usage error (no JSON on stdout), **3** the ledger is clean but open or closed tracker issues match — read those and decide. See references/ledger.md.
-
-The ledger half reports its own readability as its own field, `ledger.ok`, the
-peer of `tracker.ok`: false when the file did not exist, and false too when the
-path led to something that did not parse as a ledger — which is what tells a
-ledger that was read and held nothing filed from one there was nothing to read. The absent case is the normal one for a run's first `check` — `.fleet/`
-is git-ignored and created lazily by the first write — so it stays `clean` at
-exit 0, and `ledger.ok` is the field that says why rather than the verdict
-moving. The stderr warning is deliberately narrower than the field: it fires on
-a path with no file, so a `--file` that landed on the wrong existing file is a
-silent `ok:false` with nothing on stderr. Gate on the field, not on the warning.
-
-**Write the ledger line before dispatching, not after.** A member that dies
-between spawn and write is invisible — and members die in batches.
-
 ## Failure handling
 
 Match the failure to its row in the table below and run that response; where the row says report or flag, stop there.
@@ -1737,6 +1382,10 @@ Match the failure to its row in the table below and run that response; where the
 | Member **killed** (spend limit, API error, crash) | Confirm it is dead first — a frozen transcript does not establish that; see below — then run the **Member confirmed dead or never dispatched** wake, then new member, new name, prompt carries inherited state |
 | Member **unaccounted** (a live token the tick flags `CHECK-LIVENESS`, or any live token nothing has reported on) | Registry census first: `read history://` once. A row other than `running` → `read agent://<member>` and the artifacts (PR head, worktree, labels), settle the real outcome with the existing vocabulary, and resume a `parked` member with `write agent://<member>` when its work is worth continuing. A `running` row → the mtime discriminator below, two polls: moved means BLOCKED and alive; frozen at both polls **and** no artifact movement → `write proc://<member>/kill`, the **Member confirmed dead or never dispatched** wake, fresh name. Three independent alive-signals — the first poll, the second poll, the artifacts — must all be silent before a kill; the tick settles and kills nothing |
 | A claim abandoned mid-run (a collision found after the claim) | `~/.fleet/bin/fleet-run release-ticket.sh <N> impl-<N> implementer --apply`, the pair the claim took. Run it over every claimed ticket with no PR when the run ends or the maintainer drains, and on the spot for a claim abandoned mid-run (a bail before implementing, a collision found after the claim). **That refusal is the finding, never an obstacle**: a claim carrying commits or a pushed branch is not auto-released, ever — run `worktree-audit.sh` (it audits every worktree; find this claim's row in the output) and decide by hand. Update the released tickets' ledger rows in the same step. See references/reaping.md |
+| A second review launch refused for an open one | Wait for that one's `reviewed=`, or, once the **Member killed** row has confirmed its runner dead, settle it `=failed` in the same `ledger.mjs review` call as the new launch. |
+| `ledger.mjs settle <member> --from-report` exits 3 | A check failed: the member's claim and the world disagree, and nothing is written. You rule. |
+| `ledger.mjs settle <member> --from-report` exits 2 | The report is absent or invalid, or a check could not look; nothing is written. A check that could not look is run again once `gh` and `git` answer. |
+| A suite wait exits 75 naming a wedged `~/.fleet/suite-slots/<i>.lock` | Remove each named file by hand once no suite run is running, the way references/ledger.md removes `<file>.lock`, then run the suite again. |
 
 ### Recovery
 
@@ -1768,10 +1417,6 @@ review-due. A
 runner member that is killed rather than failed follows **Failure
 handling** (fresh name, inherited state stated).
 
-## Guards
-
-Each guard here is a check to run before the step it guards: run it, and where it fails, stop and report rather than go on.
-
 **Verify every reported SHA.** `~/.fleet/bin/fleet-run verify-sha.sh
 <branch> <sha>` before enqueueing — a member can commit in a nested worktree,
 leaving the SHA on a stray branch while its report reads normally. Exit codes as
@@ -1787,14 +1432,7 @@ ticket over a failure a re-run would have cleared.
 
 **Never `--delete-branch` — the merge bot deletes the head branch itself.**
 `gh pr merge <n> --merge` alone: the flag's local cleanup errors on a `main`
-held by another worktree, or strands the feature worktree on `main`. After the
-merge, `delete-merged-branch.sh <pr>` deletes the branch from `origin` and reads
-the deletion back; `reap.sh` takes the `[gone]` local branch and its worktree.
-No repo setting is relied on to do it. A branch another open PR still
-uses as its head or base is kept instead — `branch-kept-#<that PR>` in the bot's
-report, a deliberate keep and not a failure.
-The branch-delete step also releases the claim label: it drops `in-progress` from
-every issue the PR closes.
+held by another worktree, or strands the feature worktree on `main`.
 
 **Never force a rebase to start.** No `git clean`, `git checkout .`,
 `git reset --hard`, `git stash`. Uncommitted changes may exist nowhere else.
@@ -1804,14 +1442,6 @@ empty answer here and licenses the rebase over work this check exists to
 protect. Stashing empties it either way, so that check and
 `no-undo-audit.sh` both go quiet on work nothing else holds.
 
-**Cross-check what members report about their environment.** Wrong often enough
-to matter, and a confident wrong report from a reviewer flips a verdict.
-
-**Distrust negative claims hardest.** "Nothing else references this", "the sweep
-is clean" — most likely false, least likely checked: a grep that found nothing
-looks like a grep never run. Make members state their search scope. Negative claim
-vs specific finding with paths → paths win.
-
 **Members share one filesystem, one docker stack and one process table**, and the
 failures arrive as *wrong findings*, not errors:
 
@@ -1830,70 +1460,18 @@ failures arrive as *wrong findings*, not errors:
   and the controller re-checks any measurement taken in the window.
 
   **Do not guess the victim — the blast radius is the machine, not the Pull.**
-  In that incident the controller reasoned from dispatch scope to "almost
-  certainly `impl-<N>`" and told the maintainer so; the named member then proved
-  it was not the victim (it had never invoked those files standalone, and its
-  mutation baselines post-dated the window). Idle members of *previous* runs,
-  other omp sessions on the same machine, and the maintainer's own shell are
-  all `pkill -f` targets and none of them appear in your ledger. Warn every live
+  Warn every live
   member, record the incident as unattributed, and re-check measurements by
-  timestamp rather than by who you think was running.
+  timestamp rather than by who you think was running. See references/isolation.md.
 
 - **A warning acted on silently is indistinguishable from one that never
-  arrived.** The same incident: the controller's warning DID reach the member,
-  which re-ran, found nothing changed, and said nothing — correctly reading
-  "send once, never re-send" as covering it. The controller then had to spend a
-  round trip asking whether its own outbox was lossy. So the briefs say that
-  **confirmation state includes warnings received and acted on, even
-  when the outcome is no change** — one line, in the report the member already
-  owes. That is the cheap half of the *never read silence as assent* rule, paid
-  by the member rather than by the controller's guesswork.
-
-- **Specialist tree isolation is `review-and-fix.md`'s job — do not restate it.**
-  It owns the object-store rule, the two-tree split, snapshot provisioning, and
-  which suites a snapshot cannot validly run. Your only duty is to *not*
-  contradict it.
-- **Filesystem isolation is not stack isolation.** A private copy of the
-  tree and a test command solve different problems; the compose project
-  name comes from the environment, not the working directory, so three
-  agents on three snapshots still collide on one postgres. "I'm on my own
-  copy" is exactly the intuition that skips the command — say both, every
-  time. Which command depends on the audience: a member in a worktree
-  uses `./agent-test`; a specialist on a snapshot does not, and takes the
-  one `review-and-fix.md` hands out. Which runner the worktree holds
-  decides why: the runner a claim writes is untracked, so a `git archive`
-  snapshot never carries it; one the repository tracks does ride along,
-  but no claim exported ports into it — its isolation is whatever that
-  repository built, not one triple per snapshot. See
-  references/isolation.md.
+  arrived.** See references/isolation.md.
+- **Specialist tree isolation is `review-and-fix.md`'s job — do not restate it.** See references/isolation.md.
+- **Filesystem isolation is not stack isolation.** See references/isolation.md.
 - **Scratchpad paths need two levels — the member's own partition, then one
-  directory per child it dispatches — and nothing outside them.** An
-  implementer partitions at `<scratch>/impl-<N>/`; the review side's partition
-  is `<scratch>/pr<N>/…`, which the review core creates itself, so a review
-  runner is handed the scratch root, never that partition; any member that
-  dispatches a child writes an absolute directory under its own partition into
-  that child's prompt, one per child and never shared, and a child never
-  derives its own. Finding ids restart at 1 every review, so two fix-appliers
-  on different PRs both reach for `unv1`; one
-  agent overwrote a sibling's `package.json`, and a probe built a git repo at
-  the *checkout root*. Read from the object store at a pinned ref, write only
-  under your own path. See references/isolation.md.
-- **IDE/harness diagnostics attribute by bare filename, with no path.** **Never
-  relay a diagnostic without reproducing it in that member's specific worktree**
-  (re-run the check that raised it from there): probe copies carry the real
-  tree's filenames, so a sibling's throwaway mutation reads exactly like a live
-  worktree's error.
-  See references/isolation.md.
-- **Every implementer body carries the claim discipline, because tickets that restate facts ship new wrong claims** — inherited from the ticket, and minted in prose nobody asked for. See references/correction-tickets.md.
-- **The settling command for "which files read X" must never be a literal-path
-  grep.** Replace the file with `MUTATED` in a throwaway copy, run the suite, and read off
-  which suites red: that answers which ones **depend on its contents**, which is
-  the question a coverage claim actually needs, and it returns a different set
-  from any spelling of the grep. See references/correction-tickets.md.
-- **A settling command over literal text uses `grep -F`, and its zero counts only after the same command finds a line known to match.** See references/correction-tickets.md.
-
-Suspect a neighbour before a member's own diff — for unexplained failures, and
-equally for any **finding** that came from reading source.
+  directory per child it dispatches — and nothing outside them.** See references/isolation.md.
+- **Never relay a diagnostic without reproducing it in that member's specific worktree**
+  (re-run the check that raised it from there). See references/isolation.md.
 
 ## Red flags
 
@@ -1942,3 +1520,15 @@ One running table, updated as events land:
 ```
 
 Plus a queue-depth line: shortlist, supply, whether triage was suggested.
+
+**Do not read a cell early.** A cell's
+comparison is one session holding an admissible row at that cell — its tier
+check passed and its resolved effort is the cell's level — and one at
+`slow-high` whose resolved model and effort differ. Count them per cell, never
+pooled across cells, and stop until
+there are at least ten of them across five or more distinct `run_date`s; below
+that, a comparison count is a number, not evidence. **Report the count the per-cell readout prints,
+never one from any other query:** `~/.fleet/bin/fleet-run cell-readout.mjs`
+prints `<cell> <comparisons> <run_dates> <resolved models>` for each cell past
+that floor and a cell below it only as a count on stderr; a `mixed (…)` models
+column means the cell's history spans more than one model behind its role. See references/pull.md.

package/skills/run-team/references/isolation.md

@@ -1,6 +1,6 @@
 # Isolation: filesystem vs stack
 
-Why isolation envelope file not briefing, why private filesystem not private stack. Assertions these justify live in references/pull.md Claiming section and SKILL.md Guards section; evidence here.
+Why isolation envelope file not briefing, why private filesystem not private stack. Assertions these justify live in references/pull.md Claiming section and SKILL.md Failure handling section; evidence here.
 
 ## Materialize the isolation envelope as a file, not a briefing
 
@@ -262,3 +262,29 @@ get is not yours to choose — members are briefed on `./agent-test` with the
 arguments the Test entrypoint takes, and the runner hands them on exactly as
 its caller's shell expanded them. Clearing your own leftover process needs its
 PID, not a pattern.
+
+## Do not guess the victim — the blast radius is the machine, not the Pull
+
+In the `pkill -f` incident "A pattern kill reaches siblings" measures, the controller reasoned from dispatch scope to "almost
+certainly `impl-<N>`" and told the maintainer so; the named member then proved
+it was not the victim (it had never invoked those files standalone, and its
+mutation baselines post-dated the window). Idle members of *previous* runs,
+other omp sessions on the same machine, and the maintainer's own shell are
+all `pkill -f` targets and none of them appear in your ledger.
+
+## A warning acted on silently is indistinguishable from one that never arrived
+
+The same `pkill -f` incident: the controller's warning DID reach the member,
+which re-ran, found nothing changed, and said nothing — correctly reading
+"send once, never re-send" as covering it. The controller then had to spend a
+round trip asking whether its own outbox was lossy. So the briefs say that
+**confirmation state includes warnings received and acted on, even
+when the outcome is no change** — one line, in the report the member already
+owes. That is the cheap half of the *never read silence as assent* rule, paid
+by the member rather than by the controller's guesswork.
+
+## Specialist tree isolation is `review-and-fix.md`'s job
+
+It owns the object-store rule, the two-tree split, snapshot provisioning, and
+which suites a snapshot cannot validly run. Your only duty is to *not*
+contradict it.

package/skills/run-team/references/ledger.md

@@ -1,6 +1,6 @@
 # The run ledger: the evidence behind its rules
 
-Evidence for the rules SKILL.md states in **Run ledger**, keyed by the rule each justifies.
+Evidence for the rules SKILL.md's wake and dispatch sections state, keyed by the rule each justifies.
 
 ## Writer policy: every write is serialized by `<file>.lock`
 
@@ -55,3 +55,49 @@ them before filing. The stdout JSON names all of that in one field:
 `unverified`. Only `already-filed` and `tracker-hit` carry a non-zero code, so
 `verdict` is the only thing that tells a searched-and-clean tracker from one
 that was never read and from one whose rows you have to read yourself.
+
+## Why the ledger outlives your context
+
+One git-ignored `.fleet/ledger.md` per run is updated at every state change through the `~/.fleet/bin/fleet-run ledger.mjs` subcommands (`row`, `filed`, `ruled`, `check`, `read`, `dispatch`, `settle`, `review`, `drain`, `rotate`). Your context is the least durable thing in the run: it compacts, and a controller that loses the dispatch map or the filed list redoes finished work. Two duplicate tickets shipped in one run from exactly that.
+
+## One line per ticket
+
+One line per ticket, rewritten in place (`ledger.mjs row <ticket> <text>`; `ledger.mjs token <key> <token>…` adds a token and keeps every token already on the row):
+
+```
+#<t1> impl-<t1>=PR#<p1> → PR#<p1> → MERGED 73b356de
+#<t2> impl-<t2>=PR#<p2> → PR#<p2> · fix-pr-<p2> · ports=16<t2> · ruled:6-applies · held-behind:#<t3>
+#<t3> impl-<t3> · tier=task-high
+#<t4> excluded · behind-pr:#<p2>
+#<t5> excluded · behind-issue:#<t3>
+```
+
+## Writing before dispatch
+
+A member that dies between spawn and write is invisible — and members die in batches.
+
+## filed and ruled
+
+`filed` is checked with `ledger.mjs check <subject>` before every `gh issue create`, so a finding already recorded this run is not filed twice. That is not a guarantee against duplicates at large; the tracker query, described under `check`'s exits and its `verdict` above, is what covers those.
+
+`ruled` records PR + decision + one-line reason, so a replacement controller does not re-litigate a settled call.
+
+## Label-off and conflict holds
+
+`label-off=<finisher-pr-M[-x]>` is written before you take `ready-to-merge` off PR M on purpose (taking it off before you approve a push, or clearing one left on a moved head), naming that PR's latest finisher attempt: the tick reads a missing label as a finisher's miss only after the last attempt a `label-off=` names, so without it your own removal reads as one.
+
+`ci=<run-id>:<attempt>:<conclusion>` and `held-behind:#<lower>` are row tokens the same way, and so is `conflict-hold:#<pr>` — written by the merge bot itself (`run-merge-bot.md` step 1), or by you off the tick's `CONFLICT` line, naming the row's own PR. It is not an Exclusion: that gates a ticket's claim, this a PR's merge.
+
+## The review pair on a PR's row
+
+A PR's review is not a member, so it carries its own pair of row tokens, written with `review` onto the PR's row (**The reviewer**): `review=wf:<runId>` | `review=member:<name>` at launch, `<name>` being `review-pr-<n>` for the PR's first runner and the next letter its rows do not carry yet (`review-pr-<n>-b`, `-c`, …) for every later one, settled dead as `…=failed`, then `reviewed=<head>:<survived>/<refuted>/<unverified>:<run>` when the result lands, `<run>` the review's `run-XXXXXXXX` run root under `<scratch>/pr<n>/`, which holds its `review.json`.
+
+## The ledger's readability field: `ledger.ok`
+
+The ledger half reports its own readability as its own field, `ledger.ok`, the peer of `tracker.ok`: false when the file did not exist, and false too when the path led to something that did not parse as a ledger — which is what tells a ledger that was read and held nothing filed from one there was nothing to read. The absent case is the normal one for a run's first `check` — `.fleet/` is git-ignored and created lazily by the first write — so it stays `clean` at exit 0, and `ledger.ok` is the field that says why rather than the verdict moving. The stderr warning is deliberately narrower than the field: it fires on a path with no file, so a `--file` that landed on the wrong existing file is a silent `ok:false` with nothing on stderr.
+
+## Suite slots
+
+**The suite slots wedge the same ways, and clear the same way.**
+
+`~/.fleet/suite-slots/<i>.lock` is built on the ledger's lock primitive, so an empty or unparseable `<i>.lock` and a leftover `<i>.lock.reap` are permanent, a zombie holder is transient, and a dead holder is taken over. A wait that expired with exit 75 names each wedged file — remove it by hand once no suite run is running, the way the Writer policy section above removes `<file>.lock`.

package/skills/run-team/references/pull.md

@@ -426,6 +426,71 @@ is not enough either: the two rows must actually have RUN a different model or
 effort, because a deliberate dispatch whose two sides resolve to the same model
 (a `modelRoles` override, measured on omp 2026-09-12) controls nothing.
 
+## Accumulate per PR, never conclude a tier result inside one run
+
+The unit is the PR —
+supply is one Pull per free slot, so there are no implementer batches. The
+guard this section speaks of is SKILL.md's **Guard: accumulate per PR, never
+conclude inside one run**, under **Reading a review result**.
+
+**Why not decide inside one run.** A run holds 2-3 implementer PRs, and ticket
+difficulty swamps the tier effect — a gojq parity harness and a two-statement
+shell reorder are not comparable units. Finding-counts are not comparable either:
+`selectDimensions` trims the fan-out by diff profile, so one PR fields 29 agents
+over six dimensions and its sibling fields 8 over three. And the fleet is not
+stationary — this prompt gets edited mid-run when a defect earns it. Hence a
+binary outcome per PR, accumulating, rather than a per-run verdict.
+
+**Why the rows this guard fired on could not answer the tier question, and this
+is the load-bearing part.** Until the 2026-08-16 revert, `class` and `tier` were
+perfectly confounded: routine always ran `sonnet`, correction always ran top
+tier. So the comparison the file invites — routine-at-sonnet against
+correction-at-top-tier — measures **class, not tier**, because those classes fail
+in different ways by construction: corrections ship false claims in prose,
+routines ship incomplete or regressing code. A run that "mixes both" does not fix
+it. **Only a same-class comparison across tiers is informative**, and the old
+rule could not produce one, since no routine ticket ever ran at top tier.
+
+**That last sentence is no longer true, and this is the part to re-read.** Since
+the revert every routine ticket runs at top tier, so the file now holds 55
+`routine`/`opus` rows against 11 `routine`/`sonnet` (as of 2026-08-28, 103 rows
+— recount before citing). The same-class comparison the paragraph above calls
+the only informative one therefore EXISTS now. It is still not clean: the two
+groups are split almost entirely by calendar date, so it measures prompt
+evolution at least as much as tier. Recount
+both, and every other figure in this section, with:
+
+```bash
+grep -vc '^#' docs/metrics/tier-outcomes.tsv
+awk -F'\t' '!/^#/ && $4=="routine" {n++; d[$1]=1; if($6=="no") no++} \
+  END{print n, length(d), no+0}' docs/metrics/tier-outcomes.tsv
+awk -F'\t' '!/^#/ && $4=="routine" {t[$5]++; if($6=="no") f[$5]++} \
+  END{for(k in t) print k, t[k], f[k]+0}' docs/metrics/tier-outcomes.tsv
+```
+
+**These rows are the historical corpus, and nothing appended to them fixes the
+confound.** What fixes it is the exploration draw in the dispatch rule above:
+one implementer in every five — every one, during burn-in — runs at a drawn
+cell beside the policy cell's, against the same prompts on the same day, so
+the comparison stops depending on which tier history happened to leave in
+which week. Read each cell's comparisons, not the whole-file split, once there
+are enough of them.
+
+**So read what the guard actually established: routine tickets sometimes fail to
+close their own ticket. Not that `sonnet` caused it.** The revert is the
+pre-committed rule being honoured, not a measurement. Restoring a cheap tier is
+still the maintainer's call and still a change to the dispatch rule — but the
+deliberate control it used to require is no longer something anyone has to
+authorize one ticket at a time: the exploration draw above produces one in
+every five Pulls by construction.
+
+The last guard fired with n=1 on the control side. The pre-cell pair query
+counted pairs that are no cell's comparisons, and the query before that one
+counted every session whose implementers merely differed, so it cleared the
+cell floor SKILL.md's **Report** states — at least ten comparisons across five
+or more distinct `run_date`s — by an order of magnitude while the controlled
+comparison did not exist yet.
+
 ## Why the implementer body carries enumerate-and-declare
 
 Why the agent body carries what it does — read this before editing any

package/skills/run-team/references/reviewers.md

@@ -27,6 +27,10 @@ in-between width cannot be told apart from a shifted one. The `note` field is
 free text and sits before those four, so the script refuses a tab or newline in
 it: one tab would shift all four for that row alone.
 
+**Phase 0 does not size anything** — it shortlists, a Pull claims, and
+the sizing run happens inside the member after both, which is why the verdict
+has to travel in the member's report rather than being something you already hold.
+
 ## Know the trim before you rely on it
 
 **Know the trim before you rely on it — it is wider than `docsOnly` suggests.**
@@ -135,3 +139,12 @@ reviewed and is not.
 ## The review's scratch is the scratch root, not its partition
 
 **`scratch` is the scratch root itself, the absolute path `scratch-root.mjs` prints, never the review side's `<scratch>/pr<N>` partition:** the review creates `pr<N>/` under it, so a `pr<N>` passed in nests every run root at `pr<N>/pr<N>/`, and the review refuses a `scratch` whose last component is `pr` plus digits before dispatching anything.
+
+## Cross-check what members report, and distrust negative claims hardest
+
+Wrong often enough
+to matter, and a confident wrong report from a reviewer flips a verdict.
+
+"Nothing else references this", "the sweep
+is clean" — most likely false, least likely checked: a grep that found nothing
+looks like a grep never run.

package/skills/run-team/references/tick-rows.md

@@ -14,7 +14,7 @@ The full text of each row `fleet-tick.mjs` prints and what it asks of the contro
   lifted), the implementer row's `unclaimed=` prints that same
   `<u>`, not the refreshed file's count.
 - `SUGGEST /triage, hold idle` — nothing is admissible after the refresh.
-  Suggest, never run (**Queue depth**). A head whose Pull already ended in
+  Suggest, never run. A head whose Pull already ended in
   this run is not counted toward the refresh, so a shortlist of only such
   heads triggers the refresh before this row prints. It is not printed while the
   refreshed shortlist holds a head whose Pull ended only on an exclusion whose
@@ -30,7 +30,7 @@ The full text of each row `fleet-tick.mjs` prints and what it asks of the contro
   (**The reviewer**).
 - `DISPATCH merge-bot` — the next `merge-bot-<n>` (**The merge bot**). The `<scratch>` its brief takes is the absolute `scratch-root.mjs` output, and the bot writes only under `<scratch>/pr<N>/merge-bot-<n>/`.
 - `DISPATCH finisher PR#<M> …` — a finisher settled `labelled`, yet the open
-  list shows PR M without `ready-to-merge`, and no `label-off=` (**Run ledger**)
+  list shows PR M without `ready-to-merge`, and no `label-off=` (references/ledger.md)
   accounts for the removal. Apply the finisher gate (**The finisher gate**: the
   `check` job green on the current head), then dispatch the next-suffix
   finisher at that head, one letter past the highest the PR has used: render
@@ -245,3 +245,11 @@ The full text of each row `fleet-tick.mjs` prints and what it asks of the contro
   could-not-look (exit 2), never a mismatch. The settle runs neither command,
   and a repository whose Recipe cache is absent or refused has no gate; the
   record is the member's own word, at the trust level of its report.
+
+## Read the depth off the tick, never derive it by hand
+
+**Do not re-derive this by hand — `fleet-tick.mjs` computes it.** The deficit is then *computed, not remembered*, which is
+the whole point: a table you must remember to consult is one you will not
+consult under a merge-side event storm, and that is how implementers reached
+0/target with ~57 `ready-for-agent` in supply while nobody
+noticed.