mandrel 2.56.0 → 2.57.0

package/.agents/workflows/helpers/acceptance-self-eval.md

@@ -22,9 +22,9 @@ maintainability / coverage / crap) proves the code is *healthy*, not that it
 satisfies *this Story's* acceptance criteria.
 
 The loop is **always on** (a hard cutover — there is no flag to disable it) and
-**bounded** by `delivery.acceptanceEval.maxRounds` (default 2), which the
-resolver clamps into `[1, hard ceiling]` so the cap can never be switched off or
-run unbounded. It is **distinct from** the per-run `sibling-coherence` epilogue
+**bounded** by `delivery.acceptanceEval.maxRounds` (default 2; `0` means the
+verdict is scored once with no redraft round). It is **distinct from** the
+per-run `sibling-coherence` epilogue
 step (`planRunEpilogue` for N>1): this loop is per-Story, per-criterion,
 mid-delivery, and evaluates the actual work product.
 
@@ -55,23 +55,21 @@ mid-delivery, and evaluates the actual work product.
    >
    > **Whether to spawn fresh at all is routed off the derived change level**
    > — the same signal `review-depth.js` resolves depth from, so the two
-   > decisions cannot disagree. Derive it with `deriveChangeLevel` from
-   > [`review-depth.js`](../../scripts/lib/orchestration/review-depth.js) over
-   > the **change set your caller computed once** for this Story
-   > (`computeChangeSet` from
-   > [`change-set.js`](../../scripts/lib/orchestration/change-set.js); see
-   > [`deliver-story.md`](deliver-story.md) Step 2), then
-   > resolve the ceremony per cluster with `resolveCeremonyForRisk` from
-   > [`ceremony-routing.js`](../../scripts/lib/orchestration/ceremony-routing.js)
-   > using that `derivedLevel` and `delivery.routing.freshCriticSampleRate`:
-   > **`high` (the diff touches a sensitive path registered in
-   > `audit-rules.json`) → `fresh`** (spawn the critic); **`low` (it touches
-   > none) → `inline`** (the contract-identical inline fallback below),
-   > **except** the `freshCriticSampleRate` fraction of low-level clusters the
-   > sampling floor forces `fresh` so a low level never means zero independent
-   > checking; **`null` / unknown (the diff could not be enumerated) → `fresh` +
-   > full ceremony** (fail-safe). This chooses fresh-vs-inline **per cluster
-   > only — it never changes the cluster count**.
+   > decisions cannot disagree. Derive it with one script over the Story
+   > branch (Story #5313) — never a hand-carried import block:
+   >
+   > ```bash
+   > node <main-repo>/.agents/scripts/ceremony-derive.js --story <storyId> --cwd <workCwd>
+   > ```
+   >
+   > It computes the change set once (`files`), derives the level and
+   > classes, and resolves the ceremony per cluster (`mode`, `reason`,
+   > `verdictOwner`): **`high` (the diff touches a sensitive path registered
+   > in `audit-rules.json`) → `fresh`** (spawn the critic); **`low` (it
+   > touches none) → `inline`** (the contract-identical inline fallback
+   > below); **`null` / unknown (the diff could not be enumerated) → `fresh`
+   > + full ceremony** (fail-safe). This chooses fresh-vs-inline **per
+   > cluster only — it never changes the cluster count**.
    >
    > The routing signal is deliberately **not** a planner-authored risk
    > verdict: a level the plan asserted about itself was exactly the signal
@@ -80,7 +78,7 @@ mid-delivery, and evaluates the actual work product.
    >
    > **Inline-critic path (low-level-routed OR nesting-absent harness).** The
    > verdict is authored **inline** whenever the risk router above resolves to
-   > `inline` (a low-risk cluster not caught by the sampling floor), and also as
+   > `inline` (a low-risk cluster), and also as
    > a **fallback** on any harness that cannot spawn the fresh critic.
    > Dispatching the critic as a nested `Agent` is the fresh-context shape and
    > works on any harness that carries `Agent` into sub-agents (Claude Code ≥
@@ -102,18 +100,18 @@ mid-delivery, and evaluates the actual work product.
    > comment (if you block) that the inline fallback was used.
 
    The critic:
-   - Inspects the **change set handed to it in its spawn context** — the one
+   + Inspects the **change set handed to it in its spawn context** — the one
      list computed above — and the Story's inline `acceptance[]` / `verify[]`
      arrays. Pass the file list explicitly when you dispatch the critic; it
      does not re-enumerate the diff for itself, so a commit
      landing mid-ceremony cannot leave the critic scoring a different change
      than the one that routed it.
-   - **Runs the `verify[]` commands** and consumes their output as **required
+   + **Runs the `verify[]` commands** and consumes their output as **required
      evidence** when scoring the relevant acceptance items. `verify[]` is not
      optional advisory pre-flight — a criterion cannot be scored `met` without
      the supporting `verify[]` evidence where a `verify[]` command is relevant
      to it.
-   - **Reuses the credited full-suite run instead of re-paying for it.**
+   + **Reuses the credited full-suite run instead of re-paying for it.**
      Before spawning a `verify[]` entry, classify it with `resolveVerifyCredit`
      from
      [`verify-credit.js`](../../scripts/lib/orchestration/verify-credit.js): an
@@ -125,7 +123,7 @@ mid-delivery, and evaluates the actual work product.
      manufacture a pass. The gate warns on any such entry: the intended shape
      is scoped `verify[]` entries **plus** the one credited run
      ([`deliver-digest.md`](deliver-digest.md) § 5).
-   - **Shares `lint` / `typecheck` evidence with close.** When a
+   + **Shares `lint` / `typecheck` evidence with close.** When a
      `verify[]` command is **byte-identical** to a close-validation gate — in
      practice only the cheap, command-identical `lint` and `typecheck` gates
      (`npm run lint` and the resolved `project.commands.typecheck`) — the
@@ -146,19 +144,21 @@ mid-delivery, and evaluates the actual work product.
      fresh — a false-fresh coverage record without `coverage-final.json`
      silently weakens the floor. Limit the evidence-share to `lint` and
      `typecheck`.
-   - Emits a **cluster** verdict file under `temp/` conforming to
+   + Emits a **cluster** verdict file under `temp/` conforming to
      [`acceptance-eval-verdict.schema.json`](../../schemas/acceptance-eval-verdict.schema.json):
      one `{ index, criterion, verdict: met|partial|unmet, evidence,
      verifyEvidence[] }` record per acceptance item **in that cluster**, each
      `index` being the item's position in the Story's full `acceptance[]`
      array. A fresh critic **returns that path to you** rather than calling the
      gate itself.
-2. **Dispatch the round's clusters in parallel, then merge into one verdict.**
-   The clusters of a round are independent, so dispatch **all** of the round's
-   fresh critics as N `Agent` calls **in a single assistant turn** —
-   [`parallel-tooling.md`](parallel-tooling.md) **Rule 3** — never serially,
-   and never one round per cluster. Clusters routed `inline` are authored in
-   the same round alongside them.
+2. **Dispatch the round's clusters in parallel, then merge into one verdict
+   (fresh critics only).** When the verdict owner is the **inline self-eval**,
+   author **one** verdict file covering every `acceptance[]` item and score it
+   in one gate call — the cluster merge below does not apply (Story #5313).
+   For fresh critics, the clusters of a round are independent, so dispatch
+   **all** of the round's critics as N `Agent` calls **in a single assistant
+   turn** — [`parallel-tooling.md`](parallel-tooling.md) **Rule 3** — never
+   serially, and never one round per cluster.
 
    Then **merge** the cluster verdicts into **one** verdict file under `temp/`:
    concatenate every cluster's `criteria[]` records and order the merged array
@@ -187,24 +187,24 @@ mid-delivery, and evaluates the actual work product.
 
    ```bash
    node <main-repo>/.agents/scripts/acceptance-eval.js \
-     --story <storyId> --verdict <merged-verdict-path> \
-     --expected-criteria <number of acceptance[] items>
+     --story <storyId> --verdict <verdict-path>
    ```
 
-   Pass `--expected-criteria` from the `acceptance[]` count you already read
-   off the Story body: a verdict whose `criteria[]` length differs — a single
-   cluster's verdict handed over unmerged — is rejected **before scoring**,
-   with an error naming the merge contract and consuming **no round**.
+   The gate reads the Story's `acceptance[]` count itself (Story #5313): a
+   verdict whose `criteria[]` length differs — a single cluster's verdict
+   handed over unmerged — is rejected **before scoring**, with an error naming
+   the merge contract and consuming **no round**. `--expected-criteria` is
+   still accepted but redundant; when passed it must agree with that count.
 
    The gate validates the verdict against the schema, applies the round cap,
    emits the per-criterion `acceptance-eval` signal into the retro / feedback
    substrate, prints a JSON envelope, and exits with one of three decisions:
-   - **`decision: "proceed"`** (every criterion `met`) → exit 0. Proceed to
+   + **`decision: "proceed"`** (every criterion `met`) → exit 0. Proceed to
      close.
-   - **`decision: "redraft"`** (some `partial`/`unmet`, rounds remaining) →
+   + **`decision: "redraft"`** (some `partial`/`unmet`, rounds remaining) →
      exit 0. Redraft the flagged criteria (named in `unmetCriteria[]`), commit
      the fix, and start another round.
-   - **`decision: "block"`** (round cap reached, criteria still unmet) → exit
+   + **`decision: "block"`** (round cap reached, criteria still unmet) → exit
      non-zero. **Do not proceed to close.** Take the caller's blocked path
      (transition to `agent::blocked`) and post a `friction` comment naming the
      unmet criteria and their evidence. Never silently proceed to close.

package/.agents/workflows/helpers/code-quality-guardrails.md

@@ -28,15 +28,15 @@ hook calls the same script.
 
 Cyclomatic complexity (CC) is measured per function by `escomplex` (the same
 engine the maintainability axis of `check-baselines.js` runs). Two
-thresholds, sourced from
-`delivery.quality.codingGuardrails.cyclomaticFlag` /
-`cyclomaticMustFix`:
+thresholds — the advisory `delivery.quality.codingGuardrails.cyclomaticFlag`
+and the fixed ceiling of 12 (`cyclomaticMustFix` was retired as a config
+key in Story #5313):
 
 | CC range | Action |
 | --- | --- |
 | ≤ 8 | Pass — no annotation required. |
 | > 8 (default `cyclomaticFlag`) | **Flag** — `quality:preview` counts the function in its `new-method count over c=<flag>` column. The function is allowed to land but the report names it. |
-| > 12 (default `cyclomaticMustFix`) | **Must-fix**: `check-cyclomatic.js` fails when a file gains a function above the ceiling, or when its worst function gets worse than the recorded baseline. |
+| ≥ 12 | **Advisory in `quality:preview`** — listed by file, method and reading; the preview exits 0 on it. **Ratchet in `check-cyclomatic.js`**: fails when a file gains a function above 12, or when its worst function gets worse than the recorded baseline. |
 
 `check-cyclomatic.js` is a **ratchet**, not a cliff: `baselines/cyclomatic.json`
 records the over-ceiling functions a repository already carries, so adopting

package/.agents/workflows/helpers/code-review.md

@@ -384,9 +384,8 @@ ceremony above:
    `[HEAD_REF]`, stage explicit paths only, and make **one focused
    conventional commit per lens** (`fix(<scope>): <description> (review findings batch)`).
 3. Bounded-attempt semantics extend to the batch: each finding gets **at
-   most one** attempt, and a lens's batch commit that would exceed
-   `delivery.codeReview.maxFixScopeFiles` routes that lens's findings to
-   escalation (`scope-exceeded`) instead of committing.
+   most one** attempt (the `maxFixScopeFiles` file-count ceiling was retired
+   in Story #5313 — a fix is bounded by attempts, not by file count).
 4. After **all** lens batches are committed, run a **single** validation
    pass (`npm run lint` plus the relevant `npm test` slice) and a
    **single** targeted rescan over the touched files. Surviving batched

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

@@ -49,37 +49,24 @@ the only sanctioned landing. A silent local build is not a delivery.
 ## 3. Change set — computed once, handed to everyone
 
 One enumeration per Story. A critic that re-runs its own `git diff`
-can score a different set than the one that routed it. Both routing calls take
-a single options object and are **total — they never throw**, so a wrong-shaped
-argument is silently absorbed into the `null` fail-safe:
+can score a different set than the one that routed it. Derive the change
+set, the level and the ceremony with **one script** — never a hand-carried
+import block:
 
 ```bash
-node --input-type=module -e '
-  const lib = "<main-repo>/.agents/scripts/lib/orchestration";
-  const { computeChangeSet } = await import(`${lib}/change-set.js`);
-  const { deriveChangeLevel } = await import(`${lib}/review-depth.js`);
-  const { resolveCeremonyForRisk } = await import(`${lib}/ceremony-routing.js`);
-  const { files } = computeChangeSet({ baseRef: "main", headRef: "story-<storyId>" });
-  // deriveChangeLevel({ changedFiles, injectedRules?, selectSensitivePathClassesFn? })
-  //   -> { level, classes } — an OBJECT, never a bare level.
-  const { level, classes } = deriveChangeLevel({ changedFiles: files });
-  // resolveCeremonyForRisk({ derivedLevel, clusterIndex?, freshCriticSampleRate?,
-  //   ceremonyProfile? }) -> { mode, reason, sampled, profile, verdictOwner }.
-  // derivedLevel is that level STRING — the object above matches no tier and
-  // routes to the null fail-safe: a fresh critic, silently.
-  const ceremony = resolveCeremonyForRisk({ derivedLevel: level, clusterIndex: 0 });
-  console.log(JSON.stringify({ files, level, classes, ...ceremony }));
-'
+node <main-repo>/.agents/scripts/ceremony-derive.js --story <storyId> --cwd <workCwd>
 ```
 
-Level rules ([`review-depth.js`](../../scripts/lib/orchestration/review-depth.js)):
-a sensitive path registered in `audit-rules.json` → `high`, none → `low`, an
-unenumerable diff (`files === null`) → `null`. Ceremony rules
-([`ceremony-routing.js`](../../scripts/lib/orchestration/ceremony-routing.js)):
-`minimal` → always inline, `strict` → always fresh, `standard` → `high`/`null`
-→ fresh and `low` → inline unless the `freshCriticSampleRate` floor forces
-fresh. An `inline` dispatch mode overrides all of it to inline critics. Close's
-`review-depth.js` reads the same derived level, so the two cannot disagree.
+It prints one JSON object: `files` — the one change set every critic is
+handed (`null` when the diff could not be enumerated) — plus `level` and
+`classes` from `review-depth.js`, and `mode`, `reason` and `verdictOwner`
+from `ceremony-routing.js`. Level rules: a sensitive path registered in
+`audit-rules.json` → `high`, none → `low`, an unenumerable diff → `null`.
+Ceremony rules: `minimal` → always inline, `strict` → always fresh,
+`standard` → `high`/`null` → fresh and `low` → inline. An `inline` dispatch
+mode overrides all of it to inline critics. Close's `review-depth.js` reads
+the same derived level, so the two cannot disagree. `--base <ref>` overrides
+`project.baseBranch`.
 
 ## 4. Acceptance self-eval (Step 1a, required)
 
@@ -87,52 +74,49 @@ fresh. An `inline` dispatch mode overrides all of it to inline critics. Close's
 self-eval, named by `verdictOwner`, never both and never a warm-up pass. Each
 scores its cluster's `acceptance[]` items against the change set above, with
 `verify[]` output as evidence. Bounded by `delivery.acceptanceEval.maxRounds`
-(default 2).
+(default 2; `0` scores once with no redraft).
 
-**One round = N cluster critics → ONE merged verdict → ONE gate call.** Merge
-every cluster's records into a single `criteria[]` in `acceptance[]` order, one
-per acceptance item, and score that once. A gate call per cluster spends a
-round *per cluster* and races the round ledger:
+**Inline owner:** author **one** verdict file covering every `acceptance[]`
+item and score it in **one** gate call — there is no cluster merge.
+**Fresh critics:** one round = N cluster critics → ONE merged verdict → ONE
+gate call. Merge every cluster's records into a single `criteria[]` in
+`acceptance[]` order and score that once; a gate call per cluster spends a
+round *per cluster* and races the round ledger.
 
 `node <main-repo>/.agents/scripts/acceptance-eval.js --story <storyId>
---verdict <merged-verdict-path> --expected-criteria <acceptance[] count>`
+--verdict <verdict-path>`
 
-Pass `--expected-criteria` — **without it the coverage assertion is inert**, so
-an unmerged cluster verdict scores a fraction of the criteria and still reports
-`proceed`. A mismatch is rejected before scoring and costs no round.
+The gate reads the Story's `acceptance[]` count itself and rejects a verdict
+whose `criteria[]` length differs **before** scoring, consuming no round;
+`--expected-criteria` is accepted but redundant.
 
 `proceed` → close. `redraft` → one more round inside the cap. `block` → **do
 not close**: post a `friction` comment and flip `agent::blocked`.
 Per-round mechanics: [`acceptance-self-eval.md`](acceptance-self-eval.md).
 
-## 5. The one creditable full-suite run
+## 5. The one full-suite run
 
-**After the self-eval loop's last fix commit, immediately after the push** —
-the credit is keyed on the tree, not push state: a later commit voids it, a
-push does not, and the backgrounded capture (below) ends the turn. Redraft
-rounds run scoped tests; only this run needs credit, and a bare `npm test` /
-`pnpm run test` deposits **none**, so close re-runs it. Shape it by what
-`close-validation/gates.js` runs:
+After the self-eval loop's last fix commit, run the project test runner
+**once** in the worktree:
 
 ```bash
-# CRAP gate on (default) + a `test:coverage` script — writes close's stamp:
-node <main-repo>/.agents/scripts/coverage-capture.js --cwd <workCwd>
-# otherwise — the record close's `test` gate reads; <workCwd> ABSOLUTE,
-# runner exactly `npm test` (both sides hash {cmd, args, cwd}):
-node <main-repo>/.agents/scripts/evidence-gate.js --standalone \
-  --scope-id <storyId> --gate test --worktree <workCwd> -- npm test
+npm test   # in <workCwd>
 ```
 
-Dispatch it in the **background**: it outruns the host's sync Bash ceiling, and its completion re-invokes you. Never spawn a task to poll or
-`sleep`-loop against it ([`parallel-tooling.md`](parallel-tooling.md)
-Rule 2).
-
-Read the **output**, not the exit code: capture skips — no test run, no
-credit — when nothing changed under CRAP `targetDirs`. Run the scoped
-projects for the roots you changed plus `verify[]`, not the whole suite.
+A green full run on `story-<id>` deposits the `test` evidence close reads,
+keyed on the tree, so close reports the gate as **credited** at unchanged
+HEAD — a later commit voids it. The CRAP gate still captures coverage itself
+when it needs an artifact. If the suite outruns the host's sync Bash
+ceiling, dispatch it in the **background** — its completion re-invokes you;
+never spawn a task to poll or `sleep`-loop against it
+([`parallel-tooling.md`](parallel-tooling.md) Rule 2). Read the **output**,
+not the exit code: the runner prints whether it deposited credit, and a run
+off the Story branch or of a partial tier deposits nothing and says so.
+Redraft rounds run the scoped projects for the roots you changed plus
+`verify[]`, not the whole suite; only this run needs credit.
 
 `verify[]` is scoped entries **plus** this one run: an entry that is itself a
-full-suite command is reported credited against the same stamp, never
+full-suite command is reported credited against the same record, never
 respawned.
 
 ## 6. Terminal envelope — the return contract

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

@@ -1,6 +1,6 @@
 ---
 description:
-  The unplanned prompt path shared by /mandrel-deliver and /mandrel-plan Gate #1. Judges a
+  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.
@@ -9,9 +9,9 @@ description:
 # Unplanned delivery (the prompt path)
 
 > **A path, not a command.** There is no `/deliver-light` to type. This file is
-> reached two ways — `/mandrel-deliver "<prompt>"` (an operator describing small work)
-> and `/mandrel-plan` Gate #1 (a seed the suggestion says fits the light ceilings, once
-> the operator confirms). Read
+> reached one way — `/mandrel-deliver "<prompt>"` (an operator describing small
+> work); Story #5312 retired the `/mandrel-plan` Gate #1 suggestion that used
+> to be the second door. Read
 > [`deliver-digest.md`](deliver-digest.md) once first — the engine invariants,
 > gates, and terminal-envelope contract below are its.
 
@@ -24,13 +24,11 @@ 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.
 
-Two callers, one gate: whichever door you arrived through, the suitability gate
-below is the decision. A `/mandrel-plan` Gate #1 suggestion is a *suggestion* — it is
-read against seed-time signals (`DELIVER_LIGHT_SUGGESTION_CEILINGS`: artifacts,
-risk hits, sensitive-path classes), while the gate here is read against the
-predicted work's *effort and risk* (`STORY_SHAPE_CEILINGS`: change kinds,
-magnitude, uncertainty, deployable span). They are deliberately two different
-checks, so the gate still runs after a confirm.
+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}
 
@@ -55,8 +53,10 @@ 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 **not overridable** (§ Recording a proceed-light
-answer).
+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.
 
 ## Four invariants (do not skip one)
 
@@ -64,12 +64,13 @@ answer).
    shared effort/risk machinery (`deriveStoryShape` / `deriveChangeLevel`)
    **and** a ledgered model verdict with a recorded reason. Both must agree on
    `lite`.
-2. **Over-scope stops — it never hard-fails.** An over-ceiling prompt STOPS and
-   asks the operator to escalate to `/mandrel-plan` or proceed light. **Both answers
-   are executable** — `--operator-proceed-light` records the second one
-   (§ Recording a proceed-light answer). Under `--yes` it fails closed to an
+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).
+   terminal). There is no question to wait for and no answer flag.
 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.
@@ -95,30 +96,16 @@ answer).
 
    Branch on `action` in the JSON envelope:
    - **`proceed-light`** — the receipt Story is authored; read `storyId` and
-     `nextCommands`. Continue to step 2.
-   - **`ask-operator`** — predicted scope exceeds the light ceilings. STOP and
-     ask the operator to escalate to `/mandrel-plan` or proceed light. Do not proceed
-     on your own. This is a **question, not a terminal** — wait for the answer,
-     then act on it: *escalate* leaves for `/mandrel-plan`, *proceed light* re-runs the
-     same command with `--operator-proceed-light "<their reason>"`
-     (§ Recording a proceed-light answer).
-   - **over-scope under `--yes`** — no `action` to branch on: the gate emits an
-     **`escalated` terminal envelope** instead (exit 2). § Escalation is
-     terminal governs; you are finished.
+     `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.
+   - **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.
 
    `--amends '#<id>'` is the canonical light case — shape-checked identically; a
    heavy amendment escalates to `/mandrel-plan` like any other over-scope prompt.
 
-   **Entered from `/mandrel-plan` Gate #1?** Fill `--creates` / `--refactors` /
-   `--acceptance` / `--reason` from the plan-context envelope's codebase
-   snapshot and `complexitySignals` rather than re-deriving them from the seed
-   text — Gate #1 has already done that work, and re-deriving throws away the
-   better signal. An `ask-operator` verdict here means the two ceiling sets
-   disagreed: **return to [`../mandrel-plan.md`](../mandrel-plan.md) step 2 (Author) in the same
-   session**, carrying the interrogation you already paid for. That bounce-back
-   is not an escalation and does not need a fresh session (§ Why the two
-   directions differ).
-
 2. **Init (same engine).** From the main checkout, synchronously, with the
    maximum Bash timeout:
 
@@ -177,42 +164,10 @@ answer).
    [`deliver-digest.md`](deliver-digest.md) § 5 — every close
    gate runs byte-identical to the full path.
 
-## Recording a proceed-light answer {#recording-a-proceed-light-answer}
-
-The gate offers the operator two options, so **both** have to be executable.
-Re-run the identical gate command with their answer appended:
-
-```bash
-node .agents/scripts/deliver-light.js --prompt "<prompt>" … \
-  --operator-proceed-light "<the operator's reason, in their words>"
-```
-
-The gate then proceeds light, records the decision in the receipt Story, and
-returns it on the envelope's `override`. Do **not** instead re-shape the
-prediction — shrinking `--refactors` until the gate stops objecting is
-under-declaring the footprint, which is the one thing the coarse design must
-not reward.
-
-It is deliberately narrow, and a refusal is printed rather than silent:
-
-- **Only a size prediction is waivable** — change kinds, magnitude,
-  uncertainty, deployable span. A sensitive-path class, a
-  migration-with-consumers span, and an unknown footprint (undeclared, glob,
-  no acceptance, unclassifiable) are refused: those are risk, not size, and
-  § Scope by effort keeps them absolute.
-- **The ledgered verdict still stands on its own.** The override substitutes
-  for the predicted *shape* only; `--route lite --reason "<why>"` is still
-  required.
-- **Attended-only.** With `--yes` it is a usage error, not a quiet no-op —
-  an unattended run has no operator whose answer this could be, and over-scope
-  there still fails closed (§ Escalation is terminal).
-
-What licenses this at all is step 4: the operator waives a *guess*, never the
-diff backstop, which re-checks the actual change set against ground truth.
-
 ## Escalation is terminal {#escalation-is-terminal}
 
-Over-scope under `--yes` emits a schema-validated `story-deliver-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`
 envelope with **`status: "escalated"`**, `storyId: null`, and a `nextCommand`
 naming the `/mandrel-plan` invocation that owns the work.
 
@@ -237,51 +192,31 @@ Nothing is left half-started: an escalated run creates **no receipt Story, no
 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 the two directions differ {#why-the-two-directions-differ}
+## Why escalation breaks the session {#why-the-two-directions-differ}
 
-Traffic runs both ways between this path and `/mandrel-plan`, and the two directions
-have **deliberately different session rules**. It reads like an inconsistency;
-it is not. The rule:
+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. The
-> direction whose guard is mechanical need not.**
+> **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.
-
-**`/mandrel-plan` → light may stay in-session.** Gate #1 fires **before** authoring, so
-there is no authoring to corrupt, and the frame at that point is "plan this
-seed" — the neutral one, not the small one. Everything on the receiving side is
-mechanical: `STORY_SHAPE_CEILINGS`, the ledgered verdict, the diff backstop.
-None of them degrade because the context is large, so nothing is gained by
-paying for a fresh session.
-
-Do not "fix" this into symmetry in either direction. Making `/mandrel-plan` → light
-require a fresh session throws away a paid-for interrogation for no guard.
-Letting light → `/mandrel-plan` run in-session reintroduces the exact failure the
-`escalated` envelope exists to prevent.
-
-## Constraints
-
-- **Land, block, or escalate — never a silent local build.** The close push is
-  the only sanctioned landing; an `escalated` terminal is the only sanctioned
-  ending that delivers nothing, and it ends the session
-  (§ Escalation is terminal).
-- **No parallel engine.** This path invokes `single-story-init.js` and
-  `single-story-close.js`; it never reimplements worktree, branch, PR, or merge
-  mechanics.
-- **State only via `update-ticket-state.js`.** Drive every `agent::*`
-  transition through the script; report state, not process.
+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.
 
 ## See also
 
 - [`/mandrel-deliver`](../mandrel-deliver.md) — the delivery entry point; routes here on a
   free-text prompt.
-- [`/mandrel-plan`](../mandrel-plan.md) — routes here from Gate #1 on a confirmed suggestion,
-  and owns the work an over-scope prompt escalates to.
+- [`/mandrel-plan`](../mandrel-plan.md) — owns the work an over-scope prompt
+  escalates to.
 - [`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

@@ -361,7 +361,7 @@ sensitive-path classes in `audit-rules.json`
 | Profile | Acceptance critic | When to use |
 | --- | --- | --- |
 | `minimal` | Always inline | Tiny trusted N=1 Stories |
-| `standard` | Derived-level routed (+ sampling floor) | Default |
+| `standard` | Derived-level routed | Default |
 | `strict` | Always fresh-context | High-assurance / regulated surfaces |
 
 | Scope | What runs | Mechanism |