mandrel 1.93.0 → 2.0.0

package/.agents/workflows/audit-documentation.md

@@ -47,10 +47,10 @@ generator", not "edit the doc". Auto-generated changelog files
 (`docs/CHANGELOG.md`, release-please-owned) are likewise excluded from
 semantic review beyond Step 1's deterministic checks.
 
-## Scope (Epic mode)
+## Scope (Story / plan-run mode)
 
-When this lens is invoked from `/deliver` Phase 4 (epic-audit), the
-following block is populated with the Epic's change-set file list.
+When this lens is invoked from `/deliver` close lenses (or a plan-run audit), the
+following block is populated with the Story (or plan-run) change-set file list.
 Otherwise — for any manual `/audit-<dimension>` invocation — the block
 renders the literal substitution token and you MUST treat it as **no
 scope filter — run the lens codebase-wide** exactly as you would have
@@ -174,7 +174,7 @@ and check each one:
    renames).
 3. **Workflow & Contract Descriptions:** Described workflows, label
    taxonomies (`agent::*`, `type::*`, `meta::*`), branch shapes
-   (`story-<id>`, `epic/<id>`), and artifact contracts match how the
+   (`story-<id>`), and artifact contracts match how the
    current scripts actually behave — read the implementation when the
    prose makes a behavioural claim.
 4. **Version & Topology Claims:** Version numbers, package names, release
@@ -293,7 +293,7 @@ recurring cadence so the drift is caught before it compounds:
 Route the resulting `audit-documentation-results.md` through
 [`/audit-to-stories`](audit-to-stories.md), which groups the findings,
 deduplicates them against existing Issues by fingerprint, and opens
-remediation Stories (or chains into `/plan --idea`) so the Context-Economy
+remediation Stories (or chains into `/plan --seed`) so the Context-Economy
 findings land as actionable, tracked work rather than a report nobody reads.
 
 ## Constraint

package/.agents/workflows/audit-lighthouse.md

@@ -30,10 +30,10 @@ inflate Performance scores misleadingly.
 (check `viewport` meta, responsive CSS, or operator instruction), run
 **Mobile** instead and note the choice in the report.
 
-## Scope (Epic mode)
+## Scope (Story / plan-run mode)
 
-When this lens is invoked from `/deliver` Phase 4 (epic-audit), the
-following block is populated with the Epic's change-set file list.
+When this lens is invoked from `/deliver` close lenses (or a plan-run audit), the
+following block is populated with the Story (or plan-run) change-set file list.
 Otherwise — for any manual `/audit-<dimension>` invocation — the block
 renders the literal substitution token and you MUST treat it as **no
 scope filter — run the lens codebase-wide** exactly as you would have

package/.agents/workflows/audit-navigability.md

@@ -61,8 +61,9 @@ Read the consumer's navigability config (resolved from `.agentrc.json`):
 
 - `delivery.quality.navigability.routeGlobs` — globs identifying the
   route-adding files / route tree (e.g. `pages/**`, `app/**/route.ts`). Drives
-  both the route-tree enumeration here and the route-added routing in
-  [`epic-audit-prepare.js`](../scripts/epic-audit-prepare.js).
+  both the route-tree enumeration here and the plan-persist draft
+  reachability gate
+  ([`plan-reachability.js`](../scripts/lib/orchestration/plan-reachability.js)).
 - `delivery.quality.navigability.navRegistry` — path(s) to the consumer's
   nav-registry SSOT this lens reads.
 

package/.agents/workflows/audit-performance.md

@@ -14,10 +14,10 @@ Analyze the application for performance regressions, bottlenecks, and efficiency
 gaps. Your goal is to identify why a system is slow or where it might fail under
 load.
 
-## Scope (Epic mode)
+## Scope (Story / plan-run mode)
 
-When this lens is invoked from `/deliver` Phase 4 (epic-audit), the
-following block is populated with the Epic's change-set file list.
+When this lens is invoked from `/deliver` close lenses (or a plan-run audit), the
+following block is populated with the Story (or plan-run) change-set file list.
 Otherwise — for any manual `/audit-<dimension>` invocation — the block
 renders the literal substitution token and you MUST treat it as **no
 scope filter — run the lens codebase-wide** exactly as you would have

package/.agents/workflows/audit-privacy.md

@@ -15,10 +15,10 @@ Personally Identifiable Information (PII) and ensure compliance with data
 protection standards (GDPR, CCPA). Your goal is to find accidental logging,
 insecure storage, or unnecessary collection of sensitive data.
 
-## Scope (Epic mode)
+## Scope (Story / plan-run mode)
 
-When this lens is invoked from `/deliver` Phase 4 (epic-audit), the
-following block is populated with the Epic's change-set file list.
+When this lens is invoked from `/deliver` close lenses (or a plan-run audit), the
+following block is populated with the Story (or plan-run) change-set file list.
 Otherwise — for any manual `/audit-<dimension>` invocation — the block
 renders the literal substitution token and you MUST treat it as **no
 scope filter — run the lens codebase-wide** exactly as you would have

package/.agents/workflows/audit-quality.md

@@ -24,10 +24,10 @@ and integration test coverage alongside their feature implementations. The QA
 Engineering function focuses on End-to-End (E2E) testing, complex system
 integrations, and test environment stability.
 
-## Scope (Epic mode)
+## Scope (Story / plan-run mode)
 
-When this lens is invoked from `/deliver` Phase 4 (epic-audit), the
-following block is populated with the Epic's change-set file list.
+When this lens is invoked from `/deliver` close lenses (or a plan-run audit), the
+following block is populated with the Story (or plan-run) change-set file list.
 Otherwise — for any manual `/audit-<dimension>` invocation — the block
 renders the literal substitution token and you MUST treat it as **no
 scope filter — run the lens codebase-wide** exactly as you would have

package/.agents/workflows/audit-security.md

@@ -15,10 +15,10 @@ Conduct a comprehensive security review of the codebase. Your goal is to
 identify common vulnerabilities (OWASP Top 10), insecure configurations, and
 potential attack vectors.
 
-## Scope (Epic mode)
+## Scope (Story / plan-run mode)
 
-When this lens is invoked from `/deliver` Phase 4 (epic-audit), the
-following block is populated with the Epic's change-set file list.
+When this lens is invoked from `/deliver` close lenses (or a plan-run audit), the
+following block is populated with the Story (or plan-run) change-set file list.
 Otherwise — for any manual `/audit-<dimension>` invocation — the block
 renders the literal substitution token and you MUST treat it as **no
 scope filter — run the lens codebase-wide** exactly as you would have

package/.agents/workflows/audit-seo.md

@@ -18,10 +18,10 @@ codebase. Your goal is to surface structural, semantic, and content-level
 improvements that will increase discoverability in both traditional search
 indexes and AI-powered answer engines — without making any immediate changes.
 
-## Scope (Epic mode)
+## Scope (Story / plan-run mode)
 
-When this lens is invoked from `/deliver` Phase 4 (epic-audit), the
-following block is populated with the Epic's change-set file list.
+When this lens is invoked from `/deliver` close lenses (or a plan-run audit), the
+following block is populated with the Story (or plan-run) change-set file list.
 Otherwise — for any manual `/audit-<dimension>` invocation — the block
 renders the literal substitution token and you MUST treat it as **no
 scope filter — run the lens codebase-wide** exactly as you would have

package/.agents/workflows/audit-sre.md

@@ -15,10 +15,10 @@ release candidate. Your goal is to surface critical risks across configuration
 integrity, security, observability, and code quality — providing a prioritized,
 actionable report that can be handed off for remediation before deployment.
 
-## Scope (Epic mode)
+## Scope (Story / plan-run mode)
 
-When this lens is invoked from `/deliver` Phase 4 (epic-audit), the
-following block is populated with the Epic's change-set file list.
+When this lens is invoked from `/deliver` close lenses (or a plan-run audit), the
+following block is populated with the Story (or plan-run) change-set file list.
 Otherwise — for any manual `/audit-<dimension>` invocation — the block
 renders the literal substitution token and you MUST treat it as **no
 scope filter — run the lens codebase-wide** exactly as you would have

package/.agents/workflows/audit-to-stories.md

@@ -3,7 +3,7 @@ description:
   Convert findings produced by the audit-* workflows into actionable
   GitHub Stories. Reads temp/audits/audit-*-results.md, groups findings
   cross-audit, deduplicates against existing Issues by fingerprint, and
-  either chains into /plan --idea or opens standalone Stories.
+  either chains into /plan --seed-file or opens standalone Stories.
 ---
 
 # /audit-to-stories [audit-file-or-glob]
@@ -22,8 +22,8 @@ Dimension / Category, Current State, Recommendation, Agent Prompt).
 `/audit-to-stories` closes the loop: it parses those reports, groups
 related findings (including across audit dimensions), classifies each
 group as eligible-to-create or already-tracked, and — at the operator's
-choice — either chains into `/plan --idea` for a single planned
-Epic or opens standalone Stories directly.
+choice — either chains into `/plan --seed-file` for a planned Story
+(or N>1 under the split policy) or opens standalone Stories directly.
 
 The audit producers themselves are **not modified** by this workflow.
 They remain read-only emitters of audit reports.
@@ -117,23 +117,23 @@ Ask:
 
 > How would you like these `<M>` Stories created?
 >
-> - **Single Epic via `/plan`** **[Recommended]** — opens one Epic,
->   then chains into `/plan --idea` so the standard spec-and-WBS
->   authoring handles decomposition. Grouped Stories become the
->   seed for the authoring step's decomposition.
+> - **Single plan via `/plan`** **[Recommended]** — chains into
+>   `/plan --seed-file <emitted.md>` so the standard Story authoring
+>   handles the seed. Prefer one Story; split only under the
+>   default-single policy.
 > - **Individual standalone Stories** — opens one GitHub Issue per
->   group directly, no Epic wrapper.
+>   group directly (no plan ceremony).
 
 **STOP** until the operator picks.
 
-## Phase 5a — Single-Epic path
+## Phase 5a — Single-plan path
 
-Build the `/plan` idea seed from the filtered plan envelope:
+Build the `/plan` seed from the filtered plan envelope:
 
 ```bash
-node .agents/scripts/audit-to-stories.js --emit-epic-seed \
+node .agents/scripts/audit-to-stories.js --emit-plan-seed \
   --plan temp/audits/audit-to-stories-plan.json \
-  --out "temp/audits/audit-epic-seed-$(date +%Y%m%dT%H%M%S).md"
+  --out "temp/audits/audit-plan-seed-$(date +%Y%m%dT%H%M%S).md"
 ```
 
 The seed renders the canonical one-pager sections — Problem Statement,
@@ -144,11 +144,11 @@ authoring step has concrete anchors), Not Doing.
 Chain into the existing planning entrypoint:
 
 ```text
-/plan --idea "<path-to-seed>"
+/plan --seed-file <path-to-seed>
 ```
 
-`/plan` then runs its 3-step Epic path (interrogate → author →
-persist), as documented in its workflow.
+(`/plan --seed "$(cat <path>)"` also works for small seeds). `/plan`
+then runs its author → persist path, as documented in its workflow.
 Each Story it spawns from the seed carries `context::audit:
 <reportLink>` and `audit-fingerprint: <sha>` in its body so future
 Phase 6 idempotency works on the next run.
@@ -220,13 +220,13 @@ Persist `temp/audits/audit-to-stories-$(date +%Y%m%dT%H%M%S).md`
 summarising the run:
 
 - Per-group breakdown: which findings merged, fingerprints, dependency
-  edges, created/skipped Issue link (or new Epic link).
+  edges, created/skipped Issue link (or plan-run / Story links).
 - The severity threshold and grouping mode the operator chose.
 - Final tally: `"<M> groups planned · <K> created · <J> skipped (open)
   · <L> skipped (re-occurring)"`.
 
-When the Single-Epic path ran, link the Epic the chained `/plan`
-opened. When the Standalone-Stories path ran, list every Issue URL.
+When the single-plan path ran, link the Story (or plan-run) the chained
+`/plan` opened. When the Standalone-Stories path ran, list every Issue URL.
 
 ## Constraints
 
@@ -261,8 +261,8 @@ issue 4482.)
 
 ## See also
 
-- [`/plan`](helpers/plan-epic.md) — the planning pipeline `/audit-to-stories`
-  chains into for the Single-Epic grouping mode.
+- [`/plan`](plan.md) — the planning pipeline `/audit-to-stories`
+  chains into for Story creation.
 - [`lib/findings/route-finding.js`](../scripts/lib/findings/route-finding.js) —
   the shared fingerprint/dedup/route helper this workflow and `qa-explore`
   both consume. There is no second dedup implementation.

package/.agents/workflows/audit-ux-ui.md

@@ -14,10 +14,10 @@ Evaluate the frontend implementation for UI consistency, UX best practices, and
 adherence to the project's design system. Ensure the application feels premium
 and cohesive.
 
-## Scope (Epic mode)
+## Scope (Story / plan-run mode)
 
-When this lens is invoked from `/deliver` Phase 4 (epic-audit), the
-following block is populated with the Epic's change-set file list.
+When this lens is invoked from `/deliver` close lenses (or a plan-run audit), the
+following block is populated with the Story (or plan-run) change-set file list.
 Otherwise — for any manual `/audit-<dimension>` invocation — the block
 renders the literal substitution token and you MUST treat it as **no
 scope filter — run the lens codebase-wide** exactly as you would have

package/.agents/workflows/deliver.md

@@ -1,157 +1,148 @@
 ---
 description:
-  Unified delivery entry point. Inspects the ticket type(s) and
-  Epic-reference state of the supplied IDs, composes a sequential segment
-  plan over any mix of Epics and standalone Stories, then delegates each
-  segment to the Epic wave loop or the standalone multi-Story fan-out —
-  preserving every flag and the parallel-delivery contract of the retired
-  commands.
+  Unified delivery entry point. Delivers one or more Stories via the single
+  deliver-story engine — story-<id> → PR → main. Sequences N>1 by depends_on
+  and runs the per-run epilogue once at the end.
 ---
 
-# /deliver [Epic IDs...] | [Story IDs...]
+# /deliver <storyId...> | --run <planRunId>
 
 ## Role
 
-Router. `/deliver` owns input classification, segment-plan composition, and
-path selection only — all phase content lives in the two path helpers:
+Single delivery path. `/deliver` owns input resolution and sequencing only —
+every Story runs through
+[`helpers/deliver-story.md`](helpers/deliver-story.md) (the evolved
+single-Story engine). There is no Epic wave loop, no `epic/<id>` integration
+branch, and no `--no-ff` wave merges.
 
-- [`helpers/deliver-epic.md`](helpers/deliver-epic.md) — the full Epic
-  delivery loop (preflight, wave loop fanning out
-  [`helpers/epic-deliver-story`](helpers/epic-deliver-story.md),
-  close-validation, epic-audit, code-review, retro, finalize, watch,
-  auto-merge gate, cleanup).
-- [`helpers/deliver-stories.md`](helpers/deliver-stories.md) — the
-  standalone multi-Story path (`stories-wave-tick.js` continuous ready-set
-  loop, operator confirmation, parallel fan-out to
-  [`helpers/single-story-deliver`](helpers/single-story-deliver.md)).
+## Inputs
 
-## Input matrix (authoritative)
+| Invocation | Behavior |
+| --- | --- |
+| `/deliver <storyId>` | Deliver one Story via `helpers/deliver-story.md`. |
+| `/deliver <storyId> <storyId> ...` | Sequence Stories in `depends_on` order via `stories-wave-tick.js`; each ready Story runs `deliver-story`. Default concurrency is **3**. |
+| `/deliver --run <planRunId>` | Resolve Stories labeled `plan-run::<planRunId>` (envelope includes `dag` + `done`); sequence as above; after the last Story lands, run the per-run epilogue. |
 
-Fetch each supplied ID's labels and body (`type::*` label, `Epic: #N`
-reference) before routing:
+Any ticket that is not `type::story`, or that still carries an `Epic: #N`
+reference, is a hard error naming the ID and the fix (close or re-plan as a
+v2 Story).
 
-| Input | Route |
-| --- | --- |
-| Exactly one `type::epic` ID | **Epic path** — run [`helpers/deliver-epic.md`](helpers/deliver-epic.md) Phases 1–9 unchanged (single-segment plan; no confirmation prompt). |
-| One or more `type::story` IDs, none carrying an `Epic: #N` reference | **Standalone path** — run [`helpers/deliver-stories.md`](helpers/deliver-stories.md) Phases 0–3 (single-segment plan; no confirmation prompt). |
-| Any combination of ≥1 `type::epic` IDs and ≥0 standalone `type::story` IDs | **Segment plan** — compose and execute the sequential segment plan below. |
-| Any Story carrying an `Epic: #N` reference (alone or mixed into an otherwise-valid set) | **Error**, naming every affected ID and the fix: `Story #<id> belongs to Epic #<n> — run /deliver <n>`. |
-
-Per-ID classification is unchanged: fetch the `type::*` label and probe the
-body for an `Epic: #N` reference before routing. Never guess a route.
-
-## Segment plan (mixed / multi-Epic input)
-
-When the supplied IDs span more than one Epic, or mix Epics with standalone
-Stories, the router composes a **segment plan** and executes the segments
-**strictly sequentially**:
-
-1. **Standalone segment first** (when any standalone Story IDs are
-   present): the full standalone-Story set forms **one** segment,
-   delivered via [`helpers/deliver-stories.md`](helpers/deliver-stories.md)
-   Phases 0–3 unchanged. It runs first because it is fast, each Story
-   merges to `main` independently, and each subsequent Epic segment's
-   Phase 7.0 base-sync then integrates those merges naturally instead of
-   the Epic PR opening behind base.
-2. **Epic segments in input order**: each `type::epic` ID forms its own
-   segment, delivered via
-   [`helpers/deliver-epic.md`](helpers/deliver-epic.md) Phases 1–9
-   unchanged.
-
-Sequential execution is a deliberate design decision: the Epic path assumes
-a single main checkout (prepare's checkout guard, Phase 7.0
-`git checkout epic/<id>`), holds a per-Epic lease, serializes same-machine
-sessions via `epic-merge-lock.js`, and constrains dispatch to one wave at a
-time. Segments are never interleaved or parallelized; running them one at a
-time keeps both helpers' machinery untouched.
-
-**Confirmation gate.** When the composed plan has more than one segment,
-present it to the operator before dispatching — the segments, the IDs in
-each, and the execution order — and wait for confirmation. `--yes`
-suppresses this prompt. Single-segment plans route directly with today's
-behavior (no new prompt; the standalone path's own Phase 1 confirmation
-still applies as before).
-
-**Failure policy.** A segment that ends non-complete (blocked, failed, or
-halted at a gate) **stops the run** — no subsequent segment dispatches.
-Report the terminal state: which segments completed, which segment halted
-(and why), and which segments never started. Name the resume command:
-re-running `/deliver` with the same IDs — both path helpers short-circuit
-already-done work (the Epic path resumes idempotently from its checkpoint;
-merged standalone Stories no-op).
-
-## Flags (scoped per segment)
-
-| Path | Flags |
+## Flags
+
+| Flag | Meaning |
 | --- | --- |
-| Epic | `--skip-epic-audit`, `--skip-code-review`, `--skip-retro`, `--full-retro`, `--steal`, `--as <handle>` |
-| Story | `--dep <from>:<to>`, `--yes`, `--concurrency <n>` |
+| `--run <planRunId>` | Deliver every Story in the plan-run (label `plan-run::<id>`). |
+| `--dep <from>:<to>` | Extra operator dependency edge (Story id → Story id). |
+| `--concurrency <n>` | Ready-set fan-out cap (default **3** from `delivery.deliverRunner.concurrencyCap`; set `1` for sequential). |
+| `--yes` | Suppress the multi-Story confirmation gate. |
+| `--steal` | Forwarded to `single-story-init.js` / lease steal. |
+| `--wait-merge` | Force close-and-land (default when `delivery.routing.closeAndLand` is true). |
+| `--no-wait-merge` | Opt out of close-and-land; stop at `agent::closing` for a human land. |
+
+## Procedure
+
+1. **Resolve the Story set.**
+   - Positional IDs → use them.
+   - `--run <planRunId>` →
+
+     ```bash
+     node .agents/scripts/resolve-plan-run.js --run <planRunId>
+     ```
+
+     Capture `stories[]`, `dag[]`, and `done[]` from the envelope. Prefer
+     the emitted `dag` — do **not** rebuild it by hand when `--run` was used.
+
+2. **Build the DAG (positional only).** When delivering positional IDs
+   (no `--run`), read `depends_on` / `blocked by` from each body and merge
+   `--dep` edges into a JSON DAG for `stories-wave-tick.js`:
+
+   ```json
+   [{ "id": 101, "dependsOn": [] }, { "id": 102, "dependsOn": [101] }]
+   ```
+
+3. **Confirm (N>1).** Present the order and wait unless `--yes`.
 
-In a segment plan, Epic-path flags apply to **every** Epic segment;
-Story-path flags apply to the standalone segment. `--yes` additionally
-suppresses the router's segment-plan confirmation gate above. A flag with
-no applicable segment in the plan is reported once as a no-op warning and
-ignored — never an error (the existing convention, restated for segment
-plans).
+4. **Sequence.** Loop until every Story is done:
 
-**Multi-Story parallel contract (preserved verbatim).**
+   ```bash
+   node .agents/scripts/stories-wave-tick.js \
+     --dag '<json>' --done <csv> --in-flight <n> --concurrency <n>
+   ```
+
+   For each `ready` Story id, read
+   [`helpers/deliver-story.md`](helpers/deliver-story.md) **in full** and
+   execute it (init → implement → ceremony → close-and-land). Under
+   `--yes` / injected helper content, execute directly without a re-read
+   turn.
+
+5. **Per-run epilogue (N>1).** After the last Story lands:
+
+   ```bash
+   # Plan-run label path:
+   node .agents/scripts/plan-run-epilogue.js --run <planRunId>
+
+   # Positional multi-Story path (synthesizes an adhoc planRunId):
+   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`)
+
+   A single-Story run skips the epilogue — follow-ups are captured on
+   merge confirm instead (`captureStoryFollowUps`).
+
+## Branch model (authoritative)
+
+Every Story:
 
 ```text
-/deliver <id> <id> … --dep <from>:<to> --concurrency <n> --yes
+story-<id>  →  PR  →  main (squash + required checks)
 ```
 
-preserves the retired multi-Story command's full surface — the same flags,
-the same operator confirmation gate (suppressed by `--yes`), and the same
-parallel fan-out to
-[`helpers/single-story-deliver`](helpers/single-story-deliver.md) — but
-schedules through `stories-wave-tick.js`'s **continuous ready-set loop**
-(the shared `selectReadySet` core) rather than a static wave plan: each
-Story dispatches the instant its own dependencies are done, capped by the
-resolved global `concurrencyCap` and guarded against file-overlap
-co-dispatch, exactly as the Epic path is. The parallelism lives **inside**
-the standalone segment; segments themselves remain strictly sequential.
+There is no `epic/<id>` integration branch and no `--no-ff` wave merge.
+Dependent Stories land sequentially so each builds on the previous merge
+to `main`.
 
-## Procedure
+## Ceremony (profiles + two scopes)
+
+Ceremony depth is selected by `delivery.routing.ceremonyProfile`
+(`minimal` | `standard` | `strict`, default `standard`) and the Story's
+planning risk:
+
+| Profile | Acceptance critic | When to use |
+| --- | --- | --- |
+| `minimal` | Always inline | Tiny trusted N=1 Stories |
+| `standard` | Risk-routed (+ sampling floor) | Default |
+| `strict` | Always fresh-context | High-assurance / regulated surfaces |
 
-1. **Parse args.** At least one positive-integer ID is required.
-2. **Classify.** Fetch each ticket's labels + body and apply the input
-   matrix above. Any Epic-attached Story ID is a hard error naming the
-   affected IDs and the fix — never guess a route.
-3. **Compose the segment plan.** Standalone-Story set (when present) as
-   one segment, then one segment per Epic ID in input order. For a
-   multi-segment plan, present it and wait for operator confirmation
-   (`--yes` suppresses).
-4. **Execute segments sequentially.** For each segment in order, read the
-   selected path helper **in full** and execute it from its entry phase,
-   forwarding the segment's scoped flags. The helper's phase numbering,
-   watchdogs, gates, and scripts are unchanged — this router adds no phase
-   content. Stop on the first non-complete segment per the failure policy.
-5. **Report.** On completion (or halt), summarize per-segment outcomes and,
-   when halted, the resume command.
+| Scope | What runs | Mechanism |
+| --- | --- | --- |
+| **Per-Story (always)** | Gates, branch discipline, close-and-land | `deliver-story` / `single-story-close` |
+| **Per-Story (profile + risk)** | Acceptance critic mode; review depth; audit lenses | `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 land** | Actionable follow-ups from friction | `captureStoryFollowUps` in confirm-merge |
 
 ## Constraints
 
-- **Land or block — never a silent local build (issue #4483).** The
-  helpers' orchestration path (worktrees, `story-<id>`/`epic/<id>` branches,
-  close-validation, PR) is the ONLY sanctioned delivery mechanism.
-  Executing story slices inline in this session and/or committing the
-  delivery to local `main` is expressly forbidden, regardless of how the
-  environment looks. Each path surfaces verified remote evidence
-  (`remoteVerified`) at entry; on `false`, transition the ticket to
-  `agent::blocked` quoting `remoteProbe.detail` and halt.
-- `/deliver` requires planned tickets: Epics at `agent::ready` (the
-  Epic helper's preflight enforces this, per segment) or well-formed
-  standalone Stories. Planning happens in [`/plan`](plan.md); the
-  plan-review gate between the two commands is a hard boundary.
-- The router performs no git or label mutations itself; the path helpers
-  own every script invocation.
-- Segments execute strictly sequentially — never interleave a standalone
-  Story fan-out with an Epic wave loop, and never run two Epic segments
-  concurrently.
+- **Land or block — never a silent local build.** Worktrees, `story-<id>`
+  branches, close-validation, and PR-to-`main` are the only sanctioned
+  delivery mechanism. Attended delivers default to close-and-land
+  (`delivery.routing.closeAndLand: true`); use `--no-wait-merge` only when
+  a human will land the PR.
+- `/deliver` never plans — tickets come from [`/plan`](plan.md).
+- The router performs no git/label mutations; `deliver-story` owns every
+  script invocation per Story.
 
 ## See also
 
-- [`/plan`](plan.md) — the unified planning entry point.
-- [`helpers/deliver-epic.md`](helpers/deliver-epic.md) /
-  [`helpers/deliver-stories.md`](helpers/deliver-stories.md) — the path
-  helpers, delegated to per segment.
+- [`/plan`](plan.md) — unified planning entry point.
+- [`helpers/deliver-story.md`](helpers/deliver-story.md) — the one Story
+  delivery engine.
+- Placeholder design Story for a fully deterministic deliver-run
+  orchestrator: [#4521](https://github.com/dsj1984/mandrel/issues/4521).

package/.agents/workflows/git-cleanup.md

@@ -226,10 +226,9 @@ The merged-branch sweep recognizes three detection signals, in order:
    `git merge-tree --write-tree <base> <branch>` (git ≥ 2.38) produces a
    tree identical to `<base>`'s own tree — i.e. applying the branch's
    changes on top of `<base>` is a content no-op. This catches
-   `story-<id>` branches merged into `epic/<id>` whose Epic PR
-   **squash-merged** to `main` (the story commits are not ancestors of
-   `main` and the story branch usually has no PR of its own), and any
-   other branch whose content landed via a different route (a renamed
+   `story-<id>` branches whose PR **squash-merged** to `main` (the story
+   commits are not ancestors of `main`), and any other branch whose content
+   landed via a different route (a renamed
    head, a cherry-pick, a manual `merge --squash`). When git rejects
    `--write-tree` (git < 2.38) or the simulated merge conflicts, the
    probe is inconclusive and the branch keeps its existing `not-merged`

package/.agents/workflows/helpers/_merge-conflict-template.md

@@ -1,7 +1,7 @@
 # Merge Conflict Resolution — Shared Procedure
 
 Canonical, workflow-agnostic procedure for resolving merge / rebase conflicts.
-Referenced by `deliver-stories.md` and `deliver-epic.md`.
+Referenced by `deliver.md` and `helpers/deliver-story.md`.
 
 ## Procedure