mandrel 1.59.0 → 1.61.0

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

@@ -7,7 +7,7 @@ description: >-
 # Code Review (helper)
 
 > **Helper module.** Not a slash command. Invoked automatically from
-> `/story-deliver` (Story scope) and `/epic-deliver` Phase 5 (Epic scope).
+> `/deliver` (Story scope) and `/deliver` Phase 5 (Epic scope).
 > To run a review directly, invoke the parent workflow — operators do not
 > call this helper by hand.
 
@@ -17,7 +17,7 @@ is merged upstream. It runs in two scopes:
 - **Story scope** — reviews the diff between a Story branch and its parent
   Epic branch, before `story-close.js` merges the Story into the Epic.
 - **Epic scope** — reviews the cumulative diff between an Epic branch and
-  `main`, before `/epic-deliver` opens the integration pull request.
+  `main`, before `/deliver` opens the integration pull request.
 
 > **Persona**: `architect` · **Skills**: `core/code-review-and-quality`,
 > `core/security-and-hardening`
@@ -43,7 +43,7 @@ the argument envelope.
 
 `depth` is the risk-derived thoroughness lever introduced by Story #3876 and
 made a live consumed signal end to end by Story #3937. The Epic caller
-(`/epic-deliver` Phase 5) resolves it from the Epic's judged `planningRisk`
+(`/deliver` Phase 5) resolves it from the Epic's judged `planningRisk`
 envelope via
 [`resolveReviewDepthForEpic`](../../scripts/lib/orchestration/code-review.js)
 (`high` → `deep`, `low` → `light`, everything else — including a missing
@@ -54,7 +54,7 @@ It is an **input-only** signal: it changes *how thorough* the review is, never
 the findings envelope (`{ status, severity, posted, report, halted,
 blockerReason }`) nor the posted `code-review` structured-comment body. An
 absent or malformed `depth` is treated as `standard`, so an Epic that skipped
-`/epic-plan` still gets a passing review with no new failure mode.
+`/plan` still gets a passing review with no new failure mode.
 
 How each tier changes the review protocol:
 
@@ -307,7 +307,7 @@ When `selectedAudits` is non-empty:
 2. **Append** a `## Cross-phase re-check` section to the **existing**
    `audit-results` structured comment on the Epic ticket. Do **not** post
    a new comment; the comment is idempotent and downstream consumers
-   (the code-review trim, `/epic-deliver` Pillar 2, the retro helper)
+   (the code-review trim, `/deliver` Pillar 2, the retro helper)
    read it once. The append carries the re-checked lens names, the new
    findings (if any), and the focused-fix commit SHAs that triggered the
    re-run, so reviewers can trace each finding back to the change set

package/.agents/workflows/{epic-deliver.md → helpers/deliver-epic.md}

@@ -10,16 +10,16 @@ description: >-
   inspects the surface area.
 ---
 
-# /epic-deliver #[Epic ID]
+# helpers/deliver-epic — Epic delivery path (invoked by /deliver)
 
 ## Overview
 
-`/epic-deliver` is the **single SDL execution command** in the 5.40 surface.
+`/deliver` is the **single SDL execution command** in the 5.40 surface.
 It opens a PR against `main` and auto-merges when every signal certifies a
 clean run; otherwise it falls back to the operator-merges-button path.
 
 ```text
-/epic-deliver <epicId>
+/deliver <epicId>
   → Phase 1 — prepare              (epic-deliver-prepare.js)
   → Phase 2 — wave loop            (wave-tick.js + Agent fan-out × concurrencyCap)
   → Phase 3 — close-validation     (lint + test + ratchets on epic/<id>)
@@ -33,8 +33,8 @@ clean run; otherwise it falls back to the operator-merges-button path.
 ```
 
 The argument is always an Epic ID (`type::epic`). Story IDs go to
-[`/story-deliver`](story-deliver.md) (standalone) or the
-[`helpers/epic-deliver-story`](helpers/epic-deliver-story.md) helper
+[`/deliver`](deliver-stories.md) (standalone) or the
+[`helpers/epic-deliver-story`](epic-deliver-story.md) helper
 (Epic-attached, invoked by this workflow's fan-out); Tasks are not directly
 executable.
 Story dispatch is in-session via the Agent tool — no subprocess is
@@ -45,11 +45,11 @@ spawned.
 ## Arguments
 
 ```text
-/epic-deliver <epicId> [--skip-epic-audit] [--skip-code-review] [--skip-retro] [--full-retro]
+/deliver <epicId> [--skip-epic-audit] [--skip-code-review] [--skip-retro] [--full-retro]
 ```
 
 - `epicId` — must carry `type::epic`. Otherwise STOP and tell the operator
-  to use `/story-deliver <id>` (standalone Story) or open the parent Epic.
+  to use `/deliver <id>` (standalone Story) or open the parent Epic.
 - `--skip-epic-audit` — skip Phase 4 (log the override). Use only when the
   change-set audits are known to be irrelevant (e.g., docs-only Epic).
 - `--skip-code-review` — skip Phase 5 (log the override).
@@ -79,7 +79,7 @@ Every other runtime modifier is sourced from the Epic's labels or from
   typed events on the in-session lifecycle bus; a fixed roster of
   listeners performs the side effects. Phase 7, 8.5, and 9 each fire
   exactly one lifecycle event via the generic
-  [`lifecycle-emit.js`](../scripts/lifecycle-emit.js) CLI
+  [`lifecycle-emit.js`](../../scripts/lifecycle-emit.js) CLI
   (`--event epic.close.end` / `--event epic.automerge.start` /
   `--event epic.merge.armed`); the matching listener chain runs the
   bus-driven side effects (acceptance reconcile, automerge-armer,
@@ -88,20 +88,20 @@ Every other runtime modifier is sourced from the Epic's labels or from
   the canonical manual sequence and `finalizer.js` for the listener's
   no-op disclaimer. The append-only NDJSON ledger at
   `temp/epic-<id>/lifecycle.ndjson` is the resume target. See
-  [`docs/LIFECYCLE.md`](../../docs/LIFECYCLE.md) for the bus
+  [`docs/LIFECYCLE.md`](../../../docs/LIFECYCLE.md) for the bus
   contract, event taxonomy, ledger format, and listener model.
 
-> **Hierarchy.** `/epic-deliver` operates over the 3-tier hierarchy
-> (Epic → Feature → Story). The fan-out is one `Agent` tool call per
+> **Hierarchy.** `/deliver` operates over the 2-tier hierarchy
+> (Epic → Story). The fan-out is one `Agent` tool call per
 > Story per wave (§ 2b); Story branches merge into `epic/<id>` with
 > `--no-ff` via `story-close.js`; the close-validation chain
 > (Phase 3), epic-audit, code-review, retro, finalize, and auto-merge
 > gates all operate on Story-level units.
-> [`helpers/epic-deliver-story`](helpers/epic-deliver-story.md) runs a
+> [`helpers/epic-deliver-story`](epic-deliver-story.md) runs a
 > single Story-implementation phase per Story against the Story's
 > inline `acceptance[]` / `verify[]` fields. See
-> [`.agents/instructions.md` § 5.D](../instructions.md) and
-> [`.agents/docs/SDLC.md` § Ticket hierarchy](../docs/SDLC.md) for the full
+> [`.agents/instructions.md` § 5.D](../../instructions.md) and
+> [`.agents/docs/SDLC.md` § Ticket hierarchy](../../docs/SDLC.md) for the full
 > contract.
 
 ---
@@ -132,7 +132,7 @@ flip the Epic to `agent::blocked`, surface the envelope in chat for the
 operator, and halt before Phase 1's `epic-deliver-prepare.js` call.
 Resume after the operator unblocks (raising the threshold in
 `.agentrc.json`, splitting the Epic, or accepting the cost) by re-running
-`/epic-deliver <epicId>` — the preflight is idempotent and the second
+`/deliver <epicId>` — the preflight is idempotent and the second
 run upserts the same comment in place.
 
 Threshold defaults live in `delivery.preflight.*` in `.agentrc.json`
@@ -157,7 +157,7 @@ and upserts the `epic-run-state` checkpoint. Treat the printed JSON as
 > **Preflight guards (Story #3482 / F-workflow-guards).** Before the
 > snapshot phase runs — and before any worktree is created — prepare runs
 > two **fail-closed** guards
-> ([`lib/orchestration/epic-deliver-lease-guard.js`](../scripts/lib/orchestration/epic-deliver-lease-guard.js)):
+> ([`lib/orchestration/epic-deliver-lease-guard.js`](../../scripts/lib/orchestration/epic-deliver-lease-guard.js)):
 >
 > 1. **Checkout safety.** Prepare refuses to start when the working tree is
 >    dirty or HEAD is on a branch other than the expected one (`epic/<id>`
@@ -182,23 +182,23 @@ and upserts the `epic-run-state` checkpoint. Treat the printed JSON as
 >    `epic-merge-lock.js` continues to serialize same-machine sessions.
 >
 > Both guards throw on failure, which `runAsCli` maps to `process.exit(1)`
-> per [`orchestration-error-handling.md`](../rules/orchestration-error-handling.md).
+> per [`orchestration-error-handling.md`](../../rules/orchestration-error-handling.md).
 
 Once the preflight guards pass, the snapshot phase applies one more gate:
 
 > **Acceptance-spec start gate.** Before the wave loop fans out, the
 > snapshot phase
-> ([`lib/orchestration/epic-runner/phases/snapshot.js`](../scripts/lib/orchestration/epic-runner/phases/snapshot.js))
+> ([`lib/orchestration/epic-runner/phases/snapshot.js`](../../scripts/lib/orchestration/epic-runner/phases/snapshot.js))
 > asserts that the Epic either carries the `acceptance::n-a` waiver
 > label **or** has a linked `context::acceptance-spec` ticket. The
 > ticket's GitHub state (open / closed) is **not** checked —
 > presence is sufficient, matching the PRD and Tech Spec contract.
-> The reviewer's OK during `/epic-plan` Phase 7 is the approval
+> The reviewer's OK during `/plan` Phase 7 is the approval
 > signal, not a manual ticket-close action. Neither condition met →
 > the snapshot throws a clear error
 > (`[epic-deliver] Epic #<id> cannot launch: …`) and `runAsCli`
 > maps it to `process.exit(1)`. Operator remediation: either run
-> `/epic-plan` Phase 7 to author the spec, or apply the
+> `/plan` Phase 7 to author the spec, or apply the
 > `acceptance::n-a` label to opt out.
 
 ---
@@ -206,7 +206,7 @@ Once the preflight guards pass, the snapshot phase applies one more gate:
 ## Phase 2 — Wave loop
 
 The wave-loop state machine lives in
-[`lib/wave-runner/tick.js`](../scripts/lib/wave-runner/tick.js) — one
+[`lib/wave-runner/tick.js`](../../scripts/lib/wave-runner/tick.js) — one
 stateless `tick({ epic })` call returns one `WaveTickResult` describing
 the next action. The slash command's job is to call `tick()` via its CLI
 shim, dispatch from `nextAction.stories` via the Agent tool, persist the
@@ -243,7 +243,7 @@ only the two wave-window forensics signals that have a live consumer —
 `waveParallelism` report (and `wave-start` anchors span-tree Story spans).
 Story #3909 retired the write-only wave events with no reader (`wave-tick`,
 `epic-complete`) — they duplicated the checkpoint + rollup. The
-[`signals` helper](helpers/signals.md) (`node .agents/scripts/signals-view.js`)
+[`signals` helper](signals.md) (`node .agents/scripts/signals-view.js`)
 renders the forensics signals in the span-tree view.
 
 ### 2b. Dispatch — fan out per-Story Agent calls
@@ -252,7 +252,7 @@ renders the forensics signals in the span-tree view.
 invoke `helpers/epic-deliver-story` yourself. Emit **one `Agent` tool call per
 Story** in `nextAction.stories` (even when `length === 1` — the
 parent-child boundary keeps the return-parser uniform). The *children*
-run [`helpers/epic-deliver-story`](helpers/epic-deliver-story.md). Use
+run [`helpers/epic-deliver-story`](epic-deliver-story.md). Use
 `subagent_type: general-purpose`.
 
 Emit **one assistant turn** with **N parallel `Agent` calls** where
@@ -276,7 +276,7 @@ the cap, never wait for a whole batch before refilling.
 **Ledger the dispatch BEFORE the Agent call.** Immediately before each
 per-Story `Agent` tool call (one shell-out per Story, every attempt —
 including retries from a refill), invoke
-[`lifecycle-emit-story-dispatch.js`](../scripts/lifecycle-emit-story-dispatch.js)
+[`lifecycle-emit-story-dispatch.js`](../../scripts/lifecycle-emit-story-dispatch.js)
 so the lifecycle ledger durably records the dispatch attempt. The
 emit must happen **before** the Agent call fires — never after — so
 that a host-process crash mid-Agent leaves a `story.dispatch.start`
@@ -425,7 +425,7 @@ one in-flight Story has been silent for ≥ the threshold:
 
 **On a stall.** When the watchdog exits non-zero, post the envelope
 verbatim as a `wave-stall` structured comment on the Epic (use
-[`post-structured-comment.js`](../scripts/post-structured-comment.js)
+[`post-structured-comment.js`](../../scripts/post-structured-comment.js)
 with `--kind wave-stall`), then re-evaluate the affected Stories: if a
 child sub-agent has crashed (no `story.dispatch.end`, no recent
 heartbeat, no commit on `story-<id>`), re-dispatch the Story per § 2b
@@ -465,14 +465,14 @@ the Epic branch; if any drifts, refresh and commit
 ## Phase 4 — Epic audit (change-set lenses)
 
 Skip when `--skip-epic-audit`. Otherwise auto-invoke
-[`helpers/epic-audit.md`](helpers/epic-audit.md) inline. The helper runs
-[`epic-audit-prepare.js`](../scripts/epic-audit-prepare.js) to ask the
-[`selectAudits`](../scripts/lib/audit-suite/index.js) SDK which lenses fire
+[`helpers/epic-audit.md`](epic-audit.md) inline. The helper runs
+[`epic-audit-prepare.js`](../../scripts/epic-audit-prepare.js) to ask the
+[`selectAudits`](../../scripts/lib/audit-suite/index.js) SDK which lenses fire
 at the `gate3` close gate, **unions in the model-judged risk-routed lenses**
 (Story #3889 — `epic-audit-prepare.js` reads the Epic's `planningRisk`
 envelope off the `epic-plan-state` checkpoint and maps each high-risk axis to
 its lens via `resolveAuditLenses`), then dispatches each selected lens through
-[`runAuditSuite`](../scripts/lib/audit-suite/index.js). A high-risk Epic
+[`runAuditSuite`](../../scripts/lib/audit-suite/index.js). A high-risk Epic
 therefore auto-runs its mapped lenses (e.g. a `security`-axis Epic runs
 `audit-security`) even when the change set alone did not select them; a
 low-risk Epic adds nothing. Findings are persisted as an `audit-results`
@@ -492,7 +492,7 @@ structured comment on the Epic.
 
 Skip when `--skip-code-review`. Otherwise resolve the **risk-derived review
 depth** for this Epic, then auto-invoke
-[`helpers/code-review.md`](helpers/code-review.md) inline (read-only audit)
+[`helpers/code-review.md`](code-review.md) inline (read-only audit)
 with the argument envelope `{ scope: 'epic', ticketId: <epicId>, baseRef:
 'main', headRef: 'epic/<epicId>', depth: <reviewDepth> }`. The helper
 persists findings as a `code-review` structured comment on the Epic.
@@ -500,11 +500,11 @@ persists findings as a `code-review` structured comment on the Epic.
 The `depth` is the live epic-scope producer for Story #3876's review-depth
 lever (Story #3937). Resolve it from the Epic's judged risk envelope the same
 best-effort way Phase 4 routes audit lenses — via
-[`resolveReviewDepthForEpic`](../scripts/lib/orchestration/code-review.js),
+[`resolveReviewDepthForEpic`](../../scripts/lib/orchestration/code-review.js),
 which reads `planningRisk.overallLevel` off the Epic's `epic-plan-state`
 checkpoint and maps it: `high` → `deep`, `low` → `light`, everything else
 (including a missing/unparseable checkpoint, or an Epic that skipped
-`/epic-plan`) → `standard`. The helper threads `depth` into `runCodeReview`,
+`/plan`) → `standard`. The helper threads `depth` into `runCodeReview`,
 which forwards it to every provider's `runReview` input; the LLM-backed
 providers (codex, security-review, ultrareview) render it into the prompt they
 emit so a high-risk Epic gets a deeper adversarial pass and a low-risk one a
@@ -527,12 +527,12 @@ runner via its CLI wrapper:
 node .agents/scripts/retro-run.js --epic <epicId>
 ```
 
-[`retro-run.js`](../scripts/retro-run.js) resolves the config/provider,
+[`retro-run.js`](../../scripts/retro-run.js) resolves the config/provider,
 constructs a lifecycle bus with a `LedgerWriter` (so the run's
 `retro.start` / `retro.end` boundaries land in
 `temp/epic-<epicId>/lifecycle.ndjson`), and calls `runRetro` — the
 canonical compose-and-post surface at
-[`.agents/scripts/lib/orchestration/retro-runner.js`](../scripts/lib/orchestration/retro-runner.js).
+[`.agents/scripts/lib/orchestration/retro-runner.js`](../../scripts/lib/orchestration/retro-runner.js).
 Propagate `--full-retro` to bypass the compact-path heuristic.
 
 Retro fires here (before the PR opens) so it stays in the operator's
@@ -541,7 +541,7 @@ local session with full env access (env vars, credentials, MCP).
 After the GitHub upsert succeeds, the retro body is also **mirrored
 locally** to the per-Epic temp tree at `temp/epic-<epicId>/retro.md`
 (path resolved via
-[`lib/config/temp-paths.js`](../scripts/lib/config/temp-paths.js)'s
+[`lib/config/temp-paths.js`](../../scripts/lib/config/temp-paths.js)'s
 `epicRetroMirrorPath`, which honours `project.paths.tempRoot`).
 Operators can read the retro without re-fetching from GitHub. GitHub
 remains the source of truth — a mirror-write failure only logs a warn
@@ -592,16 +592,16 @@ responsibility below runs inside the listener chain — the operator
 shells nothing manually. The `Finalizer` listener (Story #2894 —
 bus-owned finalize) composes three helpers under
 `.agents/scripts/lib/orchestration/finalize/` and emits the canonical
-chain.** Treat this section as a runtime contract — `/epic-deliver`
+chain.** Treat this section as a runtime contract — `/deliver`
 just fires the emit and reads the resulting ledger.
 
 1. **Acceptance-spec reconciliation — bus-driven.** The
    `AcceptanceReconciler` listener invokes
-   [`acceptance-spec-reconciler.js`](../scripts/acceptance-spec-reconciler.js)
+   [`acceptance-spec-reconciler.js`](../../scripts/acceptance-spec-reconciler.js)
    to diff the AC IDs declared in the linked `context::acceptance-spec`
    body against `@ac-*` / `@pending` tags in `tests/features/**`. A
    non-OK reconciliation throws (per
-   [`rules/orchestration-error-handling.md`](../rules/orchestration-error-handling.md)),
+   [`rules/orchestration-error-handling.md`](../../rules/orchestration-error-handling.md)),
    aborting finalize **before** any PR is opened or planning artifacts
    are closed — so the PRD, Tech Spec, and Acceptance Spec stay open
    until the AC coverage gap is fixed. The reconciler returns
@@ -611,10 +611,10 @@ just fires the emit and reads the resulting ledger.
    start gate in Phase 1 would normally catch that first).
 2. **PR open — bus-driven (Story #2894).** On
    `acceptance.reconcile.ok` the `Finalizer` listener invokes
-   [`openOrLocatePr`](../scripts/lib/orchestration/finalize/open-or-locate-pr.js)
+   [`openOrLocatePr`](../../scripts/lib/orchestration/finalize/open-or-locate-pr.js)
    with `{ epicId, headBranch: 'epic/<id>', baseBranch: 'main' }`.
    The helper probes for an existing open PR on the head branch
-   first (idempotent locate path — a re-run of `/epic-deliver`
+   first (idempotent locate path — a re-run of `/deliver`
    on the same branch short-circuits without opening a duplicate)
    and only opens a new PR when none exists. The listener then
    emits `pr.created` → `epic.finalize.end` and **stops** (Story
@@ -627,17 +627,17 @@ just fires the emit and reads the resulting ledger.
    driven later from the gated watch path (`pr.created` → `Watcher`
    → `epic.watch.end` → `AutomergePredicate` → `epic.merge.ready` →
    `AutomergeArmer`) re-entered in Phase 8.5. The merge-lockout rule
-   in [`check-lifecycle-lint.js`](../scripts/check-lifecycle-lint.js)
+   in [`check-lifecycle-lint.js`](../../scripts/check-lifecycle-lint.js)
    keeps `gh pr merge --auto --squash --delete-branch` confined to
    `AutomergeArmer` — Phase 7 never shells the merge command.
 3. **Planning-artifact close + hand-off — bus-driven (Story
    #2894).** After `openOrLocatePr` returns, the `Finalizer` chains
-   [`closePlanningTickets`](../scripts/lib/orchestration/finalize/close-planning-tickets.js)
+   [`closePlanningTickets`](../../scripts/lib/orchestration/finalize/close-planning-tickets.js)
    to close the three planning context tickets
    (`context::prd`, `context::tech-spec`, `context::acceptance-spec`)
    so the Epic's `Closes #<id>` auto-close path is not blocked by
    open sub-issues, then
-   [`postHandoffComment`](../scripts/lib/orchestration/finalize/post-handoff-comment.js)
+   [`postHandoffComment`](../../scripts/lib/orchestration/finalize/post-handoff-comment.js)
    to upsert the canonical `epic-handoff` structured comment naming
    the PR URL. Both helpers are idempotent — already-closed tickets
    are counted under `alreadyClosed`, and the handoff comment is

package/.agents/workflows/{story-deliver.md → helpers/deliver-stories.md}

@@ -4,20 +4,20 @@ description: >-
   computes a dependency-aware wave plan via `stories-wave-tick.js`, asks the
   operator to confirm the plan, then fans out parallel Agent calls per wave
   — each delegating to `helpers/single-story-deliver`. Stories without an
-  `Epic: #N` reference only; Epic-attached Stories use `/epic-deliver`.
+  `Epic: #N` reference only; Epic-attached Stories use `/deliver`.
 ---
 
-# /story-deliver [Story IDs...]
+# helpers/deliver-stories — multi-Story delivery path (invoked by /deliver)
 
 ## Overview
 
-`/story-deliver` is the **operator-facing multi-Story delivery command**. It
+`/deliver` is the **operator-facing multi-Story delivery command**. It
 takes one or more Story IDs, builds a dependency-aware wave plan, optionally
 confirms it with the operator, and fans out one Agent call per Story per wave
 — parallel within each wave, serialised across waves.
 
 ```text
-/story-deliver 101 102 103
+/deliver 101 102 103
   → Phase 0 — Validate input & build DAG
   → Phase 1 — stories-wave-tick.js → wave plan + operator confirmation
   → Phase 2 — for each wave:
@@ -26,22 +26,22 @@ confirms it with the operator, and fans out one Agent call per Story per wave
   → Phase 3 — Summary
 ```
 
-**When to use `/story-deliver` vs. other commands:**
+**When to use `/deliver` vs. other commands:**
 
 | Scenario | Command |
 | --- | --- |
-| 1+ standalone Stories (no `Epic: #N` in body) | `/story-deliver <id> [<id>...]` |
+| 1+ standalone Stories (no `Epic: #N` in body) | `/deliver <id> [<id>...]` |
 | Exactly one standalone Story (lighter path) | `/single-story-deliver <id>` |
-| Epic-attached Stories (have `Epic: #N`) | `/epic-deliver <epicId>` |
+| Epic-attached Stories (have `Epic: #N`) | `/deliver <epicId>` |
 
-`/story-deliver` **refuses** Stories that carry an `Epic: #N` reference in
+`/deliver` **refuses** Stories that carry an `Epic: #N` reference in
 their body. Those Stories belong to an Epic's dispatch manifest and must flow
-through `/epic-deliver`. Use `/single-story-deliver` for a single Epic-free
+through `/deliver`. Use `/single-story-deliver` for a single Epic-free
 Story when you want the leaner one-story path without wave machinery.
 
 > **Concurrency cap.** The cap is resolved **deterministically in code** by
 > `stories-wave-tick.js` (Phase 1a) — the same `resolveConfig` + `getRunners`
-> seam `/epic-deliver` uses — and emitted as the `concurrencyCap` field on the
+> seam `/deliver` uses — and emitted as the `concurrencyCap` field on the
 > `stories-wave-plan` envelope. The default is 3; override persistently via
 > `delivery.deliverRunner.concurrencyCap` in `.agentrc.json` (a
 > `.agentrc.local.json` override is honored) or per-run via the `--concurrency`
@@ -53,7 +53,7 @@ Story when you want the leaner one-story path without wave machinery.
 ## Arguments
 
 ```text
-/story-deliver <storyId> [<storyId> ...] [--dep <fromId>:<toId> ...] [--yes] [--concurrency <n>]
+/deliver <storyId> [<storyId> ...] [--dep <fromId>:<toId> ...] [--yes] [--concurrency <n>]
 ```
 
 - `storyId` — One or more GitHub issue numbers carrying `type::story` and
@@ -79,7 +79,7 @@ For each supplied Story ID:
 
 1. Confirm the issue exists and carries the `type::story` label.
 2. Confirm the issue body does **not** contain an `Epic: #N` reference. If
-   it does, STOP and tell the operator to use `/epic-deliver <epicId>`
+   it does, STOP and tell the operator to use `/deliver <epicId>`
    instead.
 3. Collect `blocked by #N` references between the supplied Story IDs.
    References to Story IDs outside the supplied set are advisory warnings
@@ -112,7 +112,7 @@ node .agents/scripts/stories-wave-tick.js --dag '<dag-json>'
 node .agents/scripts/stories-wave-tick.js --dag '<dag-json>' --concurrency <n>
 ```
 
-When the operator passed `--concurrency <n>` to `/story-deliver`, forward it
+When the operator passed `--concurrency <n>` to `/deliver`, forward it
 verbatim to `stories-wave-tick.js`. The script resolves the cap from config
 (`delivery.deliverRunner.concurrencyCap`, default 3) and the override wins for
 that run.
@@ -184,7 +184,7 @@ envelope field is the single deterministic source.
 Each Agent call:
 
 1. Names the Story ID and instructs the child to invoke
-   [`helpers/single-story-deliver`](helpers/single-story-deliver.md)
+   [`helpers/single-story-deliver`](single-story-deliver.md)
    for that Story.
 2. States the **return contract** (see § 2c).
 3. Reminds the child of the **non-interactive contract**: no clarifying
@@ -226,7 +226,7 @@ After every Story in a wave returns:
 - **Any `status === 'blocked'`** → STOP the wave loop. Post a summary
   of blocked Stories and their `blockerCommentId` references. Do not
   dispatch the next wave. Wait for the operator to resolve each blocker
-  and re-run `/story-deliver` with the same set (already-done Stories
+  and re-run `/deliver` with the same set (already-done Stories
   will short-circuit because `single-story-close.js` is idempotent).
 - **Any `status === 'failed'`** → STOP the wave loop. Report the
   failures. The operator must fix the failing Stories before re-running.
@@ -238,7 +238,7 @@ After every Story in a wave returns:
 Print a final run summary:
 
 ```text
-/story-deliver — 3 Stories delivered in 2 waves
+/deliver — 3 Stories delivered in 2 waves
 
   Wave 0: #101 ✅ done, #103 ✅ done
   Wave 1: #102 ✅ done
@@ -265,8 +265,8 @@ Story's suite is green and the close-validation gates already pass — and
 key is unset or `false`, story-deliver behaves exactly as documented above
 and this stage is skipped entirely.
 
-The stage adopts the [`refactorer`](../personas/refactorer.md) persona and the
-[`core/refactoring-discipline`](../skills/core/refactoring-discipline/SKILL.md)
+The stage adopts the [`refactorer`](../../personas/refactorer.md) persona and the
+[`core/refactoring-discipline`](../../skills/core/refactoring-discipline/SKILL.md)
 skill to drive a behaviour-preserving pass that lowers CRAP and removes
 duplication on the files the Story already touched:
 
@@ -277,7 +277,7 @@ duplication on the files the Story already touched:
   must be reverted.
 - **Advisory, not a gate.** This stage does **not** introduce a new
   close-validation gate and does **not** change the semantics of the existing
-  [close-validation](../scripts/lib/close-validation/runner.js) chain (typecheck,
+  [close-validation](../../scripts/lib/close-validation/runner.js) chain (typecheck,
   lint, test, format, maintainability, coverage, crap). The canonical gates
   remain the single source of pass/fail at close; the refactor stage only adds
   an extra behaviour-preserving cleanup commit when enabled.
@@ -293,7 +293,7 @@ duplication on the files the Story already touched:
 `/single-story-deliver` is idempotent at every phase:
 `single-story-init.js` reuses an existing worktree and
 `single-story-close.js` short-circuits when the Story is already closed.
-Re-running `/story-deliver` with the same Story set after a partial
+Re-running `/deliver` with the same Story set after a partial
 failure is safe — already-done Stories produce no-op outcomes; only the
 blocked or unstarted Stories execute.
 
@@ -313,15 +313,15 @@ blocked or unstarted Stories execute.
   `node .agents/scripts/update-ticket-state.js --ticket <id> --state <state>`.
   This CLI is the authoritative mechanism — there is no separate
   state-mutation MCP server to degrade from (see
-  [`.agents/instructions.md` § 1.D](../instructions.md)).
+  [`.agents/instructions.md` § 1.D](../../instructions.md)).
 
 ---
 
 ## See also
 
-- [`helpers/single-story-deliver`](helpers/single-story-deliver.md) — the
+- [`helpers/single-story-deliver`](single-story-deliver.md) — the
   per-Story worker this command delegates to.
-- [`/epic-deliver`](epic-deliver.md) — full Epic wave loop for
+- [`/deliver`](deliver-epic.md) — full Epic wave loop for
   Epic-attached Stories.
-- [`helpers/epic-deliver-story`](helpers/epic-deliver-story.md) — the
-  per-Story worker `/epic-deliver` uses internally.
+- [`helpers/epic-deliver-story`](epic-deliver-story.md) — the
+  per-Story worker `/deliver` uses internally.

package/.agents/workflows/helpers/diagnose.md

@@ -9,7 +9,7 @@ description: >-
 
 > **Helper, not a slash command.** Files under `workflows/helpers/` are not
 > projected into the mandrel plugin command tree. The same `lib/checks/` registry runs
-> automatically as preflight inside `/epic-deliver`, `/story-close`, and
+> automatically as preflight inside `/deliver`, `/story-close`, and
 > `npm test` — this viewer exists only for ad-hoc inspection. Invoke the
 > backing script directly: `node .agents/scripts/diagnose.js [args]`.
 

package/.agents/workflows/helpers/epic-audit.md

@@ -8,8 +8,8 @@ description: >-
 # Epic Audit (helper)
 
 > **Helper module.** Not a slash command. Invoked automatically from
-> `/epic-deliver` Phase 4 once the wave loop completes (all Stories at
-> `agent::done`). To run an audit directly, use `/epic-deliver [Epic_ID]` — it
+> `/deliver` Phase 4 once the wave loop completes (all Stories at
+> `agent::done`). To run an audit directly, use `/deliver [Epic_ID]` — it
 > delegates here (or pass `--skip-epic-audit` to bypass).
 
 This helper runs the **change-set-aware audit pass** on an Epic branch
@@ -32,7 +32,7 @@ change-set selection. Both lens sources fire through the **same**
 `runAuditSuite` dispatch below — no new audit machinery.
 
 > **When to run**: After Phase 3 close-validation passes and before Phase 5
-> code-review. `/epic-deliver` invokes this automatically once the wave loop
+> code-review. `/deliver` invokes this automatically once the wave loop
 > completes and all Stories reach `agent::done`.
 >
 > **Persona**: `architect` · **Skills**: `core/code-review-and-quality`,
@@ -94,7 +94,7 @@ resolved by the shared `resolveDepth` resolver from the Epic's model-judged
 risk envelope (`overallLevel` off the `epic-plan-state` checkpoint) folded
 with `changedFilesCount`: a high-risk **or** wide-footprint Epic resolves to
 `deep`, a low-risk small one to `light`, and everything else — including an
-Epic that skipped `/epic-plan` and has no checkpoint — to `standard`.
+Epic that skipped `/plan` and has no checkpoint — to `standard`.
 
 Depth changes **how deeply** each lens runs, never **which** lenses fire:
 
@@ -274,8 +274,8 @@ The body MUST include:
 ### Severity gating
 
 - **Any 🔴 Critical Blocker** → STOP. Relay to the operator and let
-  `/epic-deliver` Phase 4 record a manual intervention.
-- **Only 🟠/🟡/🟢** → log as non-blocking and return to `/epic-deliver`
+  `/deliver` Phase 4 record a manual intervention.
+- **Only 🟠/🟡/🟢** → log as non-blocking and return to `/deliver`
   Phase 5 (code-review).
 
 ## Constraints

package/.agents/workflows/helpers/epic-deliver-story.md

@@ -1,7 +1,7 @@
 ---
 description: >-
   Helper — not a slash command. Execute one Epic-attached Story end-to-end on
-  behalf of `/epic-deliver`. Calls `story-init.js`, `cd`s into the worktree,
+  behalf of `/deliver`. Calls `story-init.js`, `cd`s into the worktree,
   runs the Story-implementation phase against the inline acceptance[] /
   verify[] arrays, writes a `story-run-progress` snapshot per transition, and
   finally calls `story-close.js` to merge into the Epic branch and reap the
@@ -13,19 +13,19 @@ caller: epic-deliver.md
 
 > **Not a slash command.** This file lives in `helpers/` and is not projected
 > into the mandrel plugin command tree. It is invoked exclusively by the
-> [`/epic-deliver`](../epic-deliver.md) per-wave fan-out via an `Agent` tool
-> call (`subagent_type: general-purpose`). Run `/epic-deliver <epicId>` from
+> [`/deliver`](deliver-epic.md) per-wave fan-out via an `Agent` tool
+> call (`subagent_type: general-purpose`). Run `/deliver <epicId>` from
 > the operator surface, not this helper directly.
 
 ## Overview
 
 `epic-deliver-story` is the **single-Story worker** for Epic-attached Stories.
-It sits below [`/epic-deliver`](../epic-deliver.md) (which fans out one Story
+It sits below [`/deliver`](deliver-epic.md) (which fans out one Story
 sub-agent per slot, per wave) and runs one Story from init to close in one
 invocation.
 
 ```text
-/epic-deliver <epicId>
+/deliver <epicId>
   → for each wave N:
       Agent tool × concurrencyCap parallel calls (one assistant turn):
         helpers/epic-deliver-story <storyId>
@@ -36,10 +36,10 @@ invocation.
 ```
 
 The argument is always a **Story ID** (`type::story`). Epic IDs go through
-[`/epic-deliver`](../epic-deliver.md).
+[`/deliver`](deliver-epic.md).
 
 **Standalone Stories** (no `Epic: #N` in body) use
-[`/story-deliver`](../story-deliver.md) instead — that workflow's helper
+[`/deliver`](deliver-stories.md) instead — that workflow's helper
 branches from `main`, opens its PR directly to `main`, and skips the
 Epic-scoped machinery (cascade, dispatch manifest, dashboard regen). This
 helper requires a parent Epic and will refuse to initialize a Story that lacks
@@ -56,7 +56,7 @@ the `Epic: #N` reference.
 
 ## Non-interactive execution contract
 
-`epic-deliver-story` runs as a sub-agent of `/epic-deliver`'s per-wave fan-out
+`epic-deliver-story` runs as a sub-agent of `/deliver`'s per-wave fan-out
 (common case) or interactively for a single Story. Sub-agent runs share
 the parent's permissions but have **no input channel** mid-run.
 
@@ -93,7 +93,7 @@ node .agents/scripts/story-init.js --story <storyId>
 > prevention is cheaper: just give Bash the 10-minute timeout and block.
 
 The script validates `type::story`, checks blockers, traces the
-Feature → Epic → PRD/Tech-Spec hierarchy, seeds `story-<id>` from the
+Epic → PRD/Tech-Spec hierarchy, seeds `story-<id>` from the
 Epic branch, and (when worktree isolation is on) runs `git worktree add`
 at `.worktrees/story-<id>/`. The Story flips to `agent::executing`. A
 `story-init` structured comment is upserted with the Story's inline
@@ -130,7 +130,7 @@ The Step 0 result envelope carries a `prepare.renderedBody` field — the
 markdown body for the initial Story-phase table. **Relay it verbatim to
 chat** so operators see the initial progress block before the first commit
 lands. Do the same after every transition in Step 1 / Step 3 (the body is
-the Story-level rollup the parent `/epic-deliver` aggregator reads).
+the Story-level rollup the parent `/deliver` aggregator reads).
 
 ---
 
@@ -291,7 +291,7 @@ When run as a sub-agent, return one JSON object:
 > existing `storyId` / `branchDeleted` / `phase` / `detail` /
 > `renderedBody` fields — do **not** add new envelope fields). Do not
 > narrate the steps you took to get there, and do not prescribe how
-> `/epic-deliver`'s aggregator should do its job downstream. The parent
+> `/deliver`'s aggregator should do its job downstream. The parent
 > reads structured state from this envelope and the `story-run-progress`
 > snapshot; prose process commentary only bloats the hydrated prompt
 > (`delivery.maxTokenBudget` elision).
@@ -307,7 +307,7 @@ regardless of the reap status.
 `renderedBody` is the **most recent** `renderedBody` returned by
 `story-phase.js` (typically the `phase: 'done'` snapshot at close,
 or the `phase: 'blocked'` snapshot on a blocker). The parent
-`/epic-deliver` may inline a digest of this in its wave-level Notable
+`/deliver` may inline a digest of this in its wave-level Notable
 section. When run interactively (no parent), omit it — the chat already
 has the latest body relayed during Step 1 / Step 3.
 
@@ -328,7 +328,7 @@ running this helper against an already-closed Story is safe.
   only integration target is the parent Epic's integration branch. If
   `story-close.js` short-circuits, no-ops, or otherwise fails to merge,
   **do NOT** fall back to `gh pr create --base main`, **do NOT** invoke
-  `/story-deliver` on the same Story, and **do NOT** open a PR by
+  `/deliver` on the same Story, and **do NOT** open a PR by
   hand against `main`. Such a PR orphans the change on `main` and forces
   a manual `git merge origin/main` back into `epic/<id>` to recover (the
   Epic #2880 wave-5 / Story #2960 friction note). The framework refuses