mandrel 1.58.0 → 1.60.0

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
@@ -120,21 +120,17 @@ tri-state carries one of three values:
 
 ### Step 0.6 — Initial `story-run-progress` snapshot
 
-Re-read the `story-init` comment, apply the install tri-state, and upsert
-the initial snapshot (`phase: "init"`):
+Story #4017 inlined the former standalone prepare CLI into
+`story-init.js`: Step 0's init run already applied the install tri-state
+in-process (retrying the install command when
+`dependenciesInstalled === 'false'`, default `npm ci`) and rendered the
+initial snapshot (`phase: "init"`). There is no separate command to run.
 
-```bash
-node .agents/scripts/story-deliver-prepare.js --story <storyId> --cwd .
-```
-
-The CLI runs the install command when `dependenciesInstalled === 'false'`
-(default `npm ci`; override with `--install-cmd "<cmd>"`).
-
-The CLI's stdout JSON envelope carries a `renderedBody` field — the markdown
-body that was upserted onto the Story ticket. **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 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 `/deliver` aggregator reads).
 
 ---
 
@@ -295,30 +291,23 @@ 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).
 
 `branchDeleted` is sourced from the `branchDeleted` field of the
-`story-close.js` result envelope, which is `branchCleanup.localDeleted &&
-branchCleanup.remoteDeleted`. It is **independent** of `worktreeReap.status`.
-Specifically, when `worktreeReap.status === 'stale-registry-entry'` — a
-Windows-only outcome where the worktree directory was removed and the local
-branch was deleted but `git worktree list` still shows the entry — the
-close still reports `branchDeleted: true` because the branch was honestly
-deleted; a pending-cleanup entry is recorded so the next post-close drain
-(or the next plan-time sweep) clears the stale `.git/worktrees/<name>/`
-registry entry. Treat `stale-registry-entry` as operationally complete
-when computing your return contract: `status: 'done'` is appropriate when
-all Tasks are closed and `branchDeleted: true`, regardless of whether
-`worktreeReap.status` is `'removed'`, `'removed-after-drain'`, or
-`'stale-registry-entry'`.
+`story-close.js` result envelope. It is **independent** of
+`worktreeReap.status` — every reap outcome the close reports (including
+the Windows-only `stale-registry-entry`, which queues a pending-cleanup
+entry for the next drain) is operationally complete. `status: 'done'` is
+appropriate when the Story is closed and `branchDeleted: true`,
+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.
 
@@ -339,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

package/.agents/workflows/helpers/epic-plan-decompose.md

@@ -1,14 +1,14 @@
 ---
 description: >-
   Phase 8 of sprint planning — decompose an Epic's PRD and Tech Spec into a
-  Feature/Story hierarchy, persist the backlog, and flip the Epic to
+  backlog of child Stories, persist the backlog, and flip the Epic to
   `agent::ready`. Host-LLM authored; no external API calls.
 ---
 
 # Sprint Plan — Decompose Phase (helper)
 
-> **Helper module.** Not a slash command. Invoked by `/epic-plan` (Phase 8).
-> To run the decompose phase interactively, use `/epic-plan [Epic_ID]` — it
+> **Helper module.** Not a slash command. Invoked by `/plan` (Phase 8).
+> To run the decompose phase interactively, use `/plan [Epic_ID]` — it
 > delegates here after the spec phase.
 
 ## Role
@@ -19,9 +19,9 @@ Director / Architect
 
 This helper is the **decompose phase** of the split planning pipeline. It
 reads the PRD and Tech Spec previously produced by the spec phase helper
-([`epic-plan-spec.md`](epic-plan-spec.md)), generates the Feature /
-Story ticket hierarchy, persists it to GitHub, and flips the Epic to
-`agent::ready` (parking) so a human can run `/epic-deliver` when
+([`epic-plan-spec.md`](epic-plan-spec.md)), generates the Epic's child
+Story tickets, persists them to GitHub, and flips the Epic to
+`agent::ready` (parking) so a human can run `/deliver` when
 execution should begin.
 
 The ticket array is authored **directly by you, the host LLM**.
@@ -29,8 +29,8 @@ The ticket array is authored **directly by you, the host LLM**.
 authoring context you need and (b) validates, persists, and transitions the
 Epic lifecycle state.
 
-The ticket array contains `type::feature` and `type::story` tickets
-only — no `type::task` children. Acceptance criteria and verification
+The ticket array contains `type::story` tickets only — no Feature
+containers and no `type::task` children. Acceptance criteria and verification
 steps are inlined on each Story body via the `acceptance[]` and
 `verify[]` fields. The decomposer system prompt lives in the
 [`epic-plan-decompose-author`](../../skills/core/epic-plan-decompose-author/SKILL.md)
@@ -41,13 +41,13 @@ skill.
 - **Do not** run this skill until the spec phase is complete. The Epic must
   have linked `context::prd` and `context::tech-spec` issues; the script will
   refuse to proceed otherwise.
-- **Do not** reassign Story parents across Features after the
-  decomposition writes — the `epic-plan-state` checkpoint records the
-  structure as committed. Use `--force` to rebuild from scratch.
+- **Do not** restructure the Story set after the decomposition
+  writes — the `epic-plan-state` checkpoint records the structure as
+  committed. Use `--force` to rebuild from scratch.
 - **Every** temp file must include the Epic ID in its name. Multiple Epics
   may be decomposed concurrently; bare names will collide.
 - **Do not** flip the Epic past `agent::ready` from this helper. Execution
-  begins when an operator runs `/epic-deliver [Epic_ID]`.
+  begins when an operator runs `/deliver [Epic_ID]`.
 
 ## Prerequisites
 
@@ -70,7 +70,7 @@ decomposer system prompt, and the `maxTickets` **reviewability budget**
 ## Step 2 — Author the ticket array
 
 Read `temp/epic-[Epic_ID]/decomposer-context.json`. Produce a JSON array of
-Feature / Story objects that conforms to the schema in the system prompt
+Story objects that conforms to the schema in the system prompt
 and write it to `temp/epic-[Epic_ID]/tickets.json`.
 
 When the Tech Spec carries a `## Delivery Slicing` section, author toward the
@@ -95,12 +95,12 @@ skill with `[Epic_ID]` as input. It reads the draft
 - a human-readable `temp/epic-[Epic_ID]/consolidation-report.md` (rationale +
   before/after diff).
 
-The pass is constrained to scope-preserving operations only — **merge Stories,
-collapse single-Story Features into siblings, re-parent, rewire `depends_on`**.
-It MUST NOT add scope or invent tickets. It resolves single-Story Features by
-**collapsing** them (rec #2), never by splitting a lone Story into two; the
-`assertNoSingleStoryFeature` validator stays as the post-consolidation
-backstop.
+The pass is constrained to scope-preserving operations only — **merge sibling
+Stories and rewire `depends_on`**. It MUST NOT add scope or invent tickets.
+It consolidates fragmented slices by merging them into a cohesive Story,
+never by splitting one into two; the `assertAllTicketsAreStories` validator
+(in `lib/orchestration/ticket-validator.js`) stays as the post-consolidation
+backstop that rejects any non-Story ticket the pass might emit.
 
 > **HITL diff gate.** Show the operator
 > `temp/epic-[Epic_ID]/consolidation-report.md` (the before/after diff +
@@ -141,7 +141,7 @@ On success the script:
 Delegate the structural invariants (hierarchy completeness, dependency DAG
 acyclicity, missing complexity labels) to `epic-plan-healthcheck.js`. It is
 the single source of truth for post-decompose validation — the Phase 10 run
-inside `/epic-plan` calls the same script, so local and remote flows agree.
+inside `/plan` calls the same script, so local and remote flows agree.
 
 ```bash
 node .agents/scripts/epic-plan-healthcheck.js --epic [Epic_ID] --paranoid
@@ -156,7 +156,7 @@ checks without performing any I/O — it is not a substitute for
 The script exits 0 regardless of findings (non-blocking), but lists any
 `ERR`-level findings that must be addressed before execution:
 
-- Missing `type::feature` / `type::story` tickets.
+- Missing `type::story` tickets.
 - Stories without `complexity::` labels.
 - Dependency cycles across Stories.
 
@@ -183,11 +183,11 @@ is the single source of truth for which temp paths this phase owns.
 - Surface the backlog summary and the Wave 0 candidates to the operator:
 
   > "Decomposition complete. Epic #[ID] is on `agent::ready` with NN ticket(s)
-  > across MM Stories. Run `/epic-deliver [Epic_ID]` to begin execution."
+  > across MM Stories. Run `/deliver [Epic_ID]` to begin execution."
 
 ## Troubleshooting
 
-- "Epic #N is missing a linked PRD or Tech Spec" — run `/epic-plan [Epic_ID]`
+- "Epic #N is missing a linked PRD or Tech Spec" — run `/plan [Epic_ID]`
   first (it will run the spec phase if the PRD / Tech Spec are missing).
 - Validator rejects the tickets file — the most common causes are a
   Story whose `parent_slug` does not point at a Feature, a missing

package/.agents/workflows/helpers/epic-plan-spec.md

@@ -7,8 +7,8 @@ description: >-
 
 # Sprint Plan — Spec Phase (helper)
 
-> **Helper module.** Not a slash command. Invoked by `/epic-plan` (Phase 7).
-> To run the spec phase interactively, use `/epic-plan [Epic_ID]` — it
+> **Helper module.** Not a slash command. Invoked by `/plan` (Phase 7).
+> To run the spec phase interactively, use `/plan [Epic_ID]` — it
 > delegates here.
 
 ## Role
@@ -27,7 +27,7 @@ reviewer can read the artifacts on GitHub before decomposition.
 > **Single prose home.** The canonical, full-detail spec-phase contract
 > (idempotent context tickets, the three-ticket rationale, the
 > `acceptance::n-a` waiver, the Epic-lease preflight) lives in
-> [`epic-plan.md` § Phase 7](../epic-plan.md). This helper carries only the
+> [`epic-plan.md` § Phase 7](plan-epic.md). This helper carries only the
 > operational step list; when the two disagree, `epic-plan.md` wins.
 
 The PRD and Tech Spec are authored **directly by you, the host LLM**.
@@ -36,7 +36,7 @@ context you need and (b) persists the artifacts and transitions the Epic
 lifecycle state.
 
 The complementary Phase 8 helper is
-[`epic-plan-decompose.md`](epic-plan-decompose.md). The `/epic-plan`
+[`epic-plan-decompose.md`](epic-plan-decompose.md). The `/plan`
 wrapper chains both helpers with a confirmation gate in between.
 
 ## Constraint
@@ -101,7 +101,7 @@ Using `systemPrompts.acceptanceSpec`, the PRD, and the Tech Spec, write the
 Acceptance Spec to `temp/epic-[Epic_ID]/acceptance-spec.md`. It captures the
 stable-ID acceptance criteria table
 (`| AC ID | Outcome | Feature File | Scenario | Disposition |`) that drives
-close-time reconciliation in `/epic-deliver` Phase 6.
+close-time reconciliation in `/deliver` Phase 6.
 
 **Skip this step only** when the Epic carries the `acceptance::n-a` waiver
 label (refactor-only or docs-only Epics); in that case omit `--acceptance-spec`
@@ -166,7 +166,7 @@ JSON (`planningRisk`, `reviewRouting`):
   URLs to the operator:
 
   > "Spec phase complete for Epic #[ID]. Review PRD (#XX) and Tech Spec (#YY)
-  > on GitHub. When you're ready, re-run `/epic-plan [Epic_ID]` — the wrapper
+  > on GitHub. When you're ready, re-run `/plan [Epic_ID]` — the wrapper
   > will pick up where it left off and run the decompose phase."
 
 - **Low risk — auto-proceed.** Relay `reviewRouting.operatorMessage` and

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

@@ -5,7 +5,7 @@ description: QA Epic-testing workflow — ingest the agent-driven QA harness swe
 # Epic Testing (helper)
 
 > **Helper module.** Not a slash command. Invoked from the QA gate during
-> `/epic-deliver` or directly by an operator when the Epic-testing ticket
+> `/deliver` or directly by an operator when the Epic-testing ticket
 > needs refreshed evidence. For ad-hoc acceptance runs use `/qa-run-harness` —
 > this helper owns the Epic-evidence ticket lifecycle on top of it.
 
@@ -15,7 +15,7 @@ evidence artifact is the **agent-driven QA harness sweep report** produced by
 findings), **not** a hand-ticked markdown checklist.
 
 > **When to run**: During the QA phase of an Epic, after all Story merges
-> have landed on the Epic branch and before `/epic-deliver`. Also run ad-hoc
+> have landed on the Epic branch and before `/deliver`. Also run ad-hoc
 > when a regression is suspected mid-Epic.
 >
 > **Persona**: `qa-engineer` · **Skills**:
@@ -84,7 +84,7 @@ do not paste — large artifacts.
    - One-line symptom.
    - Link to the failing scenario's snapshot or trace.
 
-Do not close the Epic-testing ticket on a failed run. `/epic-deliver`
+Do not close the Epic-testing ticket on a failed run. `/deliver`
 depends on green evidence.
 
 ## Deprecated — Markdown Checklist Flow

package/.agents/workflows/helpers/parallel-tooling.md

@@ -57,7 +57,7 @@ the same shape as Rule 1 but at the sub-agent layer.
 
 - **Tool primitives:** `Agent` (one call per independent unit, all in one
   turn).
-- **When:** wave-level Story fan-out from `/epic-deliver`, per-dimension
+- **When:** wave-level Story fan-out from `/deliver`, per-dimension
   audit dispatch, any "for each X in Xs run /Y X" loop where the Xs do not
   share write paths.
 - **Anti-pattern:** serial `Agent` calls (`Agent` → wait → `Agent` → wait)