mandrel 1.58.0 → 1.60.0

package/.agents/scripts/single-story-init.js

@@ -139,7 +139,7 @@ export function makeGhRunner(cwd) {
 export function assertDeliverableStory(story, storyId) {
   if (!story.labels.includes(TYPE_LABELS.STORY)) {
     throw new Error(
-      `Issue #${storyId} is not a Story (labels: ${story.labels.join(', ')}). Use /story-deliver or /epic-deliver for Epic-attached work.`,
+      `Issue #${storyId} is not a Story (labels: ${story.labels.join(', ')}). Use /deliver or /deliver for Epic-attached work.`,
     );
   }
   if (story.state === 'closed') {

package/.agents/scripts/stories-wave-tick.js

@@ -1,7 +1,7 @@
 #!/usr/bin/env node
 
 /**
- * stories-wave-tick.js — DAG/wave engine for the top-level /story-deliver workflow.
+ * stories-wave-tick.js — DAG/wave engine for the top-level /deliver workflow.
  *
  * Consumes an operator-supplied dependency DAG of standalone Story IDs and
  * emits ordered execution waves. Analogous to wave-tick.js but for standalone
@@ -26,11 +26,11 @@
  *   }
  *
  * The per-wave concurrency cap is resolved from the same config seam
- * `/epic-deliver` uses — `resolveConfig` + `getRunners` reading
+ * `/deliver` uses — `resolveConfig` + `getRunners` reading
  * `delivery.deliverRunner.concurrencyCap` (default 3) — so a
  * `.agentrc.local.json` override is honored. A `--concurrency <n>` CLI flag
  * overrides the config-resolved value for that run only. This puts both the
- * standalone (`/story-deliver`) and Epic (`/epic-deliver`) delivery paths on
+ * standalone (`/deliver`) and Epic (`/deliver`) delivery paths on
  * one deterministic config source.
  *
  * On cycle detection, exits with code 2 and sets cycleError in the envelope.
@@ -43,6 +43,7 @@ import { runAsCli } from './lib/cli-utils.js';
 import { getRunners, resolveConfig } from './lib/config-resolver.js';
 import { assignLayers, detectCycle } from './lib/Graph.js';
 import { Logger } from './lib/Logger.js';
+import { buildStoryAdjacency } from './lib/story-adjacency.js';
 
 const HELP = `Usage: node .agents/scripts/stories-wave-tick.js --dag '<json>' | --dag-file <path> [--concurrency <n>]
 
@@ -132,21 +133,23 @@ export function parseDag(raw) {
  * Build an adjacency map from parsed DAG nodes.
  * Returns Map<id, id[]> where each id maps to its dependencies.
  *
+ * Delegates to the shared story-level builder
+ * (`lib/story-adjacency.js#buildStoryAdjacency`) with `dropForeign: false`
+ * to preserve the operator-DAG contract: a `dependsOn` id absent from the
+ * input set still deepens the dependent's layer (assignLayers treats the
+ * unknown id as a root).
+ *
  * @param {Array<{id: number, dependsOn: number[]}>} nodes
  * @returns {Map<number, number[]>}
  */
 export function buildAdjacency(nodes) {
-  const adjacency = new Map();
-  for (const node of nodes) {
-    adjacency.set(node.id, [...node.dependsOn]);
-  }
-  return adjacency;
+  return buildStoryAdjacency(nodes, { dropForeign: false });
 }
 
 /**
  * Resolve the per-wave concurrency cap.
  *
- * Mirrors the `/epic-deliver` seam (`epic-deliver-prepare.js`): resolve the
+ * Mirrors the `/deliver` seam (`epic-deliver-prepare.js`): resolve the
  * project config (which deep-merges `.agentrc.local.json` over `.agentrc.json`)
  * then read `delivery.deliverRunner.concurrencyCap` via `getRunners` (default
  * 3). An explicit `override` (the `--concurrency <n>` CLI flag) wins over
@@ -174,7 +177,7 @@ export function resolveConcurrencyCap({ cwd, config, override } = {}) {
  *
  * Uses detectCycle from Graph.js to validate the DAG before computing
  * layers via assignLayers. Returns the wave envelope, carrying the resolved
- * per-wave `concurrencyCap` so the `/story-deliver` workflow dispatches
+ * per-wave `concurrencyCap` so the `/deliver` workflow dispatches
  * `min(wave.stories.length, concurrencyCap)` from a deterministic field rather
  * than from recalled prose.
  *

package/.agents/scripts/story-close.js

@@ -22,7 +22,7 @@
  *   1  error
  *   2  prior-state (pass --resume / --restart) OR preflight refused
  *
- * @see .agents/workflows/story-deliver.md
+ * @see .agents/workflows/helpers/deliver-stories.md
  */
 
 import { runAsCli } from './lib/cli-utils.js';

package/.agents/scripts/story-init.js

@@ -15,7 +15,7 @@
  *   5. branch-initializer   — materialise the story branch (single-tree
  *                             checkout or isolated worktree).
  *   6. state-transitioner   — flip the Story to `agent::executing`. Under
- *                             the 3-tier hierarchy the Story has inline
+ *                             the 2-tier hierarchy the Story has inline
  *                             acceptance and no child Task lifecycle.
  *
  * Usage:
@@ -25,7 +25,7 @@
  *   0 — Initialization complete. Agent can start implementation.
  *   1 — Blocked or error (details in stderr).
  *
- * @see .agents/workflows/story-deliver.md
+ * @see .agents/workflows/helpers/deliver-stories.md
  */
 
 import path from 'node:path';
@@ -38,8 +38,13 @@ import {
 } from './lib/config-resolver.js';
 import { parseBlockedBy } from './lib/dependency-parser.js';
 import { getEpicBranch, getStoryBranch } from './lib/git-utils.js';
+import { runInstallCommand } from './lib/install-cmd-parser.js';
 import { Logger } from './lib/Logger.js';
 import { setActiveStoryEnv } from './lib/observability/active-story-env.js';
+import {
+  defaultStoryPhases,
+  upsertStoryRunProgress,
+} from './lib/orchestration/epic-runner/story-run-progress-writer.js';
 import { upsertStructuredComment } from './lib/orchestration/ticketing.js';
 import { createProvider } from './lib/provider-factory.js';
 import { validateBlockers } from './lib/story-init/blocker-validator.js';
@@ -136,7 +141,7 @@ export async function runStoryInit({
   progress('INIT', `Initializing Story #${storyId}...`);
 
   // Stage 1 — context.
-  const { story, body, epicId, featureId } = await resolveContext({
+  const { story, body, epicId, parentId } = await resolveContext({
     provider,
     logger: stageLogger,
     input: { storyId, recutOf, dryRun },
@@ -149,10 +154,7 @@ export async function runStoryInit({
     input: { epicId },
   });
 
-  progress(
-    'CONTEXT',
-    `Epic: #${epicId}, Feature/Parent: #${featureId ?? 'none'}`,
-  );
+  progress('CONTEXT', `Epic: #${epicId}, Parent: #${parentId ?? 'none'}`);
   progress(
     'CONTEXT',
     `PRD: #${prdId ?? 'none'}, Tech Spec: #${techSpecId ?? 'none'}`,
@@ -187,8 +189,8 @@ export async function runStoryInit({
     progress('BLOCKERS', '✅ All blockers resolved');
 
   // Stage 4 — task graph. Pass the Story body so buildTaskGraph can detect
-  // the inline-acceptance 3-tier shape. After Task #3154 collapsed the
-  // hierarchy flag, 3-tier is the only supported shape.
+  // the inline-acceptance 2-tier shape. After Task #3154 collapsed the
+  // hierarchy flag, 2-tier is the only supported shape.
   const { sortedTasks, mode: hierarchyMode } = await buildTaskGraph({
     provider,
     logger: stageLogger,
@@ -322,7 +324,7 @@ export async function runStoryInit({
     worktreeCreated,
     installStatus,
     sortedTasks,
-    featureId,
+    parentId,
     prdId,
     techSpecId,
     dryRun,
@@ -330,11 +332,6 @@ export async function runStoryInit({
     hierarchy: hierarchyMode,
   });
 
-  emitStoryInitResult(result, {
-    storyId,
-    dryRun,
-  });
-
   if (!dryRun) {
     await postStoryInitComment({
       provider,
@@ -342,11 +339,153 @@ export async function runStoryInit({
       result,
       logger: stageLogger,
     });
+
+    // Story #4017 — the formerly standalone prepare CLI (which
+    // re-read the story-init structured comment seconds after this process
+    // wrote it) is inlined here: apply the install tri-state and render the
+    // initial Story-phase snapshot in-process, off the result we already
+    // hold.
+    result.prepare = await runStoryInitPrepare({
+      provider,
+      storyId,
+      result,
+      notify: _notifyFn,
+      logger: stageLogger,
+    });
   }
 
+  emitStoryInitResult(result, {
+    storyId,
+    dryRun,
+  });
+
   return { success: true, result };
 }
 
+const VALID_INSTALLED_STATES = new Set(['true', 'false', 'skipped']);
+
+/**
+ * Apply the dependenciesInstalled tri-state to derive the next install
+ * action. Pure helper — exposes the Step 0.5 truth table as data so tests
+ * can pin each branch without spinning up a child process.
+ *
+ * @param {'true' | 'false' | 'skipped'} dependenciesInstalled
+ * @param {{ skipInstall?: boolean }} [options]
+ * @returns {'skip' | 'install'}
+ */
+export function deriveInstallAction(dependenciesInstalled, options = {}) {
+  if (!VALID_INSTALLED_STATES.has(dependenciesInstalled)) {
+    throw new RangeError(
+      `deriveInstallAction: dependenciesInstalled "${dependenciesInstalled}" must be one of: ${[...VALID_INSTALLED_STATES].join(', ')}`,
+    );
+  }
+  if (options.skipInstall) return 'skip';
+  return dependenciesInstalled === 'false' ? 'install' : 'skip';
+}
+
+/**
+ * Resolve the install command to run when `dependenciesInstalled === 'false'`.
+ * `project.commands` does not currently carry a dedicated install key,
+ * so this defaults to `npm ci`. Operators can override per-invocation via
+ * the `installCmd` option.
+ *
+ * @param {{ override?: string }} [options]
+ * @returns {string}
+ */
+export function resolveInstallCommand(options = {}) {
+  const trimmed = options.override?.trim();
+  if (trimmed) {
+    return trimmed;
+  }
+  return 'npm ci';
+}
+
+/**
+ * Post-init prepare step (Story #4017 — formerly a standalone prepare
+ * CLI, now consuming the in-process init result
+ * instead of re-reading the `story-init` structured comment):
+ *
+ *   1. Apply the `dependenciesInstalled` tri-state truth table — `'false'`
+ *      (install attempted and failed) retries the install command in the
+ *      worktree; `'true'` / `'skipped'` proceed.
+ *   2. Render the initial Story-phase snapshot with every phase pinned to
+ *      `pending` and `phase: 'init'` via `upsertStoryRunProgress`
+ *      (render-only since Story #3909 — no comment is posted). The
+ *      `renderedBody` markdown is relayed to chat by the delivery
+ *      workflows so operators see the initial progress block before the
+ *      first commit lands.
+ *
+ * Install failure throws (init exits non-zero); a snapshot-render failure
+ * is non-fatal observability loss and only warns.
+ *
+ * @param {{
+ *   provider: object,
+ *   storyId: number,
+ *   result: { workCwd?: string, dependenciesInstalled?: string, storyBranch?: string },
+ *   notify?: Function | null,
+ *   runInstall?: (cmd: string, cwd: string) => { status: number, stderr?: string },
+ *   skipInstall?: boolean,
+ *   installCmd?: string,
+ *   logger?: object,
+ * }} args
+ * @returns {Promise<{
+ *   installAction: 'skip' | 'install',
+ *   installCmd: string | null,
+ *   installResult: { status: number, stderr?: string } | null,
+ *   snapshot: object | null,
+ *   renderedBody: string | null,
+ * }>}
+ */
+export async function runStoryInitPrepare({
+  provider,
+  storyId,
+  result,
+  notify: notifyFn = null,
+  runInstall = runInstallCommand,
+  skipInstall = false,
+  installCmd: installCmdOverride,
+  logger = stageLogger,
+}) {
+  const dependenciesInstalled = String(
+    result?.dependenciesInstalled ?? 'skipped',
+  );
+  const installAction = deriveInstallAction(dependenciesInstalled, {
+    skipInstall,
+  });
+  let installCmd = null;
+  let installResult = null;
+  if (installAction === 'install') {
+    installCmd = resolveInstallCommand({ override: installCmdOverride });
+    installResult = runInstall(installCmd, result.workCwd);
+    if (installResult.status !== 0) {
+      throw new Error(
+        `runStoryInitPrepare: install command \`${installCmd}\` failed with status ${installResult.status}: ${installResult.stderr ?? ''}`,
+      );
+    }
+  }
+
+  let snapshot = null;
+  let renderedBody = null;
+  try {
+    const { body, payload } = await upsertStoryRunProgress({
+      provider,
+      storyId,
+      branch: result?.storyBranch ?? `story-${storyId}`,
+      phase: 'init',
+      phases: defaultStoryPhases(),
+      notify: notifyFn,
+    });
+    snapshot = payload;
+    renderedBody = body;
+  } catch (err) {
+    logger?.warn?.(
+      `[story-init] ⚠️ Failed to render initial story-run-progress snapshot: ${err?.message ?? err}`,
+    );
+  }
+
+  return { installAction, installCmd, installResult, snapshot, renderedBody };
+}
+
 function buildStoryInitResult({
   storyId,
   epicId,
@@ -358,7 +497,7 @@ function buildStoryInitResult({
   worktreeCreated,
   installStatus,
   sortedTasks,
-  featureId,
+  parentId,
   prdId,
   techSpecId,
   dryRun,
@@ -372,11 +511,11 @@ function buildStoryInitResult({
     storyBranch,
     epicBranch,
     storyTitle: story.title,
-    // Hierarchy mode resolved by buildTaskGraph. 3-tier is the only
+    // Hierarchy mode resolved by buildTaskGraph. 2-tier is the only
     // supported shape after Task #3154 deleted the `planning.hierarchy`
     // flag; this is retained as a constant marker for downstream
     // consumers and persisted artefacts.
-    hierarchy: hierarchy ?? '3-tier',
+    hierarchy: hierarchy ?? '2-tier',
     worktreeEnabled,
     workCwd,
     worktreeCreated,
@@ -392,7 +531,7 @@ function buildStoryInitResult({
       labels: t.labels,
       dependencies: t.dependsOn ?? parseBlockedBy(t.body ?? ''),
     })),
-    context: { featureId, prdId, techSpecId },
+    context: { parentId, prdId, techSpecId },
     dryRun,
   };
 }
@@ -449,20 +588,17 @@ export function renderStoryInitCommentBody(result) {
     epicId: result.epicId,
     storyBranch: result.storyBranch,
     epicBranch: result.epicBranch,
-    // Hierarchy mode is always `'3-tier'` after Task #3154 deleted the
+    // Hierarchy mode is always `'2-tier'` after Task #3154 deleted the
     // `planning.hierarchy` flag. Persisted so resumed runs can read it
     // without re-resolving anything in the worker.
-    hierarchy: result.hierarchy ?? '3-tier',
+    hierarchy: result.hierarchy ?? '2-tier',
     worktreeEnabled: result.worktreeEnabled,
     workCwd: result.workCwd,
     worktreeCreated: result.worktreeCreated,
     dependenciesInstalled: result.dependenciesInstalled,
     installStatus: result.installStatus,
-    // Embed the canonical task list so `story-deliver-prepare.js` can seed the
-    // initial `story-run-progress` snapshot without re-fetching the task graph.
-    // Without this field, the prepare CLI silently seeded an empty snapshot,
-    // breaking every subsequent phase-writer call (it asserts the
-    // task id is present in the snapshot).
+    // Embed the canonical task list so downstream snapshot consumers can
+    // seed phase-writer calls without re-fetching the task graph.
     tasks: Array.isArray(result.tasks)
       ? result.tasks.map((t) => ({ id: t.id, title: t.title }))
       : [],

package/.agents/scripts/story-phase.js

@@ -1,10 +1,10 @@
 #!/usr/bin/env node
 
 /**
- * story-phase.js — phase snapshot + heartbeat writer (3-tier).
+ * story-phase.js — phase snapshot + heartbeat writer (2-tier).
  *
  * Replaces the deleted per-Task progress writer from the 4-tier era
- * (removed under #3157). `/story-deliver` calls this CLI at each Story-
+ * (removed under #3157). `/deliver` calls this CLI at each Story-
  * level phase transition (init → implementing → closing → done, or any
  * → blocked). Each call:
  *
@@ -14,7 +14,7 @@
  *      longer posts a `story-run-progress` comment (the redundant mid-flight
  *      progress surface was deleted); the snapshot is render-only.
  *   2. Appends one `story.heartbeat` lifecycle record to
- *      `temp/epic-<epicId>/lifecycle.ndjson` so `/epic-deliver`'s
+ *      `temp/epic-<epicId>/lifecycle.ndjson` so `/deliver`'s
  *      §2e Idle Watchdog (`wave-tick.js --check-idle 30`) can confirm
  *      forward progress without polling the Story comment.
  *
@@ -35,7 +35,7 @@
  *
  * `renderedBody` is the markdown body upserted onto the Story so the
  * caller can relay it to chat verbatim (mirrors the contract the deleted
- * per-Task progress writer exposed and that `/story-deliver` Step 1 / 3
+ * per-Task progress writer exposed and that `/deliver` Step 1 / 3
  * already documents).
  */
 
@@ -175,7 +175,7 @@ async function resolveStoryBranch({ provider, storyId }) {
  * lease-owner handle the SAME way the lease primitive does
  * (`normalizeOperatorHandle(github.operatorHandle)`) and stamps it as
  * `operator` so `latestHeartbeatForOwner({ epicId, owner })` resolves a real
- * heartbeat — without it `isClaimLive(null)` is false and /epic-deliver
+ * heartbeat — without it `isClaimLive(null)` is false and /deliver
  * silently reclaims a live foreign claim (audit #3513). The field is attached
  * only when a handle resolves, preserving the "omit when absent" shape for
  * repos that have not configured `github.operatorHandle`. A failed append is

package/.agents/scripts/story-plan.js

@@ -2,9 +2,9 @@
 /* node:coverage ignore file */
 
 /**
- * story-plan.js — Local `/story-plan` wrapper.
+ * story-plan.js — Local `/plan` wrapper.
  *
- * Standalone counterpart to `/epic-plan` for Stories that do **not**
+ * Standalone counterpart to `/plan` for Stories that do **not**
  * attach to an Epic. The script is deliberately a thin CLI around the
  * pure helpers in `lib/story-plan.js`:
  *
@@ -24,7 +24,7 @@
  *      GitHub. Echoes the rendered body and the `gh` argv it would
  *      have run.
  *
- * Mirrors the `/epic-plan` pattern: deterministic Node I/O wrappers
+ * Mirrors the `/plan` pattern: deterministic Node I/O wrappers
  * with HITL gating handled by the host LLM in chat. No external LLM
  * APIs are called from this script.
  */

package/.agents/scripts/sync-branch-from-base.js

@@ -6,7 +6,7 @@
  *
  * Use this from workflow markdown when the operator needs to sync a
  * working branch with `origin/<baseBranch>` before opening a PR — for
- * example as a pre-Phase-6 step in `/epic-deliver` so the Epic→main PR
+ * example as a pre-Phase-6 step in `/deliver` so the Epic→main PR
  * opens with the latest `main` commits already integrated.
  *
  * For `/single-story-deliver`, the sync runs in-process inside
@@ -31,10 +31,10 @@
 import path from 'node:path';
 import { parseArgs } from 'node:util';
 import { runAsCli } from './lib/cli-utils.js';
-import { PROJECT_ROOT } from './lib/config-resolver.js';
 import { syncBranchFromBase } from './lib/git/sync-from-base.js';
 import { gitSpawn, gitSync } from './lib/git-utils.js';
 import { Logger } from './lib/Logger.js';
+import { PROJECT_ROOT } from './lib/project-root.js';
 
 const progress = Logger.createProgress('sync-branch-from-base', {
   stderr: true,

package/.agents/scripts/validate-docs-freshness.js

@@ -201,7 +201,7 @@ export function renderFreshnessFailureMessage(epicId) {
   return (
     `[docs-freshness] ❌ Documentation freshness gate FAILED for Epic #${epicId}.\n\n` +
     `Update each failing file so its commit message or body references #${epicId}, ` +
-    `then re-run /epic-deliver.`
+    `then re-run /deliver.`
   );
 }
 

package/.agents/scripts/wave-tick.js

@@ -6,7 +6,7 @@
  *
  * Reads the `epic-run-state` checkpoint plus fresh Story labels and
  * prints one `WaveTickResult` envelope. The slash-command operator
- * (`/epic-deliver`) consumes the envelope to decide whether to dispatch
+ * (`/deliver`) consumes the envelope to decide whether to dispatch
  * the next wave, observe in-flight stories, or finalize the Epic.
  *
  * Usage:

package/.agents/skills/core/analyze-execution/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   Aggregate per-Story or per-Epic execution signals into a structured
   perf-summary or perf-report and upsert it onto the corresponding GitHub
   ticket. Use after a Story closes (Story mode) or as part of
-  `/epic-deliver` Phase 6 (Epic mode). Reads NDJSON via
+  `/deliver` Phase 6 (Epic mode). Reads NDJSON via
   `lib/signals/read` and writes a single structured comment.
 allowed_tools:
   - Read
@@ -36,7 +36,7 @@ into the Epic dashboard.
   pipeline dispatches this Skill (or the wrapping script) to roll up the
   Story's NDJSON signals into a single `<!-- structured:story-perf-summary -->`
   marker comment on the Story ticket.
-- **Epic mode** — during `/epic-deliver` Phase 6.0 (or the retro
+- **Epic mode** — during `/deliver` Phase 6.0 (or the retro
   composer), the Skill fans out across every Story under the Epic,
   reads each Story's structured perf summary, and posts a single
   `<!-- structured:epic-perf-report -->` marker on the Epic ticket.

package/.agents/skills/core/epic-plan-consolidate/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: epic-plan-consolidate
 description: >-
-  Run a holistic, pre-persist consolidation pass over the draft Feature/Story
+  Run a holistic, pre-persist consolidation pass over the draft Story
   ticket array an Epic's decompose phase produced. Use during Phase 8 of
-  `/epic-plan`, after `epic-plan-decompose-author` writes
+  `/plan`, after `epic-plan-decompose-author` writes
   `temp/epic-<Epic_ID>/tickets.json` and before `epic-plan-decompose.js`
   validates and persists it. Reconciles the draft against the Tech Spec
   "Delivery Slicing" target via scope-preserving operations only.
@@ -19,13 +19,12 @@ allowed_tools:
 
 - Run only after `epic-plan-decompose-author` has written `temp/epic-<Epic_ID>/tickets.json`; fail loudly if the draft array is missing. Read the PRD / Tech Spec from `temp/epic-<Epic_ID>/decomposer-context.json` (the same envelope the author skill consumed) — never re-fetch from GitHub, and never call the GitHub API from this Skill.
 - Emit exactly two artifacts inside `temp/epic-<Epic_ID>/`: the **consolidated** `tickets.json` (overwriting the draft array in place) and a human-readable `consolidation-report.md` (the rationale + before/after diff the operator reviews at the HITL gate). Both MUST exist before returning.
-- **Scope conservation is the load-bearing invariant.** You are a *critic*, not a second author: you MUST NOT add scope, invent tickets, or drop acceptance criteria. Every acceptance item and every `verify` entry present in the draft MUST survive into the consolidated array (possibly re-homed onto a merged Story). **This is your contract, not a machine guarantee:** there is **no runtime acceptance-union diff** on your output. The only deterministic runtime backstop the validator applies after you run is `assertNoSingleStoryFeature` (Story #3777) plus the standard ticket-structure validation — neither re-derives the pre-consolidation acceptance/verify union, so a critic that silently dropped an acceptance item would **not** be caught downstream. (The repo's unit test exercises a *pure model* of the merge over an over-fragmented fixture to document the intended invariant; it does not inspect this Skill's actual output.) Conserve scope yourself, deliberately, on every merge.
-- Your operations are constrained to exactly four shapes: **(1) merge two or more Stories** into one (union their `changes`/`acceptance`/`verify`/`references`, keep one coherent `goal`); **(2) collapse a single-Story Feature** into a sibling Feature (re-parent its lone Story, drop the empty Feature) — **never** by manufacturing a second Story; **(3) re-parent** a Story to a different sibling Feature; **(4) rewire `depends_on`** so the edges still reference surviving sibling-Story slugs. No other mutation is permitted.
-- Consume the Tech Spec **"Delivery Slicing"** section as the authoritative target grouping when one is present: cluster the draft's Stories toward the N shippable Stories the Architect proposed. When the section is **absent**, degrade gracefully — apply only the cohesion + single-Story-Feature rules below and leave the rest of the draft shape intact.
-- Implement rec #2: resolve every single-Story Feature by **collapsing** it into a sibling (operation 2), not by splitting its lone Story into two. The `assertNoSingleStoryFeature` validator from Story #3777 stays as the post-consolidation backstop — your output must already satisfy it.
+- **Scope conservation is the load-bearing invariant.** You are a *critic*, not a second author: you MUST NOT add scope, invent tickets, or drop acceptance criteria. Every acceptance item and every `verify` entry present in the draft MUST survive into the consolidated array (possibly re-homed onto a merged Story). **This is your contract, not a machine guarantee:** there is **no runtime acceptance-union diff** on your output. The only deterministic runtime backstop the validator applies after you run is the standard ticket-structure validation — it does not re-derive the pre-consolidation acceptance/verify union, so a critic that silently dropped an acceptance item would **not** be caught downstream. (The repo's unit test exercises a *pure model* of the merge over an over-fragmented fixture to document the intended invariant; it does not inspect this Skill's actual output.) Conserve scope yourself, deliberately, on every merge.
+- Your operations are constrained to exactly two shapes: **(1) merge two or more Stories** into one (union their `changes`/`acceptance`/`verify`/`references`, keep one coherent `goal`); **(2) rewire `depends_on`** so the edges still reference surviving sibling-Story slugs. No other mutation is permitted.
+- Consume the Tech Spec **"Delivery Slicing"** section as the authoritative target grouping when one is present: cluster the draft's Stories toward the N shippable Stories the Architect proposed. When the section is **absent**, degrade gracefully — apply only the cohesion rules below and leave the rest of the draft shape intact.
 - Apply the same cohesion heuristic the author skill leads with: **one Story = one coherent change with one reason to exist**, and the **single-consumer merge rule** (a Story whose only consumer is one sibling Story is merged into that sibling). Lead every merge decision with the change's reason, not its file count.
-- After every merge / collapse / re-parent, **rewire `depends_on`**: drop self-edges, collapse edges that now point at the absorbing Story onto itself, and re-point any edge that named a now-deleted slug at its surviving successor. Never leave a `depends_on` referencing a slug absent from the consolidated array — the validator HARD-rejects unknown deps.
-- The consolidation report MUST name each operation applied (merged slugs → surviving slug, collapsed Feature → sibling, re-parented Story, rewired edges) with a one-line reason, plus a before/after Story-count line, so the operator can approve or reject at the HITL diff gate before the persist call.
+- After every merge, **rewire `depends_on`**: drop self-edges, collapse edges that now point at the absorbing Story onto itself, and re-point any edge that named a now-deleted slug at its surviving successor. Never leave a `depends_on` referencing a slug absent from the consolidated array — the validator HARD-rejects unknown deps.
+- The consolidation report MUST name each operation applied (merged slugs → surviving slug, rewired edges) with a one-line reason, plus a before/after Story-count line, so the operator can approve or reject at the HITL diff gate before the persist call.
 
 ## Role
 
@@ -38,7 +37,7 @@ against the Tech Spec's intentional grouping before any GitHub write.
 
 ## When to use
 
-`/epic-plan` Phase 8, as the **8.3 — Holistic Consolidation** sub-step:
+`/plan` Phase 8, as the **8.3 — Holistic Consolidation** sub-step:
 immediately after `epic-plan-decompose-author` writes
 `temp/epic-<Epic_ID>/tickets.json` and **before**
 `epic-plan-decompose.js --tickets …` validates and persists. The pass operates
@@ -51,7 +50,7 @@ emit a plan the validator would reject.
 The dispatcher passes the Epic ID as the Skill argument. The Skill itself
 reads:
 
-- `temp/epic-<Epic_ID>/tickets.json` — the **draft** Feature/Story array the
+- `temp/epic-<Epic_ID>/tickets.json` — the **draft** Story array the
   `epic-plan-decompose-author` Skill wrote. This is the consolidation input.
 - `temp/epic-<Epic_ID>/decomposer-context.json` — the authoring envelope
   emitted by `epic-plan-decompose.js --emit-context`. Read `prd.body` /
@@ -62,7 +61,7 @@ reads:
 ## Outputs
 
 - `temp/epic-<Epic_ID>/tickets.json` — the **consolidated** array, overwriting
-  the draft. Same schema as the author skill emits (Feature → Story; Stories
+  the draft. Same schema as the author skill emits (flat Story array; Stories
   carry top-level `acceptance[]` / `verify[]`; `body` is a serialized string).
   The downstream `epic-plan-decompose.js --tickets …` validator is the final
   gate — author for its rules, not for "looks right."
@@ -83,21 +82,18 @@ anything:
 
 1. The **target grouping** — the N shippable Stories the Architect proposed in
    Delivery Slicing, or `null` when the section is absent (graceful-degrade
-   mode: cohesion + single-Story-Feature rules only).
-2. The **draft Story count per Feature** — so you can spot single-Story
-   Features and over-fragmented capability clusters.
+   mode: cohesion rules only).
+2. The **draft Story count** — so you can spot over-fragmented capability
+   clusters.
 
 ### Step 2 — Plan the consolidation
 
-For each Feature, decide which Stories merge, which collapse, which re-parent:
+Across the draft Story array, decide which Stories merge:
 
-- **Single-Story Feature** → collapse its lone Story into a sibling Feature
-  whose capability is closest (Delivery-Slicing target, else thematic
-  proximity). Drop the now-empty Feature. Never split the lone Story.
 - **Over-fragmented capability** → when several draft Stories map to one
   Delivery-Slicing target (or one coherent reason to exist), merge them into a
   single Story: union their `changes` / `acceptance` / `verify` / `references`,
-  write one `goal` naming the parent Feature, and keep the union of labels.
+  write one coherent `goal`, and keep the union of labels.
 - **Single-consumer Story** → merge into the one sibling that consumes it.
 
 Record each decision with its one-line reason for the report.
@@ -120,7 +116,7 @@ Write the consolidated array to `temp/epic-<Epic_ID>/tickets.json` (2-space
 indent, machine-consumed) and the rationale + before/after diff to
 `temp/epic-<Epic_ID>/consolidation-report.md`.
 
-### Step 5 — Hand back to `/epic-plan`
+### Step 5 — Hand back to `/plan`
 
 Return control. The workflow shows the operator the consolidation report at the
 HITL diff gate; on approval it runs
@@ -133,13 +129,12 @@ persists the hierarchy, and flips the Epic to `agent::ready`.
 - Do **not** call the GitHub API from this Skill. It reads two temp artifacts
   and writes two temp artifacts; persistence belongs to the script.
 - Do **not** write outside `temp/epic-<Epic_ID>/`.
-- Do **not** add scope or invent tickets. The four permitted operations (merge
-  Stories, collapse single-Story Features, re-parent, rewire `depends_on`) are
-  exhaustive — anything else is out of contract.
+- Do **not** add scope or invent tickets. The two permitted operations (merge
+  Stories, rewire `depends_on`) are exhaustive — anything else is out of
+  contract.
 - If `temp/epic-<Epic_ID>/tickets.json` is missing, fail loudly and instruct
   the caller to run the `epic-plan-decompose-author` Skill first.
 - The validator
   ([`lib/orchestration/ticket-validator.js`](../../../scripts/lib/orchestration/ticket-validator.js))
-  is the authoritative post-consolidation gate — including
-  `assertNoSingleStoryFeature`. Re-consolidate when it rejects rather than
-  patching tickets by hand.
+  is the authoritative post-consolidation gate. Re-consolidate when it
+  rejects rather than patching tickets by hand.