mandrel 2.58.0 → 2.60.0

package/.agents/workflows/helpers/deliver-light.md

@@ -1,9 +1,9 @@
 ---
 description:
   The unplanned prompt path /mandrel-deliver takes for a free-text prompt. Judges a
-  prompt's predicted footprint, authors a receipt Story, then lands it through
-  the same single-story-init / single-story-close engine — every close gate
-  unchanged.
+  prompt's predicted footprint for risk, authors a receipt Story, then lands it
+  through the same single-story-init / single-story-close engine — every close
+  gate unchanged.
 ---
 
 # Unplanned delivery (the prompt path)
@@ -24,53 +24,45 @@ straight to execution from a prompt, landing through the unchanged close path.
 It never relaxes a close gate, never bypasses the PR to `main`, and never lands
 over-scope work silently.
 
-One gate, whatever the door: the suitability gate below is the decision, read
-against the predicted work's *effort and risk* (`STORY_SHAPE_CEILINGS`: change
-kinds, magnitude, uncertainty, deployable span). `/mandrel-plan` no longer
-suggests this path at its Gate #1 (Story #5312) — a prompt reaches it through
-`/mandrel-deliver`, and the gate runs there every time.
-
-## Scope by effort, not by artifact count {#scope-by-effort}
-
-**Counting the footprint is the wrong axis.** Three identical one-line edits
-across three files is trivial work with a high count; a 200-line rewrite of one
-module is a single change. The axes are therefore effort and risk: distinct
-change **kinds** (N instances of one mechanical edit is one kind at N sites), a
-coarse **magnitude** bucket, and **uncertainty** — is the shape determined by
-the request, or does it still need the design decisions `/mandrel-plan` exists to
-resolve?
-
-Because the predicted footprint is a *declaration* — a guess, and a gameable one
-— this gate is deliberately **coarse**: it rejects clearly-epic work only
-(multiple deployables, a migration plus its consumers, an explicit
-multi-capability enumeration). Size is enforced where ground truth is available:
-the diff backstop in step 4. Do not talk yourself past that one.
-
-**The backstop counts by the same principle.** It reads magnitude — changed
-lines over implementation files — not artifacts, and exempts the test and doc
-companions the framework itself mandates. A ceiling that punishes a repo for
-obeying its own test-first rule is a ceiling that over-fires.
+## One gate, and it reads evidence {#one-gate}
+
+There is exactly **one gate** at prediction time, and it asks one question:
+does the predicted footprint trip an absolute **risk** rule? Two do — a path in
+a registered sensitive class, and a migration paired with its consumers — and
+both are derived from the paths you name, not from anything you assert about
+the size of your own request.
+
+**A size you declare about your own request is not a measurement.** The path
+used to ask for four more axes (distinct change kinds, a magnitude bucket, an
+uncertainty bucket, a deployable span) and judge them against framework
+ceilings. Story #5313 demoted them to warnings, which meant they decided
+nothing; Story #5344 deleted them. Every one was supplied by the same agent
+asking to proceed, so the axis and the answer had a single author.
+
+**Size is enforced where ground truth is available:** the diff backstop in
+step 4, against the actual committed change set. `LIGHT_DIFF_CEILINGS` —
+implementation lines plus a file-sprawl tripwire — is the only size block on
+this path, and it reads a diff rather than a declaration.
+
+**The backstop counts by the right principle too.** It reads magnitude —
+changed lines over implementation files — not artifacts, and exempts the test
+and doc companions the framework itself mandates. A ceiling that punishes a
+repo for obeying its own test-first rule is a ceiling that over-fires.
 
 Sensitivity is the exception and stays absolute: a footprint touching an auth,
-crypto, billing, or migration class routes `full` however small or mechanical —
-and unlike a ceiling, it is never a warning. The shape ceilings themselves
-stopped gating in Story #5313: a prediction past one is carried as a
-`warnings[]` entry on the envelope, naming the exceeded axis, and the run
-proceeds — `LIGHT_DIFF_CEILINGS` in the backstop is the only size block.
+crypto, billing, or migration class routes `full` however small or mechanical,
+at prediction time and again at the backstop. That one was never a ceiling and
+is not being loosened.
 
 ## Four invariants (do not skip one)
 
-1. **Suitability gate.** The prompt's predicted footprint is judged by the
-   shared effort/risk machinery (`deriveStoryShape` / `deriveChangeLevel`)
-   **and** a ledgered model verdict with a recorded reason. Both must agree on
-   `lite`.
-2. **The predicted shape warns; risk escalates.** A prompt past a shape
-   ceiling proceeds light with a `warnings[]` entry (Story #5313) — the
-   prediction is a guess the backstop bounds for real. Only an un-ledgered
-   verdict or an un-waivable risk rule (a sensitive-path class, a migration
-   span) refuses, and it refuses the same way attended or not: an
-   **`escalated` terminal envelope** that ends the session (§ Escalation is
-   terminal). There is no question to wait for and no answer flag.
+1. **Risk gate.** The predicted footprint is judged by the shared risk
+   machinery (`deriveStoryShape` / `deriveChangeLevel`) **and** a ledgered
+   verdict carrying a recorded reason.
+2. **Only risk and the ledger refuse.** An un-waivable risk rule (a
+   sensitive-path class, a migration span) or an unrecorded reason emits an
+   **`escalated` terminal envelope** (§ Escalation ends this path), attended or
+   not. Nothing else refuses at prediction time.
 3. **Diff-derived backstop.** After implementation the ACTUAL change set is
    re-checked — the diff is the real scope signal — and an over-ceiling diff is
    blocked rather than landed.
@@ -80,31 +72,26 @@ proceeds — `LIGHT_DIFF_CEILINGS` in the backstop is the only size block.
 
 ## Procedure
 
-1. **Predict + gate.** Form the predicted footprint (new files, edited files,
-   acceptance count), judge its effort honestly (`--kinds` / `--magnitude` /
-   `--uncertainty`, per § Scope by effort), and record your ledgered verdict (a
-   recorded reason for `lite`), then run the gate — it documents every flag
-   itself, so run it with `--help` rather than guessing:
+1. **Predict + gate.** Form the predicted footprint (new files, edited files)
+   and record the reason you are taking this path, then run the gate — it
+   documents every flag itself, so run it with `--help` rather than guessing:
 
    ```bash
    node .agents/scripts/deliver-light.js --prompt "<prompt>" \
-     --creates <csv> --refactors <csv> --acceptance <n> \
-     --kinds <csv> --magnitude trivial|moderate|substantial \
-     --uncertainty determined|needs-design \
-     --route lite --reason "<why this is trivial>" [--amends '#<id>'] [--yes]
+     --creates <csv> --refactors <csv> \
+     --reason "<why this is small>" [--amends '#<id>']
    ```
 
    Branch on `action` in the JSON envelope:
    - **`proceed-light`** — the receipt Story is authored; read `storyId` and
-     `nextCommands`. Relay every `warnings[]` entry to the operator verbatim
-     (each names the shape axis the prediction exceeded), then continue to
-     step 2 — the diff backstop in step 4 is what bounds the actual change.
+     `nextCommands`, then continue to step 2. The diff backstop in step 4 is
+     what bounds the actual change.
    - **escalation** — no `action` to branch on: the gate emits an
      **`escalated` terminal envelope** instead (exit 2), attended or not.
-     § Escalation is terminal governs; you are finished.
+     § Escalation ends this path governs.
 
-   `--amends '#<id>'` is the canonical light case — shape-checked identically; a
-   heavy amendment escalates to `/mandrel-plan` like any other over-scope prompt.
+   `--amends '#<id>'` is the canonical light case — judged identically; an
+   amendment touching a sensitive class escalates like any other prompt.
 
 2. **Init (same engine).** From the main checkout, synchronously, with the
    maximum Bash timeout:
@@ -120,7 +107,7 @@ proceeds — `LIGHT_DIFF_CEILINGS` in the backstop is the only size block.
 3. **Implement + self-eval.** `cd` into `workCwd`, implement the change, run
    the full suite once in the worktree **so close can credit it** — the
    crediting invocation and the freshness contract are
-   [`deliver-story.md`](deliver-story.md) Step 1.3, unchanged here — then run
+   [`deliver-digest.md`](deliver-digest.md) § 5, unchanged here — then run
    the bounded acceptance self-eval loop
    ([`deliver-story.md`](deliver-story.md) Step 1a). Commit
    on `story-<id>` with `(refs #<storyId>)`.
@@ -132,7 +119,7 @@ proceeds — `LIGHT_DIFF_CEILINGS` in the backstop is the only size block.
    ```
 
    This is the pass that actually bounds size, which is why the prediction gate
-   above can afford to be coarse. It measures **magnitude on the change's
+   above can afford to judge risk only. It measures **magnitude on the change's
    implementation half** — changed lines (additions + deletions) plus a file
    sprawl tripwire — never raw artifact count. Tests, `docs/**`, `**/*.md`,
    `baselines/**`, and lockfiles are exempt from the counts, because the
@@ -161,62 +148,66 @@ proceeds — `LIGHT_DIFF_CEILINGS` in the backstop is the only size block.
    ```
 
    Branch on the terminal envelope's `status` per
-   [`deliver-digest.md`](deliver-digest.md) § 5 — every close
+   [`deliver-digest.md`](deliver-digest.md) § 6 — every close
    gate runs byte-identical to the full path.
 
-## Escalation is terminal {#escalation-is-terminal}
+## Escalation ends this path {#escalation-is-terminal}
 
-A refused gate — an un-ledgered verdict or an un-waivable risk rule, under
-`--yes` or attended alike — emits a schema-validated `story-deliver-terminal`
+A refused gate — an un-ledgered verdict or an un-waivable risk rule, attended
+or unattended alike — emits a schema-validated `story-deliver-terminal`
 envelope with **`status: "escalated"`**, `storyId: null`, and a `nextCommand`
 naming the `/mandrel-plan` invocation that owns the work.
 
-**That envelope IS this session's terminal output.** Relay it and stop. There is
-no remaining step, no degraded fallback, and no smaller version of the work to
-attempt.
-
-**Invoking `/mandrel-plan` in this same session is forbidden.** Hand the operator the
-`nextCommand`; `/mandrel-plan` runs in a **fresh** session.
-
-This is not style — it is the empirical finding that motivated the envelope.
-A mandrel-bench 2.13.0 light-arm run read the escalation and continued anyway:
-it invoked `/mandrel-plan` in-session and delivered. The in-session plan authored **one**
-Story against the scenario's 3–5 contract, where a fresh `/mandrel-plan` session on the
-identical seed authored **four**. Planning inside a session already framed as
-small work under-decomposes, so walking past the escalation silently produced
-the very outcome the guard exists to prevent. The gate's decision was right both
-times; only the outcome's finality was missing.
+**That envelope IS this session's terminal output for the light path.** There
+is no remaining light step, no degraded fallback, and no smaller version of the
+work to attempt. Relay the envelope.
 
 Nothing is left half-started: an escalated run creates **no receipt Story, no
 `story-<id>` branch, and no worktree** — the escalation path returns before
 every creation call site, and `escalation.created` records all three as `false`
 in a shape the schema pins, so a later run finds nothing to trip over.
 
-## Why escalation breaks the session {#why-the-two-directions-differ}
-
-Traffic runs one way between this path and `/mandrel-plan` — light →
-`/mandrel-plan` on an over-scope prompt — and that direction has a deliberate
-session rule:
-
-> **The direction whose guard is model judgment must break the session.**
-
-**Light → `/mandrel-plan` must be a fresh session.** What is being protected is
-*authoring judgment*, and the empirical finding above is that a session already
-framed as small work under-decomposes — one Story against a 3–5 contract where
-a fresh session on the identical seed authored four. The frame is the hazard,
-so only a new session removes it. Everything on this path's own side is
-mechanical — `STORY_SHAPE_CEILINGS`, the ledgered verdict, the diff backstop —
-and none of it degrades because the context is large.
-
-Do not "fix" this by letting light → `/mandrel-plan` run in-session: that
-reintroduces the exact failure the `escalated` envelope exists to prevent.
+## Continuing into `/mandrel-plan` {#continuing-into-plan}
+
+You may run the `nextCommand` **in this same session**, and when you do, seed
+it deliberately:
+
+- hand `/mandrel-plan` the **original prompt** and the envelope's
+  `escalation.reasons` verbatim — the reasons name the risk class or the
+  missing ledger, which is planning input, not noise;
+- state plainly that the light path refused it, so the planning pass starts
+  from "this is not small" rather than from the framing that produced the
+  prompt.
+
+**A fresh session is still the safer default** when the work is clearly larger
+than the prompt admitted, or when the reasons name a sensitive class you had
+not considered: the cost is one boot, and it removes the frame entirely.
+
+### Why in-session planning was barred, and why it is not any more
+
+Story #4746 required the *session* to end here, on one mandrel-bench 2.13.0
+light-arm observation: a run read the escalation, invoked `/mandrel-plan`
+in-session, and the in-session plan authored **one** Story against the
+scenario's 3–5 contract, where a fresh `/mandrel-plan` session on the identical
+seed authored **four**. The reading was that a session already framed as small
+work under-decomposes.
+
+That is one observation on one scenario, and the rule it bought cost every
+escalated prompt a full cold boot — the exact session multiplication this path
+exists to remove. Story #5344 keeps the finding and drops the ban: the
+under-decomposition risk is real, so the seeding instructions above exist to
+counter the frame directly, and the **light-arm cell of mandrel-bench** is the
+measurement that decides whether the loosening stays. If that cell's
+decomposition counts regress against the fresh-session arm, the ban comes back
+and this section is the record of why. See
+[`docs/decisions.md`](../../../docs/decisions.md) ADR `20260917-5344`.
 
 ## See also
 
 - [`/mandrel-deliver`](../mandrel-deliver.md) — the delivery entry point; routes here on a
   free-text prompt.
-- [`/mandrel-plan`](../mandrel-plan.md) — owns the work an over-scope prompt
-  escalates to.
+- [`/mandrel-plan`](../mandrel-plan.md) — owns the work an escalated prompt
+  goes to next.
 - [`deliver-story.md`](deliver-story.md) — the one Story delivery engine every
   path shares.
 - [`deliver-digest.md`](deliver-digest.md) — engine invariants, gates, and the

package/.agents/workflows/helpers/deliver-reference.md

@@ -20,7 +20,7 @@ means exactly the five ids in it.
 
 **Pass the span through; never expand it by hand.** Every id-list flag on the
 delivery path takes range tokens — `resolve-stories.js --ids`,
-`stories-wave-tick.js --stories` and `--dispatched`, and
+`deliver-run.js --stories` and `--handoff`, and
 `plan-run-epilogue.js --stories`. Normalize the operator's spacing away and hand
 the scripts one unspaced token (`--ids 4922-4926`), mixed freely with singles
 and commas (`--ids 4901,4922-4926`); overlaps dedupe. A hand-typed enumeration
@@ -40,7 +40,7 @@ The cap is per range token, not per run: a genuine 60-Story delivery is still
 expressible as two ranges, but a slipped digit cannot fan out into a live
 resolution sweep of thousands of issues.
 
-## Sequencing edge cases (`stories-wave-tick.js`)
+## Sequencing edge cases (`deliver-run.js` over `stories-wave-tick.js`)
 
 **What "discovered, not declared" means concretely.** `resolve-stories.js` reads
 the graph from live state as the union of the Story bodies' `depends_on` edges
@@ -56,6 +56,21 @@ worker at an unenriched body, after taking its lease. Route it through
 `/mandrel-plan` first, which applies `agent::ready` at the end of planning.
 `--allow-unlabelled` is the deliberate escape hatch.
 
+**Inspecting a beat without taking one.** `deliver-run.js` writes — the ledger,
+the prompts — so it is not the tool for "what *would* the next beat do?". The
+tick underneath it is read-only and answers exactly that, with no ledger and no
+prompt files:
+
+```bash
+node .agents/scripts/stories-wave-tick.js --stories <id,id,...> --probe-live
+```
+
+Its envelope is the beat's scheduling half verbatim — `ready`, `inFlight`,
+`inFlightReservation`, `footprintGuard`, `foreignHeld`, `wedged`. Read it when
+a slot is unfilled and you want to know why before acting. Do **not** drive a
+run from it: without the ledger the init window reopens, and the same Story is
+handed out twice.
+
 **The non-zero exit codes.** **2** — `cycleError`: the graph is
 self-referential; fix `depends_on`, do not retry. **3** — `wedged`: nothing
 dispatchable and nothing in flight, with the undone Stories and their unmet
@@ -77,22 +92,45 @@ another run), and derives **in-flight** from live `agent::executing` /
 `agent::closing` labels. You never compute `done` or `in-flight` — that
 accounting is read from reality every beat.
 
-**`--dispatched` is the one thing you must tell it.** List every
-Story id you have spawned this run. Live state cannot instantly report a Story
-you dispatched moments ago: `single-story-init.js` publishes `agent::executing`
-before the worktree install (ahead of the multi-minute install, so the
-window is short rather than minutes-long), but it is not
-zero — until the label lands the Story still reads `agent::ready` and, without
-`--dispatched`, the next beat would hand it back and a second sub-agent would
-join the first on the same branch and worktree, interleaving commits.
-`--dispatched` closes that residual same-run window. The rule is
-**append-only: add each id as you dispatch it and never remove one.** The flag
-is additive, not authoritative — the probe unions it into the label-derived set
-and then filters it against live state, so an id that has since gone
-`agent::done` is dropped for you. Re-listing an id costs nothing and cannot
-double-count a slot; *omitting* one is the only way to get this wrong. This is
-why `--dispatched` is not the retired `--done` bookkeeping, and why
-`--in-flight` remains rejected under `--probe-live`.
+**The run ledger closes the init window, and you maintain nothing.** Live state
+cannot instantly report a Story dispatched moments ago:
+`single-story-init.js` publishes `agent::executing` before the worktree install
+(ahead of the multi-minute install, so the window is short rather than
+minutes-long), but it is not zero — until the label lands the Story still reads
+`agent::ready`, and an unaugmented beat would hand it back so a second
+sub-agent joined the first on the same branch and worktree, interleaving
+commits. `deliver-run.js` closes that window from its own ledger
+(`<tempRoot>/run-<id>/ledger.json`): every id it hands out as ready is
+recorded, and the next beat reads the file back and seeds the tick with it.
+Append-only by construction, so the "forgot to re-list one" failure the
+hand-maintained list had cannot occur. The ledger is additive, not
+authoritative — the probe unions it into the label-derived set and then filters
+it against live state, so an id that has since gone `agent::done` is dropped
+for you. A missing or corrupt ledger costs one extra beat of the init window,
+never the run. The run id is a stable digest of the Story id set, so every beat
+of one run finds the same ledger and two concurrent runs never share one;
+`--run-id` pins it explicitly.
+
+**A spawn that never reached init is the ledger's one sharp edge.** Append-only
+is what makes the list safe to keep, and it is also why a bad entry never
+leaves: if a spawn dies before `single-story-init.js` runs, the id stays
+ledgered, is withheld as in flight on every later beat, and the run returns an
+empty `ready[]` with a non-zero `inFlight` forever — which reads exactly like a
+healthy wait. The beat names it instead: every ledgered id live state still
+reports as `agent::ready` appears in `stalledDispatch[]`, with the recovery in
+`stalledDispatchReason`. That is its **own** reason — not a footprint withhold
+(which names a blocking peer and the colliding paths) and not a foreign lease
+(which names a holder and clears itself when their run ends).
+
+It is a report, not a release. A slow init and a dead spawn are the same
+observation at the beat's altitude, and auto-releasing would re-dispatch a live
+Story onto its own branch — the failure the ledger exists to prevent. So the
+operator owns the call: confirm no worker is running, remove the id from
+`dispatched` in `<tempRoot>/run-<id>/ledger.json` (deleting the file works too,
+at the cost of reopening the init window for the rest), and beat again with
+`--run-id <id>` so the same run directory is reused. An id that has since
+picked up `agent::executing`, `agent::closing` or `agent::done` is never
+reported here — live state has moved on and the ledger entry is already inert.
 
 **Cross-run de-confliction is automatic.** A Story another
 operator is delivering is withheld without any bookkeeping from you: the probe
@@ -122,21 +160,12 @@ report is `available: false` and selection de-conflicts within the beat only.
 advisory, note }`. They used to be an unreported skip, so a Story simply
 vanished from `ready[]` and an unfilled slot read exactly like a cap that was
 never reached. Every entry in **either** report carries the colliding `paths`
-and a `source` tag:
-
-- `declared-overlap` — both Stories' `changes[]` named the path (or a declared
-  glob). Intended serialization; two Stories rewriting the same generated
-  baseline must not co-dispatch.
-- `scraped-overlap` — only the text evidence produced it. Real signal — a
-  declaration is only a lower bound — but the class where a false positive is
-  possible.
-
-**The evidence scrape excludes exactly three token sources**, each structurally
-incapable of naming an edit target: `audit-fingerprints` /
-`audit-semantic-keys` provenance footers, paths under `project.paths.tempRoot`,
-and markdown-link URL interiors. Nothing else is stripped — a
-`<!-- DECOMPOSITION -->` block's paths are genuine intent
-([`instructions.md` § 7](../../instructions.md)) and still count.
+and one `source` tag, `declared-overlap`: both Stories' `changes[]` named the
+path, or one declared a glob. Intended serialization — two Stories rewriting
+the same generated baseline must not co-dispatch. A declared footprint is the
+whole footprint: Story #5313 retired the body scrape that used to widen it,
+and the second source class it produced, so `changes[]` is the only evidence
+a collision is scored against.
 
 **`delivery.deliverRunner.footprintGuard`** selects what a collision does:
 
@@ -163,23 +192,23 @@ anything, read the Story's `dispatchMode` from the resolver envelope
 `lib/orchestration/complexity-gate.js`, which decides on the resolved set size
 alone — it does not read the Story body). A Story with `dispatchMode: "inline"`
 executes [`deliver-story.md`](deliver-story.md) **inline in this session** — no
-`story-worker` sub-agent boot and no fresh acceptance-critic sub-agents
-(sub-agent boots are the dominant deliver-phase token cost at trivial scope) —
-threading the same `docsDigestPath` / `checklistPath` / change-set discipline
-as a spawned worker. Inline removes model-side fan-out only: every
-`single-story-close.js` gate, the PR to `main`, and the terminal envelope are
-identical.
+`story-worker` sub-agent boot (sub-agent boots are the dominant deliver-phase
+token cost at trivial scope) — threading the same `docsDigestPath` /
+`checklistPath` / change-set discipline as a spawned worker. It does not touch
+the acceptance verdict owner, which the ceremony profile alone names
+([`deliver-digest.md`](deliver-digest.md) § 3). Every `single-story-close.js`
+gate, the PR to `main`, and the terminal envelope are identical.
 
 **A trivial shape does not buy that session.** Only the
 one-Story rule above yields `inline`; every Story of a multi-Story run comes
 back `subagent` however lite its body, because the ready set below may offer
 several Stories on one beat and a session cannot be split between them. The
-Story's derived shape is still reported (it sets ceremony, and a sensitive
-footprint keeps the fresh acceptance critic), and the `route::lite` label
-remains a human-visible hint only, never the control signal — a lost or
-never-written label cannot misroute delivery.
+Story's shape does not enter the decision at all — `resolveStoryDispatchMode`
+reads the resolved set size and nothing else, and the `route::lite` hint label
+was retired with the plan-side route claim (Story #5312), so there is no label
+left to lose or misread.
 
-**Issue a beat's spawns in one turn.** A wave tick hands you a ready set, not a
+**Issue a beat's spawns in one turn.** A beat hands you a ready set, not a
 queue: those Stories have no dependency edge between them (the resolver already
 withheld any that do) and no shared write paths (each owns its own worktree and
 branch). Dispatch them the way
@@ -200,43 +229,25 @@ exposes agent dispatch, spawn each ready Story as its own
 sub-agent executes [`deliver-story.md`](deliver-story.md) Steps 0–2.5
 (init → implement → acceptance self-eval → **push**) and stops there; **you**
 own Step 3, serialized — see `/mandrel-deliver` § Closing what the workers hand back.
-Thread into its prompt: `storyId`; `docsDigestPath` (the per-run docs digest, null when
-`project.docsContextFiles` is unset); `checklistPath` (the footprint-matched
-write-time audit checklist, produced at dispatch, below); and the
-**change-set discipline** — the worker computes the change set once with
-`computeChangeSet` and hands that one list to every acceptance critic; it
-never lets a critic re-derive the diff.
-
-**Produce `checklistPath` before the spawn.** Compute the payload
-from the Story's predicted footprint (its `changes[]` / `references[]` path
-entries) with `buildDispatchChecklist` and write it to the run temp dir, then
-thread the resulting path (empty when nothing matched):
 
-```bash
-node --input-type=module -e '
-  import { buildDispatchChecklist } from "<main-repo>/.agents/scripts/lib/audit-suite/index.js";
-  import { parse } from "<main-repo>/.agents/scripts/lib/story-body/story-body.js";
-  // storyBody is the fetched Story issue body.
-  const { changes, references } = parse(process.env.STORY_BODY);
-  const { checklistPath } = buildDispatchChecklist({
-    storyId: <storyId>, changes, references, runTempDir: "temp/run-<id>",
-  });
-  console.log(checklistPath ?? "");
-'
-```
-
-`buildDispatchChecklist` (`lib/audit-suite/dispatch-checklist.js`) is a pure
-function of the footprint and the on-disk checklists; an empty match prints
-nothing and the worker runs with no write-time checklist — the maker-blind
-close-scope pass still covers it.
+**The beat writes the prompt; you pass the file.** Each `ready[]` entry carries
+a `promptPath` under `<tempRoot>/run-<id>/`, and that file is the whole spawn
+payload: the Story id, the `workCwd` conventions, the `docsDigestPath` (null
+when `project.docsContextFiles` is unset), the `checklistPath` — the
+footprint-matched write-time audit checklist built from the Story's declared
+`changes[]` / `references[]`, empty when nothing matched — and the
+**change-set discipline** (derive the change set once with `ceremony-derive.js`
+and hand that one list to the verdict owner; never let a critic re-derive the
+diff). An unmatched checklist costs nothing: the maker-blind close-scope pass
+still covers the Story.
 
 **Inline fallback (`roleScopedAgents: false` / no-nesting harness).** When the
 kill-switch is off, or the host cannot spawn a sub-agent at this nesting depth,
 do **not** stall: read [`deliver-story.md`](deliver-story.md) **in full** and
-execute it directly, in this turn, threading the same `docsDigestPath` /
-`checklistPath` / change-set discipline. Under `--yes` / injected helper
-content, execute directly without a re-read turn. The engine, gates, and
-terminal envelope are identical either way — only the isolation differs.
+execute it directly, in this turn, following that same dispatch prompt. Under
+`--yes` / injected helper content, execute directly without a re-read turn. The
+engine, gates, and terminal envelope are identical either way — only the
+isolation differs.
 
 ## Intent phrases (what replaced the flag table)
 
@@ -292,18 +303,22 @@ node .agents/scripts/plan-run-epilogue.js --stories 101,102
 
 This executes, in order:
 
-- `audit-roster` — selects cross-Story audit lenses over the combined landed
-  tip and posts `plan-run-audit-roster` on the primary Story; the host MUST
-  walk each listed lens against the combined diff.
 - `follow-up-rollup` — friction follow-ups across every Story in the run
   (files issues when auto-file is on; posts `follow-ups`).
-- `sibling-coherence` — Spec/Acceptance coherence check across sibling bodies
-  (`plan-run-sibling-coherence`).
 - `epic-close` — **reports** which of the run's container Epics its land tails
   left closed and which are still open. **Read-only** — it derives nothing:
   every child state change is already a rollup edge, so the container was
   derived from a complete child set by the last Story's own land tail.
 
+**The audit roster is opt-in** (Story #5343). Add `--audit-roster` and the run
+also selects cross-Story audit lenses over the combined landed tip and posts
+`plan-run-audit-roster` on the primary Story — and the host MUST then walk
+every listed lens against the combined diff, one `auditor` sub-agent per lens.
+That walk is the expensive half, and it only pays for itself when someone is
+going to read it, so **the operator asks for it** — exactly as for the
+pre-mortem plan critic. Without the flag no roster comment is posted and no
+auditor is spawned.
+
 A single-Story run skips the epilogue — follow-ups are captured on merge
 confirm instead (`captureStoryFollowUps`).
 
@@ -353,22 +368,25 @@ strands its container open above finished work.
 ## Ceremony (profiles + two scopes)
 
 Ceremony depth is selected by `delivery.routing.ceremonyProfile`
-(`minimal` | `standard` | `strict`, default `standard`) and the **change level
-derived from the Story's own diff** — the changed files' intersection with the
-sensitive-path classes in `audit-rules.json`
-(`review-depth.js#deriveChangeLevel`), not a planner-authored verdict:
-
-| Profile | Acceptance critic | When to use |
+(`minimal` | `standard` | `strict`, default `standard`) — and by that alone
+since Story #5343. The **change level derived from the Story's own diff** (the
+changed files' intersection with the sensitive-path classes in
+`audit-rules.json`, `review-depth.js#deriveChangeLevel`, never a
+planner-authored verdict) still selects **review depth**, which is the second
+row of the scope table below:
+
+| Profile | Acceptance verdict owner | When to use |
 | --- | --- | --- |
-| `minimal` | Always inline | Tiny trusted N=1 Stories |
-| `standard` | Derived-level routed | Default |
-| `strict` | Always fresh-context | High-assurance / regulated surfaces |
+| `minimal` | Inline self-eval | Tiny trusted N=1 Stories |
+| `standard` | Inline self-eval | Default |
+| `strict` | Fresh-context critic | High-assurance / regulated surfaces |
 
 | Scope | What runs | Mechanism |
 | --- | --- | --- |
 | **Per-Story (always)** | Gates, branch discipline, close-and-land | `deliver-story` / `single-story-close` |
-| **Per-Story (profile + derived level)** | Acceptance critic mode; review depth | `ceremony-routing.js` + `review-depth.js` + `code-review.js` |
-| **Per-run (N>1)** | Audit roster · follow-up roll-up · sibling coherence | `plan-run-epilogue.js` once at run end |
+| **Per-Story (profile)** | Acceptance verdict owner (the rule: digest § 3) | `ceremony-routing.js` |
+| **Per-Story (derived level)** | Review depth | `review-depth.js` + `code-review.js` |
+| **Per-run (N>1)** | Follow-up roll-up · container-Epic report (· audit roster on `--audit-roster`) | `plan-run-epilogue.js` once at run end |
 | **Per-Story land tail** | Follow-up capture · status resync · Epic rollup · ref cleanup · base fast-forward | `single-story-close/phases/post-land.js` (in-process, per-step reported) |
 
 ## Async merge-confirm mode (`delivery.mergeWatch.mode: "async"`)
@@ -383,17 +401,15 @@ agent) and move on to the next Story; `single-story-confirm-merge.js` is
 idempotent and owns the whole tail. Do not foreground-poll the merge. The
 default `"sync"` behaviour is unchanged.
 
-**On a multi-Story run, pass `--merge-watch-mode async` on every close.** Close
+**On a multi-Story run the beat adds `--merge-watch-mode async` for you.** Close
 sees one Story and cannot see run topology, so it cannot make this call for
-itself — you can. Implementation runs in parallel but the close tail is
+itself — `deliver-run.js` can, and does: every `close[]` command it renders
+carries the flag when the run holds more than one Story and omits it for a run
+of one. Run the command it printed verbatim rather than composing your own.
+The reason it matters: implementation runs in parallel but the close tail is
 serialized one at a time, and under `sync` each of those closes holds the
 foreground for its full merge wait before the next Story's close may start.
-That is the run's dominant serialized cost, and it is paid per sibling:
-
-```bash
-node <main-repo>/.agents/scripts/single-story-close.js \
-  --story <storyId> --cwd <main-repo> --merge-watch-mode async
-```
+That is the run's dominant serialized cost, and it is paid per sibling.
 
 The flag overrides `delivery.mergeWatch.mode` for that invocation only — the
 config default stays `"sync"`, which is right for the solo delivery that has no