specrails-core 4.12.0 → 5.0.0

package/commands/enrich.md

@@ -1,1456 +0,0 @@
-# Enrich: Agent Workflow System
-
-Interactive wizard to configure the full agent workflow system for this repository. Analyzes the codebase, discovers target users, generates VPC personas, and creates all agents, commands, rules, and configuration adapted to this project. Supports config-driven mode for direct installation from a pre-built config file.
-
-**Prerequisites:** Ensure this repo was initialized with `npx specrails-core@latest init` (or via specrails-desktop) so `.specrails/setup-templates/` exists.
-
-### Desktop App Checkpoint Protocol
-
-When running inside specrails-desktop, emit checkpoint markers at key transitions so the desktop app `CheckpointTracker` can display progress. Each checkpoint is a single line printed to stdout:
-
-```
-[checkpoint:phase_1_analysis] Codebase analysis complete
-[checkpoint:phase_2_personas] VPC personas generated
-[checkpoint:phase_3_commands] Commands and rules generated
-[checkpoint:phase_4_agents] Agent files generated
-[checkpoint:phase_5_cleanup] Cleanup and summary complete
-```
-
-The desktop app parses these via `detectCheckpointFromText()` regex patterns. Always emit checkpoints at the end of each phase, even in `--from-config` and `--quick` modes.
-
----
-
-## Mode Detection
-
-Check `$ARGUMENTS` in this order:
-
-1. If `--update` is present → execute **Update Mode** (below), then stop.
-2. If `--from-config` is present → execute **From-Config Mode** (below), then stop.
-3. If `--quick` or `--lite` is present → execute **Quick Mode** (below), then stop.
-4. Otherwise (no flags) → skip directly to **Phase 1** and execute the full 5-phase wizard.
-
-**Default is the full wizard.** Quick Mode only runs when `--quick` or `--lite` is explicitly passed.
-
----
-
-## From-Config Mode
-
-When `--from-config` is passed, execute a fully automated installation using `.specrails/install-config.yaml`. No interactive prompts — all decisions come from the config file.
-
-### FC1: Read and Validate Config
-
-Read `.specrails/install-config.yaml`. If it does not exist, display:
-> "`.specrails/install-config.yaml` not found. Run the TUI installer first (`npx specrails-core@latest init`) or use `/specrails:enrich` without `--from-config` for the interactive wizard."
-Then stop.
-
-Parse the YAML and extract:
-- `config.version` — must be `1`; if not, warn and proceed
-- `config.provider` — `claude` (this is the Claude enrichment flow); default `claude`
-- `config.tier` — `full` or `quick`; default `full`
-- `config.agents.selected` — list of agent names to install
-- `config.agents.excluded` — list of agent names to skip (for reference only)
-- `config.models.preset` — `balanced`, `budget`, or `max` (see Model Presets below)
-- `config.models.defaults.model` — default model override (overrides preset)
-- `config.models.overrides` — per-agent model overrides (highest priority)
-
-Store all values in variables prefixed `FC_`.
-
-**Model Presets** (applied when `config.models.defaults` is not set):
-- `balanced` (default): sr-architect=opus, sr-product-manager=opus, all others=sonnet
-- `budget`: all agents=haiku
-- `max`: all agents=opus
-
-To resolve the model for any given agent:
-1. Check `config.models.overrides.<agent-name>` — if present, use it
-2. Check `config.models.defaults.model` — if present, use it
-3. Apply preset defaults based on `config.models.preset`
-4. Fallback to model in template frontmatter
-
-### FC2: Provider Setup
-
-This is the Claude enrichment flow. Set `SPECRAILS_DIR = ".claude"`.
-
-### FC3: If tier is `quick` — run Quick Mode with config context
-
-If `FC_tier == "quick"`:
-- Set `FC_AGENTS_SELECTED` as the list of agents to generate (instead of defaults)
-- Execute Quick Mode (QS1–QS4), generating all `FC_AGENTS_SELECTED` agents (not just defaults)
-- Then stop.
-
-### FC4: If tier is `full` — run automated full wizard
-
-**Phase 1 (Silent):** Run the full Phase 1 analysis (1.1–1.4) without any user prompts. Store all detected values internally.
-
-**Phase 2 (AI-Inferred VPC Discovery):** Run VPC persona generation from codebase analysis:
-- Analyze the codebase (README, package.json, source code, configs) to infer what the product does and who it serves
-- Generate `PROJECT_DESCRIPTION` (2–3 sentence summary) and `TARGET_USERS` from analysis
-- Use these inferred values to generate full VPC personas (3 primary, 3 secondary)
-- Do not ask the user any questions — infer everything from codebase analysis
-
-**Phase 3 (Silent):** Run Phase 3 normally without user prompts.
-
-**Phase 4 (Config-Driven Agent Generation):** 
-- Generate only agents in `FC_AGENTS_SELECTED` (skip any not in the list)
-- Apply model resolution (FC1 preset/override logic) to each agent's frontmatter
-- Run all Phase 4 sub-phases (4.1, 4.2, 4.3, 4.4) normally but without interactive prompts
-
-**Phase 5 (Normal):** Run Phase 5 cleanup normally.
-
-### FC5: Completion
-
-Display:
-```
-✅ Enrich complete (from-config).
-
-Agents generated: <count> of <total selected>
-Models applied:
-  sr-architect: <resolved-model>
-  sr-developer: <resolved-model>
-  [... one line per generated agent ...]
-
-Next steps:
-  > /specrails:implement <feature>
-```
-
----
-
-## Update Mode
-
-When `--update` is passed, execute this streamlined flow instead of the full wizard. Do not run any phases from the full wizard. When Phase U7 is complete, stop.
-
-### Phase U1: Read Update Context
-
-Read the following files to understand the current installation state:
-
-1. Read `.specrails/specrails-manifest.json` — contains agent template checksums from the last install/update. Structure:
-   ```json
-   {
-     "version": "0.2.0",
-     "installed_at": "2025-01-15T10:00:00Z",
-     "artifacts": {
-       "templates/agents/architect.md": "sha256:<checksum>",
-       "templates/agents/developer.md": "sha256:<checksum>",
-       "templates/agents/reviewer.md": "sha256:<checksum>"
-     }
-   }
-   ```
-   If this file does not exist, inform the user:
-   > "No `.specrails/specrails-manifest.json` found. This repo predates the Node-native installer. Re-run `npx specrails-core@latest init` to refresh the install, then re-run `/specrails:enrich --update`."
-   Then stop.
-
-2. Read `.specrails/specrails-version` — contains the current version string (e.g., `0.2.0`). If it does not exist, treat version as `0.1.0 (legacy)`.
-
-3. This is the **Claude** enrichment flow: it operates on `.claude/` (`specrails_dir = ".claude"`). Codex projects use their own codex-native `$enrich` skill, not this command.
-
-4. List all template files in `.specrails/setup-templates/agents/` — these are the NEW agent templates from the update:
-   ```bash
-   ls .specrails/setup-templates/agents/
-   ```
-   Template files are named with `sr-` prefix (e.g., `sr-architect.md`, `sr-developer.md`).
-
-5. List all template files in `.specrails/setup-templates/commands/specrails/` — these are the NEW command templates from the update:
-   ```bash
-   ls .specrails/setup-templates/commands/specrails/
-   ```
-   Command template files include `implement.md`, `batch-implement.md`, `compat-check.md`, `refactor-recommender.md`, `why.md`, `get-backlog-specs.md`, `auto-propose-backlog-specs.md`.
-   If this directory does not exist, skip command template checking for this update.
-
-6. Read `.specrails/backlog-config.json` if it exists — contains stored provider configuration needed for command placeholder substitution.
-
-7. Read `.specrails/agents.yaml` if it exists — contains agent model configuration. Validate all `model:` values (only `opus`, `sonnet`, `haiku` are valid). Store as `AGENTS_CONFIG` for use in Phase U4. If the file does not exist, set `AGENTS_CONFIG = null`.
-
-### Phase U2: Quick Codebase Re-Analysis
-
-Perform the same analysis as Phase 1 of the full setup wizard, but silently — do not prompt the user and do not show the findings table. Just execute and store results internally.
-
-Detect:
-- **Languages**: Check for `*.py`, `*.ts`, `*.tsx`, `*.go`, `*.rs`, `*.java`, `*.kt`, `*.rb`, `*.cs`
-- **Frameworks**: Search for imports (`fastapi`, `express`, `react`, `vue`, `angular`, `django`, `spring`, `gin`, `actix`, `rails`)
-- **Directory structure**: Identify backend/frontend/core/test directories
-- **Database**: Check for SQL files, ORM configs, migration directories
-- **CI/CD**: Parse `.github/workflows/*.yml` for lint/test/build commands
-- **Naming conventions**: Read 2-3 source files per detected layer
-
-Read:
-- `README.md` (if exists)
-- `package.json` / `pyproject.toml` / `Cargo.toml` / `go.mod` / `pom.xml` (detect stack)
-- `.github/workflows/*.yml` (detect CI commands)
-
-Store all results for use in Phases U4 and U5.
-
-### Phase U3: Identify What Needs Regeneration
-
-**Agent templates:** For each agent template, find its entry in the manifest's `artifacts` map (keyed as `templates/agents/sr-<name>.md`). Compute the SHA-256 checksum of the corresponding file in `.specrails/setup-templates/agents/`:
-
-```bash
-sha256sum .specrails/setup-templates/agents/sr-<name>.md
-```
-
-Build three lists for agents:
-
-1. **Changed agents**: agent name exists in manifest AND the current template checksum differs from the manifest checksum → mark for regeneration
-2. **New agents**: template file exists in `.specrails/setup-templates/agents/` but the agent name is NOT in the manifest → mark for evaluation
-3. **Unchanged agents**: agent name exists in manifest AND checksum matches → skip
-
-**Command templates:** If `.specrails/setup-templates/commands/specrails/` exists, for each command template file, find its entry in the manifest's `artifacts` map (keyed as `templates/commands/specrails/<name>.md`). Compute the SHA-256 checksum of the corresponding file in `.specrails/setup-templates/commands/specrails/`:
-
-```bash
-sha256sum .specrails/setup-templates/commands/specrails/<name>.md
-```
-
-Build three lists for commands:
-
-1. **Changed commands**: command name exists in manifest AND the current template checksum differs from the manifest checksum → mark for update
-2. **New commands**: template file exists in `.specrails/setup-templates/commands/specrails/` but the command name is NOT in the manifest → mark for evaluation
-3. **Unchanged commands**: command name exists in manifest AND checksum matches → skip
-
-Display the combined analysis to the user:
-
-```
-## Update Analysis
-
-### Agents — Changed Templates (will be regenerated)
-- sr-architect.md (template modified)
-- sr-developer.md (template modified)
-
-### Agents — New Templates Available
-- sr-frontend-developer.md
-- sr-backend-developer.md
-
-### Agents — Unchanged (keeping current)
-- sr-reviewer.md
-- sr-product-manager.md
-
-### Commands — Changed Templates (will be updated)
-- implement.md (template modified)
-
-### Commands — New Templates Available
-- refactor-recommender.md
-
-### Commands — Unchanged (keeping current)
-- compat-check.md
-- why.md
-```
-
-If there are no changed agents, no new agents, no changed commands, and no new commands, display:
-```
-All agents and commands are already up to date. Nothing to regenerate.
-```
-Then jump to Phase U7.
-
-### Phase U4: Regenerate Changed Agents
-
-For each agent in the "changed" list:
-
-1. Read the NEW template from `.specrails/setup-templates/agents/sr-<name>.md`
-2. Use the codebase analysis from Phase U2 to fill in all `{{PLACEHOLDER}}` values, using the same substitution rules as Phase 4.1 of the full setup:
-   - `{{PROJECT_NAME}}` → project name (from README.md or directory name)
-   - `{{ARCHITECTURE_DIAGRAM}}` → detected architecture layers
-   - `{{LAYER_TAGS}}` → detected layer tags (e.g., `[backend]`, `[frontend]`, `[api]`)
-   - `{{CI_COMMANDS_BACKEND}}` → backend CI commands
-   - `{{CI_COMMANDS_FRONTEND}}` → frontend CI commands
-   - `{{LAYER_CONVENTIONS}}` → detected conventions per layer
-   - `{{PERSONA_NAMES}}` → read existing persona names from `$SPECRAILS_DIR/agents/personas/` filenames
-   - `{{PERSONA_FILES}}` → paths to existing persona files in `$SPECRAILS_DIR/agents/personas/`
-   - `{{DOMAIN_EXPERTISE}}` → infer from detected stack and README
-   - `{{KEY_FILE_PATHS}}` → important file paths detected in Phase U2
-   - `{{WARNINGS}}` → read from existing `CLAUDE.md` if present
-   - `{{MEMORY_PATH}}` → `$SPECRAILS_DIR/agent-memory/sr-<agent-name>/`
-3. Resolve the agent's model using `AGENTS_CONFIG` (loaded in Phase U1, step 7):
-   - Check `AGENTS_CONFIG.agents.<agent-name>.model` (per-agent override)
-   - If not present, check `AGENTS_CONFIG.defaults.model` (global default)
-   - If `AGENTS_CONFIG` is null, use the model from the template frontmatter
-   - Replace the `model:` field in the YAML frontmatter with the resolved value before writing
-4. Write the adapted agent (same rules as Phase 4.1):
-   - Write to `.claude/agents/sr-<name>.md` (Markdown with YAML frontmatter)
-5. Show: `✓ Regenerated sr-<name>`
-
-After regenerating all changed agents, verify no unresolved placeholders remain:
-```bash
-grep -r '{{[A-Z_]*}}' .claude/agents/sr-*.md 2>/dev/null || echo "OK: no broken placeholders"
-```
-
-### Phase U4b: Update Changed Commands
-
-For each command in the "changed commands" list from Phase U3:
-
-1. Read the NEW template from `.specrails/setup-templates/commands/specrails/<name>.md`
-2. Read stored backlog configuration from `.specrails/backlog-config.json` (if it exists) to resolve provider-specific placeholders:
-   - `BACKLOG_PROVIDER` → `provider` field (`github`, `jira`, or `none`)
-   - `BACKLOG_WRITE` → `write_access` field
-   - `JIRA_BASE_URL` → `jira_base_url` field
-   - `JIRA_PROJECT_KEY` → `jira_project_key` field
-3. Substitute all `{{PLACEHOLDER}}` values using the same rules as Phase 4.3 of the full setup:
-   - `{{CI_COMMANDS_BACKEND}}` → backend CI commands detected in Phase U2
-   - `{{CI_COMMANDS_FRONTEND}}` → frontend CI commands detected in Phase U2
-   - `{{DEPENDENCY_CHECK_COMMANDS}}` → stack-specific dependency check commands from Phase U2
-   - `{{TEST_RUNNER_CHECK}}` → test runner commands from Phase U2
-   - `{{BACKLOG_FETCH_CMD}}` → provider-specific fetch command from backlog config
-   - `{{BACKLOG_CREATE_CMD}}` → provider-specific create command from backlog config
-   - `{{BACKLOG_VIEW_CMD}}` → provider-specific view command from backlog config
-   - `{{BACKLOG_PREFLIGHT}}` → provider-specific preflight check from backlog config
-   - Any other `{{PLACEHOLDER}}` values → use Phase U2 analysis data
-4. Write the updated file to `.claude/commands/specrails/<name>.md`
-5. Show: `✓ Updated /specrails:<name>`
-
-After updating all changed commands, verify no unresolved placeholders remain:
-```bash
-grep -l '{{[A-Z_]*}}' .claude/commands/specrails/*.md 2>/dev/null || echo "OK: no broken placeholders"
-```
-If any placeholders remain unresolved, warn the user:
-> "⚠ Some placeholders in `<filename>` could not be resolved automatically. Please review the file and fill them in manually."
-
-### Phase U5: Evaluate New Agents
-
-For each agent in the "new" list:
-
-1. Read the template from `.specrails/setup-templates/agents/sr-<name>.md` to understand what stack or layer it targets (read its description and any layer-specific comments)
-2. Match against the codebase detected in Phase U2:
-   - If the template targets a layer/stack that IS present (e.g., `sr-frontend-developer` and React was detected), prompt:
-     > "New agent available: `sr-<name>` — your project uses [detected tech]. Add it? [Y/n]"
-   - If the template targets a layer/stack that is NOT present (e.g., `sr-backend-developer` and no backend was detected), prompt:
-     > "New agent available: `sr-<name>` — no [layer] detected in your project. Skip? [Y/n]"
-3. If the user accepts (or presses Enter on a pre-selected default):
-   - Generate the agent using the same template adaptation as Phase U4
-   - Create memory directory if it does not exist: `$SPECRAILS_DIR/agent-memory/sr-<name>/`
-   - Show: `✓ Added sr-<name>`
-4. If the user declines:
-   - Show: `→ Skipped sr-<name>`
-
-For each command in the "new commands" list from Phase U3:
-
-1. Read the template from `.specrails/setup-templates/commands/specrails/<name>.md`
-2. Prompt the user: `"New command available: /specrails:<name> — [one-line description]. Install it? [Y/n]"`
-3. If the user accepts (or presses Enter):
-   - Apply placeholder substitution using the same rules as Phase U4b (backlog config + codebase analysis)
-   - Write to `.claude/commands/specrails/<name>.md` — show `✓ Added /specrails:<name>`
-4. If the user declines:
-   - Show `→ Skipped /specrails:<name>`
-
-### Phase U6: Update Workflow Commands
-
-If any new agents were added in Phase U5:
-
-1. Read the implement command at `.claude/commands/specrails/implement.md`
-2. Check if the file references agent names in its orchestration steps (look for `sr-architect`, `sr-developer`, `sr-reviewer` etc.)
-3. If newly added agents belong in the implementation pipeline (i.e., they are layer-specific developers such as `sr-frontend-developer` or `sr-backend-developer`), add them to the appropriate step in the implement command — specifically where parallel developer agents are launched
-4. Write the updated file to `.claude/commands/specrails/implement.md` if any changes were made
-5. Show which commands were updated, or "No command updates needed" if nothing changed
-
-This is a lightweight check — only update commands where the sr- agent clearly belongs. Do not restructure the entire command.
-
-### Phase U7: Summary
-
-Display the final summary and stop. Do not continue to Phase 1 of the full setup wizard.
-
-```
-## Update Complete
-
-specrails updated from v<previous> to v<new>.
-
-| Action              | Count |
-|---------------------|-------|
-| Agents regenerated  | N     |
-| Agents added        | N     |
-| Agents skipped      | N     |
-| Commands updated    | N     |
-| Commands added      | N     |
-| Commands skipped    | N     |
-
-All agents and commands are now up to date.
-
-### Agents Regenerated
-[list agent names, or "(none)"]
-
-### Agents Added
-[list agent names, or "(none)"]
-
-### Agents Skipped
-[list agent names, or "(none)"]
-
-### Commands Updated
-[list command names, or "(none)"]
-
-### Commands Added
-[list command names, or "(none)"]
-
-### Commands Skipped
-[list command names, or "(none)"]
-```
-
-Update `.specrails/specrails-manifest.json` to reflect the new checksums for all regenerated/updated and added agents and commands:
-- For each regenerated agent: update its checksum entry to the new template's checksum (keyed as `templates/agents/sr-<name>.md`)
-- For each added agent: add a new entry with its checksum
-- For each updated command: update its checksum entry to the new template's checksum (keyed as `templates/commands/specrails/<name>.md`)
-- For each added command: add a new entry with its checksum
-- Update the `version` field to the version read from `.specrails/specrails-version`
-
----
-
-## Quick Mode
-
-When `--quick` or `--lite` is passed, run this streamlined 3-question setup. Do NOT run Phase 1–5. When QS4 is complete, stop.
-
-### QS1: Infer context and ask git access
-
-**Step 1 — AI inference (silent):** Analyze the codebase to infer:
-- `QS_PROJECT_DESCRIPTION` — a 2–3 sentence summary of what this project does (from README, package.json, source code, configs)
-- `QS_TARGET_USERS` — who the target users are (from docs, UI copy, API design, domain language)
-
-**Step 2 — Ask one question:**
-
-Display the following prompt EXACTLY ONCE:
-
-Welcome to specrails! Let's get your AI agent team set up.
-
-I've analyzed your codebase:
-- **Project:** {QS_PROJECT_DESCRIPTION}
-- **Target users:** {QS_TARGET_USERS}
-
-1. Git access for agents — read-only or read-write?
-   (read-only = agents can read and suggest; read-write = agents can commit)
-
-Store the answer as:
-- `QS_GIT_ACCESS` — "read-only" or "read-write" (normalize if user types "ro", "rw", "readonly", etc.)
-
-### QS2: Apply opinionated defaults
-
-Use these defaults for all configuration not asked in QS1:
-
-| Setting | Quick Mode Default |
-|---------|------------------|
-| Agents enabled | sr-architect, sr-developer, sr-reviewer, sr-product-manager |
-| Git mode | Derived from QS_GIT_ACCESS |
-| CLAUDE.md template | `templates/CLAUDE-quickstart.md` |
-| OpenSpec enabled | Yes if `openspec` CLI is detected in PATH, No otherwise |
-| Telemetry | Not configured (deferred to PRD-002) |
-| Backlog provider | local (lightweight JSON-based, no external tools needed) |
-
-Detect whether this is an existing codebase or new project:
-- **Existing codebase**: `package.json`, `Gemfile`, `pyproject.toml`, `go.mod`, or `pom.xml` found in the repo root
-- **New project**: none of the above found
-
-Store as `QS_IS_EXISTING_CODEBASE=true/false`.
-
-### QS2.5: Re-run Detection
-
-Before generating files, check if this is a re-run:
-
-1. Check if commands already exist — check if `.claude/commands/specrails/` directory exists with any `.md` files:
-   ```bash
-   ls .claude/commands/specrails/*.md 2>/dev/null
-   ```
-2. If files are found → this is a **re-run**. Store `QS_IS_RERUN=true`.
-3. If the directory does not exist or is empty → this is a **fresh install**. Store `QS_IS_RERUN=false`.
-
-In re-run mode, QS3 executes in **gap-fill mode** for command files:
-- For each command in the list, check if it already exists at `.claude/commands/specrails/<name>.md`
-- If it exists: skip it and show `✓ Already installed: /specrails:<name>`
-- If it does NOT exist: install it and show `✓ Added /specrails:<name> (was missing)`
-- Do NOT prompt the user for confirmation on missing files — install them automatically
-
-For CLAUDE.md/AGENTS.md and agent files, the existing per-file prompts already handle re-runs (user is asked before overwriting). No change needed there.
-
-### QS3: Generate files
-
-Generate files using the Quick Mode defaults.
-
-**1. CLAUDE.md**
-
-Read `.specrails/setup-templates/claude-md/CLAUDE-quickstart.md` (or fall back to `.specrails/setup-templates/claude-md/default.md` if quickstart template is not found).
-
-Replace placeholders:
-- `{{PROJECT_NAME}}` → derive from directory name or README.md first heading
-- `{{GIT_ACCESS}}` → `QS_GIT_ACCESS`
-
-Write to `CLAUDE.md` in the repo root. If `CLAUDE.md` already exists, ask:
-> "CLAUDE.md already exists. Overwrite? [Y/n]"
-Skip if user says no.
-
-**2. Agent files**
-
-For each default agent (sr-architect, sr-developer, sr-reviewer, sr-product-manager), read the template from `.specrails/setup-templates/agents/<name>.md` and generate the adapted agent file using the rules from Phase 4.1:
-- Write to `.claude/agents/<name>.md` (Markdown with frontmatter)
-
-If `.specrails/agents.yaml` exists, read it and apply model resolution (per-agent override → defaults → template value) before writing each agent file.
-
-Fill placeholders with best-effort values from the limited context available:
-- `{{PROJECT_NAME}}` → directory name or README first heading
-- `{{GIT_ACCESS}}` → `QS_GIT_ACCESS`
-- `{{ARCHITECTURE_DIAGRAM}}` → "(Quick Mode — run `/specrails:enrich` for full architecture analysis)"
-- `{{TECH_EXPERTISE}}` → "(Quick Mode — run `/specrails:enrich` for codebase-specific expertise)"
-- `{{LAYER_TAGS}}` → detect from package.json / Gemfile / go.mod if present; otherwise leave empty
-- All other placeholders → "(not configured — run `/specrails:enrich`)"
-
-Create memory directories: `$SPECRAILS_DIR/agent-memory/sr-<name>/`
-
-**3. Command files**
-
-Core commands (always install if missing):
-- `implement.md`
-- `batch-implement.md`
-- `propose-spec.md`
-- `compat-check.md`
-- `why.md`
-- `get-backlog-specs.md`
-- `auto-propose-backlog-specs.md`
-
-**Initialize local ticket storage** (backlog provider defaults to `local`):
-1. Copy `templates/local-tickets-schema.json` to `.specrails/local-tickets.json` and set `last_updated` to the current ISO-8601 timestamp. Skip if the file already exists.
-2. Write `.specrails/backlog-config.json` (skip if already exists):
-   ```json
-   {
-     "provider": "local",
-     "write_access": true,
-     "git_auto": true
-   }
-   ```
-
-If `QS_IS_RERUN=false` (fresh install): for each core command, read the template from `.specrails/setup-templates/commands/specrails/<name>.md`, substitute the backlog placeholders with local values (using the same table as Phase 4.3 "Local Tickets"), stub all persona placeholders with `(Quick Mode — run /specrails:enrich to configure personas)`, then write to `.claude/commands/specrails/<name>.md`.
-
-If `QS_IS_RERUN=true` (gap-fill mode): for each command in the list above, check if `.claude/commands/specrails/<name>.md` already exists:
-- If it exists: skip it — show `✓ Already installed: /specrails:<name>`
-- If it does NOT exist: read template, substitute placeholders as above, write to `.claude/commands/specrails/<name>.md` — show `✓ Added /specrails:<name> (was missing)`
-
-**4. Cleanup**
-
-Remove `.specrails/setup-templates/` (same as full wizard cleanup in Phase 5).
-
-Remove `commands/enrich.md` from `.claude/commands/` if it was copied there by the installer.
-
-### QS4: First Task Prompt
-
-After generating all files, display the setup complete message.
-
-Then, based on `QS_IS_EXISTING_CODEBASE`:
-- **Existing codebase** (`true`): recommend `/specrails:refactor-recommender`
-- **New project** (`false`): recommend `/specrails:get-backlog-specs`
-
-If `QS_IS_RERUN=false`, display:
-```
-✅ Setup complete.
-
-Try your first command:
-  > /specrails:get-backlog-specs
-```
-(Replace `/specrails:get-backlog-specs` with `/specrails:refactor-recommender` for existing codebases.)
-
-If `QS_IS_RERUN=true`, display the gap-fill summary and stop:
-```
-✅ Re-run complete.
-
-Commands status:
-  ✓ Already installed: /specrails:<name>
-  ✓ Added /specrails:<name> (was missing)
-  [... one line per command ...]
-
-All commands are up to date.
-```
-If all commands were already present, display:
-```
-✅ Re-run complete. All commands already installed — nothing to add.
-```
-
-Then stop. Do not execute Phase 1.
-
----
-
-## Phase 1: Codebase Analysis
-
-Analyze the repository to understand its architecture, stack, and conventions.
-
-### 1.1 Read project structure
-
-```bash
-# Get the repo root and basic info
-git rev-parse --show-toplevel
-ls -la
-```
-
-Read the following to understand the project:
-- `README.md` (if exists)
-- `CLAUDE.md` (if exists — don't overwrite, merge later)
-- `package.json` or `pyproject.toml` or `Cargo.toml` or `go.mod` or `pom.xml` (detect stack)
-- `.github/workflows/*.yml` (detect CI commands)
-- `docker-compose.yml` or `Dockerfile` (detect infra)
-
-### 1.2 Detect architecture layers
-
-Use Glob and Grep to identify:
-
-1. **Languages**: Check for `*.py`, `*.ts`, `*.tsx`, `*.go`, `*.rs`, `*.java`, `*.kt`, `*.rb`, `*.cs`
-2. **Frameworks**: Search for imports (`fastapi`, `express`, `react`, `vue`, `angular`, `django`, `spring`, `gin`, `actix`, `rails`)
-3. **Directory structure**: Identify backend/frontend/core/test directories
-4. **Database**: Check for SQL files, ORM configs, migration directories
-5. **CI/CD**: Parse workflow files for lint/test/build commands
-
-### 1.3 Infer conventions
-
-Read 3-5 representative source files from each detected layer to understand:
-- Naming conventions (camelCase, snake_case, PascalCase)
-- Import patterns
-- Error handling patterns
-- Testing patterns (framework, structure, mocking approach)
-- API patterns (REST, GraphQL, tRPC)
-
-### 1.4 Present findings
-
-Display the detected architecture to the user:
-
-```
-## Codebase Analysis
-
-| Layer       | Tech                | Path          |
-|-------------|---------------------|---------------|
-| Backend     | FastAPI (Python)    | backend/      |
-| Frontend    | React + TypeScript  | frontend/     |
-| Core        | Python package      | src/          |
-| Tests       | pytest              | tests/        |
-| Database    | PostgreSQL          | migrations/   |
-
-### CI Commands Detected
-- Lint: `ruff check .`
-- Format: `ruff format --check .`
-- Test: `pytest tests/ -q`
-- Frontend lint: `npm run lint`
-- Frontend build: `npx tsc --noEmit`
-
-### Conventions Detected
-- Python: snake_case, type hints, Pydantic models
-- TypeScript: strict mode, functional components
-- Testing: pytest fixtures with scope="function"
-
-### OSS Project Detection
-
-Read `.specrails/setup-templates/.oss-detection.json` if it exists.
-
-| Signal | Status |
-|--------|--------|
-| Public repository | [Yes / No / Unknown] |
-| CI workflows (.github/workflows/) | [Yes / No] |
-| CONTRIBUTING.md | [Yes / No] |
-| **Result** | **OSS detected / Not detected / Could not check** |
-
-If `is_oss: false` but at least one signal is `true`:
-> "Some OSS signals were found but not all three. Is this an open-source project? (yes/no)"
-
-If `.oss-detection.json` does not exist:
-> "Is this an open-source project? (yes/no)"
-
-When `IS_OSS=false` and no signals are present, skip OSS output entirely to avoid cluttering the display for non-OSS projects.
-
-Store the final OSS determination as `IS_OSS` for use throughout the rest of setup.
-
-[Confirm] [Modify] [Rescan]
-```
-
-Wait for user confirmation. If they want to modify, ask what to change.
-
----
-
-## Phase 2: User Personas & Product Discovery
-
-### 2.1 Ask about target users
-
-Ask the user:
-
-> If IS_OSS=true, prepend:
-> "This is an OSS project. The **Maintainer** persona (Kai) is automatically included —
-> you do not need to add 'open-source maintainers' to your list.
-> Describe your other target user types below."
-
-> **Who are the target users of your software?**
->
-> Describe them in natural language. Examples:
-> - "Developers who manage Kubernetes clusters"
-> - "Small business owners tracking inventory and sales"
-> - "Gamers who collect and trade digital items"
->
-> I'll research the competitive landscape and create detailed personas
-> with Value Proposition Canvas profiles for each user type.
->
-> **How many distinct user types do you have?** (typically 2-3)
-
-Wait for the user's response.
-
-### 2.2 Research competitive landscape
-
-For each user type described, use WebSearch to research:
-
-1. **Existing tools** they use today (competitors)
-2. **Common pain points** reported in forums, Reddit, product reviews
-3. **Feature gaps** in current tools
-4. **Unmet needs** and workflow frustrations
-
-Search queries to use (adapt to the domain):
-- `"[domain] [user type] best tools 2025"`
-- `"[domain] [user type] pain points frustrations"`
-- `"[competitor name] missing features complaints"`
-- `"[domain] management app feature comparison"`
-- `site:reddit.com "[domain] [user type] what tool do you use"`
-
-### 2.3 Generate VPC personas
-
-For each user type, generate a full Value Proposition Canvas persona file following the template at `.specrails/setup-templates/personas/persona.md`.
-
-Each persona must include:
-- **Profile**: Demographics, behaviors, tools used, spending patterns
-- **Customer Jobs**: Functional, social, emotional (6-8 jobs)
-- **Pains**: Graded by severity (Critical > High > Medium > Low) with 6-8 entries
-- **Gains**: Graded by impact (High > Medium > Low) with 6-8 entries
-- **Key Insight**: The #1 unmet need that this project can address
-- **Sources**: Links to competitive analysis, forums, reviews used in research
-
-### 2.4 Present personas
-
-Display each generated persona to the user:
-
-```
-## Generated Personas
-
-### Persona 1: "[Nickname]" — The [Role]
-- Age: X-Y
-- Key pain: [Critical pain]
-- Key insight: [Main unmet need]
-
-### Persona 2: "[Nickname]" — The [Role]
-- Age: X-Y
-- Key pain: [Critical pain]
-- Key insight: [Main unmet need]
-
-[Accept] [Edit] [Regenerate]
-```
-
-Wait for confirmation. If the user wants edits, apply them.
-
-### 2.5 Initialize agent config
-
-Check for `.specrails/agents.yaml`:
-
-1. If the file **exists**:
-   - Read it
-   - Validate all `model:` values — only `opus`, `sonnet`, and `haiku` are valid
-   - If any value is invalid, warn the user and fall back to the template default for that agent
-   - Store as `AGENTS_CONFIG` for use in Phase 4
-
-2. If the file **does not exist**:
-   - Generate it with the default model assignments matching the template hard-coded values:
-
-   ```yaml
-   # specrails agent configuration
-   # Modify model assignments and other agent settings
-   # Valid models: opus, sonnet, haiku
-
-   defaults:
-     model: sonnet
-
-   agents:
-     sr-architect:
-       model: sonnet
-     sr-developer:
-       model: sonnet
-     sr-reviewer:
-       model: sonnet
-     sr-product-manager:
-       model: opus
-     sr-product-analyst:
-       model: haiku
-     sr-test-writer:
-       model: sonnet
-     sr-security-reviewer:
-       model: sonnet
-     sr-backend-developer:
-       model: sonnet
-     sr-frontend-developer:
-       model: sonnet
-     sr-backend-reviewer:
-       model: sonnet
-     sr-frontend-reviewer:
-       model: sonnet
-     sr-doc-sync:
-       model: sonnet
-     sr-merge-resolver:
-       model: sonnet
-     sr-performance-reviewer:
-       model: sonnet
-   ```
-
-   - Write this file to `.specrails/agents.yaml`
-   - Store as `AGENTS_CONFIG` for use in Phase 4
-   - Log: "Generated `.specrails/agents.yaml` with default model assignments"
-
----
-
-## Phase 3: Configuration
-
-### 3.1 Agents to install
-
-Present the available agents and let the user choose:
-
-```
-## Agent Selection
-
-Which agents do you want to install?
-
-| Agent | Purpose | Model | Required |
-|-------|---------|-------|----------|
-| sr-architect | Design features, create implementation plans | Sonnet | Yes |
-| sr-developer (full-stack) | Implement features across all layers | Sonnet | Yes |
-| sr-reviewer | CI/CD quality gate, fix issues | Sonnet | Yes |
-| sr-test-writer | Generate unit, integration, and edge-case tests after implementation | Sonnet | Yes |
-| sr-security-reviewer | Scan for secrets, OWASP vulnerabilities, hardcoded credentials | Sonnet | Yes |
-| sr-product-manager | Product discovery, ideation, VPC evaluation | Opus | Recommended |
-| sr-product-analyst | Read-only backlog analysis | Haiku | Recommended |
-| sr-backend-developer | Specialized backend implementation | Sonnet | If backend layer exists |
-| sr-frontend-developer | Specialized frontend implementation | Sonnet | If frontend layer exists |
-
-[All] [Required only] [Custom selection]
-```
-
-### 3.2 Backlog provider
-
-Ask the user how they want to manage their product backlog. Default is local — no external tools or accounts required:
-
-```
-## Backlog Provider
-
-Use local ticket management or connect an external provider?
-
-1. **Local tickets** (default, recommended) — lightweight JSON-based ticket management built into the project.
-   No external tools or accounts required. Tickets stored in `.specrails/local-tickets.json`, version-controlled and diffable.
-2. **External provider** — connect GitHub Issues, JIRA, or disable backlog commands
-```
-
-If the user selects **1** or presses Enter without typing anything: set `BACKLOG_PROVIDER=local` and proceed directly to **If Local Tickets** below. Do NOT ask about GitHub CLI, JIRA credentials, or any external provider configuration.
-
-If the user selects **2**: display the secondary menu:
-
-```
-## External Backlog Provider
-
-Which external provider?
-
-1. **Local tickets** (recommended) — lightweight JSON-based ticket management built into the project.
-   No external tools required. Tickets stored in `.specrails/local-tickets.json`, version-controlled and diffable.
-2. **GitHub Issues** — uses `gh` CLI to read/create issues with labels and VPC scores
-3. **JIRA** — uses JIRA CLI or REST API to read/create tickets in a JIRA project
-4. **None** — skip backlog commands (you can still use /implement with text descriptions)
-```
-
-Wait for the user's choice. Set `BACKLOG_PROVIDER` to `local`, `github`, `jira`, or `none`.
-
-#### If Local Tickets
-
-No external tools or credentials required. Initialize the storage file:
-
-1. Copy `templates/local-tickets-schema.json` to `.specrails/local-tickets.json`
-2. Set `last_updated` to the current ISO-8601 timestamp
-
-Store configuration in `.specrails/backlog-config.json`:
-```json
-{
-  "provider": "local",
-  "write_access": true,
-  "git_auto": true
-}
-```
-
-Local tickets are always read-write — there is no "read only" mode since the file is local.
-
-**Ticket schema** — each entry in the `tickets` map has these fields:
-
-```json
-{
-  "id": 1,
-  "title": "Feature title",
-  "description": "Markdown description",
-  "status": "todo",
-  "priority": "medium",
-  "labels": ["area:frontend", "effort:medium"],
-  "assignee": null,
-  "prerequisites": [],
-  "metadata": {
-    "vpc_scores": {},
-    "effort_level": "Medium",
-    "user_story": "",
-    "area": ""
-  },
-  "comments": [],
-  "created_at": "<ISO-8601>",
-  "updated_at": "<ISO-8601>",
-  "created_by": "user",
-  "source": "manual"
-}
-```
-
-**Status values:** `todo`, `in_progress`, `done`, `cancelled`
-**Priority values:** `critical`, `high`, `medium`, `low`
-**Labels:** Freeform strings following the `area:*` and `effort:*` convention
-**Source values:** `manual`, `get-backlog-specs`, `propose-spec`
-
-**Advisory file locking protocol** (CLI agents and desktop app server must both follow this):
-
-The `revision` counter in the JSON root enables optimistic concurrency — increment it on **every** write. The lock file prevents concurrent corruption:
-
-1. **Acquire lock:** Check for `.specrails/local-tickets.json.lock`
-   - If the file exists and its `timestamp` is less than 30 seconds old: wait 500ms and retry (max 5 attempts before aborting with an error)
-   - If the file exists and its `timestamp` is 30+ seconds old (stale): delete it and proceed
-   - If no lock file exists: proceed immediately
-2. **Create lock file:** Write `{"agent": "<agent-name-or-process>", "timestamp": "<ISO-8601>"}` to `.specrails/local-tickets.json.lock`
-3. **Minimal lock window:** Read the JSON → modify in memory → write back → release
-4. **Release lock:** Delete `.specrails/local-tickets.json.lock`
-5. **Always increment `revision`** by 1 and update `last_updated` on every successful write
-
-The desktop app server uses `proper-lockfile` (or equivalent) to honor the same protocol via the `.lock` file path.
-
-#### If GitHub Issues
-
-- Verify `gh auth status` works. If not, warn and offer to skip.
-- Ask about **access mode**:
-
-```
-## GitHub Issues — Access Mode
-
-How should we interact with GitHub Issues?
-
-1. **Read & Write** (default) — read backlog, create new issues from product discovery,
-   close resolved issues, add comments on partial progress
-2. **Read only** — read backlog for prioritization, but don't create or modify issues.
-   Product discovery will propose ideas as output but won't sync them to GitHub.
-```
-
-Set `BACKLOG_WRITE=true/false`.
-
-- If write mode, ask if they want to create labels:
-  - `product-driven-backlog` (purple) — product feature ideas
-  - `area:*` labels for each detected layer/area
-  - `enhancement`, `bug`, `tech-debt`
-
-#### If JIRA
-
-First, check if JIRA CLI is installed:
-
-```bash
-command -v jira &> /dev/null
-```
-
-If not installed, offer to install it:
-
-> JIRA CLI is not installed. There are several options:
->
-> 1. **go-jira** (recommended) — lightweight CLI
->    - macOS: `brew install go-jira`
->    - Linux/other: `go install github.com/go-jira/jira/cmd/jira@latest`
-> 2. **Atlassian CLI** — official but heavier
->    - `npm install -g @atlassian/cli`
-> 3. **Skip CLI, use REST API** — no CLI needed, uses `curl` with API token
->
-> Which option? (1/2/3)
-
-If the user chooses option 1 or 2, run the install command. If option 3, proceed with REST API mode.
-
-Then ask for JIRA configuration:
-
-> To connect to JIRA, I need:
->
-> 1. **JIRA base URL** (e.g., `https://your-company.atlassian.net`)
-> 2. **Project key** (e.g., `PROJ`, `DECK`, `MYAPP`)
-> 3. **Authentication method**:
->    - **JIRA CLI** (`jira` command) — if already configured
->    - **API token** — stored in `.env` as `JIRA_API_TOKEN` and `JIRA_USER_EMAIL`
->
-> Optional:
-> - **Custom issue type** for backlog items (default: "Story")
-> - **Custom fields** for VPC scores (or use labels/description)
-
-Then ask about **access mode**:
-
-```
-## JIRA — Access Mode
-
-How should we interact with JIRA?
-
-1. **Read & Write** — read tickets for implementation context, create new tickets
-   from product discovery, add a comment to tickets when implementation is complete
-2. **Read only** — read tickets for implementation context, but never create or
-   modify tickets. Product discovery will propose ideas as output only. After
-   implementation, the pipeline will show what to update manually but won't
-   touch JIRA.
-```
-
-Set `BACKLOG_WRITE=true/false`.
-
-<!-- This command is mirrored from commands/enrich.md for staged installs. -->
-
-#### Project Label
-
-After the access mode selection, ask:
-
-> **Project Label (optional but recommended)**
->
-> JIRA teams often tag all tickets for a product with a project label
-> (e.g., `PROJECT-specrails`, `PLATFORM`, `MOBILE`). This label is applied
-> to every ticket the backlog pipeline creates — making it easy to filter all
-> AI-generated backlog items across JIRA.
->
-> Enter a project label, or press Enter to skip:
-
-If the user enters a label: set `PROJECT_LABEL=<value>`.
-If the user skips: set `PROJECT_LABEL=""`.
-
-#### Epic Link Field
-
-Ask:
-
-> **Epic Link Field (optional — advanced)**
->
-> JIRA Next-Gen (team-managed) projects link stories to epics using the `parent`
-> field. JIRA Classic (company-managed) projects use `Epic Link` (customfield_10014).
->
-> Which does your project use?
-> 1. `parent` — Next-Gen / team-managed **(default)**
-> 2. `customfield_10014` — Classic / company-managed
-
-Set `EPIC_LINK_FIELD` to `parent` or `customfield_10014`. Default: `parent`.
-
-Store the full configuration in `.specrails/backlog-config.json`:
-```json
-{
-  "provider": "jira",
-  "write_access": true,
-  "jira_base_url": "https://your-company.atlassian.net",
-  "jira_project_key": "PROJ",
-  "issue_type": "Story",
-  "auth_method": "api_token",
-  "cli_installed": true,
-  "project_label": "<PROJECT_LABEL or empty string>",
-  "epic_link_field": "parent",
-  "epic_mapping": {}
-}
-```
-
-#### If None
-
-- Skip `/specrails:get-backlog-specs` and `/specrails:auto-propose-backlog-specs` commands.
-- The `/specrails:implement` command will still work with text descriptions.
-
-### 3.3 Git & shipping workflow
-
-Ask how the user wants to handle git operations after implementation:
-
-```
-## Git & Shipping
-
-After implementation is complete, how should we handle shipping?
-
-1. **Automatic** (default) — create branch, commit changes, push, and open a PR
-   (requires GitHub CLI for PRs, otherwise prints a compare URL)
-2. **Manual** — stop after implementation and review. You handle branching,
-   committing, and PR creation yourself. The pipeline will show a summary
-   of all changes but won't touch git.
-```
-
-Set `GIT_AUTO=true/false`.
-
-If automatic, also check if `gh` is authenticated (for PR creation). If not, warn that PRs will be skipped but commits and push will still work.
-
-### 3.4 Commands to install
-
-```
-## Command Selection
-
-| Command | Purpose | Requires |
-|---------|---------|----------|
-| /specrails:implement | Full pipeline: sr-architect → sr-developer → sr-reviewer → ship | sr-architect + sr-developer + sr-reviewer |
-| /specrails:batch-implement | Orchestrate multiple features in dependency-aware waves | sr-architect + sr-developer + sr-reviewer |
-| /specrails:propose-spec | Interactively propose and refine a feature spec, then create a GitHub issue | GitHub CLI |
-| /specrails:get-backlog-specs | View prioritized backlog with VPC scores | sr-product-analyst + Backlog provider |
-| /specrails:auto-propose-backlog-specs | Generate new feature ideas via product discovery | sr-product-manager + Backlog provider |
-| /specrails:compat-check | Snapshot API surface and detect breaking changes | None |
-| /specrails:refactor-recommender | Scan for refactoring opportunities ranked by impact/effort | None |
-| /specrails:why | Search past architectural decisions from agent memory | None |
-
-[All] [Custom selection]
-```
-
-Note: If `BACKLOG_PROVIDER=none`, the backlog commands are not offered.
-
-### 3.5 Confirm configuration
-
-Display the full configuration summary including access modes:
-
-```
-## Configuration Summary
-
-| Setting | Value |
-|---------|-------|
-| Backlog provider | GitHub Issues / JIRA / None |
-| Backlog access | Read & Write / Read only |
-| Project label (JIRA) | PROJECT-specrails / (none) |
-| Epic link field (JIRA) | parent / customfield_10014 |
-| Git workflow | Automatic / Manual |
-| Agents | [list] |
-| Commands | [list] |
-| Personas | [count] personas |
-
-Note: The `Project label (JIRA)` and `Epic link field (JIRA)` rows are only shown when `BACKLOG_PROVIDER=jira`.
-
-[Confirm] [Modify]
-```
-
-Wait for final confirmation.
-
----
-
-## Phase 4: Generate Files
-
-Read each template from `.specrails/setup-templates/` and generate the final files adapted to this project. Use the codebase analysis from Phase 1, personas from Phase 2, and configuration from Phase 3.
-
-**Output base directory:** All output paths in Phase 4 use `.claude` as the base directory (`specrails_dir = ".claude"`).
-
-### 4.1 Generate agents
-
-For each selected agent, read the template and generate the adapted version.
-
-**Template → Output mapping:**
-
-- `.specrails/setup-templates/agents/sr-architect.md` → `.claude/agents/sr-architect.md`
-- `.specrails/setup-templates/agents/sr-developer.md` → `.claude/agents/sr-developer.md`
-- `.specrails/setup-templates/agents/sr-reviewer.md` → `.claude/agents/sr-reviewer.md`
-- `.specrails/setup-templates/agents/sr-test-writer.md` → `.claude/agents/sr-test-writer.md`
-- `.specrails/setup-templates/agents/sr-security-reviewer.md` → `.claude/agents/sr-security-reviewer.md`
-- `.specrails/setup-templates/agents/sr-product-manager.md` → `.claude/agents/sr-product-manager.md`
-- `.specrails/setup-templates/agents/sr-product-analyst.md` → `.claude/agents/sr-product-analyst.md`
-- `.specrails/setup-templates/agents/sr-backend-developer.md` → `.claude/agents/sr-backend-developer.md` (if backend layer)
-- `.specrails/setup-templates/agents/sr-frontend-developer.md` → `.claude/agents/sr-frontend-developer.md` (if frontend layer)
-
-When generating each agent:
-1. Read the template
-2. Replace all `{{PLACEHOLDER}}` values with project-specific content:
-   - `{{PROJECT_NAME}}` → project name
-   - `{{ARCHITECTURE_DIAGRAM}}` → detected architecture
-   - `{{LAYER_TAGS}}` → detected layer tags (e.g., `[backend]`, `[frontend]`, `[api]`, `[mobile]`)
-   - `{{CI_COMMANDS_BACKEND}}` → backend CI commands from Phase 1
-   - `{{CI_COMMANDS_FRONTEND}}` → frontend CI commands from Phase 1
-   - `{{LAYER_CONVENTIONS}}` → detected conventions per layer
-   - `{{PERSONA_NAMES}}` → names from generated personas
-   - `{{PERSONA_FILES}}` → paths to persona files
-   - `{{DOMAIN_EXPERTISE}}` → domain knowledge from Phase 2 research
-   - `{{COMPETITIVE_LANDSCAPE}}` → competitors discovered in Phase 2
-   - `{{KEY_FILE_PATHS}}` → important file paths detected in Phase 1
-   - `{{WARNINGS}}` → project-specific warnings (from existing CLAUDE.md or detected)
-   - `{{MEMORY_PATH}}` → agent memory directory path (e.g., `$SPECRAILS_DIR/agent-memory/sr-<agent-name>/`)
-   - `{{TECH_EXPERTISE}}` → detected languages, frameworks, and test frameworks from Phase 1
-   - `{{LAYER_CLAUDE_MD_PATHS}}` → comma-separated paths to per-layer rules files (e.g., `$SPECRAILS_DIR/rules/backend.md`, `$SPECRAILS_DIR/rules/frontend.md`)
-   - `{{SECURITY_EXEMPTIONS_PATH}}` → `$SPECRAILS_DIR/security-exemptions.yaml`
-3. Resolve the agent's model using `AGENTS_CONFIG` (loaded in Phase 2.5):
-   - Check `AGENTS_CONFIG.agents.<agent-name>.model` (per-agent override)
-   - If not present, check `AGENTS_CONFIG.defaults.model` (global default)
-   - If `AGENTS_CONFIG` was not loaded (e.g., re-run without config), use the model from the template frontmatter (current behavior)
-   - Replace the `model:` field in the YAML frontmatter with the resolved value before writing
-4. Write the final file as Markdown with YAML frontmatter — the template file as-is (frontmatter preserved).
-
-### 4.2 Generate personas
-
-If IS_OSS=true:
-1. Copy `.specrails/setup-templates/personas/the-maintainer.md` to `$SPECRAILS_DIR/agents/personas/the-maintainer.md`
-2. Log: "Maintainer persona included"
-3. Set MAINTAINER_INCLUDED=true for use in template substitution
-4. Set `{{MAINTAINER_PERSONA_LINE}}` = `- \`$SPECRAILS_DIR/agents/personas/the-maintainer.md\` — "Kai" the Maintainer (open-source maintainer)`
-5. Increment `{{PERSONA_COUNT}}` by 1 to account for the Maintainer
-
-If IS_OSS=false:
-- Set `{{MAINTAINER_PERSONA_LINE}}` = *(empty string)*
-
-Then for each user-defined VPC persona from Phase 2.3:
-
-Write each persona to `$SPECRAILS_DIR/agents/personas/`:
-- Use the VPC personas generated in Phase 2
-- File naming: kebab-case of persona nickname (e.g., `the-developer.md`, `the-admin.md`)
-
-### 4.3 Generate commands
-
-For each selected command, read the template and adapt.
-
-- `.specrails/setup-templates/commands/specrails/implement.md` → `.claude/commands/specrails/implement.md`
-- `.specrails/setup-templates/commands/specrails/batch-implement.md` → `.claude/commands/specrails/batch-implement.md`
-- `.specrails/setup-templates/commands/specrails/propose-spec.md` → `.claude/commands/specrails/propose-spec.md`
-- `.specrails/setup-templates/commands/specrails/get-backlog-specs.md` → `.claude/commands/specrails/get-backlog-specs.md` (if `BACKLOG_PROVIDER != none`)
-- `.specrails/setup-templates/commands/specrails/auto-propose-backlog-specs.md` → `.claude/commands/specrails/auto-propose-backlog-specs.md` (if `BACKLOG_PROVIDER != none`)
-- `.specrails/setup-templates/commands/specrails/compat-check.md` → `.claude/commands/specrails/compat-check.md`
-- `.specrails/setup-templates/commands/specrails/refactor-recommender.md` → `.claude/commands/specrails/refactor-recommender.md`
-- `.specrails/setup-templates/commands/specrails/why.md` → `.claude/commands/specrails/why.md`
-- `.specrails/setup-templates/commands/specrails/reconfig.md` → `.claude/commands/specrails/reconfig.md`
-
-Create the output directory before writing (`mkdir -p .claude/commands/specrails/`).
-
-Adapt:
-- CI commands to match detected stack
-- **Persona references** to match generated personas (see substitution rules below)
-- File paths to match project structure
-- Layer tags to match detected layers
-- **Backlog provider commands** based on `BACKLOG_PROVIDER`:
-
-#### Backlog command persona placeholder substitution
-
-When adapting `auto-propose-backlog-specs.md` and `get-backlog-specs.md`, substitute the persona placeholders based on the full persona set (user-generated personas + Maintainer if `IS_OSS=true`):
-
-| Placeholder | Substitution rule |
-|-------------|------------------|
-| `{{PERSONA_FILE_READ_LIST}}` | One bullet per persona file: `- Read \`$SPECRAILS_DIR/agents/personas/{name}.md\`` |
-| `{{PERSONA_SCORE_HEADERS}}` | Column headers for each persona nickname: e.g., `Alex \| Sara \| Kai` |
-| `{{PERSONA_SCORE_SEPARATORS}}` | One `------` separator per persona column |
-| `{{PERSONA_FIT_FORMAT}}` | Inline score display: e.g., `Alex: X/5, Sara: X/5, Kai: X/5` |
-| `{{PERSONA_VPC_SECTIONS}}` | One VPC section block per persona (see format below) |
-| `{{MAX_SCORE}}` | Total max score = 5 × number of personas (e.g., `15` for 3 personas) |
-| `{{PERSONA_NAMES_WITH_ROLES}}` | Comma-separated: e.g., `Alex (Lead Dev), Sara (Product Founder), Kai (OSS Maintainer)` |
-
-**`{{PERSONA_VPC_SECTIONS}}` format** — repeat for each persona in order:
-```
-### "{Nickname}" — The {Role} (X/5)
-- **Jobs addressed**: {list}
-- **Pains relieved**: {list with severity}
-- **Gains created**: {list with impact}
-```
-
-**Kai inclusion rule**: When `IS_OSS=true`, Kai (`sr-the-maintainer.md`) is always the last entry in persona lists and the rightmost column in scoring tables. Kai uses the evaluation criteria defined in `.claude/agents/personas/sr-the-maintainer.md` — features score high (4-5/5) for Kai when they reduce async review burden, enforce project-specific conventions, or automate release/dependency coordination; features score low (0-1/5) when they add configuration complexity or require paid tiers.
-
-**When `IS_OSS=false`**: All Kai-related persona references are omitted. `{{MAX_SCORE}}` reduces by 5. Tables and inline scores contain only user-generated personas.
-
-#### Local Tickets (`BACKLOG_PROVIDER=local`)
-
-For the local provider, backlog placeholders resolve to **inline file-operation instructions** embedded in the generated command markdown — not shell commands. Agents execute these by reading/writing `.specrails/local-tickets.json` directly using their file tools.
-
-All write operations must follow the **advisory file locking protocol** defined in Phase 3.2. Always increment `revision` and update `last_updated` on every write.
-
-| Placeholder | Substituted value |
-|-------------|-------------------|
-| `{{BACKLOG_PROVIDER_NAME}}` | `Local Tickets` |
-| `{{BACKLOG_PREFLIGHT}}` | `[[ -f ".specrails/local-tickets.json" ]] && echo "Local tickets storage: OK" \|\| echo "WARNING: .specrails/local-tickets.json not found — run /specrails:enrich to initialize"` |
-| `{{BACKLOG_FETCH_CMD}}` | Read `.specrails/local-tickets.json`. Parse the `tickets` map and return all entries where `status` is `"todo"` or `"in_progress"`. |
-| `{{BACKLOG_FETCH_ALL_CMD}}` | Read `.specrails/local-tickets.json`. Parse the `tickets` map and return all entries regardless of status. |
-| `{{BACKLOG_FETCH_CLOSED_CMD}}` | Read `.specrails/local-tickets.json`. Parse the `tickets` map and return all entries where `status` is `"done"` or `"cancelled"`. |
-| `{{BACKLOG_VIEW_CMD}}` | Read `.specrails/local-tickets.json`. Parse JSON and return the full ticket object at `tickets["{id}"]`, or an error if not found. |
-| `{{BACKLOG_CREATE_CMD}}` | Write to `.specrails/local-tickets.json` using the advisory locking protocol: acquire lock → read file → set `id = next_id`, increment `next_id`, set all ticket fields, set `created_at` and `updated_at` to now, bump `revision`, update `last_updated` → write → release lock. |
-| `{{BACKLOG_UPDATE_CMD}}` | Write to `.specrails/local-tickets.json` using the advisory locking protocol: acquire lock → read file → update fields in `tickets["{id}"]`, set `updated_at` to now, bump `revision`, update `last_updated` → write → release lock. |
-| `{{BACKLOG_DELETE_CMD}}` | Write to `.specrails/local-tickets.json` using the advisory locking protocol: acquire lock → read file → delete `tickets["{id}"]`, bump `revision`, update `last_updated` → write → release lock. |
-| `{{BACKLOG_COMMENT_CMD}}` | Write to `.specrails/local-tickets.json` using the advisory locking protocol: acquire lock → read file → append `{"author": "<agent-name>", "body": "<comment>", "created_at": "<ISO-8601>"}` to `tickets["{id}"].comments` (create the array if absent), set `updated_at` to now, bump `revision`, update `last_updated` → write → release lock. |
-| `{{BACKLOG_PARTIAL_COMMENT_CMD}}` | Same as `{{BACKLOG_COMMENT_CMD}}` but append `{"author": "<agent-name>", "body": "<comment>", "type": "progress", "created_at": "<ISO-8601>"}`. |
-| `{{BACKLOG_INIT_LABELS_CMD}}` | No label initialization required. Local tickets use freeform label strings. Standard label conventions: `area:frontend`, `area:backend`, `area:api`, `effort:low`, `effort:medium`, `effort:high`. |
-
-#### GitHub Issues (`BACKLOG_PROVIDER=github`)
-- Issue fetch: `gh issue list --label "product-driven-backlog" --state open --limit 100 --json number,title,labels,body`
-- Issue create: `gh issue create --title "..." --label "..." --body "..."`
-- Issue view: `gh issue view {number} --json number,title,labels,body`
-- Issue label names to match project areas
-- Pre-flight check: `gh auth status`
-
-#### JIRA (`BACKLOG_PROVIDER=jira`)
-- Issue fetch: `jira issue list --project {{JIRA_PROJECT_KEY}} --type Story --label get-backlog-specs --status "To Do" --plain` or equivalent JIRA REST API call via curl:
-  ```bash
-  curl -s -u "$JIRA_USER_EMAIL:$JIRA_API_TOKEN" \
-    "{{JIRA_BASE_URL}}/rest/api/3/search?jql=project={{JIRA_PROJECT_KEY}} AND labels=get-backlog-specs AND status='To Do'&fields=summary,description,labels,priority"
-  ```
-- Issue create: `jira issue create --project {{JIRA_PROJECT_KEY}} --type Story --summary "..." --label get-backlog-specs --description "..."` or equivalent REST API call
-- Issue view: `jira issue view {key}` or REST API
-- VPC scores stored in the issue description body (same markdown format, parsed from description)
-- Pre-flight check: `jira me` or test API connectivity
-- Store JIRA config in `.specrails/backlog-config.json`:
-  ```json
-  {
-    "provider": "jira",
-    "jira_base_url": "https://your-company.atlassian.net",
-    "jira_project_key": "PROJ",
-    "issue_type": "Story",
-    "auth_method": "api_token"
-  }
-  ```
-
-The command templates use `{{BACKLOG_FETCH_CMD}}`, `{{BACKLOG_CREATE_CMD}}`, `{{BACKLOG_VIEW_CMD}}`, `{{BACKLOG_PREFLIGHT}}`, and related placeholders that get filled with the provider-specific commands (for `local`) or instructions (for `github`, `jira`). The `{{BACKLOG_PROVIDER_NAME}}` placeholder is substituted with a human-readable provider label in all three cases.
-
-### 4.4 Generate rules
-
-For each detected layer, read the layer rule template and generate a layer-specific rules file:
-- `.specrails/setup-templates/rules/layer.md` → `$SPECRAILS_DIR/rules/{layer-name}.md`
-
-Each rule file must:
-- Have the correct `paths:` frontmatter matching the layer's directory
-- Contain conventions specific to that layer (from Phase 1 analysis)
-- Reference actual file paths and patterns from the codebase
-
-### 4.5 Generate root instructions file
-
-If no `CLAUDE.md` exists, generate one from the template. If one already exists, **merge** — add the agent workflow sections without removing existing content.
-
-### 4.6 Generate settings
-
-Create or merge `.claude/settings.json` with permissions for:
-- All detected CI commands
-- Git operations
-- OpenSpec CLI (if installed)
-- GitHub CLI (if available)
-- Language-specific tools (python, npm, cargo, go, etc.)
-
-### 4.7 Initialize agent memory
-
-Create memory directories for each installed agent using the provider-aware base directory:
-
-```bash
-mkdir -p $SPECRAILS_DIR/agent-memory/sr-{agent-name}/
-```
-
-Each gets an empty `MEMORY.md` that will be populated during usage.
-
----
-
-## Phase 5: Cleanup & Summary
-
-### 5.1 Remove all scaffolding artifacts
-
-The setup process installed temporary files that are only needed during installation. Remove them all now that the final files have been generated.
-
-```bash
-# 1. Remove setup templates (used as structural references during generation)
-rm -rf .specrails/setup-templates/
-
-# 2. Remove the /specrails:enrich command itself — it's a one-time installer, not a permanent command
-rm -f .claude/commands/enrich.md
-
-# 3. Remove the specrails/ directory from the repo if it exists at the root
-#    (it was only needed for the retired shell installer and staging templates — everything is now in .claude/)
-#    NOTE: Only remove if it's inside this repo. Ask the user if unsure.
-```
-
-**What gets removed:**
-| Artifact | Why |
-|----------|-----|
-| `.specrails/setup-templates/` | Temporary — templates already rendered into final files |
-| `.claude/commands/enrich.md` | One-time installer — running it again would overwrite customized agents |
-
-**What to do with `specrails/`:**
-
-The `specrails/` directory should NOT be committed to the target repo — it's an installer tool, not part of the project. Always add it to `.gitignore`:
-
-```bash
-# Add specrails/ to .gitignore if not already there
-if ! grep -q '^specrails/' .gitignore 2>/dev/null; then
-  echo '' >> .gitignore
-  echo '# specrails installer (one-time setup tool, not part of the project)' >> .gitignore
-  echo 'specrails/' >> .gitignore
-fi
-```
-
-Then ask the user:
-
-> `specrails/` has been added to `.gitignore`. Do you also want to delete it?
->
-> 1. **Keep it** (default) — stays locally in case you want to re-run setup or install in other repos
-> 2. **Delete it** — everything is installed, you don't need it anymore
-
-Apply the user's choice.
-
-### 5.2 Verify clean state
-
-After cleanup, verify that only the intended files remain:
-
-```bash
-# These should exist (the actual system):
-ls .claude/agents/sr-*.md
-ls .claude/agents/personas/*.md
-ls .claude/commands/specrails/*.md
-ls .claude/rules/*.md
-ls .claude/agent-memory/
-
-# These should NOT exist (scaffolding):
-# .specrails/setup-templates/  — GONE
-# .claude/commands/enrich.md  — GONE
-```
-
-If any scaffolding artifact remains, remove it.
-
-### 5.3 Summary
-
-Display the complete installation summary:
-
-```
-## Setup Complete
-
-### Agents Installed
-| Agent | File | Model |
-|-------|------|-------|
-| sr-architect | .claude/agents/sr-architect.md | Sonnet |
-| sr-developer | .claude/agents/sr-developer.md | Sonnet |
-| sr-reviewer | .claude/agents/sr-reviewer.md | Sonnet |
-| sr-test-writer | .claude/agents/sr-test-writer.md | Sonnet |
-| sr-security-reviewer | .claude/agents/sr-security-reviewer.md | Sonnet |
-| sr-product-manager | .claude/agents/sr-product-manager.md | Opus |
-
-### Personas Created
-| Persona | File | Source |
-|---------|------|--------|
-[If IS_OSS=true:]
-| "Kai" — The Maintainer | $SPECRAILS_DIR/agents/personas/sr-the-maintainer.md | Auto-included (OSS) |
-[For each user-generated persona:]
-| "[Name]" — The [Role] | $SPECRAILS_DIR/agents/personas/[name].md | Generated |
-
-### Commands Installed
-| Command | File |
-|---------|------|
-| /specrails:implement | .claude/commands/specrails/implement.md |
-| /specrails:batch-implement | .claude/commands/specrails/batch-implement.md |
-| /specrails:propose-spec | .claude/commands/specrails/propose-spec.md |
-| /specrails:get-backlog-specs | .claude/commands/specrails/get-backlog-specs.md |
-| /specrails:auto-propose-backlog-specs | .claude/commands/specrails/auto-propose-backlog-specs.md |
-| /specrails:compat-check | .claude/commands/specrails/compat-check.md |
-| /specrails:refactor-recommender | .claude/commands/specrails/refactor-recommender.md |
-| /specrails:why | .claude/commands/specrails/why.md |
-
-Note: Only commands selected during setup are shown. Backlog commands are excluded if no backlog provider was configured.
-
-### Rules Created
-| Layer | File |
-|-------|------|
-| Backend | $SPECRAILS_DIR/rules/backend.md |
-| Frontend | $SPECRAILS_DIR/rules/frontend.md |
-
-### Scaffolding Removed
-| Artifact | Status |
-|----------|--------|
-| .specrails/setup-templates/ | Deleted |
-| .claude/commands/enrich.md | Deleted |
-| specrails/ | [User's choice] |
-
-### Next Steps
-1. Review the generated files in .claude/
-2. Run `/specrails:get-backlog-specs` to see your backlog (if GitHub Issues exist)
-3. Run `/specrails:auto-propose-backlog-specs` to generate feature ideas
-4. Run `/specrails:implement #issue-number` to implement a feature
-5. Commit the .claude/ directory to version control
-
-### Quick Start
-- `/specrails:implement "describe a feature"` — implement something right now
-- `/specrails:get-backlog-specs` — see prioritized feature ideas
-- `/specrails:auto-propose-backlog-specs` — discover new features using VPC
-```
-
-## First Task Prompt (Full Wizard)
-
-After displaying the setup complete summary above, detect the project type and output:
-
-**New project** (no `package.json`, `Gemfile`, `pyproject.toml`, `go.mod`, or `pom.xml` in root):
-```
-✅ Setup complete.
-
-Try your first spec:
-  > /specrails:get-backlog-specs
-```
-
-**Existing codebase** (one or more of the above files found in root):
-```
-✅ Setup complete.
-
-Try your first spec:
-  > /specrails:refactor-recommender
-```
-
-Then stop.