@feigi/fleet-ctl 3.82.12 → 3.82.14

package/skills/run-team/briefs/fix-applier.md

@@ -53,7 +53,7 @@ and `cwdAudit` before any result of the shared test run. Every one of those
 rulings is yours — nobody upstream has made one, and the controller never
 reads the findings.
 
-**Run `<checkCmd>` from the worktree before committing**, copied verbatim. **Run `<testCmd>` from the worktree before committing**, copied verbatim.
+**Run `recipe-check.mjs` (below) from the worktree before committing.**
 `tests 0` is a FAILED run, not a pass. Red or zero-test → fix it, or move that
 finding to defer; never commit over it. **Never `--no-verify`** on a commit you push, or on the push — a failing
 hook is a finding you report, not an obstacle you route around. Report the test
@@ -67,11 +67,11 @@ claim, never your patch.
 ## kind: conflict
 Bring `<branch>` current with `origin/main`, resolving every conflict by the
 **No-undo audit** in `$(~/.fleet/bin/fleet-run --root)/commands/run-merge-bot.md`.
-Run `<checkCmd>` and `<testCmd>` from the worktree before you push, then push with
+Run `recipe-check.mjs` (below) from the worktree before you push, then push with
 `~/.fleet/bin/fleet-run push-sync.mjs --branch <branch>`. Report the new head, or that no conflict was
 left.
 ## kind: red-check
-Read the failing job's log and fix the cause. Run `<checkCmd>` and `<testCmd>`
+Read the failing job's log and fix the cause. Run `recipe-check.mjs` (below)
 from the worktree before you push, then push with `~/.fleet/bin/fleet-run push-sync.mjs --branch <branch>`.
 Report the new head and **stop**: do not watch, poll or wait for CI — the
 controller owns the next run on the pushed head. A red that is not yours to
@@ -90,6 +90,16 @@ runs the hook, so every change still unstaged after it is the hook's alone:
 never stage those, `git restore -- <that path>` for each such path alone, then
 rebase and re-run.
 
+**`recipe-check.mjs` is how you run `<checkCmd>` and `<testCmd>`:**
+`~/.fleet/bin/fleet-run recipe-check.mjs --member <your name> --testCmd "<testCmd>" --reports <scratch>/reports`,
+from the worktree, after `git add` and before the commit — `<testCmd>` copied
+verbatim as the one quoted argument. It runs the Recipe's Check step,
+`<checkCmd>`, then `<testCmd>`, against the staged tree and records both beside
+your report. Run it again after any content change or rebase: the controller
+refuses an `applied` report whose head's tree has no green record, and a
+message-only amend keeps the record valid. Exit 1 is red; exit 75 is no test
+result — no slot was free and nothing ran — so run it again.
+
 Your report is a file, `<scratch>/reports/<your name>.json`, `<your name>` the
 `fix-pr-` name you were dispatched as, in the shape
 `~/.fleet/bin/fleet-run report-schema.mjs print fix-pr` prints. Write it

package/skills/run-team/briefs/implementer.md

@@ -22,6 +22,14 @@ The ticket, pasted verbatim from the controller's own read — its title, the
 
 The controller's staleness probe: <staleness>
 
+Before you commit and push, run
+`~/.fleet/bin/fleet-run recipe-check.mjs --member <your name> --testCmd ./agent-test --reports <scratch>/reports`
+from the worktree, after `git add`: it runs the Recipe's Check step, then
+`./agent-test`, against the staged tree and records both beside your report.
+Run it again after any content change or rebase. The controller refuses a
+report whose head's tree has no green record, and exit 75 from it is no test
+result — run it again.
+
 Your report is a file, `<scratch>/reports/<your name>.json`, `<your name>` the
 `impl-<N>[-x]` you were dispatched as, in the shape
 `~/.fleet/bin/fleet-run report-schema.mjs print impl` prints. Write it before

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

@@ -200,7 +200,7 @@ kernel — is a session setting a child inherits, not something one dispatch can
 set for one member. Isolating a member's kernel is an omp-side change, so
 discipline is the whole of the remedy here — unlike the missing `cwd` field
 above, which `member-write-guard` enforces for `write`/`edit`/`ast_edit` and
-`eval` bypasses. **Phase 2** carries all three rules to every member.
+`eval` bypasses. **Dispatching the Pull's member** carries all three rules to every member.
 
 ## `release-ticket.sh` is not a no-op on omp, and a running member hides nothing from `inflight.sh`
 

package/skills/run-team/references/member-lifecycle.md

@@ -99,3 +99,49 @@ warning is the only reason it did not repeat the stall. Its
 the poll it was waiting on was structurally incapable of firing. This file is
 yours, not theirs: the implementer, fix-applier and finisher briefs carry the
 rule, as the line `A member runs its test suite in the foreground and blocks on it.`
+
+## No workpool, and no kernel-resident handle
+
+A pool's only refill virtue — handing a queued item to a freed worker without a controller turn — is exactly what a Pull forbids, and its completions never arrive per member. `eval`'s `agent()` is not the omp call either: a kernel-resident handle dies with the kernel and needs a `wait`, while a `task` job is process-level and its report auto-delivers on its own, like every other member's.
+
+## One claim, one dispatch, no queue
+
+The In-flight bound is the fleet's own accounting rather than anything the runtime enforces, and the member is fresh and never a wake of one that already ran. Admission is per slot and never batched, so there is nothing to hand a freed slot its next ticket but the next Pull.
+
+## The prompt pastes the Pull's own read
+
+The prompt pastes the Pull's own read of the ticket rather than telling the member to re-fetch it, and this still costs one `gh issue view` per ticket, never one per member. The fresh-context design's isolation rationale — "every implementer re-reads its Agent Brief... from scratch" — is about a member never inheriting another ticket's context, not about where the bytes come from. Pasting the Pull's own read into the prompt keeps that: the member still gets the brief verbatim and re-derives nothing from a sibling. What it drops is the unconditional re-fetch of an issue the controller already has open, on every dispatch — the fetch the agent body still carries is the backstop for a brief that turns out to be insufficient, not the default path.
+
+## A member settling with nothing is not a bail
+
+Each member's outcome arrives as its own job status. Settle (CONTEXT.md § Coordination) is three states on omp — `completed`, `failed`, `cancelled` — and reading `failed`/`cancelled` the same as a `completed` turn that had nothing to report is the exact collapse this line blocks: a member that died never chose to bail, so demoting its ticket on its silence demotes a ticket its member never got the chance to judge. Confirm death first, exactly as the Member-killed row does (Failure handling in SKILL.md) — its mtime discriminator, never silence alone.
+
+## The implementer's tier is the definition's
+
+The tier lives in that definition's frontmatter (`agents/fleet-implementer-<cell>.agent.md`; `slow-high`, the policy cell, for a row with no `tier=`), which is what an omitted `model` takes first — the session's tier applies only when the definition names none, and a member dispatched with `model` set does not get the declared tier back. Omitting `model` is therefore still the mechanism; what changed is that the tier it resolves to is now declared and pinned rather than inherited by accident. Keep `name: impl-<N>`: the name is what makes a member, and both the spend classifier and `member-outcomes.mjs` read it.
+
+## The merge bot's tier buys nothing its backstop does not cover
+
+Rebase, wait for green, check the label, merge is checklist work, and a bad merge still needs the label and the per-job CI state to have been read correctly, which is exactly what a wrong merge later surfaces and a human resolves; `no-undo-audit.sh` is the deterministic, script-driven backstop run before every push specifically to catch a wrongly-resolved conflict, so the tier buys nothing that backstop doesn't already cover.
+
+## The red-check fixer's three edges
+
+The Monitor is edge-keyed on `<run-id>:<attempt>:<conclusion>`, so a red that fired before the review never fires again, and with no push there is no new run — the other edges are the only route there, so do not wait for an event. Edit one of the three finisher-gate edges without the others and what strands is exactly the red-only PR.
+
+Take the common case, the implementer's own first CI firing turning red before any review exists: the review is still dispatched against that head as normal, because a red suite is review evidence and not a blocker.
+
+## The tier check judges the dispatch-time tier
+
+The check reads the installed definition and the live `modelRoles` at check time, not at dispatch time, so a late check judges a member against a tier it was never dispatched under.
+
+## The tier check after a /resume
+
+A live implementer rotate carried forward with no verdict on its row is unchecked, and once this session has been reopened with `/resume` its transcript sits under the earlier session's directory: the check given this run's `session` finds no `<member>.jsonl` and exits 2, writing nothing.
+
+## Dispatching on an unchecked member multiplies the damage
+
+Dispatching the next member on top of an unchecked or mismatched dispatch multiplies whatever silently degraded.
+
+## Ledger reads and their buffer
+
+`board.mjs` reads `ledger.mjs read` with an explicit `maxBuffer`, so a payload past node's default is carried rather than killed mid-flight and reported as an unreachable tool — which is how the blind cockpit came back at HTTP 200 even after the pipe cut was gone.

package/skills/run-team/references/phase-0.md

@@ -334,7 +334,7 @@ PROVEN`** → re-run both reads above (`derive-testcmd.sh . install` and
 below; their output is the Recipe this run uses. **`RECIPE NOT PROVEN`** →
 stall, below.
 
-**Where `checkCmd` comes from:** the repository's Check step, out of the same Recipe cache — `~/.fleet/bin/fleet-run derive-testcmd.sh . check` prints it. Pass it to the fix-applier beside `testCmd`; the review does not run it.
+**Where `checkCmd` comes from:** the repository's Check step, out of the same Recipe cache — `~/.fleet/bin/fleet-run derive-testcmd.sh . check` prints it. Pass it to the fix-applier beside `testCmd`; the review does not run it. Neither member runs the two by hand: `recipe-check.mjs` runs the Check step it reads off that cache, then the `testCmd` it is handed, on the member's staged tree, and writes the record `ledger.mjs settle --from-report` requires of an implementer's and a fix-applier's report.
 
 **Mid-run, a cache that stops running is re-derived once, then the run
 stalls.** A claim or a review that refuses because the Recipe cache is
@@ -424,7 +424,7 @@ token, row}]}`:
 A `resume` follows the Member-killed row across the run boundary: a new
 member under a new name — `impl-<N>-b`, or one letter past the highest
 `impl-<N>-<x>` in the archive that rotate printed the path of — on the same
-ticket, in the printed worktree and branch, its prompt the phase 2 prompt
+ticket, in the printed worktree and branch, its prompt the dispatch prompt
 off a fresh read of the issue plus what it inherits (`git -C <worktree> log
 --oneline origin/main..HEAD`, `git -C <worktree> status --short`, and the
 files under `<scratch>/impl-<N>/`). Record it the ordinary way —

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

@@ -191,7 +191,7 @@ terminating in exactly one dispatch or an empty shortlist:
    without a positive and a negative control misattributes causes rather than
    merely missing defects — one such check needed a purpose-built fixture plus
    both. A ticket no single string settles is a `could not check`: admitted,
-   annotated in the dispatch prompt (phase 2), never quietly dropped.
+   annotated in the dispatch prompt (the Pull's dispatch), never quietly dropped.
 
    **This is a consumption gate**, priced for the seat where implementer
    divergence costs a claim, a worktree and a dispatch; at filing time every
@@ -199,7 +199,7 @@ terminating in exactly one dispatch or an empty shortlist:
    `ready-for-agent`.
 
    No sizing agent here. `sizing-a-ticket` picks the *process path*, and that is
-   phase 2's call, after the ticket is claimed.
+   the dispatch's call, after the ticket is claimed.
 4. **Collision scan against open PRs and live branches** — `pull.mjs` runs it
    before Q3 and prints one line per open PR or live worktree branch that shares
    a path with the brief, `no overlap` when none, and `could not look: <which>`
@@ -227,14 +227,26 @@ terminating in exactly one dispatch or an empty shortlist:
 7. **Route, row, then dispatch** — `~/.fleet/bin/fleet-run ticket-router.mjs route
    --session <session> --ticket <N> --arm <A|B> --impl-row <k>[ --chain-head] --issue
    <scratch>/impl-<N>/issue.json --guard .fleet/cost-guard.json` prints
-   `POLICY=… CELL=… DRAW=… STRATUM=… REASON=…` (phase 2's exploration rule
+   `POLICY=… CELL=… DRAW=… STRATUM=… REASON=…` (the router's arguments paragraph below the list
    says what each argument is); then `ledger.mjs row <N> "impl-<N>[ · tier=<CELL>][ · route=<REASON>]"`,
-   `tier=<CELL>` exactly when `DRAW` is not `-`; then phase 2 at once: claim
+   `tier=<CELL>` exactly when `DRAW` is not `-`; then the dispatch at once: claim
    what you are about to dispatch; dispatch what you have just claimed. Router
    exit 2 → no row and no dispatch: release the claim (`release-ticket.sh`, SKILL.md's
    Failure handling row for a claim abandoned mid-run) and emit an event, a probe that could not look — a table the router
    refuses refuses every Pull.
 
+**The router's arguments, and nothing past its line.** `--impl-row` is the
+row count the Pull creates — or, while an assignment is rolling (the latest
+row 5k and every row after it carry no `tier=`), that row's number;
+`--chain-head` marks a ticket another open ticket sequences after, which is
+what rolls it. `--arm` is `A` for an even ticket number and `B` for an odd
+one; a B Pull routes exactly as an A one until the table opens arm B.
+`--session` is this run's own session directory. The printed line is the
+whole routing decision — never re-derive `CELL` from the table, the guard or
+this paragraph. A missing or unreadable `.fleet/cost-guard.json` routes the
+default cell only (`REASON=guard-missing`), burn-in included, and `REASON`
+other than `ok` goes on the row as `route=<REASON>`, nowhere else.
+
 **The Pull table** — every verdict a Pull can reach, and the one thing each
 does:
 
@@ -250,7 +262,7 @@ does:
 | a construct the brief names, or a brief `path:line` reference, lands in or next to a hunk of an open PR or a live branch | exclude `behind-pr:#M`, next entry |
 | `Out of scope` sequences it after an open ticket | exclude `behind-issue:#M`, next entry |
 | `claim-ticket.sh` exit 2 | taken, next entry |
-| decided, live, free, claimed | row, then dispatch (phase 2) |
+| decided, live, free, claimed | row, then dispatch |
 
 **The shortlist runs out → run `shortlist.mjs` once and Pull again; still
 empty → hold the slot idle until the next refresh trigger.** Within a turn,
@@ -467,3 +479,17 @@ whatever woke you: a member finishing, a member bailing before implementing, a
 merge landing. An edge-triggered loop that only Pulls on completion stalls
 silently the moment the shortlist empties, because 0 implementers emit no
 completion event.
+
+## The rate counts Pulls, not members
+
+**Count the rate against the ledger, because a Pull is the dispatch unit.** One Pull is one member, so a rate counted per Pull is a rate counted per member — one implementer in five, however the Pulls fall across the run — and the ledger, not your memory, is what still holds the count after a compaction.
+
+## Why the exploration pairing is within-run
+
+**Why one in five within the run, not a week of one tier then a week of the other:** tier would then be confounded with calendar date and therefore with prompt evolution, which is exactly the state the rows already on disk are in, and why they cannot answer the question they were collected for.
+
+The raw split still favours the top tier — 3 failures in 11 `routine`/`sonnet` rows against 3 in 55 `routine`/`opus`. **Do not read that as a tier result.** Tier remains largely confounded with calendar date and therefore with prompt evolution: 8 of the 11 `sonnet` rows fall on 2026-08-13 to 08-17, before the window in which 54 of the 55 `opus` rows were run, and the dispatch prompts gained rules throughout. The confound is **weakened, not resolved.** Three `sonnet` rows now break it rather than one — a maintainer-authorized deliberate control (2026-08-20) and two more (2026-08-21) — all three run against prompts of the same vintage as the `opus` rows, and **all three passed**, which is the direction opposite the raw split. Three is still not a result. **What replaces this argument going forward is the within-run pairing above**: one implementer in five at the alternate tier makes tier orthogonal to date by construction, so the question stops depending on whichever rows history happened to leave. **Orthogonal to date, and to nothing else** — the alternate member is whichever ticket the 5th Pull draws, rolling past every ticket another open one sequences after, while the top tier absorbs all of those, so the pairing trades the calendar confound for a difficulty one that runs in a known direction. That is why the four covariates exist: condition a pair comparison on `sizing`/`profile`/`loc`/`files` before reading it as a tier result, never on the raw split.
+
+## What minted_false_claim reads
+
+`minted_false_claim` **discriminates and no longer reads "always yes"** — 20 of the 66 `routine` rows carry `no`, 18 at `opus` and 2 at `sonnet`. Read it as a property of the TICKET before the tier: a pure code simplification need not add prose, while a correction ticket adds prose by construction. The honest summary is unchanged and is the reason this paragraph exists: the guard fired on the criterion the maintainer chose in advance, not on a demonstration that the cheaper tier is worse.

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

@@ -1,6 +1,6 @@
 # Reviewers: the evidence behind the review-side rules
 
-Evidence for rules SKILL.md states in Phase 2 and **Reading a review result**, keyed by the rule each justifies.
+Evidence for rules SKILL.md states in **Dispatching the Pull's member**, **Dispatching the members a wake names** and **Reading a review result**, keyed by the rule each justifies.
 
 ## A sizing verdict is a measurement only if it post-dates the run that produced it
 
@@ -131,3 +131,7 @@ The review throws on missing `args.pr`/`args.worktree` and on a snapshot agent
 that returned no tree, and a failure surfaces mid-loop, where "react, never
 block" makes it easy to log and carry on — leaving a PR that *reads* as
 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.

package/skills/run-team/references/shell-traps.md

@@ -10,6 +10,8 @@ one it runs in. **Own the CI waits**'s monitor paragraph points here instead of
 restating any of it. The merge bot's agent body is the one place this block is
 copied whole (see **The merge bot**); the other deliberate copy is named at the end.
 
+A bot already looping cannot be corrected — the loop consumes the turns a correction would land in — so `agents/fleet-merge-bot.agent.md` carries **every entry in `references/shell-traps.md`'s Shell traps**, each written out in full: the rules with the measurements from that file beside them, and the bot has them before its first turn. An edit to `references/shell-traps.md` lands in that body in the same change.
+
 **zsh word-splits an unquoted command substitution's result; it does NOT split an unquoted parameter expansion.**
 
 **Word the rule against the first row.**

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

@@ -3,19 +3,22 @@
 The full text of each row `fleet-tick.mjs` prints and what it asks of the controller. SKILL.md's **The tick's rows** carries one line for each.
 
 - `PULL #<N> …` — one Pull per named ticket, in the order printed: phase 1's
-  read, then phase 2's dispatch. A ticket that fails the read is relabelled or
+  read, then the dispatch. A ticket that fails the read is relabelled or
   excluded (phase 1), and the next tick names the next head.
 - `REFRESHED shortlist: <n> entries; <k> lifted` — the tick refreshed the
   shortlist itself, and its `PULL` row already reads the result. `REFRESH
   FAILED` is yours: `shortlist.mjs` could not run, and the implementer row is
   blind until it can. When the refresh ran because fewer than B heads were
   unclaimed (`unclaimed <u> < in-flight bound <B>`), a head whose Pull ended
-  this run not counted, the implementer row's `unclaimed=` prints that same
+  this run not counted (unless it ended on an exclusion whose premise has
+  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
   this run is not counted toward the refresh, so a shortlist of only such
-  heads triggers the refresh before this row prints.
+  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
+  premise has lifted and a slot is free: that head gets its `PULL` row.
 - `specs-dropped=#<N> … (to-spec: User Stories heading)` at the end of the
   implementer row's counts, whatever its ACTION — the tickets the to-spec
   filter kept out of `supply`, read off the shortlist's `dropped`. Never
@@ -25,7 +28,7 @@ The full text of each row `fleet-tick.mjs` prints and what it asks of the contro
   ahead of reviews on purpose: finishing what is started beats starting more.
 - `DISPATCH review PR#<M> …` — a review per PR, oldest first, off your turn
   (**The reviewer**).
-- `DISPATCH merge-bot` — the next `merge-bot-<n>` (**The merge bot**).
+- `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**)
   accounts for the removal. Apply the finisher gate (**The finisher gate**: the
@@ -104,7 +107,7 @@ The full text of each row `fleet-tick.mjs` prints and what it asks of the contro
   the hold stays while the check writes no verdict (its `tier-ok=`, or
   `tier-unverifiable=` for a member settled `killed` or `released` with no
   transcript, clears it); a mismatch is yours to clear, by dispatching the
-  replacement at the right tier (phase 2). Each prints its clearing step in
+  replacement at the right tier. Each prints its clearing step in
   the row's detail. For a mismatch that is the replacement's name —
   `impl-<N>-b` on a first retry, else one letter past the highest the ticket
   has used, or that no retry letter is left. For an unchecked tier, which
@@ -112,6 +115,24 @@ The full text of each row `fleet-tick.mjs` prints and what it asks of the contro
   by hand when the tick ran without `--apply` or the check wrote no verdict,
   with a batch entry per member it names (fill in `<file>`; `<session>` too
   when no receipt of this run records one).
+  **The batch file is a JSON array, one entry per dispatched member** — under
+  Pull, a batch of one, the member just dispatched: `{member}`.
+  `member` is the AgentId the dispatch returns (`impl-<N>`). An entry that
+  names neither `session` nor `transcript` takes the session directory phase
+  0's receipt `.fleet/phase0.json` of `--ledger`'s workspace (else the cwd's,
+  resolved as the default ledger is) records, and is exit 2 naming the receipt
+  when it records none; the check reads `<session>/<member>.jsonl`, so a
+  member with no assistant turn yet still resolves off its dispatch-time
+  record. A `session` the entry gives
+  wins over the receipt's; a caller already holding the exact transcript path
+  may give `transcript` instead. The agent type an implementer was dispatched
+  as lives only in its transcript. `resolvedModel`
+  **and** `resolvedThinkingLevel` together — the dispatch's own job record —
+  may ride beside it and are preferred for the model and level. An `impl-`
+  entry carries no `agentFile`: its definition is the row's, never the
+  caller's. `transcript`/`session` resolve relative to `--repo` (defaults to
+  the plugin's own root), and the check reads and writes the run's own ledger
+  unless `--ledger` names another.
 - `AT CAP`, `IDLE OK` — nothing to do on that row.
 - `MAIN-CHECKOUT-DIRTY <paths> …`, printed above the rows, with every
   dispatching row (implementers, reviewers, merge-bot) reading
@@ -213,3 +234,14 @@ The full text of each row `fleet-tick.mjs` prints and what it asks of the contro
   one that names its own member and fails its family's schema, with the first
   violation. A review runner has no report schema and files none, so none of
   these lines names one.
+  **The settle of an implementer's `PR#M` and of a fix-applier's
+  `applied:<head>` also checks the Check-step record** beside the report,
+  `<scratch>/reports/<member>.check.json`, which the member writes with
+  `recipe-check.mjs`: the Recipe's Check step, then the Test entrypoint it was
+  handed, run against its staged tree. The settle requires that the record
+  exists and parses, that both commands exited 0 in it, and that its tree is
+  the reported head's tree — so a message-only amend keeps it valid, and a
+  content change or a rebase does not. A head whose tree git cannot read is
+  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.