mandrel 1.94.0 → 2.0.0

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

@@ -11,7 +11,7 @@
  * emits the set of Stories safe to dispatch **on this beat** — a Story
  * becomes dispatchable the instant its own dependencies are done, under the
  * same global concurrency cap and the same file-overlap co-dispatch guard
- * the Epic path uses. There is no wave barrier: this no longer batches
+ * `lib/wave-runner/ready-set.js` applies everywhere. There is no wave barrier: this no longer batches
  * Stories into fully-draining waves; it selects continuously.
  *
  * The previous static wave-batch plan (group N must fully drain before
@@ -50,9 +50,9 @@
  * `/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 (`/deliver`) and Epic (`/deliver`) delivery paths on one
- * deterministic config source **and** one scheduling kernel.
+ * overrides the config-resolved value for that run only. This shares one
+ * deterministic config source (`delivery.deliverRunner.concurrencyCap`) and
+ * one scheduling kernel with every `/deliver` multi-Story invocation.
  *
  * On cycle detection, exits with code 2 and sets cycleError in the envelope.
  */
@@ -74,7 +74,7 @@ Continuous ready-set planner for standalone Story delivery. Consumes a
 dependency graph of Story IDs plus the live run progress and emits the set
 of Stories safe to dispatch on this beat — a Story is dispatchable the
 instant its own dependencies are done — plus the resolved per-beat
-concurrency cap and the same file-overlap guard the Epic path uses.
+concurrency cap and the same file-overlap guard as selectReadySet.
 
 Input DAG format (JSON array):
   [{ "id": 101, "dependsOn": [] }, { "id": 102, "dependsOn": [101] }]
@@ -257,7 +257,7 @@ export function parseConcurrencyOverride(raw) {
 /**
  * Resolve the per-beat concurrency cap.
  *
- * Mirrors the `/deliver` seam (`epic-deliver-prepare.js`): resolve the
+ * Mirrors the `/deliver` multi-Story seam (`helpers/deliver-story.md`): 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

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

@@ -2,33 +2,17 @@
 /* node:coverage ignore file */
 
 /**
- * story-plan.js — Local `/plan` wrapper.
+ * story-plan.js — QA helper for promote round-trips and `--emit-context`
+ * envelope emission.
  *
- * 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`:
+ * Canonical operator planning is `plan-context.js` + `plan-persist.js` (see
+ * `.agents/workflows/plan.md`). Use this CLI only for QA promote
+ * round-trips (`--body` / `--dry-run`) or test harnesses that need the
+ * standalone envelope shape.
  *
- *   1. `--emit-context` mode — given a `--idea`/`--from-notes` seed,
- *      build the context envelope (seed, refine heuristic, persona,
- *      body template, duplicate candidates, tech-stack summary, and a
- *      corpus-aware `corpusContext` — the docs digest plus relevant
- *      existing-Epic Tech Spec excerpts, Story #4432) and print it as
- *      JSON on stdout. Logs route to stderr so the envelope is
- *      byte-clean for `JSON.parse`.
- *   2. Persist mode — given a `--body <file>` authored by the host
- *      LLM after operator confirmation, validate the shape and persist
- *      via `provider.createIssue` (which also adds the new Story to
- *      the configured Projects V2 board — Story #3822) with
- *      `type::story` + the chosen persona label, falling back to
- *      `gh issue create` when the provider lacks a createIssue
- *      analogue. Prints `Next: /single-story-deliver <id>`.
- *   3. `--dry-run` — same as persist but exits without touching
- *      GitHub. Echoes the rendered body and the `gh` argv it would
- *      have run.
- *
- * 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.
+ * Operator planning:
+ *   node .agents/scripts/plan-context.js --seed "…" | --seed-file <path> | --tickets <ids>
+ *   node .agents/scripts/plan-persist.js --stories … --risk-verdict …
  */
 
 import { readFile } from 'node:fs/promises';
@@ -53,10 +37,10 @@ import {
 
 const HELP = `\
 Usage:
-  story-plan.js --emit-context (--idea "<seed>" | --from-notes <file>) \\
-    [--persona <name>] [--refine | --no-refine] [--pretty]
+  story-plan.js --emit-context (--seed "<seed>" | --seed-file <file>) \\
+    [--refine | --no-refine] [--pretty]
 
-  story-plan.js --body <file> [--persona <name>] [--dry-run]
+  story-plan.js --body <file> [--dry-run]
 
   story-plan.js --help
 
@@ -66,12 +50,11 @@ Modes:
                    draft body using the envelope and the body template.
   --body <file>    Persist a pre-authored body. Validates shape (required
                    sections, no Epic: ref, AC checklist non-empty) and
-                   calls \`gh issue create\` with type::story + persona.
+                   calls \`gh issue create\` with type::story.
   --dry-run        With --body: print the body and the gh argv that would
                    be invoked, then exit 0. No GitHub mutations.
 
 Options:
-  --persona <name>   Persona label (default: engineer).
   --refine           Force the idea-refinement hint on regardless of seed
                      length. Default heuristic: refine when seed < 200
                      chars.
@@ -80,17 +63,17 @@ Options:
 `;
 
 /**
- * Resolve the seed string from --idea or --from-notes. One of the two
+ * Resolve the seed string from --seed or --seed-file. One of the two
  * must be present in --emit-context mode.
  */
-async function resolveSeed({ idea, fromNotes }) {
-  if (idea && fromNotes) {
-    throw new Error('Pass either --idea or --from-notes, not both.');
+async function resolveSeed({ seed, seedFile }) {
+  if (seed && seedFile) {
+    throw new Error('Pass either --seed or --seed-file, not both.');
   }
-  if (idea) return idea;
-  if (fromNotes) return (await readFile(fromNotes, 'utf8')).trim();
+  if (seed) return seed;
+  if (seedFile) return (await readFile(seedFile, 'utf8')).trim();
   throw new Error(
-    '--emit-context requires --idea "<seed>" or --from-notes <file>.',
+    '--emit-context requires --seed "<seed>" or --seed-file <file>.',
   );
 }
 
@@ -147,12 +130,11 @@ async function runEmitContext({
   write = (s) => process.stdout.write(s),
 }) {
   const seed = await resolveSeed({
-    idea: values.idea,
-    fromNotes: values['from-notes'],
+    seed: values.seed,
+    seedFile: values['seed-file'],
   });
   const override = values.refine ? 'on' : values['no-refine'] ? 'off' : null;
   const refine = shouldRefine({ seed, override });
-  const persona = values.persona ?? 'engineer';
 
   // Corpus lookup uses the raw (un-defaulted) docsContextFiles list, same
   // as the `/deliver` per-Epic digest builder: `config.project` fills in
@@ -186,7 +168,6 @@ async function runEmitContext({
   const envelope = buildContextEnvelope({
     seed,
     refine,
-    persona,
     bodyTemplate,
     duplicateCandidates,
     techStack,
@@ -221,8 +202,7 @@ async function runPersist({
   }
 
   const title = extractTitle(body);
-  const persona = values.persona ?? 'engineer';
-  const labels = [TYPE_LABELS.STORY, `persona::${persona}`];
+  const labels = [TYPE_LABELS.STORY];
   const argv = renderGhArgv({ title, bodyPath, labels });
 
   if (dryRun) {
@@ -264,7 +244,7 @@ async function runPersist({
   }
 
   write(`${JSON.stringify({ issueNumber, title, labels }, null, 2)}\n`);
-  Logger.info(`Next: /single-story-deliver ${issueNumber}`);
+  Logger.info(`Next: /deliver ${issueNumber}`);
 }
 
 /* node:coverage ignore next */
@@ -272,10 +252,9 @@ async function main() {
   const { values } = parseArgs({
     options: {
       'emit-context': { type: 'boolean', default: false },
-      idea: { type: 'string' },
-      'from-notes': { type: 'string' },
+      seed: { type: 'string' },
+      'seed-file': { type: 'string' },
       body: { type: 'string' },
-      persona: { type: 'string' },
       refine: { type: 'boolean', default: false },
       'no-refine': { type: 'boolean', default: false },
       pretty: { type: 'boolean', default: false },

package/.agents/scripts/update-ticket-state.js

@@ -1,13 +1,8 @@
 /**
- * .agents/scripts/update-ticket-state.js — CLI Re-export Shim
- *
- * Thin backward-compatibility shim. The core logic has been moved to
- * `lib/orchestration/ticketing.js` as part of the SDK refactor.
- *
- * This file preserves backward compatibility for CLI usage and existing
- * testing patterns.
- *
- * Successor to the retired mandrel MCP tools. See ADR 20260424-702a in docs/decisions.md for the migration table.
+ * .agents/scripts/update-ticket-state.js — CLI entrypoint for ticket
+ * label transitions. Core logic lives in `lib/orchestration/ticketing.js`;
+ * this file is the operator-facing command surface (not a compatibility
+ * layer).
  */
 
 import { parseArgs } from 'node:util';
@@ -33,7 +28,6 @@ if (
   const { values } = parseArgs({
     args: process.argv.slice(2),
     options: {
-      task: { type: 'string' },
       ticket: { type: 'string' },
       state: { type: 'string' },
       'remove-label': { type: 'string' },
@@ -43,17 +37,14 @@ if (
     strict: false,
   });
 
-  // `--ticket` is the v5.9.0 alias for `--task` (labels can apply to any
-  // ticket type, not just Tasks). Both continue to work.
-  const idSource = values.ticket ?? values.task;
-  const ticketId = Number.parseInt(idSource, 10);
+  const ticketId = Number.parseInt(values.ticket, 10);
   const state = values.state;
   const removeLabel = values['remove-label'];
 
   if (Number.isNaN(ticketId) || (!state && !removeLabel)) {
     throw new Error(
       'Usage: node update-ticket-state.js ' +
-        '(--ticket|--task) <id> ' +
+        '--ticket <id> ' +
         '[--state <state> | --remove-label <label>]',
     );
   }

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

@@ -1,10 +1,10 @@
 ---
 name: analyze-execution
 description: >-
-  Aggregate per-Story or per-Epic execution signals into a structured
+  Aggregate per-Story or per-plan-run 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
-  `/deliver` Phase 6 (Epic mode). Reads NDJSON via
+  ticket. Use after a Story closes (Story mode) or during run closeout
+  (plan-run mode). Reads NDJSON via
   `lib/signals/read` and writes a single structured comment.
 allowed_tools:
   - Read
@@ -16,42 +16,42 @@ allowed_tools:
 ## Policy Capsule
 
 - Invoke via the wrapping CLI `node .agents/scripts/analyze-execution.js`; do not duplicate the read/write logic from this Skill body.
-- Resolve mode strictly by flags: `--story <sid> --epic <eid>` → Story mode; `--epic <eid>` alone → Epic mode.
-- Read NDJSON signals only through `lib/signals/read` (the async-iterator entry point). Never open `<tempRoot>/epic-<eid>/story-<sid>/signals.ndjson` directly — the reader owns the warn-once malformed-JSON policy.
+- Resolve mode strictly by flags: Story + run id → Story mode; run id alone → plan-run mode. The current CLI still spells the run-id flag as `--epic <id>`; treat that value as the run id and do not add a second executor path here.
+- Read NDJSON signals only through `lib/signals/read` (the async-iterator entry point). Never open `<tempRoot>/run-<id>/stories/story-<sid>/signals.ndjson` directly — the reader owns the warn-once malformed-JSON policy.
 - Emit a single structured GitHub comment per ticket (`<!-- structured:story-perf-summary -->` or `<!-- structured:epic-perf-report -->`); rely on `upsertStructuredComment` for idempotence — never post duplicates.
-- Never rename or alter the structured-marker IDs; the retro composer and Epic dashboard grep them verbatim.
+- Never rename or alter the structured-marker IDs; the retro composer and run dashboard grep them verbatim.
 - Validate the structured payload against `docs/data-dictionary.md §StoryPerfSummary` or `§EpicPerfReport` before posting. Schema violations exit non-zero.
-- Soft-fail (exit 0 with a warning) when NDJSON is missing for a Story or an Epic has no children — observability output MUST NOT block the close pipeline.
+- Soft-fail (exit 0 with a warning) when NDJSON is missing for a Story or a plan-run has no children — observability output MUST NOT block the close pipeline.
 - Do not write to disk. Persistence is GitHub; the Skill is read-NDJSON + post-comment only.
 
 ## Role
 
 Observability writer. Composes the structured `story-perf-summary` /
 `epic-perf-report` comment bodies the retro composer downstream renders
-into the Epic dashboard.
+into the run dashboard.
 
 ## When to use
 
-- **Story mode** — after `story-close.js` finishes, the post-merge
+- **Story mode** — after `single-story-close.js` finishes, the close
   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 `/deliver` Phase 6.0 (or the retro
-  composer), the Skill fans out across every Story under the Epic,
+- **Plan-run mode** — during run closeout (or the retro
+  composer), the Skill fans out across every Story under the plan-run,
   reads each Story's structured perf summary, and posts a single
-  `<!-- structured:epic-perf-report -->` marker on the Epic ticket.
+  `<!-- structured:epic-perf-report -->` marker on the run ticket.
 
 ## Inputs
 
 The Skill reads (never writes) the NDJSON signal stream at:
 
 ```text
-<tempRoot>/epic-<eid>/story-<sid>/signals.ndjson
+<tempRoot>/run-<id>/stories/story-<sid>/signals.ndjson
 ```
 
 Use the `lib/signals/read` async-iterator entry point — never open the
 file directly. Story mode also reads `phase-timings.json` written by
-`post-merge-close.js`.
+the close pipeline.
 
 ## Outputs
 
@@ -64,8 +64,8 @@ the new one.
 
 ### Step 1 — Resolve mode
 
-If both `--story <sid>` and `--epic <eid>` are supplied → Story mode.
-If only `--epic <eid>` is supplied → Epic mode. The script
+If both Story id and run id are supplied → Story mode.
+If only run id is supplied → plan-run mode. The script
 `analyze-execution.js` is the dispatcher today; this Skill documents the
 contract the dispatcher implements.
 
@@ -77,6 +77,9 @@ node .agents/scripts/analyze-execution.js --story <sid> --epic <eid>
 node .agents/scripts/analyze-execution.js --epic <eid>
 ```
 
+`--epic <eid>` is the legacy spelling of the run-id flag in the current
+CLI; treat `<eid>` as the run id for path/layout purposes.
+
 ### Step 3 — Validate the structured payload before posting
 
 The payload must conform to `docs/data-dictionary.md §StoryPerfSummary`
@@ -92,7 +95,7 @@ the contract so we never silently emit malformed comments.
 - Do **not** rename the structured-marker IDs
   (`<!-- structured:story-perf-summary -->`,
   `<!-- structured:epic-perf-report -->`); the retro composer and the
-  Epic dashboard both grep for them verbatim.
+  run dashboard both grep for them verbatim.
 - Soft-failure mode is intentional: missing NDJSON for a Story or no
-  children for an Epic returns exit 0 with a warning so close pipelines
+  children for a plan-run returns exit 0 with a warning so close pipelines
   never block on observability output.

package/.agents/skills/core/idea-refinement/SKILL.md

@@ -35,12 +35,12 @@ structured divergent and convergent thinking.
 
 ## Activation
 
-Called from `/plan` Phase 1 (ideation entry, when no `<epic#>` is
-supplied or `--idea "<seed>"` is passed) and Phase 6 (Epic Clarity Gate,
-when an existing Epic body fails the section-presence rubric). In Phase 6
-the skill is seeded from the **current Epic body** — not a blank seed —
-with the rubric gap list (`missingOrPlaceholder`) as the convergence
-target.
+Called from [`/plan`](../../../workflows/plan.md) during ideation when the
+operator supplies `--seed "<text>"` (or runs ideation with no seed and
+the host collects one interactively). The skill sharpens freeform intent
+into canonical planning sections that `/plan` then folds into a Story.
+There is no separate Epic Clarity Gate path in v2 — N=1 Story authoring
+with a folded `## Spec` is the lean default.
 
 ## Usage
 

package/.agents/skills/core/scope-triage/SKILL.md

@@ -1,189 +1,45 @@
 ---
 name: scope-triage
 description:
-  Judge whether a piece of planned work is epic-sized or story-sized before the
-  planning ceremony is paid for. Emits one of three verdicts —
-  `epic` | `story` | `borderline` — over any planning artifact (a one-pager, an
-  Epic body, or a Story draft). Use from `/plan` Phase 1.5 and any other
-  planning gate that needs the canonical story-vs-epic rubric.
+  Optional split-advisory for `/plan`. Under v2 there is no epic|story routing
+  verdict — `/plan` always authors Stories. Use this skill only when judging
+  whether a draft should stay one Story or legitimately split (near-zero
+  overlap or an architectural seam).
 ---
 
-# scope-triage
+# scope-triage (split advisory)
 
 ## Policy Capsule
 
-- Produce exactly one verdict — `epic` | `story` | `borderline` — for the
-  artifact under judgment. Never auto-route on the verdict; the verdict is
-  **advisory**, and the operator always decides what to do with it.
-- Anchor every sizing judgment to the existing sizing SSOT **by reference**:
-  `DELIVERABLE_GRANULARITY_GUIDANCE` and `DEFAULT_TASK_SIZING` in
+- There is **no** `epic | story | borderline` routing verdict in v2. `/plan`
+  is a single path that emits **one Story by default**.
+- This skill is an optional **split advisory**: should the author keep one
+  Story, or does the seed clear the default-single split policy?
+- Anchor sizing judgment to `DEFAULT_MODEL_CAPACITY` and
+  `DELIVERABLE_GRANULARITY_GUIDANCE` in
   [`ticket-validator-sizing.js`](../../../scripts/lib/orchestration/ticket-validator-sizing.js).
-  **Do not restate the numeric thresholds** — read them from that module so the
-  rubric cannot drift from the validator that enforces them.
-- The verdict is **host-LLM judgment**, not a deterministic score. There is no
-  `--flag`, no scorer, no schema, and no label transition behind this skill —
-  it is read-on-demand library content, evaluated with judgment per
-  [`.agents/instructions.md` § 1.B](../../../instructions.md).
-- Lead with **cohesion**, the same primary heuristic the sizing SSOT leads
-  with: one Story is *one coherent change with one reason to exist*. The file /
-  acceptance ceilings are the backstop, not the first cut.
-- Bias toward `epic` only when the work genuinely spans multiple independent
-  capabilities, crosses subsystems, or carries a real dependency graph. Being
-  wrong in the `epic` direction is cheap — the Phase 8.3 consolidation pass and
-  the sizing validator catch an over-planned Story later. Being wrong in the
-  `story` direction is expensive — a story-sized scope pushed through the full
-  Epic ceremony pays a sectioned-Epic-body (Tech Spec + Acceptance Table) +
-  Story backlog +
-  `epic/<id>` integration-branch tax for a degenerate one-Story output.
-- Keep the rubric prose **artifact-agnostic**. The thing under judgment may be a
-  sharpened one-pager, an existing Epic body, or a draft Story — the rubric
-  reads the same against all three so every consumer reuses it verbatim.
+  Do not restate numeric thresholds.
+- Lead with **cohesion**: one Story is one coherent change with one reason
+  to exist. Coupled work stays one Story and uses `## Slicing` for
+  intra-session checkpoints.
 
-## Verdicts
+## Split policy (when N>1 is allowed)
 
-The skill emits exactly one of three verdicts.
+Split into sibling Stories **only** when:
 
-### `story`
+1. **Near-zero overlap** — genuinely independent capabilities that happen to
+   share a seed idea, or
+2. **Architectural seam** — different deployables, or a migration vs the
+   feature that consumes it.
 
-The work is a single shippable capability. Signals:
+Otherwise keep one Story. Persist refuses coupled splits via
+`assertAcceptancePartition` (identical AC text across Stories).
 
-- **One capability, one reason to exist.** The artifact describes one coherent
-  change a reviewer would accept as a single PR — the
-  `DELIVERABLE_GRANULARITY_GUIDANCE.definition` notion of a Story.
-- **Acceptance fits one Story.** The acceptance-criteria list reads as the
-  binding contract of one coherent capability rather than spanning many
-  independent outcomes. Acceptance mass is advisory-only (the
-  `softAcceptanceCount` nudge in `DEFAULT_TASK_SIZING` — there is no hard
-  ceiling), so the question is cohesion, not count.
-- **Footprint fits Story sizing.** The plausible file footprint fits the Story
-  width described by `DEFAULT_TASK_SIZING` (the `softFiles` / `hardFiles`
-  knobs); a legitimately broad-but-cohesive change would declare `wide` rather
-  than being two Stories.
-- **No novel architecture, no high-risk trigger.** The work introduces no novel
-  architectural decision and matches none of the `planning.riskHeuristics` in
-  `.agentrc.json` (destructive/irreversible changes, shared auth/security,
-  CI/CD gate changes, monorepo-wide rewrites, destructive migrations).
-- **Decomposition would degenerate.** Running it through `/plan` would
-  plausibly yield exactly **one Feature with one Story** — the shape the Phase
-  8.3 consolidation skill flags only after all the spec authoring is already
-  sunk cost.
+## Advisory output
 
-### `epic`
+Emit one of:
 
-The work is genuinely Epic-sized. Signals (any one is sufficient):
+- `keep-single` — default; fold complexity into `## Spec` / `## Slicing`
+- `split` — list the proposed Stories and the seam/overlap rationale
 
-- **Multiple independent capabilities.** The artifact bundles two or more
-  capabilities that each stand alone as a unit of work.
-- **Cross-subsystem blast radius.** The change reaches across subsystems that
-  do not share one cohesive reason to exist.
-- **A real dependency graph.** The work has internal ordering — slices that
-  must land before others — rather than one atomic change.
-
-### `borderline`
-
-The work is genuinely on the line — it could reasonably be one ambitious Story
-or a small Epic, and neither call is clearly right. **Present the choice rather
-than deciding for the operator.** Do not force a verdict to avoid the third
-option; a borderline scope surfaced as borderline is the correct output.
-
-## Change-Request Triage Rubric
-
-A **change request** — "fix this", "tweak that", "extend the existing X" —
-is the common case this rubric routes cheaply: a delta against a surface the
-project already shipped, not a from-scratch capability. Route it to `story`
-by default when all three delta signals hold; treat any one signal's absence
-as a prompt to re-check, not an automatic `epic` bump.
-
-### Delta signals
-
-- **Delta to an already-delivered surface.** The request references a
-  concrete existing capability (a module, workflow, script, or shipped
-  feature) rather than proposing a new one. "Fix the flaky retry in
-  `evidence-gate.js`" is a delta; "add a retry framework" is not.
-- **Existing corpus covers the touched area.** The project's docs digest
-  and/or an already-closed or in-flight Epic's Tech Spec section already
-  describe the surface being changed — the standalone-Story path can draft
-  against that inherited context (`corpusContext` in the `/plan --idea`
-  envelope) instead of re-deriving architecture from a blank slate. When no
-  corpus hit exists for the touched area, that is a signal the request may
-  be reaching into genuinely new territory — re-check the `epic` signals
-  below before defaulting to `story`.
-- **Footprint fits Story sizing.** The plausible file footprint and
-  acceptance-criteria count still fit the Story width in
-  `DEFAULT_TASK_SIZING` (per the `story` verdict signals above) — a change
-  request that fans out across independent subsystems is sized like an Epic
-  regardless of how small the originating request sounded.
-
-### Story-verdict rationale template
-
-Use this template to record the verdict — it names which delta signal
-carried the call, so a reviewer can sanity-check the routing decision without
-re-deriving it:
-
-```text
-Verdict: story
-Delta: <the existing surface this change targets>
-Corpus hit: <docs digest section / Epic # and Tech Spec excerpt that covers
-  this area, or "none — re-checked epic signals, still story-sized">
-Footprint: <rough file/AC count vs DEFAULT_TASK_SIZING>
-```
-
-### Worked example
-
-> Request: "The `/plan` standalone-Story path always drafts from a blank
-> slate even when a change request is a small delta against something we
-> already shipped — thread the existing docs digest and matching Epic
-> Tech Spec sections into the draft context."
->
-> ```text
-> Verdict: story
-> Delta: story-plan.js's --emit-context envelope and the plan-story.md
->   Phase 2 drafting instructions — both already exist and ship today.
-> Corpus hit: Epic #4429's own Tech Spec section (this rubric's parent
->   Epic) already describes the docs-digest reuse pattern from
->   orchestration/docs-digest.js.
-> Footprint: one new lib module (planning-corpus.js), one envelope field,
->   one helper-doc instruction — comfortably inside DEFAULT_TASK_SIZING's
->   softFiles/softAcceptanceCount band.
-> ```
-
-## Handoff & no-re-triage rule
-
-A workflow entered via a scope-triage **handoff** MUST NOT re-triage. A handoff
-*is* a triage decision already made — re-running this gate on the receiving side
-would re-litigate a settled call and risk a ping-pong between two planning
-workflows. Handoff invocations identify themselves as such (e.g. `/plan`
-entered via a `/plan` scope-triage escalation, or `/plan` entered
-via an `/plan` Phase 1.5 handoff), and the receiving workflow skips its own
-scope-triage gate when it detects the handoff marker.
-
-## When to use
-
-- **`/plan` Phase 1.5** (ideation path only) — judge the sharpened
-  one-pager Phase 1 produced before the Epic ceremony is paid for. The verdict
-  folds into the existing Phase 1 HITL stop; on a `story` / `borderline`
-  verdict the operator may hand off to
-  [`/plan --from-notes`](../../../workflows/helpers/plan-story.md).
-- Any other planning gate that needs the canonical story-vs-epic rubric. Keep
-  the rubric here as the SSOT; consumers reference this file rather than
-  forking the prose.
-
-## Output
-
-A single verdict (`epic` | `story` | `borderline`) plus a one-paragraph
-rationale grounded in the signals above. The rationale names the deciding
-signal (cohesion, capability count, blast radius, dependency graph, or sizing
-fit) so the operator can sanity-check the call before acting on it.
-
-## Anti-patterns to avoid
-
-- **Restating the sizing numbers.** Reference `DEFAULT_TASK_SIZING` /
-  `DELIVERABLE_GRANULARITY_GUIDANCE`; never copy the thresholds into this file
-  (they would drift from the validator).
-- **Auto-routing on the verdict.** The verdict is advisory; the operator
-  decides. Never silently fork a workflow on a `story` verdict.
-- **Forcing a binary call.** When the work is genuinely on the line, emit
-  `borderline` and present the choice. Do not collapse it to `epic` or `story`
-  to look decisive.
-- **Re-triaging after a handoff.** A handoff is a settled decision. Skip the
-  gate when the invocation identifies itself as a scope-triage handoff.
+Never auto-route. The operator (or `--yes` default = `keep-single`) decides.