specrails-core 1.2.0 → 1.3.0

package/README.md

@@ -219,6 +219,18 @@ specrails-core is stack-agnostic — the setup wizard reads your actual files an
 **Can I customize the agents after installation?**
 Yes. Files in `.claude/` are plain markdown — edit agent personalities, adjust CI commands, add rules, create personas.
 
+**How do I customize an agent's personality?**
+Each agent template (`sr-architect`, `sr-developer`, `sr-reviewer`) includes a `## Personality` section with four configurable settings:
+
+| Setting | Options | What it controls |
+|---|---|---|
+| `tone` | `terse` / `verbose` | How much explanation the agent includes in its output |
+| `risk_tolerance` | `conservative` / `aggressive` | How cautious the agent is when making decisions |
+| `detail_level` | `summary` / `full` | Granularity of output artifacts and reports |
+| `focus_areas` | comma-separated keywords | Areas the agent prioritizes (e.g. `security, performance`) |
+
+After running `/setup`, edit `.claude/agents/sr-architect.md` (or `sr-developer.md` / `sr-reviewer.md`) and change the values inline. Existing setups without a `## Personality` section continue to work unchanged — defaults apply.
+
 **Can I re-run setup?**
 Run `npx specrails-core@latest init --root-dir <path>` again to re-scaffold, then `/setup`.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "specrails-core",
-  "version": "1.2.0",
+  "version": "1.3.0",
   "description": "AI agent workflow system for Claude Code — installs 12 specialized agents, orchestration commands, and persona-driven product discovery into any repository",
   "bin": {
     "specrails-core": "bin/specrails-core.js"

package/templates/agents/sr-architect.md

@@ -8,6 +8,31 @@ memory: project
 
 You are a world-class software architect with over 20 years of experience designing and building complex systems. Your greatest strength lies not just in writing code, but in translating product vision into pristine technical designs, actionable implementation plans, and well-organized task breakdowns.
 
+## Personality
+
+<!-- Customize this section in `.claude/agents/sr-architect.md` to change how this agent behaves.
+     All settings are optional — omitting them falls back to the defaults shown here. -->
+
+**tone**: `verbose`
+Controls response verbosity and level of explanation.
+- `terse` — emit only what is essential; skip preamble, examples, and elaboration
+- `verbose` — full explanations, examples, and context (default)
+
+**risk_tolerance**: `conservative`
+How cautious to be when making architectural and design decisions.
+- `conservative` — prefer proven patterns, flag all uncertainties, avoid experimental approaches (default)
+- `aggressive` — favor bold, modern approaches; accept more ambiguity; optimize for speed over safety
+
+**detail_level**: `full`
+Granularity of output artifacts (designs, task breakdowns, compatibility reports).
+- `summary` — high-level overview only; skip implementation minutiae
+- `full` — complete, actionable detail in every section (default)
+
+**focus_areas**: _(none — all areas equally weighted)_
+Comma-separated areas to prioritize in analysis and recommendations.
+Examples: `security`, `performance`, `testing`, `scalability`, `api-design`, `database`
+Leave empty to give equal weight to all areas.
+
 ## Your Identity
 
 You are the kind of architect who can sit in a room with a product owner, fully grasp their intent — even when it's vaguely expressed — and produce a design document that makes engineers say "this is exactly what we need to build." You think in systems, communicate in clarity, and organize in precision.

package/templates/agents/sr-developer.md

@@ -8,6 +8,31 @@ memory: project
 
 You are an elite full-stack software engineer. You possess deep mastery across the entire software development stack. You are the agent that gets called when OpenSpec changes need to be applied — turning specifications into flawless, production-grade code.
 
+## Personality
+
+<!-- Customize this section in `.claude/agents/sr-developer.md` to change how this agent behaves.
+     All settings are optional — omitting them falls back to the defaults shown here. -->
+
+**tone**: `verbose`
+Controls response verbosity and level of inline explanation.
+- `terse` — emit only code and essential notes; skip rationale and elaboration
+- `verbose` — explain implementation decisions and architectural choices as you go (default)
+
+**risk_tolerance**: `conservative`
+How cautious to be when choosing implementation approaches and handling edge cases.
+- `conservative` — prefer battle-tested patterns, add defensive checks, flag unknowns before proceeding (default)
+- `aggressive` — favor concise, modern approaches; skip defensive boilerplate; move fast
+
+**detail_level**: `full`
+Granularity of implementation output and verification reports.
+- `summary` — show only changed files with a brief description of each change
+- `full` — show every file created or modified with complete implementation context (default)
+
+**focus_areas**: _(none — all areas equally weighted)_
+Comma-separated areas to prioritize when making implementation trade-offs.
+Examples: `security`, `performance`, `testing`, `accessibility`, `error-handling`, `type-safety`
+Leave empty to give equal weight to all areas.
+
 ## Your Identity & Expertise
 
 You are a polyglot engineer with extraordinary depth in:

package/templates/agents/sr-reviewer.md

@@ -8,6 +8,31 @@ memory: project
 
 You are a meticulous code reviewer and CI/CD quality gate. Your job is to catch every issue that would fail in the CI pipeline BEFORE pushing code. You run the exact same checks as CI, fix problems, and ensure the code is production-ready.
 
+## Personality
+
+<!-- Customize this section in `.claude/agents/sr-reviewer.md` to change how this agent behaves.
+     All settings are optional — omitting them falls back to the defaults shown here. -->
+
+**tone**: `terse`
+Controls verbosity of review output and issue descriptions.
+- `terse` — report findings concisely; one line per issue; skip elaboration (default)
+- `verbose` — explain every finding, its root cause, and the fix rationale in full
+
+**risk_tolerance**: `conservative`
+How strictly to apply quality and security standards.
+- `conservative` — flag all warnings, block on any security or correctness concern (default)
+- `aggressive` — block only on hard failures; treat warnings as advisory; allow ambiguous patterns through
+
+**detail_level**: `full`
+Granularity of the final review report.
+- `summary` — pass/fail table only; omit per-file findings and fixed-file lists
+- `full` — complete report with CI check table, issues fixed, layer findings, and modified files (default)
+
+**focus_areas**: _(none — all areas equally weighted)_
+Comma-separated areas to apply extra scrutiny during review.
+Examples: `security`, `performance`, `test-coverage`, `accessibility`, `sql-injection`, `types`
+Leave empty to review all areas with equal weight.
+
 ## Your Mission
 
 You are the last line of defense between developer output and a PR. You:

package/templates/commands/sr/implement.md

@@ -182,6 +182,65 @@ If neither pattern is found, print:
 
 This advisory is non-blocking and suppressed when `.gitignore` already covers the file.
 
+#### Pipeline state initialization
+
+Set `PIPELINE_STATE_PATH=.claude/pipeline-state/<feature-name>.json` (use the same kebab-case feature name derived above).
+
+Create the directory if it does not exist:
+
+```bash
+mkdir -p .claude/pipeline-state
+```
+
+Write the initial state file:
+
+```json
+{
+  "schema_version": "1",
+  "feature": "<feature-name>",
+  "started_at": "<current ISO 8601 timestamp>",
+  "updated_at": "<current ISO 8601 timestamp>",
+  "phases": {
+    "architect": "pending",
+    "developer": "pending",
+    "test-writer": "pending",
+    "doc-sync": "pending",
+    "reviewer": "pending",
+    "ship": "pending",
+    "ci": "pending"
+  },
+  "last_successful_phase": null,
+  "failed_phase": null,
+  "error_context": null,
+  "openspec_artifacts": "openspec/changes/<feature-name>/",
+  "implemented_files": [],
+  "input": {
+    "issues": [<issue numbers, or null for text-description mode>],
+    "flags": {
+      "dry_run": <DRY_RUN>,
+      "apply_mode": <APPLY_MODE>,
+      "single_mode": <SINGLE_MODE>
+    }
+  }
+}
+```
+
+If the write fails: print `[pipeline-state] Warning: could not write state file. Smart retry (/sr:retry) will not be available for this run.` Set `PIPELINE_STATE_AVAILABLE=false`. Do NOT abort the pipeline.
+
+If the write succeeds: set `PIPELINE_STATE_AVAILABLE=true`.
+
+**State update helper** — used by all subsequent phases to record progress:
+
+When a phase completes or fails, update `PIPELINE_STATE_PATH`:
+1. Read the current file.
+2. Set `phases.<phase-key>` to `"done"`, `"failed"`, or `"skipped"`.
+3. If `"done"`: set `last_successful_phase` to the phase key.
+4. If `"failed"`: set `failed_phase` to the phase key; set `error_context` to a one-line description of the failure (agent name, error type, exit code if known).
+5. Set `updated_at` to the current ISO 8601 timestamp.
+6. Overwrite the file.
+
+If `PIPELINE_STATE_AVAILABLE=false`: skip all state updates silently.
+
 **If the user passed area names**:
 - Check for open backlog issues. If found, filter and pick top 3.
 - If none, proceed to Phase 1.
@@ -331,6 +390,8 @@ Quick-check each architect's artifacts:
 3. File references are real (>70% must exist)
 4. Layer tags present on tasks
 
+**Pipeline state:** update `architect` → `done`. If any architect agent failed (skipped area): update `architect` → `failed` with error context `"sr-architect failed for: <area-names>"`.
+
 ## Phase 3b: Implement
 
 ### Pre-flight: Verify Bash permission
@@ -371,6 +432,8 @@ For each feature, analyze the tasks' layer tags:
 
 Wait for all developers to complete.
 
+**Pipeline state:** update `developer` → `done`. Also update `implemented_files` in the state file with the complete list of files created or modified by the developer agent(s). If developer failed: update `developer` → `failed` with error context `"sr-developer failed: <exit code or error description>"`.
+
 ## Phase 3c: Write Tests
 
 Launch a **sr-test-writer** agent for each feature immediately after its developer completes.
@@ -403,6 +466,8 @@ If a test-writer agent fails or times out:
 - Continue to Phase 4 — the sr-test-writer failure is non-blocking
 - Include in the reviewer agent prompt: "Note: the sr-test-writer failed for this feature. Check for coverage gaps."
 
+**Pipeline state:** update `test-writer` → `done` (or `failed` with error context `"sr-test-writer timed out or errored"`). Failure does not block the pipeline.
+
 ## Phase 3d: Doc Sync
 
 Launch a **sr-doc-sync** agent for each feature after its tests are written.
@@ -435,6 +500,8 @@ If a doc-sync agent fails or times out:
 - Continue to Phase 4 — the sr-doc-sync failure is non-blocking
 - Include in the reviewer agent prompt: "Note: the sr-doc-sync agent failed for this feature."
 
+**Pipeline state:** update `doc-sync` → `done` (or `failed` with error context `"sr-doc-sync timed out or errored"`). Failure does not block the pipeline.
+
 ## Phase 4: Merge & Review
 
 **This phase is fully autonomous.**
@@ -610,6 +677,8 @@ Note: if total layer report length is very large, truncate each layer report to
 
 Launch the **sr-reviewer** agent (foreground, `run_in_background: false`). Wait for it to complete.
 
+**Pipeline state:** update `reviewer` → `done` (or `failed` with error context `"sr-reviewer timed out or did not complete"` if the agent errored out).
+
 **If `DRY_RUN=true`**, add the following to the reviewer agent prompt:
 
 > Note: This is a dry-run review. Developer files are under .claude/.dry-run/\<feature-name\>/.
@@ -838,12 +907,16 @@ All implementation is complete and CI checks pass.
   | #71 / PROJ-71 | Partial progress | Comment: "X completed, Y remaining" |
   ```
 
+**Pipeline state:** update `ship` → `done` if git operations and PR creation succeeded, or `failed` with error context describing which step failed (e.g. `"git push failed: <exit code>"`, `"gh pr create failed"`, `"security gate blocked ship"`). If `DRY_RUN=true`: update `ship` → `skipped`.
+
 ### 4d. Monitor CI
 
 **Only if `GIT_AUTO=true` and code was pushed.**
 
 Check CI status after pushing. Fix failures (up to 2 retries).
 
+**Pipeline state:** update `ci` → `done` if CI passed, or `failed` with error context `"CI failed after 2 retries: <summary>"`. If CI was not run (`GIT_AUTO=false` or dry-run): update `ci` → `skipped`.
+
 If `GIT_AUTO=false`: skip — the user will push and monitor CI themselves.
 
 ### 4e. Report

package/templates/commands/sr/retry.md

@@ -0,0 +1,363 @@
+---
+name: "Smart Failure Recovery"
+description: "Resume a failed /sr:implement pipeline from the last successful phase without restarting from scratch."
+category: Workflow
+tags: [workflow, recovery, retry, resilience]
+phases:
+  - key: load
+    label: Load State
+    description: "Read pipeline state from disk and identify the resume point"
+  - key: resume
+    label: Resume
+    description: "Execute remaining phases starting from the failed phase"
+  - key: report
+    label: Report
+    description: "Print a final status report with outcomes and next steps"
+---
+
+Resume a failed `/sr:implement` run for **{{PROJECT_NAME}}**. Reads pipeline state written by the implement pipeline to identify which phases completed and which failed, then re-executes only the remaining phases.
+
+**MANDATORY: Follow this pipeline exactly. Do NOT skip phases or re-run phases that already succeeded. Read all context from the pipeline state file — do not rely on memory. Do not re-implement anything yourself; delegate to the same agents used by `/sr:implement`.**
+
+**Input:** $ARGUMENTS — accepted forms:
+
+1. `<feature-name>` — kebab-case feature name matching a `.claude/pipeline-state/<feature-name>.json` file
+2. `--list` — list all available pipeline state files and their current status, then exit
+3. `<feature-name> --from <phase>` — force resume from a specific phase (overrides auto-detection)
+4. `<feature-name> --dry-run` — override to resume in dry-run mode (no git/PR operations)
+
+---
+
+## Phase 0: Parse Input
+
+Scan `$ARGUMENTS` for flags:
+
+- `--list`: if present, set `LIST_ONLY=true`.
+- `--from <phase>`: if present, set `RESUME_FROM_OVERRIDE=<phase>`. Valid values: `architect`, `developer`, `test-writer`, `doc-sync`, `reviewer`, `ship`, `ci`.
+- `--dry-run`: if present, set `DRY_RUN_OVERRIDE=true`.
+
+Extract the first positional argument (not starting with `--`) as `FEATURE_NAME`.
+
+**If `--list`:** scan `.claude/pipeline-state/*.json`. For each file found, parse and print:
+
+```
+## Available Pipeline States
+
+| Feature | Last Successful Phase | Failed Phase | Updated At |
+|---------|----------------------|--------------|------------|
+| <name>  | <phase or —>         | <phase or —> | <ISO time> |
+```
+
+If no files found: print `No pipeline state files found. Run /sr:implement first.`
+
+Exit after printing — do not proceed.
+
+**If no positional argument and no `--list`:** print the following usage and exit:
+
+```
+Usage: /sr:retry <feature-name> [--from <phase>] [--dry-run]
+       /sr:retry --list
+
+Phases: architect | developer | test-writer | doc-sync | reviewer | ship | ci
+```
+
+---
+
+## Phase 1: Load Pipeline State
+
+Read: `.claude/pipeline-state/<FEATURE_NAME>.json`
+
+If the file does not exist:
+
+```
+[retry] Error: no pipeline state found for "<FEATURE_NAME>".
+
+Run /sr:retry --list to see available states, or start a new run:
+  /sr:implement <your input>
+```
+
+Exit.
+
+Parse the state file and set the following variables:
+
+- `LAST_SUCCESSFUL_PHASE` ← `last_successful_phase` (may be `null`)
+- `FAILED_PHASE` ← `failed_phase` (may be `null`)
+- `ERROR_CONTEXT` ← `error_context` (may be `null`)
+- `OPENSPEC_ARTIFACTS` ← `openspec_artifacts` (e.g. `openspec/changes/<name>/`)
+- `IMPLEMENTED_FILES` ← `implemented_files` (array, may be empty)
+- `ORIGINAL_ISSUES` ← `input.issues` (array of issue numbers, may be `null`)
+- `ORIGINAL_INPUT_FLAGS` ← `input.flags` object
+- `SINGLE_MODE` ← `input.flags.single_mode` (default `true`)
+- `DRY_RUN` ← if `DRY_RUN_OVERRIDE=true` then `true`, else `input.flags.dry_run` (default `false`)
+- `PHASE_STATUSES` ← `phases` map (`architect`, `developer`, `test-writer`, `doc-sync`, `reviewer`, `ship`, `ci` → `"done"`, `"failed"`, `"skipped"`, or `"pending"`)
+
+**Validation:**
+
+- If all phases are `"pending"`: the pipeline never reached any execution. Print:
+  ```
+  [retry] Warning: all phases are pending — the pipeline may not have started.
+  Recommend running /sr:implement instead.
+  ```
+  Prompt: `Proceed anyway? [y/N]`. If `n` or no response: exit.
+
+---
+
+## Phase 2: Status Report
+
+Print the pipeline status:
+
+```
+## Pipeline State: <FEATURE_NAME>
+
+| Phase        | Status  | Notes                              |
+|--------------|---------|-------------------------------------|
+| architect    | done    |                                     |
+| developer    | done    |                                     |
+| test-writer  | FAILED  | <ERROR_CONTEXT or "no details">     |
+| doc-sync     | pending |                                     |
+| reviewer     | pending |                                     |
+| ship         | pending |                                     |
+| ci           | pending |                                     |
+
+Last successful phase : <LAST_SUCCESSFUL_PHASE or "none">
+Failed phase          : <FAILED_PHASE or "—">
+Error context         : <ERROR_CONTEXT or "no details recorded">
+OpenSpec artifacts    : <OPENSPEC_ARTIFACTS>
+Implemented files     : <count> file(s) tracked
+Original input        : <issues list or "text description">
+```
+
+---
+
+## Phase 3: Determine Resume Point
+
+**Phase execution order (canonical):**
+
+```
+architect → developer → test-writer → doc-sync → reviewer → ship → ci
+```
+
+**If `RESUME_FROM_OVERRIDE` is set:** use it as `RESUME_PHASE`. Validate it is one of the canonical values; if not, print an error and exit.
+
+**Otherwise, auto-detect:**
+
+1. If `FAILED_PHASE` is set: `RESUME_PHASE = FAILED_PHASE`.
+2. Else if `LAST_SUCCESSFUL_PHASE` is set: `RESUME_PHASE` = the next phase after `LAST_SUCCESSFUL_PHASE` in canonical order.
+3. Else: `RESUME_PHASE = architect` (no phases completed).
+
+Print the resume plan:
+
+```
+## Resume Plan
+
+Resuming from phase: <RESUME_PHASE>
+
+Phases to skip (already done):
+  ✓ <phase>   (done)
+  ✓ <phase>   (done)
+
+Phases to execute:
+  ► <RESUME_PHASE>    (resuming here)
+  · <next-phase>
+  · <next-phase>
+  ...
+```
+
+Prompt the user:
+
+```
+Proceed? [Y/n]
+```
+
+If `n` or no response: exit without changes.
+
+---
+
+## Phase 4: Execute Remaining Phases
+
+Execute phases in canonical order starting from `RESUME_PHASE`. For each phase:
+
+- If its status in `PHASE_STATUSES` is `"done"` AND it precedes `RESUME_PHASE` in canonical order: **skip** — do not re-run.
+- If it equals `RESUME_PHASE` or comes after: **run** it.
+
+After each phase completes (or fails), update `.claude/pipeline-state/<FEATURE_NAME>.json`:
+1. Read the current file.
+2. Set `phases.<phase-key>` to `"done"` or `"failed"`.
+3. If `"done"`: update `last_successful_phase`.
+4. If `"failed"`: update `failed_phase` and `error_context`.
+5. Update `updated_at` to current ISO 8601 timestamp.
+6. Overwrite the file.
+
+---
+
+### 4a. Phase: architect
+
+**Only runs if `RESUME_PHASE=architect`.**
+
+Verify that `ORIGINAL_ISSUES` is non-empty or a text description is recoverable. If neither is available: print an error and stop — the original input is required to re-run the architect.
+
+Launch **sr-architect** agent(s) exactly as described in Phase 3a of the implement pipeline. Pass:
+- Original issue numbers from `ORIGINAL_ISSUES` (or text description if stored in state)
+- Same OpenSpec output directory: `OPENSPEC_ARTIFACTS`
+
+Wait for all architects to complete.
+
+**Pipeline state update:** `architect` → `done` or `failed`.
+
+---
+
+### 4b. Phase: developer
+
+**Runs if `RESUME_PHASE` is `architect` or `developer`.**
+
+Before launching, verify architect artifacts exist:
+
+```bash
+ls <OPENSPEC_ARTIFACTS>tasks.md <OPENSPEC_ARTIFACTS>context-bundle.md
+```
+
+If missing and `RESUME_PHASE=developer`: print:
+
+```
+[retry] Error: architect artifacts not found at <OPENSPEC_ARTIFACTS>.
+Retry from the architect phase: /sr:retry <FEATURE_NAME> --from architect
+```
+
+Stop.
+
+Launch **sr-developer** agent(s) exactly as described in Phase 3b of the implement pipeline.
+
+- If `SINGLE_MODE=true`: launch in main repo, foreground.
+- If `SINGLE_MODE=false`: launch in isolated worktrees, background.
+- If `DRY_RUN=true`: use the dry-run redirect instructions from Phase 3b.
+
+Wait for all developers to complete. Collect the list of files created or modified.
+
+**Pipeline state update:** `developer` → `done` (also update `implemented_files` in state with the collected file list) or `failed`.
+
+---
+
+### 4c. Phase: test-writer
+
+**Runs if `RESUME_PHASE` is `architect`, `developer`, or `test-writer`.**
+
+If `IMPLEMENTED_FILES` is empty: warn but continue — the sr-test-writer will discover files from git diff.
+
+Launch **sr-test-writer** agent(s) exactly as in Phase 3c of the implement pipeline. Pass:
+- `IMPLEMENTED_FILES_LIST`: the `implemented_files` array from state
+- `TASK_DESCRIPTION`: derived from `ORIGINAL_ISSUES` or architect artifacts
+
+Wait for completion. Failure is **non-blocking** — record `FAILED` and continue to next phase.
+
+**Pipeline state update:** `test-writer` → `done` or `failed`.
+
+---
+
+### 4d. Phase: doc-sync
+
+**Runs if `RESUME_PHASE` is any phase up to and including `doc-sync`.**
+
+Launch **sr-doc-sync** agent(s) exactly as in Phase 3d of the implement pipeline. Pass:
+- `IMPLEMENTED_FILES_LIST`: the `implemented_files` array from state
+- `TASK_DESCRIPTION`: derived from `ORIGINAL_ISSUES` or architect artifacts
+
+Wait for completion. Failure is **non-blocking** — record `FAILED` and continue.
+
+**Pipeline state update:** `doc-sync` → `done` or `failed`.
+
+---
+
+### 4e. Phase: reviewer
+
+**Runs if `RESUME_PHASE` is any phase up to and including `reviewer`.**
+
+Launch layer reviewers and the generalist sr-reviewer exactly as in Phase 4b of the implement pipeline. Pass:
+- `MODIFIED_FILES_LIST`: the `implemented_files` array from state
+- `PIPELINE_CONTEXT`: brief description from original input and issue titles
+- Layer reports from sr-frontend-reviewer, sr-backend-reviewer, sr-security-reviewer
+
+Wait for all to complete. Parse `SECURITY_BLOCKED`, `FRONTEND_STATUS`, `BACKEND_STATUS`.
+
+**Run the Confidence Gate (Phase 4b-conf)** exactly as defined in the implement pipeline.
+
+**Pipeline state update:** `reviewer` → `done` or `failed`.
+
+---
+
+### 4f. Phase: ship
+
+**Runs if `RESUME_PHASE` is `ship` or `ci`.**
+
+If `DRY_RUN=true`: skip git operations. Record skipped operations, print dry-run summary, proceed to Phase 5.
+
+Otherwise, run Phase 4c (ship) of the implement pipeline exactly as defined:
+- Security gate check (`SECURITY_BLOCKED`)
+- Conflict pre-check (Phase 4c.0)
+- Git branch creation, commit, push, PR creation
+- Backlog updates
+
+**Pipeline state update:** `ship` → `done` or `failed`.
+
+---
+
+### 4g. Phase: ci
+
+**Runs if ship succeeded and code was pushed.**
+
+Run Phase 4d (CI monitoring) of the implement pipeline exactly as defined. Check CI status, fix failures (up to 2 retries).
+
+**Pipeline state update:** `ci` → `done` or `failed`.
+
+---
+
+## Phase 5: Report
+
+Print the final report:
+
+```
+## Retry Complete: <FEATURE_NAME>
+
+Resumed from: <RESUME_PHASE>
+Phases executed this run: <comma-separated list>
+
+| Phase        | Status  |
+|--------------|---------|
+| architect    | done    |
+| developer    | done    |
+| test-writer  | done    |
+| doc-sync     | done    |
+| reviewer     | done    |
+| ship         | done    |
+| ci           | done    |
+```
+
+Include PR URL if ship ran successfully.
+
+**If any phase failed**, add:
+
+```
+## Failures
+
+| Phase       | Error Context          |
+|-------------|------------------------|
+| <phase>     | <error_context>        |
+
+Next steps:
+- To retry from the failed phase: /sr:retry <FEATURE_NAME> --from <failed-phase>
+- To see all pipeline states: /sr:retry --list
+- To restart from scratch: /sr:implement <original-input>
+```
+
+---
+
+## Error Handling
+
+| Phase | Blocking? | On failure |
+|-------|-----------|------------|
+| architect | **Yes** | Stop — cannot proceed without OpenSpec artifacts |
+| developer | **Yes** | Stop — cannot proceed without implemented files |
+| test-writer | No | Record FAILED, continue to doc-sync |
+| doc-sync | No | Record FAILED, continue to reviewer |
+| reviewer | No | Report findings, continue to ship |
+| ship | **Yes** | Stop — report failure with git/PR context |
+| ci | **Yes** | Stop — report failure with CI log and fix suggestions |