mandrel 1.58.0 → 1.60.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`
@@ -297,32 +297,25 @@ NDJSON line to `temp/epic-<epicId>/lifecycle.ndjson`; the matching
 after the Agent return is recorded in § 2c.
 
 Each Agent call's prompt must (1) name the Story + Epic ids, (2)
-instruct the child to invoke `helpers/epic-deliver-story <storyId>`, (3) state the
-**return contract** below, (4) remind the child of the
-**non-interactive contract** (no clarifying questions; transition to
-`agent::blocked` and exit if stuck), (5) ask the child to suppress
-per-Story chat relay and include its **terminal** `renderedBody` in the
-JSON return, and (6) require the child to emit a `story.heartbeat`
-lifecycle event at least once per Story-level phase transition via
-`node .agents/scripts/story-phase.js` (or whenever it stalls on a
-long-running step), and if it cannot make progress to transition
-to `agent::blocked` rather than fall silent. The pairing of
+instruct the child to invoke `helpers/epic-deliver-story <storyId>`
+(whose Step 4 defines the child's return shape), (3) remind the child
+of the **non-interactive contract** (no clarifying questions;
+transition to `agent::blocked` and exit if stuck), (4) ask the child to
+suppress per-Story chat relay, and (5) require the child to emit a
+`story.heartbeat` lifecycle event at least once per Story-level phase
+transition via `node .agents/scripts/story-phase.js` (or whenever it
+stalls on a long-running step), and if it cannot make progress to
+transition to `agent::blocked` rather than fall silent. The pairing of
 `story.heartbeat` and `agent::blocked` is what lets the §2e Idle
 Watchdog distinguish a working child from a dead one; a silent child
 with no recent heartbeat and no blocker label is the failure mode the
 watchdog is built to catch.
 
-```json
-{
-  "storyId": <number>,
-  "status": "done" | "blocked" | "failed",
-  "phase": "init|implementing|closing|blocked|done",
-  "branchDeleted": <boolean>,
-  "blockerCommentId": <string|null>,
-  "detail": <string|undefined>,
-  "renderedBody": <string|undefined>
-}
-```
+There is **no per-child JSON return-parsing ceremony** for the parent
+to enforce. GitHub state is the contract: `epic-execute-record-wave.js`
+(§ 2c, mode B) treats each child's raw return text as a best-effort
+hint and reconciles any unparseable, empty, or missing return directly
+from the Story's live labels and comments (Story #3907).
 
 **Sub-agent dispatch.** `Agent` calls emit no `model:` argument by
 default — children inherit from the `general-purpose` sub-agent
@@ -349,8 +342,8 @@ node .agents/scripts/epic-execute-record-wave.js \
 # `<inline-json>` shape: [{ "storyId": <n>, "returnText": "<raw text>" }]
 ```
 
-**Prefer mode B** when the host LLM can't fully verify every child's
-return is a parseable envelope. The CLI reconciles parse failures from
+**Mode B is the default path** — pipe the raw return texts through
+without inspecting them. The CLI reconciles parse failures from
 GitHub, aggregates terminal status, appends to `state.waves[]`,
 re-renders `epic-run-progress`, and prints
 `{ status, nextAction, renderedBody, ... }`. Print `renderedBody`
@@ -432,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
@@ -472,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`
@@ -499,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.
@@ -507,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
@@ -534,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
@@ -548,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
@@ -599,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
@@ -618,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
@@ -634,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.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