specrails-core 3.0.0 → 3.2.0

package/commands/setup.md

@@ -314,21 +314,14 @@ When no flags are passed (the default), run this streamlined 3-question setup. D
 
 ### QS1: Ask the 3 questions
 
-Ask exactly these questions in sequence. Do not ask any other questions.
+Display the following prompt EXACTLY ONCE and then wait for the user's responses. Do NOT repeat the questions — output them a single time only.
 
-```
 Welcome to specrails! Let's get your AI agent team set up in 3 quick questions.
 
 1. What is this project? (one sentence)
-   > _
-
 2. Who are the target users?
-   > _
-
 3. Git access for agents — read-only or read-write?
    (read-only = agents can read and suggest; read-write = agents can commit)
-   > _
-```
 
 Store the answers as:
 - `QS_PROJECT_DESCRIPTION` — answer to question 1
@@ -696,12 +689,78 @@ Ask the user where they manage their product backlog:
 
 Where do you track your product backlog?
 
-1. **GitHub Issues** — uses `gh` CLI to read/create issues with labels and VPC scores
-2. **JIRA** — uses JIRA CLI or REST API to read/create tickets in a JIRA project
-3. **None** — skip backlog commands (you can still use /implement with text descriptions)
+1. **Local tickets** (recommended) — lightweight JSON-based ticket management built into the project.
+   No external tools required. Tickets stored in `.claude/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 `github`, `jira`, or `none`.
+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_DIR/local-tickets.json`
+2. Set `last_updated` to the current ISO-8601 timestamp
+
+Store configuration in `$SPECRAILS_DIR/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`, `product-backlog`, `propose-spec`
+
+**Advisory file locking protocol** (CLI agents and hub 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_DIR/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_DIR/local-tickets.json.lock`
+3. **Minimal lock window:** Read the JSON → modify in memory → write back → release
+4. **Release lock:** Delete `$SPECRAILS_DIR/local-tickets.json.lock`
+5. **Always increment `revision`** by 1 and update `last_updated` on every successful write
+
+The hub server uses `proper-lockfile` (or equivalent) to honor the same protocol via the `.lock` file path.
 
 #### If GitHub Issues
 
@@ -1066,6 +1125,27 @@ When adapting `update-product-driven-backlog.md` and `product-backlog.md`, subst
 
 **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_DIR/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_DIR/local-tickets.json" ]] && echo "Local tickets storage: OK" \|\| echo "WARNING: $SPECRAILS_DIR/local-tickets.json not found — run /setup to initialize"` |
+| `{{BACKLOG_FETCH_CMD}}` | Read `$SPECRAILS_DIR/local-tickets.json`. Parse the `tickets` map and return all entries where `status` is `"todo"` or `"in_progress"`. |
+| `{{BACKLOG_FETCH_ALL_CMD}}` | Read `$SPECRAILS_DIR/local-tickets.json`. Parse the `tickets` map and return all entries regardless of status. |
+| `{{BACKLOG_FETCH_CLOSED_CMD}}` | Read `$SPECRAILS_DIR/local-tickets.json`. Parse the `tickets` map and return all entries where `status` is `"done"` or `"cancelled"`. |
+| `{{BACKLOG_VIEW_CMD}}` | Read `$SPECRAILS_DIR/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_DIR/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_DIR/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_DIR/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_DIR/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 "..."`
@@ -1094,7 +1174,7 @@ When adapting `update-product-driven-backlog.md` and `product-backlog.md`, subst
   }
   ```
 
-The command templates use `{{BACKLOG_FETCH_CMD}}`, `{{BACKLOG_CREATE_CMD}}`, `{{BACKLOG_VIEW_CMD}}`, and `{{BACKLOG_PREFLIGHT}}` placeholders that get filled with the provider-specific commands.
+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
 

package/install.sh

@@ -44,6 +44,7 @@ SPECRAILS_DIR=""
 INSTRUCTIONS_FILE=""
 HAS_CLAUDE=false
 HAS_CODEX=false
+AGENT_TEAMS=false
 
 while [[ $# -gt 0 ]]; do
     case "$1" in
@@ -98,7 +99,7 @@ if [[ -z "$CUSTOM_ROOT_DIR" && -f "$SCRIPT_DIR/install.sh" && -d "$SCRIPT_DIR/te
     echo -e "${YELLOW}⚠${NC}  You're running the installer from inside the specrails source repo."
     echo -e "   specrails installs into a ${BOLD}target${NC} repository, not into itself."
     echo ""
-    read -p "   Enter the path to the target repo (or 'q' to quit): " TARGET_PATH
+    read -p "   Enter the path to the target repo (or 'q' to quit): " TARGET_PATH || TARGET_PATH="q"
     if [[ "$TARGET_PATH" == "q" || -z "$TARGET_PATH" ]]; then
         echo "   Aborted. No changes made."
         exit 0
@@ -229,7 +230,7 @@ elif [ "$HAS_CLAUDE" = true ] && [ "$HAS_CODEX" = true ]; then
         echo "      1) Claude Code (claude)  → output to .claude/"
         echo "      2) Codex (codex)         → output to .codex/"
         echo ""
-        read -p "    Select provider (1 or 2, default: 1): " PROVIDER_CHOICE
+        read -p "    Select provider (1 or 2, default: 1): " PROVIDER_CHOICE || PROVIDER_CHOICE="1"
         PROVIDER_CHOICE="${PROVIDER_CHOICE:-1}"
         if [[ "$PROVIDER_CHOICE" == "2" ]]; then
             CLI_PROVIDER="codex"
@@ -266,6 +267,35 @@ else
     INSTRUCTIONS_FILE="CLAUDE.md"
 fi
 
+# 1.2b Agent Teams opt-in (Claude Code only)
+if [[ "$CLI_PROVIDER" == "claude" ]]; then
+    echo ""
+    if [ "$AUTO_YES" = true ]; then
+        # --yes flag: default to NOT installing (opt-in, not opt-out)
+        AGENT_TEAMS=false
+        info "Agent Teams commands: skipped (opt-in, use interactive mode to enable)"
+    else
+        echo -e "  ${BOLD}Agent Teams commands are available (experimental):${NC}"
+        echo "    /sr:team-review — Multi-perspective code review with AI reviewers"
+        echo "    /sr:team-debug  — Collaborative debugging with competing hypotheses"
+        echo ""
+        echo "  These require Claude Code Agent Teams (experimental feature)."
+        read -p "  Install Agent Teams commands? (y/n, default: n): " INSTALL_AGENT_TEAMS || INSTALL_AGENT_TEAMS="n"
+        if [[ "$INSTALL_AGENT_TEAMS" == "y" || "$INSTALL_AGENT_TEAMS" == "Y" ]]; then
+            AGENT_TEAMS=true
+            ok "Agent Teams commands will be installed"
+            echo ""
+            info "Remember to set the feature flag before using these commands:"
+            echo ""
+            echo "    export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1"
+            echo ""
+        else
+            AGENT_TEAMS=false
+            info "Agent Teams commands: skipped"
+        fi
+    fi
+fi
+
 # 1.3 API key / authentication (provider-specific)
 if [[ "$CLI_PROVIDER" == "claude" ]]; then
     CLAUDE_AUTHED=false
@@ -334,7 +364,7 @@ elif [ -f "$REPO_ROOT/node_modules/.bin/openspec" ]; then
 else
     warn "OpenSpec CLI not found."
     if [ "$HAS_NPM" = true ]; then
-        if [ "$AUTO_YES" = true ]; then INSTALL_OPENSPEC="y"; else read -p "    Install OpenSpec CLI globally? (y/n): " INSTALL_OPENSPEC; fi
+        if [ "$AUTO_YES" = true ]; then INSTALL_OPENSPEC="y"; else read -p "    Install OpenSpec CLI globally? (y/n): " INSTALL_OPENSPEC || INSTALL_OPENSPEC="n"; fi
         if [ "$INSTALL_OPENSPEC" = "y" ] || [ "$INSTALL_OPENSPEC" = "Y" ]; then
             info "Installing OpenSpec CLI..."
             npm install -g @openspec/cli 2>/dev/null && {
@@ -439,7 +469,7 @@ fi
 if [ "$EXISTING_SETUP" = true ]; then
     echo ""
     warn "This repo already has some agent/command/openspec artifacts."
-    if [ "$AUTO_YES" = true ]; then CONTINUE="y"; else read -p "    Continue and merge with existing setup? (y/n): " CONTINUE; fi
+    if [ "$AUTO_YES" = true ]; then CONTINUE="y"; else read -p "    Continue and merge with existing setup? (y/n): " CONTINUE || CONTINUE="n"; fi
     if [ "$CONTINUE" != "y" ] && [ "$CONTINUE" != "Y" ]; then
         info "Aborted. No changes made."
         exit 0
@@ -521,7 +551,9 @@ chmod +x "$REPO_ROOT/.specrails/bin/doctor.sh"
 ok "Installed specrails doctor (bin/doctor.sh)"
 
 # Copy templates (includes commands, skills, agents, rules, personas, settings)
-cp -r "$SCRIPT_DIR/templates/"* "$REPO_ROOT/$SPECRAILS_DIR/setup-templates/"
+# Use tar to exclude node_modules and package-lock.json for performance
+tar -C "$SCRIPT_DIR/templates" --exclude='node_modules' --exclude='package-lock.json' -cf - . \
+    | tar -C "$REPO_ROOT/$SPECRAILS_DIR/setup-templates/" -xf -
 ok "Installed setup templates (commands + skills)"
 
 # Write OSS detection results for /setup
@@ -542,7 +574,8 @@ cat > "$REPO_ROOT/$SPECRAILS_DIR/setup-templates/.provider-detection.json" << EO
 {
   "cli_provider": "$CLI_PROVIDER",
   "specrails_dir": "$SPECRAILS_DIR",
-  "instructions_file": "$INSTRUCTIONS_FILE"
+  "instructions_file": "$INSTRUCTIONS_FILE",
+  "agent_teams": $AGENT_TEAMS
 }
 EOF
 ok "Provider detection results written ($CLI_PROVIDER → $SPECRAILS_DIR/)"
@@ -589,6 +622,10 @@ echo ""
 echo -e "${BOLD}${GREEN}Installation summary:${NC}"
 echo ""
 echo "  Provider: $CLI_PROVIDER → output to $SPECRAILS_DIR/"
+if [[ "$AGENT_TEAMS" == "true" ]]; then
+    echo "  Agent Teams: installed (/sr:team-review, /sr:team-debug)"
+    echo "  Feature flag: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 (required)"
+fi
 echo ""
 echo "  Files installed:"
 if [[ "$CLI_PROVIDER" == "codex" ]]; then

package/integration-contract.json

@@ -35,5 +35,11 @@
     "refactor-recommender",
     "health-check",
     "compat-check"
-  ]
+  ],
+  "ticketProvider": {
+    "type": "local",
+    "storageFile": "local-tickets.json",
+    "lockFile": "local-tickets.json.lock",
+    "capabilities": ["crud", "labels", "status", "priorities", "dependencies", "comments"]
+  }
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "specrails-core",
-  "version": "3.0.0",
+  "version": "3.2.0",
   "description": "AI agent workflow system for Claude Code — installs 12 specialized agents, orchestration commands, and persona-driven product discovery into any repository",
   "bin": {
     "specrails-core": "bin/specrails-core.js"
@@ -50,6 +50,10 @@
   "bugs": {
     "url": "https://github.com/fjpulidop/specrails-core/issues"
   },
+  "scripts": {
+    "test": "bash tests/run-all.sh",
+    "test:coverage": "bash tests/run-coverage.sh"
+  },
   "license": "MIT",
   "author": "fjpulidop"
 }

package/templates/commands/sr/implement.md

@@ -24,12 +24,22 @@ Check the environment variable `CLAUDE_CODE_ENTRYPOINT`. If it contains `remote_
 
 ### Checks to run (sequential, fail-fast)
 
-#### 1. GitHub CLI authentication
+#### 1. Backlog provider availability
 
+Read `.claude/backlog-config.json` and extract `BACKLOG_PROVIDER`.
+
+**If `BACKLOG_PROVIDER=local`:**
 ```bash
-gh auth status 2>&1
+[[ -f "$SPECRAILS_DIR/local-tickets.json" ]] && echo "Local tickets storage: OK" || echo "WARNING: local-tickets.json not found"
 ```
+- Set `LOCAL_TICKETS_AVAILABLE=true/false` based on file existence.
+- Set `GH_AVAILABLE=false` (GitHub CLI not needed for local provider).
+- Set `BACKLOG_AVAILABLE=true` if local-tickets.json exists.
 
+**Otherwise:**
+```bash
+gh auth status 2>&1
+```
 - Set `GH_AVAILABLE=true/false` for later phases.
 
 #### 2. OpenSpec CLI
@@ -107,7 +117,7 @@ Initialize conflict-tracking variables:
 - Set `SINGLE_MODE = true`. No worktrees, no parallelism.
 - **Skip Phase 1 and Phase 2** — go directly to Phase 3a.
 
-**If the user passed issue/ticket references** (e.g. `#85, #71` for GitHub or `PROJ-85, PROJ-71` for JIRA):
+**If the user passed issue/ticket references** (e.g. `#85, #71` for GitHub, `#1, #2` for local tickets, or `PROJ-85, PROJ-71` for JIRA):
 - Fetch each issue/ticket:
   ```bash
   {{BACKLOG_VIEW_CMD}}
@@ -120,7 +130,44 @@ Initialize conflict-tracking variables:
 
 After fetching issue refs, capture a baseline snapshot for conflict detection.
 
-**If `GH_AVAILABLE=true` and the input mode was issue numbers:**
+##### If `BACKLOG_PROVIDER=local` and input mode was issue numbers:
+
+For each resolved ticket ID, read `$SPECRAILS_DIR/local-tickets.json` and extract the ticket object at `tickets["{id}"]`.
+
+Build a snapshot object for each ticket:
+- `number`: ticket `id` (integer)
+- `title`: ticket `title` string
+- `state`: map ticket `status` — `"done"` or `"cancelled"` → `"closed"`, otherwise → `"open"`
+- `assignees`: `[ticket.assignee]` if non-null, else `[]`
+- `labels`: ticket `labels` array, sorted alphabetically
+- `body_sha`: SHA-256 of the ticket `description` string — compute with:
+  ```bash
+  echo -n "{description}" | sha256sum | cut -d' ' -f1
+  ```
+  If `sha256sum` is not available, fall back to `openssl dgst -sha256 -r` or `shasum -a 256`.
+- `updated_at`: ticket `updated_at` value
+- `captured_at`: current local time in ISO 8601 format
+
+Write the following JSON to `.claude/backlog-cache.json` (overwrite fully — this establishes a fresh baseline for this run):
+
+```json
+{
+  "schema_version": "1",
+  "provider": "local",
+  "last_updated": "<ISO 8601 timestamp>",
+  "written_by": "implement",
+  "issues": {
+    "<id>": { <snapshot object> },
+    ...
+  }
+}
+```
+
+If the write succeeds: set `SNAPSHOTS_CAPTURED=true`.
+
+If the write fails: print `[backlog-cache] Warning: could not write cache. Conflict detection disabled for this run.` and set `SNAPSHOTS_CAPTURED=false`. Do NOT abort the pipeline.
+
+##### If `GH_AVAILABLE=true` and input mode was issue numbers (GitHub/JIRA):
 
 For each resolved issue number, run:
 
@@ -161,9 +208,9 @@ If the write succeeds: set `SNAPSHOTS_CAPTURED=true`.
 
 If the write fails (e.g., `.claude/` directory does not exist): print `[backlog-cache] Warning: could not write cache. Conflict detection disabled for this run.` and set `SNAPSHOTS_CAPTURED=false`. Do NOT abort the pipeline.
 
-**If `GH_AVAILABLE=false` or input was not issue numbers:**
+##### Otherwise (no backlog available or non-issue input):
 
-Set `SNAPSHOTS_CAPTURED=false`. Print: `[conflict-check] Snapshot skipped — GH unavailable or non-issue input.`
+Set `SNAPSHOTS_CAPTURED=false`. Print: `[conflict-check] Snapshot skipped — backlog unavailable or non-issue input.`
 
 #### Gitignore advisory
 
@@ -267,7 +314,9 @@ Pick the single idea with the best impact/effort ratio from each exploration. Pr
 
 Otherwise, re-fetch each issue in scope and diff against the Phase 0 snapshot:
 
-For each issue number in `ISSUE_REFS`:
+**If `BACKLOG_PROVIDER=local`:** For each ticket ID in `ISSUE_REFS`, read `$SPECRAILS_DIR/local-tickets.json` and extract the ticket at `tickets["{id}"]`. If the ticket does not exist (deleted): treat as a CRITICAL conflict — field `"state"`, was `<cached state>`, now `"deleted"`. Otherwise, reconstruct a current snapshot using the same mapping as the Phase 0 local snapshot.
+
+**If `BACKLOG_PROVIDER=github`:** For each issue number in `ISSUE_REFS`:
 
 ```bash
 gh issue view {number} --json number,title,state,assignees,labels,body,updatedAt
@@ -275,7 +324,7 @@ gh issue view {number} --json number,title,state,assignees,labels,body,updatedAt
 
 If the `gh` command returns non-zero (issue deleted or inaccessible): treat as a CRITICAL conflict — field `"state"`, was `<cached state>`, now `"deleted"`.
 
-Otherwise, reconstruct a current snapshot (same shape as Phase 0: sort `assignees` and `labels`, compute `body_sha`).
+In both cases, reconstruct a current snapshot (same shape as Phase 0: sort `assignees` and `labels`, compute `body_sha`).
 
 **Short-circuit:** If `current.updatedAt == cached.updated_at`, mark the issue as clean and skip field comparison.
 
@@ -848,6 +897,9 @@ This check is independent of Phase 3a.0. Even if the user chose to continue thro
 
 Re-fetch each issue in `ISSUE_REFS` and diff against `.claude/backlog-cache.json` using the same algorithm as Phase 3a.0:
 
+**If `BACKLOG_PROVIDER=local`:** Read `$SPECRAILS_DIR/local-tickets.json` and extract each ticket by ID.
+
+**If `BACKLOG_PROVIDER=github`:**
 ```bash
 gh issue view {number} --json number,title,state,assignees,labels,body,updatedAt
 ```
@@ -881,8 +933,12 @@ Record skipped operations to `.cache-manifest.json` under `skipped_operations`:
 - `"git: commit"`
 - `"git: push"`
 - `"github: pr creation"` (if `GH_AVAILABLE=true`)
-- `"github: issue comment #N"` for each issue in scope (if `BACKLOG_WRITE=true`)
-- `"github: issue close #N (via PR merge)"` for each fully resolved issue (if `BACKLOG_WRITE=true`)
+- If `BACKLOG_PROVIDER=local` and `BACKLOG_WRITE=true`:
+  - `"local: ticket comment #{id}"` for each ticket in scope
+  - `"local: ticket status update #{id}"` for each fully resolved ticket
+- If `BACKLOG_PROVIDER=github` and `BACKLOG_WRITE=true`:
+  - `"github: issue comment #N"` for each issue in scope
+  - `"github: issue close #N (via PR merge)"` for each fully resolved issue
 
 Then skip the rest of Phase 4c and proceed directly to Phase 4e.
 
@@ -934,17 +990,19 @@ All implementation is complete and CI checks pass.
 #### Backlog updates (both modes)
 
 **If `BACKLOG_WRITE=true`:**
-- For fully resolved issues/tickets: add a comment noting completion and reference the PR. Do NOT close the issue explicitly — use `Closes #N` in the PR body so GitHub/JIRA closes it automatically when the PR is merged:
+- For fully resolved issues/tickets: add a comment noting completion and reference the PR:
   ```bash
   {{BACKLOG_COMMENT_CMD}}
   ```
-  - GitHub: `gh issue comment {number} --body "Implemented in PR #XX. All acceptance criteria met."`
-  - JIRA: `jira issue comment {key} --message "Implemented in PR #XX. All acceptance criteria met."`
-  - Ensure the PR body includes `Closes #N` for each fully resolved issue (GitHub auto-closes on merge)
+  - **Local:** Update the ticket status to `"done"` using `{{BACKLOG_UPDATE_CMD}}` and add a comment: `"Implemented in PR #XX. All acceptance criteria met."` via `{{BACKLOG_COMMENT_CMD}}`. Local tickets are closed directly — there is no auto-close-on-merge mechanism.
+  - **GitHub:** `gh issue comment {number} --body "Implemented in PR #XX. All acceptance criteria met."` — do NOT close the issue explicitly. Use `Closes #N` in the PR body so GitHub auto-closes on merge.
+  - **JIRA:** `jira issue comment {key} --message "Implemented in PR #XX. All acceptance criteria met."`
+  - For GitHub/JIRA: ensure the PR body includes `Closes #N` for each fully resolved issue (auto-closes on merge)
 - For partially resolved issues/tickets: add a comment noting progress:
   ```bash
   {{BACKLOG_PARTIAL_COMMENT_CMD}}
   ```
+  - **Local:** Additionally update the ticket status to `"in_progress"` via `{{BACKLOG_UPDATE_CMD}}` if it is still `"todo"`.
 
 **If `BACKLOG_WRITE=false`:**
 - Do NOT create, modify, or comment on any issues/tickets.

package/templates/commands/sr/product-backlog.md

@@ -161,6 +161,33 @@ The product-analyst receives this prompt:
 
 7. **[Orchestrator]** After the product-analyst completes, write issue snapshots to `.claude/backlog-cache.json`.
 
+   #### If provider=local — Cache from Local Tickets
+
+   Read `$SPECRAILS_DIR/local-tickets.json` and parse the `tickets` map. For each ticket with `"product-driven-backlog"` in its `labels` array and `status` not `"cancelled"`, build a snapshot object:
+   - `number`: ticket `id` (integer)
+   - `title`: ticket `title` string
+   - `state`: map ticket `status` — `"done"` or `"cancelled"` → `"closed"`, otherwise → `"open"`
+   - `assignees`: `[ticket.assignee]` if non-null, else `[]`
+   - `labels`: ticket `labels` array, sorted alphabetically
+   - `body_sha`: SHA-256 of the ticket `description` string — compute with:
+     ```bash
+     echo -n "{description}" | sha256sum | cut -d' ' -f1
+     ```
+     If `sha256sum` is not available, fall back to `openssl dgst -sha256 -r` or `shasum -a 256`.
+   - `updated_at`: ticket `updated_at` value
+   - `captured_at`: current local time in ISO 8601 format
+
+   Write to `.claude/backlog-cache.json` with:
+   - `schema_version`: `"1"`
+   - `provider`: `"local"`
+   - `last_updated`: current ISO 8601 timestamp
+   - `written_by`: `"product-backlog"`
+   - `issues`: the map keyed by string ticket ID
+
+   If the write fails: print `[backlog-cache] Warning: could not write cache. Continuing.` Do not abort.
+
+   #### If provider=github — Cache from GitHub Issues
+
    **Guard:** If `GH_AVAILABLE=false` (from Phase 0 pre-flight), print `[backlog-cache] Skipped — GH unavailable.` and return. Do not attempt the write.
 
    **Fetch all open backlog issues in one call:**
@@ -193,3 +220,7 @@ The product-analyst receives this prompt:
    - `issues`: the merged map keyed by string issue number
 
    If the write fails (e.g., `.claude/` directory does not exist): print `[backlog-cache] Warning: could not write cache. Continuing.` Do not abort.
+
+   #### If provider=jira or provider=none
+
+   Print `[backlog-cache] Skipped — provider does not support cache.` Do not attempt the write.

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

@@ -42,3 +42,59 @@ Output ONLY the following structured markdown. Do not add any preamble or explan
 ## Estimated Complexity
 [One of: Low (< 1 day) / Medium (1-3 days) / High (3-7 days) / Very High (> 1 week)]
 [One sentence justifying the estimate]
+
+---
+
+## Backlog Sync
+
+After generating the proposal, read `.claude/backlog-config.json` to determine `BACKLOG_PROVIDER` and `BACKLOG_WRITE`.
+
+### If provider=local — Create Local Ticket
+
+Create a local ticket from the proposal output:
+
+```
+{{BACKLOG_CREATE_CMD}}
+```
+
+Set the following fields:
+- `title`: The Spec Title from the proposal
+- `description`: The full structured proposal markdown (all sections from Problem Statement through Estimated Complexity)
+- `status`: `"todo"`
+- `priority`: Map Estimated Complexity — Low → `"low"`, Medium → `"medium"`, High/Very High → `"high"`
+- `labels`: `["spec-proposal"]`
+- `source`: `"propose-spec"`
+- `created_by`: `"sr-product-engineer"`
+
+Print: `Created local ticket #{id}: {title}`
+
+### If provider=github and BACKLOG_WRITE=true — Create GitHub Issue
+
+```bash
+{{BACKLOG_CREATE_CMD}}
+```
+
+Create a GitHub Issue with:
+- Title: The Spec Title
+- Body: Full structured proposal markdown
+- Labels: `spec-proposal`
+
+Print: `Created GitHub Issue #{number}: {title}`
+
+### If provider=jira and BACKLOG_WRITE=true — Create JIRA Story
+
+Create a JIRA Story using the same authentication and API pattern as `/sr:update-product-driven-backlog`:
+- Summary: The Spec Title
+- Description: Full structured proposal in Atlassian Document Format
+- Labels: `spec-proposal`
+
+Print: `Created JIRA ticket {key}: {title}`
+
+### If BACKLOG_WRITE=false or provider=none
+
+Do NOT create any tickets. Print:
+```
+Spec proposal ready. Create a ticket manually if desired:
+  Title: {Spec Title}
+  Complexity: {Estimated Complexity}
+```

package/templates/commands/sr/team-debug.md

@@ -0,0 +1,286 @@
+---
+name: "Team Debug"
+description: "Collaborative debugging using Claude Code Agent Teams. Multiple investigators pursue competing hypotheses independently, challenge each other's findings, and produce a root cause analysis ranked by confidence."
+category: Workflow
+tags: [workflow, debugging, agent-teams, investigation]
+---
+
+Collaborative debugging for **{{PROJECT_NAME}}** using Claude Code Agent Teams. Multiple investigators pursue competing hypotheses about a bug, challenge each other's findings, and produce a confidence-ranked root cause analysis.
+
+**Input:** $ARGUMENTS — required: a bug description in one of these forms:
+- `"Login fails silently when email has uppercase letters"` — free text bug description
+- `tests/auth.test.ts` — a failing test file path
+- `"TypeError: Cannot read property 'id' of undefined"` — an error message or stack trace
+- `#42` — a GitHub issue number
+
+Optional flags:
+- `--scope <paths>` — comma-separated file/directory paths to constrain investigation (default: entire repo)
+- `--depth <level>` — investigation depth: `shallow`, `normal` (default), `deep`
+
+---
+
+## Phase 0: Feature Flag Guard
+
+**This check is mandatory and runs before anything else.**
+
+Check whether Agent Teams is enabled:
+
+```bash
+echo "${CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS:-}"
+```
+
+If the variable is unset or not equal to `1`, print this message and **stop immediately**:
+
+```
+Error: Agent Teams is an experimental feature that requires opt-in.
+
+To enable it, set the environment variable before starting Claude Code:
+
+  export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
+
+Agent Teams requires Claude Code v2.1.32 or later.
+```
+
+Do NOT proceed past this point if the guard fails.
+
+---
+
+## Phase 1: Bug Context Gathering
+
+Parse `$ARGUMENTS` to determine the bug context and flags.
+
+**Variables to set:**
+
+- `BUG_DESCRIPTION` — the user's description of the bug
+- `INPUT_TYPE` — `"text"`, `"test"`, `"error"`, or `"issue"`
+- `SCOPE_PATHS` — from `--scope` flag or `["."]` (entire repo)
+- `INVESTIGATION_DEPTH` — from `--depth` flag or `"normal"`
+
+**Detection rules:**
+
+1. If input starts with `#` or is a bare integer -> `INPUT_TYPE="issue"`, fetch issue body via `gh issue view <number> --json title,body`
+2. If input is a file path that exists and contains `test` or `spec` -> `INPUT_TYPE="test"`, run the test to capture failure output
+3. If input contains common error patterns (stack trace, `Error:`, `Exception`, `FATAL`) -> `INPUT_TYPE="error"`
+4. Otherwise -> `INPUT_TYPE="text"`
+
+If `$ARGUMENTS` is empty, print usage and stop:
+```
+Usage: /sr:team-debug <bug-description> [--scope <paths>] [--depth <level>]
+
+Examples:
+  /sr:team-debug "Login fails silently when email has uppercase letters"
+  /sr:team-debug tests/auth.test.ts --depth deep
+  /sr:team-debug "TypeError: Cannot read property 'id' of undefined" --scope src/api
+  /sr:team-debug #42
+```
+
+---
+
+## Phase 2: Hypothesis Generation
+
+Analyze the bug context and generate competing hypotheses:
+
+1. **Analyze symptoms**: Read relevant source files within `SCOPE_PATHS`, examine recent git changes (`git log --oneline -20` for the relevant paths), check related tests
+2. **Generate hypotheses**: Produce 2-3 distinct, testable hypotheses about the root cause. Each must target a different subsystem, mechanism, or failure mode.
+3. **Rank hypotheses**: Order by initial likelihood based on available evidence
+
+Each hypothesis MUST include:
+- **Title**: One-line description of the proposed cause
+- **Rationale**: Why this is plausible given the symptoms
+- **Investigation plan**: Specific files to examine, commands to run, patterns to search for
+- **Expected evidence**: What would confirm or refute this hypothesis
+
+Decide whether to launch 2 or 3 investigators:
+- Default: 2 investigators (Hypothesis A and B)
+- Launch 3 when: `--depth deep` is set, OR the bug description is ambiguous enough to warrant three genuinely distinct hypotheses
+
+Print the hypothesis summary:
+```
+## Bug Analysis
+
+**Input type:** <text / test / error / issue>
+**Scope:** <SCOPE_PATHS>
+**Depth:** <INVESTIGATION_DEPTH>
+
+### Hypotheses
+
+1. **<Hypothesis A title>** (initial confidence: X%)
+   <one-line rationale>
+
+2. **<Hypothesis B title>** (initial confidence: Y%)
+   <one-line rationale>
+
+3. **<Hypothesis C title>** (initial confidence: Z%) [if applicable]
+   <one-line rationale>
+
+Launching <N> investigators...
+```
+
+---
+
+## Phase 3: Launch Investigation Team
+
+Create 2-3 investigator teammates using Agent Teams. Each teammate receives the bug context and their assigned hypothesis.
+
+**IMPORTANT:** Use the Agent Teams teammate mechanism — NOT the Agent tool's `subagent_type`. Teammates share a task list and can message each other via mailbox.
+
+### Investigator A: Primary Hypothesis
+
+**Prompt:**
+```
+You are Investigator A on a debugging team. Your job is to prove or disprove your assigned hypothesis through systematic investigation.
+
+## Bug Context
+<BUG_DESCRIPTION>
+<additional context gathered in Phase 1: test output, error details, issue body>
+
+## Your Hypothesis
+**<Hypothesis A title>**
+<Hypothesis A rationale>
+
+## Investigation Plan
+<Hypothesis A investigation plan>
+
+## Scope
+Limit your investigation to: <SCOPE_PATHS>
+
+## Instructions
+1. Follow your investigation plan systematically
+2. Read source files, search for patterns, examine git history within scope
+3. Collect concrete evidence — file paths, line numbers, code snippets, command output
+4. Determine a confidence level (0-100%) that your hypothesis is the root cause
+5. After completing your investigation, read the other investigators' findings from the task list
+6. If you find evidence that supports or contradicts another investigator's hypothesis, send a mailbox message challenging or endorsing their findings
+7. Do NOT modify any files — this is a read-only investigation
+
+## Report Format
+Post your findings as a task list update:
+
+### Investigator A: <Hypothesis Title>
+
+#### Evidence Found
+| # | Type | Location | Finding |
+|---|------|----------|---------|
+| 1 | code/git/test/config | file:line | What was found |
+
+#### Evidence Against
+<any evidence that contradicts this hypothesis>
+
+#### Confidence: X%
+<explanation of confidence level>
+
+#### Verdict
+<CONFIRMED / REFUTED / INCONCLUSIVE>
+<brief explanation>
+```
+
+### Investigator B: Alternative Hypothesis
+
+Same structure as Investigator A, with Hypothesis B title, rationale, investigation plan, and expected evidence.
+
+### Investigator C: Contrarian Hypothesis (when applicable)
+
+Same structure as Investigator A, with Hypothesis C title, rationale, investigation plan, and expected evidence. Only launched when 3 hypotheses are generated.
+
+### Team Coordination
+
+After launching all investigators:
+
+1. Wait for all investigators to complete their independent investigations (posted to the shared task list)
+2. Allow one round of cross-investigation challenge via mailbox — each investigator may respond to findings from the others
+3. Collect all findings and challenge outcomes
+
+If any teammate fails to respond, proceed with available findings and note the gap in the final report.
+
+---
+
+## Phase 4: Root Cause Synthesis
+
+After all investigations and challenges are complete, the team lead produces the root cause analysis.
+
+### Step 1: Evidence Aggregation
+
+1. Read all investigator reports from the task list
+2. Identify converging evidence (multiple investigators pointing to the same cause)
+3. Identify conflicting evidence and note unresolved disagreements
+4. Read any mailbox challenge messages for cross-investigator insights
+
+### Step 2: Confidence Recalibration
+
+Adjust hypothesis confidence levels based on cross-investigation challenges:
+- A hypothesis endorsed by evidence from another investigator: confidence boost (+10-20%)
+- A hypothesis contradicted by another investigator's evidence: confidence reduction (-10-30%)
+- A hypothesis with no cross-investigation interaction: confidence unchanged
+- Converging evidence from multiple investigators: strongest signal for root cause
+
+### Step 3: Render Report
+
+```markdown
+## Root Cause Analysis
+
+**Bug:** <one-line bug description>
+**Scope:** <SCOPE_PATHS>
+**Depth:** <INVESTIGATION_DEPTH>
+**Investigators:** <N>
+
+---
+
+### Most Likely Root Cause
+
+**<Winning hypothesis title>** — Confidence: X%
+
+<2-3 sentence explanation of the root cause with specific file and line references>
+
+#### Key Evidence
+| # | Location | Finding |
+|---|----------|---------|
+| 1 | file:line | Evidence supporting this conclusion |
+
+#### Suggested Fix
+<specific, actionable fix recommendation with file and line references>
+
+---
+
+### Alternative Hypotheses
+
+| # | Hypothesis | Initial | Final | Verdict | Key Evidence |
+|---|-----------|---------|-------|---------|-------------|
+| 1 | <title> | X% | Y% | CONFIRMED/REFUTED/INCONCLUSIVE | <one-line> |
+| 2 | <title> | X% | Y% | CONFIRMED/REFUTED/INCONCLUSIVE | <one-line> |
+
+### Investigation Trail
+
+<for each investigator, a 2-3 line summary of what they investigated and what they found>
+
+### Cross-Investigation Notes
+
+<any points of challenge or agreement between investigators, with resolution>
+
+---
+
+### Recommended Next Steps
+
+1. <most important action — typically the fix>
+2. <verification step — test to confirm the fix>
+3. <preventive step — how to avoid this class of bug>
+```
+
+### Step 4: Cost Notice
+
+Print a brief cost notice after the report:
+
+```
+Note: Team debug used ~<N>x the tokens of a single-agent investigation (<N> parallel investigators + challenge round).
+```
+
+---
+
+## Rules
+
+- This command is **read-only** — it MUST NOT create, modify, or delete any files
+- All investigators run as Agent Teams teammates, not as Agent tool subagents
+- If Agent Teams is unavailable at runtime (API error, version mismatch), fall back to running 2-3 sequential Agent tool subagents and skip the challenge phase. Print a warning about the fallback.
+- The challenge phase is limited to one round per investigator to control token costs
+- Findings MUST include file paths and line numbers — vague findings are not acceptable
+- Investigation MUST stay within `SCOPE_PATHS` if specified
+- This command is Claude Code only — it is NOT installed when the provider is `codex`

package/templates/commands/sr/team-review.md

@@ -0,0 +1,341 @@
+---
+name: "Team Review"
+description: "Multi-perspective code review using Claude Code Agent Teams. Three specialized reviewers (security, performance, correctness) independently review changes, debate findings, and produce a consolidated report."
+category: Workflow
+tags: [workflow, review, agent-teams, security, performance]
+---
+
+Multi-perspective code review for **{{PROJECT_NAME}}** using Claude Code Agent Teams. Three specialized reviewers analyze changes independently, debate cross-cutting findings, and produce a consolidated report.
+
+**Input:** $ARGUMENTS — required: a review target in one of these forms:
+- `#123` — review a pull request by number
+- `feat/my-feature` — review a branch diff against base
+- `abc1234..def5678` — review a commit range
+
+Optional flags:
+- `--base <branch>` — override base branch for comparison (default: repository default branch)
+- `--focus <areas>` — comma-separated focus areas to weight: `security`, `performance`, `correctness`, `tests`, `types`
+
+---
+
+## Phase 0: Feature Flag Guard
+
+**This check is mandatory and runs before anything else.**
+
+Check whether Agent Teams is enabled:
+
+```bash
+echo "${CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS:-}"
+```
+
+If the variable is unset or not equal to `1`, print this message and **stop immediately**:
+
+```
+Error: Agent Teams is an experimental feature that requires opt-in.
+
+To enable it, set the environment variable before starting Claude Code:
+
+  export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
+
+Agent Teams requires Claude Code v2.1.32 or later.
+```
+
+Do NOT proceed past this point if the guard fails.
+
+---
+
+## Phase 1: Input Parsing
+
+Parse `$ARGUMENTS` to determine the review target and flags.
+
+**Variables to set:**
+
+- `REVIEW_TARGET` — the PR number, branch name, or commit range
+- `REVIEW_TYPE` — `"pr"`, `"branch"`, or `"range"`
+- `BASE_BRANCH` — from `--base` flag or detect via `gh repo view --json defaultBranchRef -q '.defaultBranchRef.name'` or fall back to `main`
+- `FOCUS_AREAS` — array from `--focus` flag or `["all"]`
+
+**Detection rules:**
+
+1. If input starts with `#` or is a bare integer → `REVIEW_TYPE="pr"`, strip `#` prefix
+2. If input contains `..` → `REVIEW_TYPE="range"`
+3. Otherwise → `REVIEW_TYPE="branch"`
+
+If `$ARGUMENTS` is empty, print usage and stop:
+```
+Usage: /sr:team-review <target> [--base <branch>] [--focus <areas>]
+
+Examples:
+  /sr:team-review #42
+  /sr:team-review feat/new-auth --focus security
+  /sr:team-review abc123..def456
+```
+
+---
+
+## Phase 2: Gather Diff
+
+Collect the code changes based on `REVIEW_TYPE`:
+
+- **PR**: Run `gh pr diff <REVIEW_TARGET>` and `gh pr diff <REVIEW_TARGET> --name-only`
+- **Branch**: Run `git diff ${BASE_BRANCH}...${REVIEW_TARGET}` and `git diff --name-only ${BASE_BRANCH}...${REVIEW_TARGET}`
+- **Range**: Run `git diff ${REVIEW_TARGET}` and `git diff --name-only ${REVIEW_TARGET}`
+
+Also collect file-level stats: `git diff --stat <appropriate-range>`
+
+**Store these variables for Phase 3:**
+- `DIFF_CONTENT` — full unified diff
+- `CHANGED_FILES` — list of changed file paths
+- `DIFF_STATS` — file-level line count changes
+
+If the diff is empty, print `No changes found for the given review target.` and stop.
+
+Print a summary:
+```
+## Review Target
+Type: <PR / Branch / Range>
+Target: <REVIEW_TARGET>
+Base: <BASE_BRANCH>
+Changed files: <N>
+Focus: <FOCUS_AREAS or "all areas">
+
+<DIFF_STATS output>
+```
+
+---
+
+## Phase 3: Launch Team Review
+
+Create three reviewer teammates using Agent Teams. Each teammate receives the full diff and file list.
+
+**IMPORTANT:** Use the Agent Teams teammate mechanism — NOT the Agent tool's `subagent_type`. Teammates share a task list and can message each other via mailbox.
+
+### Teammate 1: Security Reviewer
+
+**Persona:** sr-security-reviewer (or sr-reviewer with security focus if persona not available)
+
+**Prompt:**
+```
+You are the Security Reviewer on a team code review.
+
+## Your Focus Areas
+- Authentication and authorization flaws
+- Input validation and injection vulnerabilities (SQL, XSS, command injection)
+- Secrets or credentials in code
+- OWASP Top 10 vulnerabilities
+- Insecure dependencies or configurations
+- Missing rate limiting or access controls
+
+## Changed Files
+<CHANGED_FILES>
+
+## Diff
+<DIFF_CONTENT>
+
+## Instructions
+1. Review every changed file through a security lens
+2. Report findings using the format below — be specific about file, line, and fix
+3. After completing your review, read the other reviewers' findings from the task list
+4. If you have security-relevant context on their findings, send a mailbox message
+
+## Report Format
+Post your findings as a task list update:
+
+### Security Review Findings
+
+#### Summary
+<1-2 sentences>
+
+#### Findings
+| # | Severity | File | Line(s) | Finding | Recommendation |
+|---|----------|------|---------|---------|----------------|
+
+#### Verdict
+<APPROVE / REQUEST_CHANGES / COMMENT>
+```
+
+### Teammate 2: Performance Reviewer
+
+**Persona:** sr-performance-reviewer (or sr-reviewer with performance focus if persona not available)
+
+**Prompt:**
+```
+You are the Performance Reviewer on a team code review.
+
+## Your Focus Areas
+- Database query complexity and N+1 queries
+- Missing or broken caching
+- Memory leaks and excessive allocations
+- Algorithmic complexity (O(n^2) or worse in hot paths)
+- Bundle size and lazy loading concerns (frontend)
+- Missing pagination or unbounded data fetching
+
+## Changed Files
+<CHANGED_FILES>
+
+## Diff
+<DIFF_CONTENT>
+
+## Instructions
+1. Review every changed file through a performance lens
+2. Report findings using the format below — be specific about file, line, and fix
+3. After completing your review, read the other reviewers' findings from the task list
+4. If you have performance-relevant context on their findings, send a mailbox message
+
+## Report Format
+Post your findings as a task list update:
+
+### Performance Review Findings
+
+#### Summary
+<1-2 sentences>
+
+#### Findings
+| # | Severity | File | Line(s) | Finding | Recommendation |
+|---|----------|------|---------|---------|----------------|
+
+#### Verdict
+<APPROVE / REQUEST_CHANGES / COMMENT>
+```
+
+### Teammate 3: Correctness Reviewer
+
+**Persona:** sr-reviewer
+
+**Prompt:**
+```
+You are the Correctness Reviewer on a team code review.
+
+## Your Focus Areas
+- Logic errors and edge cases
+- Missing or inadequate test coverage
+- Type safety violations
+- Error handling gaps (uncaught exceptions, missing error paths)
+- API contract mismatches
+- Race conditions and concurrency issues
+
+## Changed Files
+<CHANGED_FILES>
+
+## Diff
+<DIFF_CONTENT>
+
+## Instructions
+1. Review every changed file through a correctness and test coverage lens
+2. Report findings using the format below — be specific about file, line, and fix
+3. After completing your review, read the other reviewers' findings from the task list
+4. If you have correctness-relevant context on their findings, send a mailbox message
+
+## Report Format
+Post your findings as a task list update:
+
+### Correctness Review Findings
+
+#### Summary
+<1-2 sentences>
+
+#### Findings
+| # | Severity | File | Line(s) | Finding | Recommendation |
+|---|----------|------|---------|---------|----------------|
+
+#### Verdict
+<APPROVE / REQUEST_CHANGES / COMMENT>
+```
+
+### Team Coordination
+
+After launching all three teammates:
+
+1. Wait for all three to complete their independent reviews (posted to the shared task list)
+2. Allow one round of cross-review debate via mailbox — each reviewer may respond to findings from the other two
+3. Collect all findings and debate outcomes
+
+If any teammate fails to respond, proceed with available reviews and note the gap in the final report.
+
+---
+
+## Phase 4: Synthesize Consolidated Report
+
+After all reviews and debate are complete, the team lead produces the final report.
+
+### Step 1: Collect and Deduplicate
+
+1. Read all three reviewer reports from the task list
+2. Identify duplicate findings (same file + overlapping lines + similar issue)
+3. For duplicates: keep the highest-severity version, note which reviewers flagged it
+
+### Step 2: Apply Focus Weighting
+
+If `FOCUS_AREAS` is not `["all"]`:
+- Findings in focus areas get their severity preserved
+- Findings outside focus areas: Critical stays Critical, but High→Medium, Medium→Low for display purposes
+- Note the weighting in the report header
+
+### Step 3: Render Report
+
+```markdown
+## Team Review Report
+
+**Target:** <PR #N / branch-name / commit-range>
+**Base:** <BASE_BRANCH>
+**Reviewers:** Security, Performance, Correctness
+**Changed files:** N files (+X/-Y lines)
+**Focus:** <FOCUS_AREAS or "all areas equally weighted">
+
+---
+
+### Critical Findings (action required before merge)
+
+| # | Severity | Domain | File | Line(s) | Finding | Recommendation | Flagged By |
+|---|----------|--------|------|---------|---------|----------------|------------|
+
+### High-Priority Findings
+
+| # | Severity | Domain | File | Line(s) | Finding | Recommendation | Flagged By |
+|---|----------|--------|------|---------|---------|----------------|------------|
+
+### Medium & Low Findings
+
+| # | Severity | Domain | File | Line(s) | Finding | Recommendation |
+|---|----------|--------|------|---------|---------|----------------|
+
+### Praise (things done well)
+<positive observations from reviewers>
+
+---
+
+### Cross-Review Notes
+<any points of debate or disagreement between reviewers, with resolution>
+
+---
+
+### Reviewer Verdicts
+
+| Reviewer | Verdict | Critical | High | Medium | Low | Info |
+|----------|---------|----------|------|--------|-----|------|
+| Security | APPROVE/REQUEST_CHANGES | N | N | N | N | N |
+| Performance | APPROVE/REQUEST_CHANGES | N | N | N | N | N |
+| Correctness | APPROVE/REQUEST_CHANGES | N | N | N | N | N |
+
+### Overall Verdict: <APPROVE / REQUEST_CHANGES>
+
+<one-paragraph summary: key risks, recommended actions, and overall assessment>
+```
+
+### Step 4: Cost Notice
+
+Print a brief cost notice after the report:
+
+```
+Note: Team review used ~3x the tokens of a single-reviewer run (3 parallel reviewers + debate round).
+```
+
+---
+
+## Rules
+
+- This command is **read-only** — it MUST NOT create, modify, or delete any files
+- All three reviewers run as Agent Teams teammates, not as Agent tool subagents
+- If Agent Teams is unavailable at runtime (API error, version mismatch), fall back to running three sequential Agent tool subagents with `subagent_type: sr-reviewer` and skip the debate phase. Print a warning about the fallback.
+- The debate phase is limited to one round per reviewer to control token costs
+- Findings MUST include file paths and line numbers — vague findings are not acceptable

package/templates/commands/sr/update-product-driven-backlog.md

@@ -68,7 +68,7 @@ After the Explore agent completes:
 1. **Display** results to the user.
 
 2. Read `.claude/backlog-config.json` and extract:
-   - `BACKLOG_PROVIDER` (`github`, `jira`, or `none`)
+   - `BACKLOG_PROVIDER` (`local`, `github`, `jira`, or `none`)
    - `BACKLOG_WRITE` (from `write_access`)
 
 ### If `BACKLOG_WRITE=false` — Display only (no sync)
@@ -98,6 +98,46 @@ After the Explore agent completes:
 
 4. **Do NOT** create, modify, or comment on any issues/tickets.
 
+### If provider=local — Sync to Local Tickets
+
+Local tickets are always read-write. Sync directly to `$SPECRAILS_DIR/local-tickets.json`.
+
+3. **Fetch existing local tickets** to avoid duplicates:
+   ```
+   {{BACKLOG_FETCH_ALL_CMD}}
+   ```
+   Collect all ticket titles into a duplicate-check set.
+
+4. **Initialize labels** (idempotent):
+   ```
+   {{BACKLOG_INIT_LABELS_CMD}}
+   ```
+
+5. **For each proposed feature, create a local ticket** (skip if title matches an existing ticket):
+   ```
+   {{BACKLOG_CREATE_CMD}}
+   ```
+   Set the following fields on each new ticket:
+   - `title`: Feature name
+   - `description`: Full VPC body markdown (same format as the GitHub/JIRA issue body above)
+   - `status`: `"todo"`
+   - `priority`: Map effort to priority — Low effort → `"high"` priority, Medium → `"medium"`, High → `"low"`
+   - `labels`: `["product-driven-backlog", "area:{area}"]`
+   - `metadata.vpc_scores`: Object with per-persona scores from the VPC evaluation
+   - `metadata.effort_level`: `"High"`, `"Medium"`, or `"Low"`
+   - `metadata.user_story`: The user story text
+   - `metadata.area`: The area name (without `area:` prefix)
+   - `prerequisites`: Array of ticket IDs for any features this depends on (empty if none)
+   - `source`: `"product-backlog"`
+   - `created_by`: `"sr-product-manager"`
+
+6. **Report** sync results:
+   ```
+   Product discovery complete:
+   - Created: {N} new feature ideas as local tickets
+   - Skipped: {N} duplicates (already exist)
+   ```
+
 ### If provider=github and BACKLOG_WRITE=true — Sync to GitHub Issues
 
 3. **Fetch existing product-driven backlog items** to avoid duplicates:

package/templates/local-tickets-schema.json

@@ -0,0 +1,7 @@
+{
+  "schema_version": "1.0",
+  "revision": 0,
+  "last_updated": null,
+  "next_id": 1,
+  "tickets": {}
+}

package/update.sh

@@ -94,7 +94,7 @@ if [[ -z "$CUSTOM_ROOT_DIR" && -f "$SCRIPT_DIR/install.sh" && -d "$SCRIPT_DIR/te
     echo -e "${YELLOW}⚠${NC}  You're running the updater from inside the specrails source repo."
     echo -e "   specrails updates a ${BOLD}target${NC} repository, not itself."
     echo ""
-    read -p "   Enter the path to the target repo (or 'q' to quit): " TARGET_PATH
+    read -p "   Enter the path to the target repo (or 'q' to quit): " TARGET_PATH || TARGET_PATH="q"
     if [[ "$TARGET_PATH" == "q" || -z "$TARGET_PATH" ]]; then
         echo "   Aborted. No changes made."
         exit 0
@@ -107,7 +107,7 @@ if [[ -z "$CUSTOM_ROOT_DIR" && -f "$SCRIPT_DIR/install.sh" && -d "$SCRIPT_DIR/te
     }
     if [[ ! -d "$REPO_ROOT/.git" ]]; then
         echo -e "${YELLOW}⚠${NC}  Warning: $REPO_ROOT does not appear to be a git repository."
-        read -p "   Continue anyway? (y/n): " CONTINUE_NOGIT
+        read -p "   Continue anyway? (y/n): " CONTINUE_NOGIT || CONTINUE_NOGIT="n"
         if [[ "$CONTINUE_NOGIT" != "y" && "$CONTINUE_NOGIT" != "Y" ]]; then
             echo "   Aborted. No changes made."
             exit 0
@@ -658,7 +658,7 @@ except Exception:
         fi
 
         local answer
-        read -p "    Regenerate agents? (y/N): " answer
+        read -p "    Regenerate agents? (y/N): " answer || answer="n"
         if [[ "$answer" == "y" ]] || [[ "$answer" == "Y" ]]; then
             NEEDS_SETUP_UPDATE=true
             ok "Will regenerate agents via /setup --update"