specrails-core 4.12.0 → 5.0.0

package/templates/commands/specrails/propose-spec.md

@@ -66,7 +66,7 @@ Set the following fields:
 - `priority`: Map Estimated Complexity — Low → `"low"`, Medium → `"medium"`, High/Very High → `"high"`
 - `labels`: `["spec-proposal"]`
 - `source`: `"propose-spec"`
-- `created_by`: `"sr-product-engineer"`
+- `created_by`: `"sr-architect"`
 
 Print: `Created local ticket #{id}: {title}`
 

package/templates/commands/specrails/refactor-recommender.md

@@ -1,11 +1,11 @@
 ---
 name: "Refactor Recommender"
-description: "Scan the codebase for refactoring opportunities ranked by impact/effort ratio and VPC persona value. Analyzes code for duplicates, long functions, large files, dead code, outdated patterns, and complex logic. Optionally creates GitHub Issues for tracking."
+description: "Scan the codebase for refactoring opportunities ranked by impact/effort ratio. Analyzes code for duplicates, long functions, large files, dead code, outdated patterns, and complex logic. Optionally creates GitHub Issues for tracking."
 category: Workflow
-tags: [workflow, refactoring, code-quality, tech-debt, vpc]
+tags: [workflow, refactoring, code-quality, tech-debt]
 ---
 
-Scan the codebase for refactoring opportunities, score each by impact/effort ratio and VPC persona value, and optionally create GitHub Issues for the top findings in {{BACKLOG_PROVIDER_NAME}}.
+Scan the codebase for refactoring opportunities, score each by impact/effort ratio, and optionally create GitHub Issues for the top findings in {{BACKLOG_PROVIDER_NAME}}.
 
 **Input:** `$ARGUMENTS` — optional: comma-separated paths to scope the analysis. Flags: `--dry-run` (print findings without creating issues).
 
@@ -38,27 +38,6 @@ Always exclude the following from all analysis:
 
 ---
 
-## Phase 1.5: VPC Context
-
-Check whether persona files exist at `.claude/agents/personas/`. This path is present in any repo that has run `/specrails:enrich`.
-
-```bash
-ls .claude/agents/personas/ 2>/dev/null
-```
-
-If the directory exists and contains persona files, set `VPC_AVAILABLE=true`. Otherwise set `VPC_AVAILABLE=false` and skip all VPC steps (they are optional enrichment, not blockers).
-
-When `VPC_AVAILABLE=true`, read each persona file and extract a compact VPC summary. For each persona record:
-
-- **name** — persona display name (e.g. "Alex — The Lead Dev")
-- **top_jobs** — up to 3 functional jobs relevant to code quality and maintainability
-- **critical_pains** — up to 3 pains marked Critical or High related to code reliability, complexity, or developer experience
-- **high_gains** — up to 3 gains marked High related to code clarity, speed, or confidence
-
-Store these as an in-memory `VPC_PROFILES` list. You will use it in Phase 3 to score persona fit.
-
----
-
 ## Phase 2: Analysis
 
 Analyze the scoped files across six categories. For each finding record:
@@ -97,24 +76,12 @@ Find deeply nested conditionals (more than 3 levels) and functions with high cyc
 
 ## Phase 3: Score and Rank
 
-Score every finding on three dimensions (1–5 each):
+Score every finding on two dimensions (1–5 each):
 
 - **Impact** — how much the refactoring improves code quality, readability, or maintainability
 - **Effort** — how hard the refactoring is to implement (1 = trivial, 5 = major)
-- **VPC Value** — how directly this refactoring addresses persona jobs, pains, or gains (1 = no relevance, 5 = resolves a critical persona pain or delivers a high-value gain). Set to 3 when `VPC_AVAILABLE=false`.
-
-**Scoring VPC Value** (only when `VPC_AVAILABLE=true`):
-
-For each finding, reason over `VPC_PROFILES`:
 
-- Does fixing this reduce a **Critical/High pain** for any persona? (e.g. complex logic → harder to trust AI output → Alex's "agents go off the rails" pain) → score 4–5
-- Does fixing this deliver a **High gain** for any persona? (e.g. extracting a function → cleaner API surface → easier onboarding → Sara's gain) → score 3–4
-- Is there indirect persona value? (e.g. dead code removal → smaller codebase → easier contributor review → Kai) → score 2–3
-- No clear persona relevance → score 1–2
-
-Assign one `vpc_value` integer per finding, and note the **primary persona** and **rationale** (one sentence).
-
-**Composite score**: `impact * 2 + (6 - effort) + vpc_value`. Higher is better.
+**Composite score**: `impact * 2 + (6 - effort)`. Higher is better.
 
 Sort all findings by composite score descending. If the same code block was flagged by multiple categories, keep only the highest-scored entry and discard the duplicates.
 
@@ -144,7 +111,6 @@ For each of the **top 5** findings (by composite score) that does not already ha
 **Category**: {category}
 **File**: {file}:{line_range}
 **Impact**: {impact}/5 | **Effort**: {effort}/5 | **Score**: {composite}
-{vpc_line}
 
 ### Current Code
 ```{lang}
@@ -163,9 +129,6 @@ For each of the **top 5** findings (by composite score) that does not already ha
 _Generated by `/specrails:refactor-recommender` in {{PROJECT_NAME}}_
 ```
 
-Where `{vpc_line}` is included only when `VPC_AVAILABLE=true`:
-`**VPC Value**: {vpc_value}/5 — {vpc_persona}: {vpc_rationale}`
-
 ---
 
 ## Phase 5: Output Summary
@@ -176,11 +139,10 @@ Print the following report:
 ## Refactoring Opportunities — {{PROJECT_NAME}}
 
 {N} opportunities found | Sorted by composite score
-{vpc_header}
 
-| # | Category | File | Impact | Effort | VPC | Score | Description |
-|---|----------|------|--------|--------|-----|-------|-------------|
-| 1 | {category} | {file}:{line_range} | {impact}/5 | {effort}/5 | {vpc_value}/5 | {composite} | {description} |
+| # | Category | File | Impact | Effort | Score | Description |
+|---|----------|------|--------|--------|-------|-------------|
+| 1 | {category} | {file}:{line_range} | {impact}/5 | {effort}/5 | {composite} | {description} |
 ...
 
 ### Top 3 Detailed Recommendations
@@ -188,7 +150,6 @@ Print the following report:
 #### 1. {description}
 **File**: {file}:{line_range}
 **Category**: {category} | **Score**: {composite}
-{vpc_detail}
 
 **Current:**
 ```{lang}
@@ -206,7 +167,3 @@ Print the following report:
 
 Issues created: {N}  (or "dry-run: no issues created")
 ```
-
-Where:
-- `{vpc_header}` is `VPC personas loaded: {persona names}` when `VPC_AVAILABLE=true`, or `VPC personas: not found (run /specrails:enrich to enable)` otherwise.
-- `{vpc_detail}` is `**VPC Value**: {vpc_value}/5 — {vpc_persona}: {vpc_rationale}` when `VPC_AVAILABLE=true`, omitted otherwise.

package/templates/commands/specrails/retry.md

@@ -35,7 +35,7 @@ Resume a failed `/specrails:implement` run for **{{PROJECT_NAME}}**. Reads pipel
 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`.
+- `--from <phase>`: if present, set `RESUME_FROM_OVERRIDE=<phase>`. Valid values: `architect`, `developer`, `reviewer`, `ship`, `ci`.
 - `--dry-run`: if present, set `DRY_RUN_OVERRIDE=true`.
 
 Extract the first positional argument (not starting with `--`) as `FEATURE_NAME`.
@@ -60,7 +60,7 @@ Exit after printing — do not proceed.
 Usage: /specrails:retry <feature-name> [--from <phase>] [--dry-run]
        /specrails:retry --list
 
-Phases: architect | developer | test-writer | doc-sync | reviewer | ship | ci
+Phases: architect | developer | reviewer | ship | ci
 ```
 
 ---
@@ -91,7 +91,7 @@ Parse the state file and set the following variables:
 - `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"`)
+- `PHASE_STATUSES` ← `phases` map (`architect`, `developer`, `reviewer`, `ship`, `ci` → `"done"`, `"failed"`, `"skipped"`, or `"pending"`)
 
 **Validation:**
 
@@ -114,9 +114,7 @@ Print the pipeline status:
 | Phase        | Status  | Notes                              |
 |--------------|---------|-------------------------------------|
 | architect    | done    |                                     |
-| developer    | done    |                                     |
-| test-writer  | FAILED  | <ERROR_CONTEXT or "no details">     |
-| doc-sync     | pending |                                     |
+| developer    | FAILED  | <ERROR_CONTEXT or "no details">     |
 | reviewer     | pending |                                     |
 | ship         | pending |                                     |
 | ci           | pending |                                     |
@@ -136,7 +134,7 @@ Original input        : <issues list or "text description">
 **Phase execution order (canonical):**
 
 ```
-architect → developer → test-writer → doc-sync → reviewer → ship → ci
+architect → developer → 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.
@@ -179,7 +177,7 @@ If `n` or no response: exit without changes.
 
 Execute phases in canonical order starting from `RESUME_PHASE`. For each phase:
 
-- If its status in `PHASE_STATUSES` is `"skipped"`: **skip** — the agent was not installed at the original run (e.g. an optional sr-test-writer / sr-doc-sync). Never launch a phase that was skipped, regardless of its position relative to `RESUME_PHASE`.
+- If its status in `PHASE_STATUSES` is `"skipped"`: **skip** — it was not run at the original invocation. Never launch a phase that was skipped, regardless of its position relative to `RESUME_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 (and is not `"skipped"`): **run** it.
 
@@ -240,46 +238,16 @@ Wait for all developers to complete. Collect the list of files created or modifi
 
 ---
 
-### 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
+### 4c. 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:
+Launch the single **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
+- The security-exemptions config path (`.claude/security-exemptions.yaml`) if present
 
-Wait for all to complete. Parse `SECURITY_BLOCKED`, `FRONTEND_STATUS`, `BACKEND_STATUS`.
+Wait for it to complete. Parse `SECURITY_BLOCKED` from the reviewer's `SECURITY_STATUS` line.
 
 **Run the Confidence Gate (Phase 4b-conf)** exactly as defined in the implement pipeline.
 
@@ -287,7 +255,7 @@ Wait for all to complete. Parse `SECURITY_BLOCKED`, `FRONTEND_STATUS`, `BACKEND_
 
 ---
 
-### 4f. Phase: ship
+### 4d. Phase: ship
 
 **Runs if `RESUME_PHASE` is `ship` or `ci`.**
 
@@ -303,7 +271,7 @@ Otherwise, run Phase 4c (ship) of the implement pipeline exactly as defined:
 
 ---
 
-### 4g. Phase: ci
+### 4e. Phase: ci
 
 **Runs if ship succeeded and code was pushed.**
 
@@ -327,8 +295,6 @@ Phases executed this run: <comma-separated list>
 |--------------|---------|
 | architect    | done    |
 | developer    | done    |
-| test-writer  | done    |
-| doc-sync     | done    |
 | reviewer     | done    |
 | ship         | done    |
 | ci           | done    |
@@ -359,8 +325,6 @@ Next steps:
 |-------|-----------|------------|
 | 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 |

package/templates/commands/specrails/telemetry.md

@@ -153,7 +153,7 @@ A valid telemetry record has the following structure (fields may be absent — t
 - Infer `agent` name from:
   1. The `agent` field directly (if present).
   2. The source log file path (if the path contains `sr-<name>`, extract it).
-  3. A `system_prompt` field snippet (if present): match against known agent persona names (`sr-architect`, `sr-developer`, `sr-test-writer`, `sr-reviewer`, `sr-security-reviewer`, `sr-doc-sync`, `sr-product-analyst`, `sr-product-manager`).
+  3. A `system_prompt` field snippet (if present): match against known agent names (`sr-architect`, `sr-developer`, `sr-reviewer`) or any `custom-*` agent declared by an active profile.
   4. If agent cannot be determined: assign to the bucket `"unknown"`.
 - Apply time filter: if `PERIOD_START` is not null, skip records where `timestamp < PERIOD_START`.
 - If `AGENT_FILTER` is set, skip records where the resolved agent name does not match.

package/templates/gemini-commands/implement.toml

@@ -72,6 +72,15 @@ The change is archived BY THE REVIEWER as part of a passing review — never by
    (`openspec validate <id> --strict`).
    Apply the outcome rules above.
 
+   **Design confidence gate.** Read
+   `${SPECRAILS_REPO_DIR:-.}/openspec/changes/<id>/design-confidence.json`
+   (written by the architect). Missing → warn and proceed (backward
+   compatible). `high`/`medium` → proceed. `low` → STOP before phase 2 and
+   report `BLOCKED: design confidence low — <blocking_question>`; tell the
+   user to answer the question in the ticket and re-run. Do NOT update the
+   ticket, do NOT invoke the developer — implementation must never run on a
+   design the architect does not trust.
+
 2. **APPLY — `invoke_agent` `sr-developer`.** Only after the architect reports
    back. It implements the tasks in TDD order and checks them off in `tasks.md`.
    Apply the outcome rules — on `MAX_TURNS`, re-invoke to RESUME until every task

package/templates/profiles/default.json

@@ -1,27 +1,14 @@
 {
   "schemaVersion": 1,
   "name": "default",
-  "description": "Baseline profile equivalent to pre-4.1.0 legacy behavior: full chain, per-agent models matching the shipped agent frontmatters, and legacy routing rules.",
+  "description": "Baseline profile: the three core agents (sr-architect, sr-developer, sr-reviewer) with the models matching their shipped frontmatters. Extend by adding user-owned custom-* agents and routing rules.",
   "orchestrator": { "model": "sonnet" },
   "agents": [
-    { "id": "sr-product-manager",     "model": "opus" },
-    { "id": "sr-product-analyst",     "model": "haiku" },
-    { "id": "sr-architect",           "model": "sonnet", "required": true },
-    { "id": "sr-developer",           "model": "sonnet", "required": true },
-    { "id": "sr-frontend-developer",  "model": "sonnet" },
-    { "id": "sr-backend-developer",   "model": "sonnet" },
-    { "id": "sr-test-writer",         "model": "sonnet" },
-    { "id": "sr-doc-sync",            "model": "sonnet" },
-    { "id": "sr-merge-resolver",      "model": "sonnet" },
-    { "id": "sr-reviewer",            "model": "sonnet", "required": true },
-    { "id": "sr-frontend-reviewer",   "model": "sonnet" },
-    { "id": "sr-backend-reviewer",    "model": "sonnet" },
-    { "id": "sr-security-reviewer",   "model": "sonnet" },
-    { "id": "sr-performance-reviewer","model": "sonnet" }
+    { "id": "sr-architect", "model": "sonnet", "required": true },
+    { "id": "sr-developer", "model": "sonnet", "required": true },
+    { "id": "sr-reviewer",  "model": "sonnet", "required": true }
   ],
   "routing": [
-    { "tags": ["frontend"],          "agent": "sr-frontend-developer" },
-    { "tags": ["backend"],           "agent": "sr-backend-developer" },
-    { "default": true,               "agent": "sr-developer" }
+    { "default": true, "agent": "sr-developer" }
   ]
 }