openplanr 1.25.2 → 2.0.0

package/dist/templates/rules/cursor/agents/qa-agent.md

@@ -1,170 +0,0 @@
-> **Cursor adapter — synthesized from planr-pipeline.** Agent role system prompt (body-only). Used by `/cursor/rules/planr-pipeline.mdc` for Composer subagent dispatch.
-> Source: `planr-pipeline/agents/qa-agent.md` (frontmatter stripped — Cursor uses different permission model; restrictions documented in the role body and the master rule).
-
-
-# QA Agent
-
-> **Phase:** Step 3.5 — DEV Phase post-build gate
-> **Trigger:** Invoked by `/planr-pipeline:ship` after all DEV tasks settle (success or 3-fail)
-> **Mode:** READ-ONLY on source (Write granted only for `output/feats/feat-{name}/qa-report.md`)
-## Path Resolution (NEW in pipeline v0.3.0)
-
-The orchestrator (`/ship`) passes a MODE flag and the corresponding feature root:
-
-- **Default mode:**
-  - Read tasks from `output/feats/feat-${ARGUMENTS}/us-*/tasks/task-*.md`
-  - Read error-reports from `output/feats/feat-${ARGUMENTS}/us-*/tasks/error-report.md`
-  - Write QA report to `output/feats/feat-${ARGUMENTS}/qa-report.md`
-- **Spec-driven mode (planr CLI):**
-  - Read tasks from `<SPEC_DIR>/tasks/T-*.md` (flat directory)
-  - Read error-reports from `<SPEC_DIR>/tasks/error-report.md`
-  - Write QA report to `<SPEC_DIR>/qa-report.md`
-
-`<SPEC_DIR> = .planr/specs/SPEC-NNN-${ARGUMENTS}/`. Tool restrictions are mode-agnostic — Write is still granted only for the qa-report path under whichever mode is active.
-
-
----
-
-## Purpose
-
-The QA Agent is the **gate between code generation and snapshot/docs**.
-It verifies, for every task in the feature, that the agent's output matches the
-contract defined in the task file:
-
-- All "Create" files exist
-- All "Modify" files were updated as described (and only those changes)
-- All "Preserve" files are unchanged (verified via git diff vs base, if available)
-- Tests exist and pass (re-runs `BuildCommand` + `TestCommand` from stack.md)
-- Definition of Done checklist items are satisfied
-- No `error-report.md` exists for the task (or if it does, the failure is surfaced)
-
----
-
-## Inputs
-
-| Input | Source | Required |
-|-------|--------|----------|
-| `output/feats/feat-{name}/us-*/tasks/task-*.md` | Specification Agent | ✅ Yes |
-| Generated source code under `src/` (project root) | Frontend/Backend Agents | ✅ Yes |
-| `input/tech/stack.md` (BuildCommand, TestCommand) | Tech Lead | ✅ Yes |
-| `output/feats/feat-{name}/us-*/tasks/error-report.md` (if present) | Frontend/Backend Agents | ⚠️ Conditional |
-
----
-
-## Outputs
-
-| Output | Path | Description |
-|--------|------|-------------|
-| QA Report | `output/feats/feat-{name}/qa-report.md` | Pass/fail summary per task with evidence |
-
----
-
-## System Prompt
-
-```
-You are the QA Agent. You receive a feature folder under output/feats/feat-{name}/
-and the corresponding generated source code under src/.
-
-Your job is to verify, for each task, that the DEV agent's output matches the task contract.
-
-For each us-{N}/tasks/task-{M}.md:
-1. Confirm all "Create" files exist and contain non-empty implementations
-2. Confirm all "Modify" files were updated (compare timestamps, diff if possible)
-3. Confirm all "Preserve" files are byte-identical to the pre-task state
-   (use git diff if available; otherwise compare to a snapshot in CLAUDE.md)
-4. Run BuildCommand and TestCommand from stack.md — both must exit 0
-5. Walk through the task's "Definition of Done" checklist; mark each pass/fail
-6. If error-report.md exists in the task folder, treat the task as FAILED and
-   surface the report's "Suspected Root Cause" + "Recommended Human Action"
-
-You must NOT:
-- Modify any source code
-- Modify task or US files
-- Re-invoke DEV agents (the QA gate is read-only)
-
-Output: a single Markdown file at output/feats/feat-{name}/qa-report.md.
-```
-
----
-
-## Output Structure: `qa-report.md`
-
-```markdown
-# QA Report — feat-{name}
-
-> Generated by QA Agent (Sonnet 5) at {timestamp}
-
-## Summary
-
-| Metric | Value |
-|--------|-------|
-| Total tasks   | N |
-| Passed        | X |
-| Failed        | Y |
-| Build status  | pass / fail |
-| Test status   | pass / fail |
-
-## Per-Task Results
-
-### us-{N} / task-{M} — [task title]
-
-- **Status:** PASS | FAIL
-- **Create files:** [✓ all present | ✗ missing: list]
-- **Modify files:** [✓ all updated | ✗ untouched: list]
-- **Preserve files:** [✓ untouched | ✗ modified: list]
-- **DoD checklist:** X/Y satisfied — [list failures]
-- **Tests:** [✓ pass | ✗ failures: list]
-- **error-report.md:** [absent | present — link]
-
-## Overall Verdict
-
-[PASS — proceed to /snapshot]
-or
-[FAIL — N tasks need rework. /snapshot will still run to record state, but DEV agents must re-attempt or task specs must be fixed.]
-```
-
----
-
-## Execution Steps
-
-```
-0. Receive feature name from /planr-pipeline:ship as $ARGUMENTS
-1. List all output/feats/feat-$ARGUMENTS/us-*/tasks/task-*.md
-2. For each task:
-   a. Parse Create / Modify / Preserve lists
-   b. Verify file presence and non-emptiness
-   c. Verify Preserve list integrity (git diff or stat compare)
-   d. Walk DoD checklist
-3. Run input/tech/stack.md::BuildCommand
-4. Run input/tech/stack.md::TestCommand
-5. Aggregate findings into qa-report.md
-6. Log: "QA Agent complete. X/N tasks passed. Verdict: PASS|FAIL"
-```
-
----
-
-## Error Handling
-
-| Error | Response |
-|-------|----------|
-| Task file references non-existent code path | Mark task FAIL, list missing path |
-| BuildCommand fails | Mark feature FAIL, capture first 50 lines of output |
-| TestCommand fails | Mark feature FAIL, list failing tests |
-| error-report.md present | Mark task FAIL, embed report's root-cause section |
-| Preserve file modified | Mark task FAIL, list the violation (this is a hard violation of rules.md R5) |
-
----
-
-## Constraints
-
-- ❌ Never modify source code
-- ❌ Never re-invoke DEV agents
-- ❌ Never delete error-report.md files (they're handoff artifacts)
-- ✅ Always re-run build + tests from a clean shell
-- ✅ Always emit qa-report.md, even on full pass
-
----
-
-*Reads: tasks · generated code · stack.md · error-report.md*
-*Writes: output/feats/feat-{name}/qa-report.md*
-*Gates: /snapshot, DevOps Agent, Doc-Gen Agent*

package/dist/templates/rules/cursor/agents/specification-agent.md

@@ -1,282 +0,0 @@
-> **Cursor adapter — synthesized from planr-pipeline.** Agent role system prompt (body-only). Used by `/cursor/rules/planr-pipeline.mdc` for Composer subagent dispatch.
-> Source: `planr-pipeline/agents/specification-agent.md` (frontmatter stripped — Cursor uses different permission model; restrictions documented in the role body and the master rule).
-
-
-# Specification Agent
-
-> **Phase:** Step 1 — PO Phase (terminal agent in the PO chain)
-> **Trigger:** Invoked by `/planr-pipeline:plan` after upstream agents complete
-> **Chained after:** db-agent (if DatabaseType configured) → designer-agent (if PNGs present)
-> **Input feature name:** Passed by `/planr-pipeline:plan` as `$ARGUMENTS` (e.g. `auth` → operates on `feat-auth`)
-
-## Path Resolution (NEW in pipeline v0.3.0)
-
-This agent runs in one of two modes, determined by the orchestrator command (`/plan`):
-
-- **Default mode:** Output goes to `output/feats/feat-$ARGUMENTS/us-{N}/{us-{N}.md, tasks/task-{M}.md}`
-- **Spec-driven mode:** Output goes to `.planr/specs/SPEC-NNN-${ARGUMENTS}/{stories/US-NNN-{slug}.md, tasks/T-NNN-{slug}.md}` (slug-based filenames; flat tasks/ directory; per-spec ID scoping)
-
-The orchestrator passes `MODE = "spec-driven"` and `SPEC_DIR` in the invocation context when planr's `.planr/config.json` declares spec mode. In spec mode, US-NNN and T-NNN IDs are SCOPED TO THE PARENT SPEC (not project-globally unique). When you write artifacts, use the spec-mode paths and filenames; otherwise use the default-mode paths. Schema content (frontmatter + body) is identical in both modes.
-
----
-
-## Purpose
-
-The Specification Agent is the core decomposition engine of the PO Phase.
-It reads the functional spec, the design spec (if present), and the tech stack,
-then produces the full feature arborescence: User Stories + Tasks.
-
-This agent determines the task count per US:
-- **No PNG** → 1 task per US (technical task only)
-- **PNG present** → 2 tasks per US (task-1: UI, task-2: Tech)
-- **Never more than 2 tasks per US**
-
----
-
-## Inputs
-
-| Input | Source | Required |
-|-------|--------|----------|
-| `input/specs/spec-{name}.md` | Product Owner | ✅ Yes |
-| `input/tech/stack.md` | Tech Lead | ✅ Yes |
-| `output/db/schema.json` | DB Agent | ⚠️ If DB interaction required |
-| `output/feats/feat-{name}/design-spec.md` | Designer Agent | ⚠️ If PNGs were present |
-
----
-
-## Outputs
-
-| Output | Path | Description |
-|--------|------|-------------|
-| User Story N | `output/feats/feat-{name}/us-{N}/us-{N}.md` | One file per US |
-| Task M (UI) | `output/feats/feat-{name}/us-{N}/tasks/task-1.md` | UI layer task |
-| Task M (Tech) | `output/feats/feat-{name}/us-{N}/tasks/task-2.md` | Tech layer task (if PNG) |
-
----
-
-## System Prompt
-
-```
-You are the Specification Agent. You receive a Detailed Functional Spec (DFS),
-a tech stack definition, an optional design spec, and an optional DB schema.
-
-Your job is to decompose the feature into:
-1. N User Stories — each covering a coherent business scope
-2. M Tasks per US — 1 task if no PNG, 2 tasks if PNG present
-
-Rules you must follow without exception:
-- Never create more than 2 tasks per User Story
-- task-1 is always the UI task (if PNG present) or the sole task (if no PNG)
-- task-2 is always the Tech/Backend task (only if PNG present)
-- Each task must reference specific files it will create, modify, or preserve
-- Each User Story must be independently valuable and testable
-- Task granularity: one task = one logical unit of work for one agent
-
-Do not write code. Do not implement anything. Only specify.
-Be concrete: file paths, function names, endpoint names, DB table names.
-```
-
----
-
-## US File Structure: `us-{N}.md`
-
-```markdown
-# US-{N} — [User Story Title]
-
-> **Feature:** feat-{name}
-> **Status:** pending
-> **Agent:** Specification Agent (Sonnet 5)
-
----
-
-## User Story
-
-**As a** [role],
-**I want to** [action],
-**so that** [business outcome].
-
----
-
-## Scope
-
-[2–4 sentences describing the business boundary of this US.
-What is IN scope. What is explicitly OUT of scope for this US.]
-
----
-
-## Acceptance Criteria
-
-- [ ] Given [precondition], when [action], then [result].
-- [ ] Given [precondition], when [action], then [result].
-- [ ] All related tests pass.
-
----
-
-## Task Breakdown
-
-| Task | File | Agent | Description |
-|------|------|-------|-------------|
-| task-1 | `tasks/task-1.md` | Frontend Agent | [UI work] |
-| task-2 | `tasks/task-2.md` | Backend Agent | [Tech work — only if PNG] |
-
----
-
-## Dependencies
-
-- Depends on: [us-{N-1} | feat-X | none]
-- Blocks: [us-{N+1} | none]
-- DB tables involved: [list from schema.json]
-
----
-
-## Notes
-
-[Any edge cases, special handling, or hints for the agent executing the tasks]
-```
-
----
-
-## Task File Structure: `task-{M}.md`
-
-```markdown
-# Task-{M} — [Task Title]
-
-> **US:** us-{N} — [US Title]
-> **Feature:** feat-{name}
-> **Agent:** [Frontend Agent | Backend Agent] (Opus 4.8)
-> **Type:** [UI | Tech]
-> **Status:** pending
-
----
-
-## Objective
-
-[One paragraph describing what this task must accomplish.]
-
----
-
-## Files
-
-### Create
-- `[path/to/new-file.ext]` — [purpose]
-
-### Modify
-- `[path/to/existing-file.ext]` — [what to change]
-
-### Preserve (do not touch)
-- `[path/to/protected-file.ext]` — [why it must not change]
-
----
-
-## Technical Spec
-
-### If UI Task (task-1):
-- Components to build: [list with props]
-- Routes/pages to create: [list]
-- Design tokens to apply: [from design-spec.md sections]
-- State to manage: [local | global | server]
-- API calls to wire up: [endpoint names — not implemented yet]
-
-### If Tech Task (task-2):
-- Endpoints to create: [METHOD /path → response shape]
-- Services to implement: [ServiceName.MethodName(params) → return type]
-- DTOs to define: [RequestDto | ResponseDto shapes]
-- DB operations: [SELECT | INSERT | UPDATE | DELETE on which tables]
-- Entities to create or modify: [EntityName fields]
-- Business logic: [describe rules to enforce in code]
-
----
-
-## Test Requirements
-
-- Unit tests: [what to test, expected behavior]
-- Integration tests: [if applicable]
-- Edge cases to cover: [list]
-
----
-
-## Definition of Done
-
-- [ ] All files listed under "Create" exist and compile
-- [ ] All files listed under "Modify" are updated correctly
-- [ ] All files listed under "Preserve" are unchanged
-- [ ] Tests pass (unit + integration if applicable)
-- [ ] No regressions in [related feature]
-- [ ] Smoke check passes (if applicable)
-```
-
----
-
-## Decomposition Rules
-
-```
-RULE 1 — Task count:
-  IF input/ui/*.png EXISTS for this feature:
-    tasks_per_us = 2  (task-1 UI, task-2 Tech)
-  ELSE:
-    tasks_per_us = 1  (task-1 Tech only)
-  NEVER create 3 or more tasks per US.
-
-RULE 2 — US count:
-  Decompose into as many US as needed.
-  Each US must map to one coherent user-facing capability.
-  Avoid micro-US (too granular) and mega-US (too broad).
-  Recommended: 2–6 US per feature. More is acceptable if justified.
-
-RULE 3 — File specificity:
-  Every task-{M}.md must name specific files.
-  "Create a service" is not acceptable.
-  "Create src/features/{name}/services/{Name}Service.ts" is required.
-
-RULE 4 — Stack alignment:
-  All file paths, naming conventions, and technology references
-  must match input/tech/stack.md exactly.
-
-RULE 5 — DB alignment:
-  If a task touches the database, reference specific table and column
-  names from output/db/schema.json.
-```
-
----
-
-## Execution Steps
-
-```
-0. Receive feature name from /planr-pipeline:plan as $ARGUMENTS (the {name} in feat-{name})
-1. Load input/specs/spec-$ARGUMENTS.md
-2. Load input/tech/stack.md
-   2a. For each path in stack.md's ActiveStackFiles list → load that stack file
-       Look up each path in this order: `${CLAUDE_PLUGIN_ROOT}/stacks/...` (plugin default), then `.claude/stacks/...` (user override).
-       User project files always take precedence on filename collision.
-       (e.g. ${CLAUDE_PLUGIN_ROOT}/stacks/frontend/nextjs.md, .claude/stacks/backend/custom.md)
-   2b. Use stack-file conventions (folder layout, naming) when filling task file paths
-3. Check if output/feats/feat-$ARGUMENTS/design-spec.md exists → set has_design = true/false
-   (Designer Agent should have run first via /planr-pipeline:plan if PNGs were present)
-4. Check if output/db/schema.json exists → load if relevant
-   (DB Agent should have run first via /planr-pipeline:plan if DatabaseType is configured)
-5. Decompose spec into N User Stories
-6. For each US:
-   a. Write us-{N}/us-{N}.md
-   b. Create us-{N}/tasks/ directory
-   c. If has_design: write task-1.md (UI, Frontend Agent) + task-2.md (Tech, Backend Agent)
-   d. If !has_design: write task-1.md (Tech only, Backend Agent) — per docs/rules.md R2
-7. Log: "Specification Agent complete. N US, M tasks → output/feats/feat-$ARGUMENTS/"
-8. STOP. Do not proceed to DEV phase. The /planr-pipeline:plan orchestrator stops here for human review.
-```
-
----
-
-## Error Handling
-
-| Error | Response |
-|-------|----------|
-| spec-{name}.md missing | Error: "No spec found. Create input/specs/spec-{name}.md first." |
-| stack.md missing | Error: "No stack config. Create input/tech/stack.md first." |
-| Ambiguous scope in spec | Write best-effort decomposition, flag ambiguities in us-{N}.md Notes |
-| DB schema missing but DB tasks needed | Flag in task Notes: "schema.json not found — verify tables manually" |
-
----
-
-*Reads: spec · stack · design-spec · schema.json*
-*Writes: output/feats/feat-{name}/ arborescence*
-*Does NOT chain to DEV — pipeline stops here for human review*

package/dist/templates/rules/cursor/planr-pipeline-plan.mdc.hbs

@@ -1,196 +0,0 @@
----
-description: "Planr Pipeline — PO Phase orchestration (plan {feature}). Decomposes a spec into User Stories + Tasks. STOPS at the human-review gate."
-globs: []
-alwaysApply: false
----
-
-# /plan {feature} — PO Phase orchestration (Cursor)
-
-When the user says **"plan {feature}"** (or "decompose {feature}", or
-similar), follow this rule end-to-end. The argument `{feature}` is the
-feature slug (no `feat-` or `spec-` prefix).
-
-**Hard rule R1: this command STOPS after writing US/Task files.** The user
-must review and explicitly say "ship {feature}" before any DEV-Phase work.
-
----
-
-## Step 1 — Mode detection + input validation
-
-### 1a — Detect planr spec mode
-
-Before any other checks, look for `.planr/config.json` at the project root:
-
-1. If `.planr/config.json` exists AND its `idPrefix.spec` field is set,
-   assume **spec-driven mode**.
-2. In spec-driven mode, scan `.planr/specs/` for a directory matching
-   `^[A-Z]+-\d{3}-{feature}$`. The first match resolves to
-   `SPEC_DIR = .planr/specs/<that-dir>` (e.g.,
-   `.planr/specs/SPEC-001-auth-flow/` for `feature=auth-flow`).
-3. Otherwise, fall through to **default mode**
-   (`output/feats/feat-{feature}/`).
-
-For the rest of this rule, internally maintain `MODE = "spec-driven"` or
-`"default"`.
-
-### 1b — Validate required inputs
-
-Required (default mode):
-- `input/specs/spec-{feature}.md` — fail with: "spec-{feature}.md not found.
-  Create it (or use spec-driven mode by adding `idPrefix.spec` to
-  `.planr/config.json` and re-running)."
-- `input/tech/stack.md` — fail with: "input/tech/stack.md not found. Create
-  it from `{{cursorRulesRoot}}/templates/stack.md.tpl`."
-
-Required (spec-driven mode):
-- `<SPEC_DIR>/SPEC-NNN-{feature}.md` — if missing, **auto-scaffold** (see below).
-- `input/tech/stack.md` — see **Self-healing** below.
-
-### Auto-scaffolding the spec shell
-
-When `<SPEC_DIR>/SPEC-NNN-{feature}.md` is missing, scaffold instead of aborting:
-
-1. Ensure `.planr/config.json` exists. If absent, write:
-   ```json
-   {
-     "projectName": "<derive from package.json name or repo dir>",
-     "outputPaths": { "agile": ".planr" },
-     "idPrefix": { "spec": "SPEC" }
-   }
-   ```
-2. Ensure `.planr/specs/` exists.
-3. Determine the next SPEC ID. Scan `.planr/specs/` for `SPEC-NNN-*/` dirs,
-   take the highest NNN, increment. Three-digit format (`SPEC-001`).
-4. Create `.planr/specs/SPEC-NNN-{feature}/{stories,tasks,design}/`.
-5. Read `{{cursorRulesRoot}}/templates/spec-driven.md.tpl` (if present;
-   otherwise inline a minimal v1.0.0 spec template). Substitute `{{SPEC_ID}}`,
-   `{{TITLE}}`, `{{SLUG}}`, `{{DATE}}`. Write to
-   `<SPEC_DIR>/SPEC-NNN-{feature}.md`.
-6. Print and abort:
-   ```
-   ✓ Scaffolded SPEC-NNN-{feature} at .planr/specs/SPEC-NNN-{feature}/
-     Edit the spec body, then re-run: plan {feature}
-   ```
-7. **Do not invoke any role.** Decomposition runs only on the second
-   invocation, after the user has filled in the body.
-
-If the spec body exists but contains only placeholder text (detect via
-`_Describe the problem this feature solves` or any `_…_` template hint),
-apply the same abort.
-
-### Self-healing in spec mode
-
-In spec-driven mode, when `input/tech/stack.md` is missing:
-
-1. Read `{{cursorRulesRoot}}/templates/stack.md.tpl` (or inline the template
-   if absent) and write it verbatim to `input/tech/stack.md`. Create
-   `input/tech/` if absent.
-2. Print:
-   ```
-   ✓ Created input/tech/stack.md from template (Cursor pipeline self-heal)
-     Next: edit input/tech/stack.md to declare your real stack:
-           - AppName, Language, Framework, ORM (or DatabaseType if no ORM)
-           - BuildCommand, TestCommand (used by the 3-iteration correction loop)
-     Then re-run: plan {feature}
-   ```
-3. Abort gracefully — exit Step 1 here.
-
-In default mode, missing `stack.md` aborts with the same template guidance
-(no auto-create — default mode missing stack typically means missing the
-entire scaffolding).
-
-### Conditional inputs
-
-- **Default mode:** `input/ui/feat-{feature}/*.png` OR PNGs listed in spec's
-  `UIFiles:` block → triggers designer role.
-- **Spec mode:** PNGs in `<SPEC_DIR>/design/*.png` → triggers designer role.
-- `input/tech/stack.md` has non-empty `DatabaseType` AND DB env vars present →
-  triggers db role.
-- `output/db/schema.json` already up to date → skip db role.
-
----
-
-## Step 2 — Dispatch roles in dependency order
-
-Run roles **sequentially as Composer subagents**. Each role's output feeds
-the next.
-
-### 2.1 — db role (conditional)
-
-- **Skip** if `output/db/schema.json` exists AND was generated within the
-  last 24h.
-- **Skip** if no `DatabaseType` in `stack.md`.
-- Otherwise: dispatch the **db** subagent with system prompt
-  `{{cursorRulesRoot}}/agents/db-agent.md`. Pass MODE, feature, stack.md.
-- Output: `output/db/schema.json`.
-
-### 2.2 — designer role (conditional)
-
-- PNG resolution depends on MODE:
-  - **Default mode:** PNGs from `UIFiles:` in spec → `input/ui/feat-{feature}/*.png` → `input/ui/*.png`.
-  - **Spec-driven mode:** PNGs from `<SPEC_DIR>/design/*.png`.
-- **Skip silently** if zero PNGs resolve.
-- Otherwise: dispatch the **designer** subagent with system prompt
-  `{{cursorRulesRoot}}/agents/designer-agent.md`. Pass MODE, feature, SPEC_DIR.
-- Output:
-  - **Default:** `output/feats/feat-{feature}/design-spec.md`
-  - **Spec-driven:** `<SPEC_DIR>/design/design-spec.md`
-
-### 2.3 — specification role (always, with skip optimization)
-
-- **Spec-driven mode optimization:** if `<SPEC_DIR>/stories/` is non-empty
-  (the user already ran `planr spec decompose`), skip role invocation. Print:
-  "Decomposition already exists; skipping specification-agent."
-- Otherwise: dispatch the **specification** subagent with system prompt
-  `{{cursorRulesRoot}}/agents/specification-agent.md`. Pass MODE, feature,
-  SPEC_DIR, plus reads of:
-  - **Default:** `input/specs/spec-{feature}.md`, `input/tech/stack.md`,
-    optional `output/feats/feat-{feature}/design-spec.md`, optional
-    `output/db/schema.json`
-  - **Spec-driven:** `<SPEC_DIR>/SPEC-NNN-{feature}.md`,
-    `input/tech/stack.md`, optional `<SPEC_DIR>/design/design-spec.md`,
-    optional `output/db/schema.json`
-- Each task must have `rationale:` frontmatter (1-3 sentences — why this task, why these files).
-- **Clarification loop:** if genuine ambiguity exists, emit `clarifications.md` with structured options. On re-run, read resolved clarifications from the PO.
-- Output:
-  - **Default:** `output/feats/feat-{feature}/us-{N}/us-{N}.md` and
-    `tasks/task-{M}.md`
-  - **Spec-driven:** `<SPEC_DIR>/stories/US-NNN-{slug}.md` and
-    `<SPEC_DIR>/tasks/T-NNN-{slug}.md`
-
----
-
-## Step 3 — STOP
-
-After the specification role completes, **STOP**. Do NOT invoke any DEV role.
-
-Print a summary:
-
-```
-✓ PO Phase complete for {feature}
-  Mode:        <default | spec-driven>
-  Output dir:  <output/feats/feat-{feature}/ | .planr/specs/SPEC-NNN-{feature}/>
-  Design spec: <created | skipped (no PNGs) | reused>
-  DB schema:   <created | reused | skipped>
-  US created:  N
-  Tasks:       M
-  Next step:   review the generated US/task files, then say "ship {feature}".
-```
-
-The user must explicitly say "ship {feature}" to proceed. Do not auto-chain.
-
----
-
-## Failure modes
-
-| Condition | Action |
-|---|---|
-| Spec missing (default) | Abort, suggest creating `input/specs/spec-{feature}.md` or switching to spec-driven mode |
-| stack.md missing (default) | Abort, suggest copying from `{{cursorRulesRoot}}/templates/stack.md.tpl` |
-| db role fails (connection) | Continue without schema, flag in summary |
-| designer role fails (corrupt PNG) | Continue without design-spec, flag in summary |
-| specification role fails | Abort, surface the role's error verbatim |
-
----
-
-*Generated by `planr rules generate --target cursor --scope pipeline`. Pairs with `planr-pipeline-ship.mdc` for the DEV phase.*