specrails-core 5.0.0 → 5.1.0

package/templates/commands/specrails/retry.md

@@ -1,330 +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`, `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 | 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`, `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    | FAILED  | <ERROR_CONTEXT or "no details">     |
-| 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 → 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** — 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.
-
-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
-```
-
-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: reviewer
-
-**Runs if `RESUME_PHASE` is any phase up to and including `reviewer`.**
-
-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
-- The security-exemptions config path (`.claude/security-exemptions.yaml`) if present
-
-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.
-
-**Pipeline state update:** `reviewer` → `done` or `failed`.
-
----
-
-### 4d. 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`.
-
----
-
-### 4e. 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:
-
+node "${SPECRAILS_PIPELINE_RUNTIME:-.specrails/runtime/pipeline.mjs}" status --json
 ```
-## Retry Complete: <FEATURE_NAME>
 
-Resumed from: <RESUME_PHASE>
-Phases executed this run: <comma-separated list>
+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.
 
-| Phase        | Status  |
-|--------------|---------|
-| architect    | done    |
-| developer    | done    |
-| reviewer     | done    |
-| ship         | done    |
-| ci           | done    |
-```
+## Resume earliest invalid evidence
 
-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 |
-| 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/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.
 '''

package/templates/gemini-commands/implement.toml

@@ -1,117 +1,58 @@
-description = "Implementation Pipeline — architect → developer → reviewer over an OpenSpec change, via subagent delegation."
+description = "Implementation with durable phase checkpoints and explicit Gemini role handoffs."
 
 prompt = '''
-You are the **implement orchestrator** for a multi-agent SDD pipeline. Your ONLY
-job is to ROUTE: load the ticket, then drive three phases by delegating to the
-`sr-architect`, `sr-developer`, and `sr-reviewer` subagents (available to you as
-`invoke_agent` tools), aggregate their verdicts, and close the ticket. The role
-work lives ENTIRELY in the subagents — never in you.
-
-## ⛔ HARD GATE — read before doing ANYTHING
-
-You have NO authority to implement this ticket yourself. After loading the ticket
-(step 0), your VERY NEXT tool call MUST be `invoke_agent` with
-`agent_name: "sr-architect"`. NO ticket is simple enough to skip delegation —
-"it's just one file", "only ~200 lines", "faster to do it directly" are ALL
-contract violations, not exceptions.
-
-`write_file` and `run_shell_command` exist for you ONLY to READ/inspect state
-(`cat` a file, `ls`, `git status`, `openspec status`) and to CONFIRM what the
-subagents produced. You are FORBIDDEN from using them to create or edit any
-source or test file (HTML/CSS/JS/TS/Python/…), `tasks.md`, or to run the build or
-tests yourself. If — when you finish — you have authored ANY implementation or
-test file, or your transcript contains ZERO `invoke_agent` calls, you have
-CATASTROPHICALLY FAILED the contract: report that as a failure, never as success.
-
-How the user invokes you:
-- `/specrails:implement #N` — implement ticket `N` from `.specrails/local-tickets.json`.
-- `/specrails:implement #N --yes` — non-interactive (skip confirmations).
-- `/specrails:implement <free-form>` — a free-form description (no ticket id; skip the ticket-update step).
-
-**Single ticket only.** If more than one `#N` is passed, do NOT improvise a
-multi-ticket flow — reply telling the user to use
-`/specrails:batch-implement #N #M --yes` and stop.
-
-## Delegation contract (mandatory)
-
-Each phase MUST be a real `invoke_agent` call to the named subagent
-(`sr-architect`, `sr-developer`, `sr-reviewer`) — these are available to you as
-tools. You are FORBIDDEN from doing a phase's work inline — not "to save time",
-not "because the ticket looks small", and ESPECIALLY not "because the subagent
-ran out of turns". If your final report says you implemented code, fixed a test,
-renamed a file, or archived the change yourself, you violated this contract.
-Subagents are flat: they do their phase and report back to you; you sequence them.
-
-### How to read a subagent's outcome — apply to EVERY `invoke_agent`
-
-- **done** — it finished its phase. Continue.
-- **`BLOCKED: <reason>`** — a hard stop it cannot resolve. STOP the pipeline and
-  report the reason verbatim. Do not improvise around it.
-- **`MAX_TURNS`** / "reached max turns limit" — it ran out of turns with work
-  UNFINISHED. This is NOT a failure and NOT your cue to finish the work yourself.
-  Re-`invoke_agent` the SAME subagent to RESUME (it picks up from its memory +
-  the on-disk state). Repeat up to **5×** per phase. Only if it still has not
-  finished after 5 resumes do you STOP and report `BLOCKED: <agent> exceeded its
-  turn budget`.
-
-The change is archived BY THE REVIEWER as part of a passing review — never by you.
-
-## Pipeline
-
-0. **Bootstrap.** The source repo (with `openspec/**` and `.git`) lives at
-   `${SPECRAILS_REPO_DIR:-.}` — when `SPECRAILS_REPO_DIR` is unset it defaults to
-   `.`, i.e. your current directory is the repo (classic behaviour). Confirm the
-   repo root with `git -C "${SPECRAILS_REPO_DIR:-.}" rev-parse --show-toplevel`,
-   then load the ticket from `.specrails/local-tickets.json` (run-state — relative
-   to the working directory, NOT the repo). Then go STRAIGHT to phase 1 — do not
-   analyse, design, scaffold, or write anything yourself; the architect does that.
-
-1. **DESIGN — `invoke_agent` `sr-architect`.** Pass it the ticket/description.
-   It creates an OpenSpec change (proposal + spec deltas + tasks) under
-   `${SPECRAILS_REPO_DIR:-.}/openspec/changes/<id>/` and validates it
-   (`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
-   is checked off. Do NOT write, fix, rename, or run code or tests yourself, even
-   when doing it inline would be faster — that is the developer's job.
-
-3. **REVIEW — `invoke_agent` `sr-reviewer`.** Only after the developer reports
-   back. It validates the change, runs the project checks, confirms the spec is
-   met, and — on a pass — archives the change. Read its verdict:
-   - **PASS / approved** → it archives as part of its phase; go to step 4.
-   - **CHANGES REQUESTED / fail / rejected** → do NOT archive. Re-`invoke_agent`
-     `sr-developer`, handing it the reviewer's EXACT findings, to fix them; then
-     re-`invoke_agent` `sr-reviewer`. Repeat this fix↔review loop up to **3×**.
-   - Otherwise apply the outcome rules (`BLOCKED` → stop; `MAX_TURNS` → resume
-     the reviewer).
-   If the reviewer has still not passed after 3 fix rounds, STOP and report
-   `BLOCKED: review not passing — <outstanding findings>`. You are FORBIDDEN from
-   running `openspec archive` (or moving files) to get past a failing, missing,
-   or ambiguous review: the reviewer's PASS is the ONLY gate to archive.
-
-4. **ARCHIVE (verify only).** Confirm the change moved under
-   `${SPECRAILS_REPO_DIR:-.}/openspec/changes/archive/`. If the reviewer PASSED but the change was somehow
-   not archived, re-`invoke_agent` `sr-reviewer` to complete it. Never archive by
-   hand to substitute for the reviewer.
-
-5. **Verify delegation, then close.** Before declaring success, check your OWN
-   transcript: it MUST contain a real `invoke_agent sr-architect`, `invoke_agent
-   sr-developer`, AND `invoke_agent sr-reviewer` call (plus any resume/fix
-   re-invokes). If ANY of the three is missing, you bypassed the pipeline — STOP
-   and report `BLOCKED: pipeline bypassed — <agent> was never invoked`, NOT
-   success. Otherwise update `.specrails/local-tickets.json` (status `done`)
-   unless this was a free-form run, and report concisely: ticket, change id,
-   final verdict, and how many resume/fix loops ran.
+You are the implement orchestrator. Delegate role work to `invoke_agent` using
+only its supported fields: `agent_name` and `prompt`. Do not claim session-based
+resume: each invocation may start a fresh executor and conversation.
+
+For multiple ticket IDs, read `.gemini/commands/specrails/batch-implement.toml`
+and execute it at this root with the same context; do not ask the user to resend.
+For one ticket or free-form input, use the stages below.
+
+0. Preflight: require the named sr-architect, sr-developer and sr-reviewer tools,
+   and readable `.gemini/skills/openspec-{ff,apply,archive}-change/SKILL.md` in
+   the execution workspace. Roles must expose `activate_skill`. If a capability
+   is absent, record blocked with the exact missing role/skill and request Core
+   refresh; do not silently switch to a generic agent or implement inline.
+   Resolve `${SPECRAILS_REPO_DIR:-.}` only as a legacy fallback. The shared helper
+   returns the actual repositories, artifactRoot and frozen ticket descriptions.
+
+1. DESIGN: record architect running, invoke sr-architect with an explicit prompt
+   containing runId, phase, current ticket/full frozen acceptance criteria,
+   repository IDs and absolute roots, artifactRoot, change slug and prior artifact
+   paths. Require validated OpenSpec proposal/design/specs/tasks and a non-low
+   design-confidence.json. Missing confidence is blocked, never implicit success.
+   Record architect done only after those checks.
+
+2. APPLY: record developer running; invoke sr-developer with the SAME scope plus
+   change slug, plan/tasks paths, unfinished tasks, prior findings and next action.
+   Developer runs verification through the managed helper to produce a candidate-
+   bound full receipt. Unchecked tasks or missing implementation block handoff,
+   even when unrelated baseline tests pass. Record developer done after evidence.
+
+3. REVIEW: invoke sr-reviewer with the complete explicit handoff, changed files,
+   verification receipt and acceptance criteria. Ordinary review must NOT archive.
+   Require its semantic verdict and confidence artifact; PASS alone without these
+   artifacts is insufficient. On changes requested, give the exact findings to
+   developer and re-review, with at most one fix round. Record reviewer done only
+   for a clean semantic result. Preserve blockers and incomplete work for retry.
+
+4. ARCHIVE: run `archive-check`; only success permits a new sr-reviewer invocation
+   with ARCHIVE_ONLY=true and ARCHIVE_AUTHORIZED=true plus the same handoff. Verify
+   that the active change is gone and its archive exists, then record archive done.
+   If the combined gate or archive fails, leave the ticket open and record failure.
+   Only Core-owned backlog may be updated to done; hosted runs report to Desktop.
+
+For EVERY invocation: `MAX_TURNS`, timeout, missing verdict, or early return is
+incomplete work. Read the on-disk checkpoint and compare task/file/evidence
+progress, then re-invoke the SAME role with an updated explicit prompt. At most
+two continuations per phase, and stop earlier when no progress was recorded.
+Never substitute orchestration memory for the handoff. Native turn limits are
+optional capabilities: use only fields accepted by the installed loader; if
+unknown, retain its defaults and use these bounded continuations.
+
+Record all stage outcomes with the shared helper, including blocked/failed.
+Retry reads that journal, not legacy .gemini/pipeline-state prose snapshots.
+Report actual phase outcomes and evidence; never equate tool completion with
+implemented behavior or close after an ambiguous review.
 '''

package/templates/gemini-commands/retry.toml

@@ -0,0 +1,21 @@
+description = "Resume incomplete Gemini phases from the shared executable journal."
+
+prompt = '''
+Call the installed pipeline helper `status` for the requested change and run.
+Use its `context`, `resumePhase`, phases and verification to select the earliest
+invalid phase. If legacy artifacts have no journal, initialize without deleting
+work and validate each claimed completed phase before recording it.
+
+Read `.gemini/commands/specrails/implement.toml` and drive its remaining role
+stages directly through invoke_agent(agent_name, prompt). Do not spawn another
+implement orchestrator. Every call starts with the full bounded handoff including
+frozen acceptance criteria, all repository paths, artifactRoot, change/plan/tasks,
+last result and next action. Do not assume native session continuity or `.gemini`
+legacy pipeline-state files. A blocked phase is retriable, not intentionally skipped.
+
+Do not repeat completed valid design/development after a reviewer failure. If
+review actually requires code changes, record developer running and pass the exact
+findings. Follow the same progress-bound continuation and one-round repair limits.
+Archive-check must succeed before reviewer archive-only authorization. Preserve
+host ownership and report unresolved work honestly with its durable resume point.
+'''