specrails-core 4.12.1 → 5.1.0

package/templates/commands/specrails/memory-inspect.md

@@ -122,12 +122,14 @@ If `AGENT_FILTER` is set (single-agent mode), show the full content of each file
 
 ## Phase 4: Orphan Detection
 
-An **orphaned** memory directory is one whose agent name does not correspond to a known sr-agent persona.
+An **orphaned** memory directory is one whose agent name does not correspond to a known agent.
 
-Known sr-agent names (check for exact match):
-`sr-architect`, `sr-developer`, `sr-test-writer`, `sr-reviewer`, `sr-frontend-reviewer`, `sr-backend-reviewer`, `sr-security-reviewer`, `sr-doc-sync`, `sr-product-manager`
+Known agent names (check for exact match):
+`sr-architect`, `sr-developer`, `sr-reviewer`
 
-For each directory in `AGENT_DIRS`, check whether its `AGENT_NAME` is in the known list. Collect non-matching directories as `ORPHANED_DIRS`.
+Any directory whose name begins with `custom-` is a user- or profile-owned agent and is **never** orphaned — treat the `custom-` prefix as known.
+
+For each directory in `AGENT_DIRS`, check whether its `AGENT_NAME` is in the known list (or carries the `custom-` prefix). Collect non-matching directories as `ORPHANED_DIRS`.
 
 If `ORPHANED_DIRS` is non-empty, print:
 

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

@@ -1,366 +1,38 @@
----
-name: "Smart Failure Recovery"
-description: "Resume a failed /specrails: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"
----
+# Retry an Implementation Pipeline
 
-Resume a failed `/specrails: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.
+**Input:** $ARGUMENTS — existing change and optional --from <phase>.
 
-**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 `/specrails:implement`.**
+## Resolve the exact run
 
-**Repository location.** Your working directory may NOT be the user's source repository. Repo-resident things — `openspec/**`, source, `.git`, the GitHub remote — live under **`${SPECRAILS_REPO_DIR:-.}`** (set by the spawner; unset ⇒ `.` ⇒ byte-identical to a classic in-repo run). The pipeline-state file itself is **run-state**, read from `.claude/pipeline-state/` relative to the working directory — do NOT prefix it. The `openspec_artifacts` value stored in that file is a repo-relative path (`openspec/changes/<name>/`); prefix it with `${SPECRAILS_REPO_DIR:-.}/` when you read those files on disk. All git/PR operations are delegated to `/specrails:implement` Phase 4c, which already runs them against the repo.
-
-**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 /specrails:implement first.`
-
-Exit after printing — do not proceed.
-
-**If no positional argument and no `--list`:** print the following usage and exit:
-
-```
-Usage: /specrails:retry <feature-name> [--from <phase>] [--dry-run]
-       /specrails: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 /specrails:retry --list to see available states, or start a new run:
-  /specrails: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 /specrails: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 `"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 `"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.
-
-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:
+Use the same absolute SPECRAILS_PIPELINE_RUNTIME and SPECRAILS_EXECUTION_CONTEXT. The managed fallback is .specrails/runtime/pipeline.mjs; the standalone workspace pointer is only discovery. Do not initialize another run, choose the newest change, replace frozen tickets from mutable backlog, or trust old ad-hoc pipeline state.
 
 ```bash
-ls "${SPECRAILS_REPO_DIR:-.}/<OPENSPEC_ARTIFACTS>tasks.md" "${SPECRAILS_REPO_DIR:-.}/<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: /specrails:retry <FEATURE_NAME> --from architect
+node "${SPECRAILS_PIPELINE_RUNTIME:-.specrails/runtime/pipeline.mjs}" status --json
 ```
 
-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`.**
+Verify runId/change match. Preserve context.specs, selected roots, backlog identity and ownership. The artifact compatibility root is `${SPECRAILS_REPO_DIR:-.}`, not necessarily the framework workspace.
 
-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
+## Resume earliest invalid evidence
 
-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:
+Follow resumePhase and receipt reasons. Completed valid phases require no model call. Blocked/failed is resumable; never convert dependent implementation into skipped. Explicit --from can reopen an earlier phase, but runtime prerequisite checks still apply.
 
+```bash
+node "${SPECRAILS_PIPELINE_RUNTIME:-.specrails/runtime/pipeline.mjs}" phase --phase <phase> --status running
 ```
-## Failures
 
-| Phase       | Error Context          |
-|-------------|------------------------|
-| <phase>     | <error_context>        |
+| Phase | Resume action |
+|-------|---------------|
+| architect | Repair official design artifacts/confidence; unblock development only after actual gate passes. |
+| developer | Continue unchecked tasks, retain completed code; scoped repairs followed by one full receipt. |
+| reviewer | Review acceptance/confidence; reuse current full evidence, refresh after edits. Do not redo valid architecture because review was blocked. |
+| archive | Fresh archive-check, then authorized official archive/sync only; preserve approved confidence bytes. |
+| ship | Only Core-owned and authorized; resume missing repository delivery without duplicating successful commits/PRs. |
+| ci | Check existing delivery; never reship merely because CI needs retry. |
 
-Next steps:
-- To retry from the failed phase: /specrails:retry <FEATURE_NAME> --from <failed-phase>
-- To see all pipeline states: /specrails:retry --list
-- To restart from scratch: /specrails:implement <original-input>
-```
+Only host-owned ship/ci may skip. Actual done clears old reason; failed/blocked records concrete remaining work. Reopening invalidates dependent completion.
 
----
+## Evidence and report
 
-## Error Handling
+Use the implement contracts for command receipts, foreground worker completion and exact repository routing. Receipt validity plus required command coverage permits reuse; baseline-only or stale evidence does not. Preview apply must check base/cache and execute checks on actual applied source.
 
-| 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 |
+Confidence, acceptance and archive approval precede delivery. Preserve host-owned Git/worktrees/backlog. Return current state, reused/new evidence and per-repository outcomes. If all phases remain valid, report completion without rerunning.

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/batch-implement.toml

@@ -1,43 +1,31 @@
-description = "Batch Implementation Orchestrator — runs the implement pipeline over multiple tickets, headless."
+description = "Aggregate batch implementation with one durable journal and final candidate gates."
 
 prompt = '''
-You are the **batch-implement orchestrator**. The user invoked you to apply the
-implement pipeline to multiple tickets in one session. This is fully headless /
-non-interactive — every phase runs with `--yes` semantics.
-
-How the user invokes you:
-- `/specrails:batch-implement #1 #2 #3 --yes` — sequential.
-- `/specrails:batch-implement --status todo` — every todo ticket, ascending id.
-- `/specrails:batch-implement #1 #2 --parallel` — opt-in parallel, only when the
-  tickets touch disjoint files (run a safety check first; fall back to sequential).
-
-## Desktop rail execution context
-
-When the working directory is a specrails-desktop isolated rail worktree (path contains `/worktrees/`, typically on a `feat/...` branch), you are the ASSIGNED executor of that rail: implement every ticket sequentially in THIS worktree on THIS branch — the desktop assembles it into a batch PR afterwards, nothing needs to land on the integration branch first. The desktop's own bookkeeping (ticket-ownership rows in its `jobs.sqlite`, state under `~/.specrails/`) describes this very launch — never read those internals, and never stop to ask which process should run the batch.
-
-## Why this drives the spawns at the ROOT level
-
-Do NOT delegate to a nested `/specrails:implement` subagent per ticket that then
-delegates to architect/developer/reviewer. Subagents are FLAT — a subagent
-cannot invoke another subagent (and nested depth-2 delegation is unreliable,
-silently dropping the reviewer phase). Instead, YOU (the root orchestrator) drive
-the three `invoke_agent` calls — `sr-architect`, `sr-developer`, `sr-reviewer` —
-directly, at depth 1, per ticket. Three real subagent calls per ticket, no
-nesting. The same delegation contract as `/specrails:implement` applies: every
-phase MUST be a real `invoke_agent` call; never inline the work.
-
-## Steps
-
-0. **Bootstrap.** Confirm `pwd` is the git repo root. Resolve the ticket list
-   (explicit ids, or `--status`/`--priority` filters over `.specrails/local-tickets.json`).
-
-1. **Per ticket, in order, run the three-phase pipeline at depth 1:**
-   a. `invoke_agent` `sr-architect` → creates + validates the OpenSpec change.
-      If `BLOCKED`, record the failure and move to the next ticket.
-   b. `invoke_agent` `sr-developer` → applies the change (implements + checks off tasks).
-   c. `invoke_agent` `sr-reviewer` → validates; on pass, `openspec archive <id> -y`.
-   d. Update the ticket to `done` (or record the failure verdict).
-
-2. **Aggregate.** After all tickets, report a single table: ticket, change id,
-   verdict (done / blocked / failed), with a one-line reason for non-done ones.
+Resolve all target IDs or filters and freeze their complete descriptions,
+acceptance criteria and repository IDs. With a host context preserve context.specs
+unchanged. Resolve source/artifact/backlog roots explicitly; cwd can be external.
+
+Initialize ONE aggregate OpenSpec change and journal for this runId. Never create
+per-ticket child changes/journals with the same context. Read
+`.gemini/commands/specrails/implement.toml` and apply its capability preflight,
+explicit invoke_agent(agent_name,prompt) handoff, progress-bound continuation and
+gates to the whole batch:
+
+1. One architect designs all tickets, groups tasks by ticket/repository and
+   dependency order, validates OpenSpec and high/medium design confidence.
+2. One developer implements groups sequentially, persisting progress in tasks.md.
+   Use scoped checks per group and one full helper verification for the aggregate
+   candidate before developer done. Incomplete groups remain retriable.
+3. One reviewer checks every acceptance criterion and cross-ticket interaction;
+   pass all frozen specs, changed paths and the full receipt. Ordinary review
+   never archives. At most one exact-findings developer repair plus re-review.
+4. After clean semantic reviewer done, run archive-check; only success authorizes
+   reviewer archive-only mode. Verify the archive and record archive done. Only
+   then close ALL Core-owned tickets, or report results to the owning host.
+
+Run these roles directly at root, no nested implement coordinator. Retry resumes
+this aggregate journal without repeating valid phases. A --parallel preference
+never overrides host ownership, unknown capacity or overlapping mutation paths;
+use sequential execution and report it honestly. Final output lists each ticket,
+aggregate verification/archive status and unresolved task groups; no partial done.
 '''