slash-do 1.8.0 → 2.0.0

package/commands/do/better-swift.md

@@ -1,13 +1,18 @@
 ---
 description: SwiftUI DevSecOps audit, remediation, test enhancement, per-category PRs, CI verification, and Copilot review loop with worktree isolation — optimized for multi-platform Swift/SwiftUI apps (iOS, macOS, watchOS, tvOS, visionOS)
-argument-hint: "[--scan-only] [--no-merge] [path filter or focus areas]"
+argument-hint: "[--interactive] [--scan-only] [--no-merge] [path filter or focus areas]"
 ---
 
 # Better Swift — Unified DevSecOps Pipeline for SwiftUI Apps
 
 Run the full DevSecOps lifecycle optimized for Swift/SwiftUI multi-platform projects: audit the codebase with 7 deduplicated agents, consolidate findings, remediate in an isolated worktree, create **separate PRs per category** with SemVer bump, verify CI, run Copilot review loops, and merge.
 
+**Default mode: fully autonomous.** Uses Balanced model profile, proceeds through all phases without prompting, auto-merges PRs with clean reviews.
+
+**`--interactive` mode:** Pauses for model profile selection, review findings approval, guardrail decisions, and merge confirmation.
+
 Parse `$ARGUMENTS` for:
+- **`--interactive`**: pause at each decision point for user approval
 - **`--scan-only`**: run Phase 0 + 1 + 2 only (audit and plan), skip remediation
 - **`--no-merge`**: run through PR creation (Phase 5), skip Copilot review and merge
 - **Path filter**: limit scanning scope to specific directories or files
@@ -15,7 +20,13 @@ Parse `$ARGUMENTS` for:
 
 ## Configuration
 
-Before starting the pipeline, present the user with configuration options using `AskUserQuestion`:
+### Default Mode (autonomous)
+
+Use the **Balanced** model profile automatically (`AUDIT_MODEL=sonnet`, `REMEDIATION_MODEL=sonnet`).
+
+### Interactive Mode (`--interactive`)
+
+Present the user with configuration options using `AskUserQuestion`:
 
 ```
 AskUserQuestion([
@@ -56,7 +67,7 @@ When compacting during this workflow, always preserve:
 - All CRITICAL/HIGH findings with file:line references
 - The current phase number and what phases remain
 - All PR numbers and URLs created so far
-- `BUILD_CMD`, `TEST_CMD`, `PROJECT_TYPE`, `WORKTREE_DIR` values
+- `BUILD_CMD`, `TEST_CMD`, `PROJECT_TYPE`, `WORKTREE_DIR`, `REPO_DIR` values
 - `VCS_HOST`, `CLI_TOOL`, `DEFAULT_BRANCH`, `CURRENT_BRANCH`
 - `PLATFORMS` (list of supported platforms: iOS, macOS, etc.)
 - `DEPLOYMENT_TARGETS` (minimum OS versions per platform)
@@ -154,6 +165,7 @@ If the project has a `Makefile` or `fastlane/Fastfile`, check for custom build/t
 Record as `BUILD_CMD` and `TEST_CMD`.
 
 ### 0d: State Snapshot
+- Record `REPO_DIR` via `git rev-parse --show-toplevel`
 - Record `CURRENT_BRANCH` via `git rev-parse --abbrev-ref HEAD`
 - Record `DEFAULT_BRANCH` via `gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'` (or `glab` equivalent)
 - Record `IS_DIRTY` via `git status --porcelain`
@@ -561,18 +573,43 @@ Before creating PRs, run a deep code review on all remediation changes to catch
 3. For each issue found:
    - Fix in a new commit: `fix: {description of review finding}`
    - Re-run `{BUILD_CMD}` and `{TEST_CMD}` on ALL platforms to verify
-4. Present a summary of review findings and fixes to the user via `AskUserQuestion`:
+4. **Default mode**: Print a brief summary of findings and fixes, then proceed to PR creation automatically.
+   **Interactive mode (`--interactive`)**: Present a summary to the user via `AskUserQuestion`:
    ```
    AskUserQuestion([{
      question: "Code review complete. {N} issues found and fixed. {list}. All {PLATFORMS} platforms build and test successfully. Proceed to PR creation?",
      options: [
        { label: "Proceed", description: "Create per-category PRs" },
+       { label: "Commit directly", description: "Merge worktree changes into {CURRENT_BRANCH} — no PRs, no review loops" },
        { label: "Show diff", description: "Show the full diff for manual review before proceeding" },
        { label: "Abort", description: "Stop here — I'll review manually" }
      ]
    }])
    ```
-5. If "Show diff" selected, print the diff and re-ask. If "Abort", stop and print the worktree path.
+5. (Interactive only) If "Show diff" selected, print the diff and re-ask. If "Abort", stop and print the worktree path.
+6. If "Commit directly" selected:
+   - All remediation and review fixes are already committed incrementally in the worktree branch `better-swift/{DATE}`. If any uncommitted changes remain, stage and commit them now:
+     ```bash
+     cd {WORKTREE_DIR}
+     git diff --quiet && git diff --cached --quiet || {
+       git add <list of remaining changed files>
+       git commit -m "fix: better-swift audit remediation — remaining changes"
+     }
+     ```
+   - Return to the main repo checkout, merge the worktree branch, and clean up on success:
+     ```bash
+     cd {REPO_DIR}
+     git checkout {CURRENT_BRANCH}
+     if git merge better-swift/{DATE}; then
+       git worktree remove {WORKTREE_DIR}
+       git branch -D better-swift/{DATE}
+     else
+       echo "Merge conflict — resolve in {REPO_DIR}, then run:"
+       echo "  git worktree remove {WORKTREE_DIR}"
+       echo "  git branch -D better-swift/{DATE}"
+     fi
+     ```
+   - Restore stash if needed (`git stash pop`), update PLAN.md, print final summary, then **stop** — this completes the workflow (Phases 5, 6, and 7 are skipped entirely since no PRs or category branches were created)
 
 ## Phase 4c: Test Enhancement
 
@@ -825,7 +862,7 @@ After creating all PRs, verify CI passes on each one:
 
 ## Phase 6: Copilot Review Loop (GitHub only)
 
-Loop until Copilot returns zero new comments (no fixed iteration limit). Sub-agents enforce a 10-iteration guardrail: at iteration 10 the sub-agent stops and returns a "guardrail" status, prompting the parent agent to ask the user whether to continue or stop.
+Loop until Copilot returns zero new comments (no fixed iteration limit). Sub-agents enforce a 10-iteration guardrail: at iteration 10 the sub-agent stops and returns a "guardrail" status. **Default mode**: auto-stop at the guardrail. **Interactive mode (`--interactive`)**: prompt the parent agent to ask the user whether to continue or stop.
 
 **Sub-agent delegation** (prevents context exhaustion): delegate each PR's review loop to a **separate general-purpose sub-agent** via the Agent tool. Launch sub-agents in parallel (one per PR). Each sub-agent runs the full loop (request → wait → check → fix → re-request) autonomously and returns only the final status.
 
@@ -845,13 +882,19 @@ Launch all PR sub-agents in parallel. Wait for all to complete.
 
 For each sub-agent result:
 - **clean**: mark PR as ready to merge
-- **timeout**: inform the user "Copilot review timed out on PR #{number}." and ask whether to continue waiting, re-request, or skip
-- **error**: inform the user and ask whether to retry or skip
-- **guardrail**: the sub-agent hit the 10-iteration limit; ask the user whether to continue with more iterations or stop
+- **timeout**: **Default mode**: skip the timed-out PR and continue. **Interactive mode**: inform the user and ask whether to continue waiting, re-request, or skip
+- **error**: **Default mode**: retry up to 3 times, then skip. **Interactive mode**: inform the user and ask whether to retry or skip
+- **guardrail**: the sub-agent hit the 10-iteration limit. **Default mode**: auto-stop and mark as best-effort. **Interactive mode**: ask the user whether to continue with more iterations or stop
 
 ### 6.3: Merge Gate (MANDATORY)
 
-**Do NOT merge any PR until Copilot review has completed (approved or commented) on ALL PRs, or the user explicitly approves skipping.**
+**Do NOT merge any PR until its own Copilot review has completed (approved or commented with zero unresolved issues).**
+
+### Default Mode (autonomous)
+
+Print the review status summary, then auto-merge all PRs whose reviews completed cleanly. PRs that timed out, hit guardrails, or still have unresolved comments are left open for manual review. Print which PRs were merged and which were left open.
+
+### Interactive Mode (`--interactive`)
 
 Present the review status summary to the user via `AskUserQuestion`:
 ```
@@ -866,7 +909,7 @@ AskUserQuestion([{
 }])
 ```
 
-Only proceed with merging based on the user's selection. Never auto-merge without user confirmation.
+Only proceed with merging based on the user's selection.
 
 ### 6.4: Merge
 

package/commands/do/better.md

@@ -1,13 +1,18 @@
 ---
 description: Unified DevSecOps audit, remediation, test enhancement, per-category PRs, CI verification, and Copilot review loop with worktree isolation
-argument-hint: "[--scan-only] [--no-merge] [path filter or focus areas]"
+argument-hint: "[--interactive] [--scan-only] [--no-merge] [path filter or focus areas]"
 ---
 
 # Better — Unified DevSecOps Pipeline
 
 Run the full DevSecOps lifecycle: audit the codebase with 7 deduplicated agents, consolidate findings, remediate in an isolated worktree, create **separate PRs per category** with SemVer bump, verify CI, run Copilot review loops, and merge.
 
+**Default mode: fully autonomous.** Uses Balanced model profile, proceeds through all phases without prompting, auto-merges PRs with clean reviews.
+
+**`--interactive` mode:** Pauses for model profile selection, review findings approval, guardrail decisions, and merge confirmation.
+
 Parse `$ARGUMENTS` for:
+- **`--interactive`**: pause at each decision point for user approval
 - **`--scan-only`**: run Phase 0 + 1 + 2 only (audit and plan), skip remediation
 - **`--no-merge`**: run through PR creation (Phase 5), skip Copilot review and merge
 - **Path filter**: limit scanning scope to specific directories or files
@@ -15,7 +20,13 @@ Parse `$ARGUMENTS` for:
 
 ## Configuration
 
-Before starting the pipeline, present the user with configuration options using `AskUserQuestion`:
+### Default Mode (autonomous)
+
+Use the **Balanced** model profile automatically (`AUDIT_MODEL=sonnet`, `REMEDIATION_MODEL=sonnet`).
+
+### Interactive Mode (`--interactive`)
+
+Present the user with configuration options using `AskUserQuestion`:
 
 ```
 AskUserQuestion([
@@ -56,7 +67,7 @@ When compacting during this workflow, always preserve:
 - All CRITICAL/HIGH findings with file:line references
 - The current phase number and what phases remain
 - All PR numbers and URLs created so far
-- `BUILD_CMD`, `TEST_CMD`, `PROJECT_TYPE`, `WORKTREE_DIR` values
+- `BUILD_CMD`, `TEST_CMD`, `PROJECT_TYPE`, `WORKTREE_DIR`, `REPO_DIR` values
 - `VCS_HOST`, `CLI_TOOL`, `DEFAULT_BRANCH`, `CURRENT_BRANCH`
 - `PHASE_4C_START_SHA` (needed for FILE_OWNER_MAP update in Phase 4c.3)
 - `VACUOUS_TESTS_FIXED`, `WEAK_TESTS_STRENGTHENED`, `NEW_TEST_CASES`, `NEW_TEST_FILES`
@@ -96,6 +107,7 @@ Derive build and test commands from the project type:
 Record as `BUILD_CMD` and `TEST_CMD`.
 
 ### 0d: State Snapshot
+- Record `REPO_DIR` via `git rev-parse --show-toplevel`
 - Record `CURRENT_BRANCH` via `git rev-parse --abbrev-ref HEAD`
 - Record `DEFAULT_BRANCH` via `gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'` (or `glab` equivalent)
 - Record `IS_DIRTY` via `git status --porcelain`
@@ -369,18 +381,43 @@ Before creating PRs, run a deep code review on all remediation changes to catch
 3. For each issue found:
    - Fix in a new commit: `fix: {description of review finding}`
    - Re-run `{BUILD_CMD}` and `{TEST_CMD}` to verify
-4. Present a summary of review findings and fixes to the user via `AskUserQuestion`:
+4. **Default mode**: Print a brief summary of findings and fixes, then proceed to PR creation automatically.
+   **Interactive mode (`--interactive`)**: Present a summary to the user via `AskUserQuestion`:
    ```
    AskUserQuestion([{
      question: "Code review complete. {N} issues found and fixed. {list}. Proceed to PR creation?",
      options: [
        { label: "Proceed", description: "Create per-category PRs" },
+       { label: "Commit directly", description: "Merge worktree changes into {CURRENT_BRANCH} — no PRs, no review loops" },
        { label: "Show diff", description: "Show the full diff for manual review before proceeding" },
        { label: "Abort", description: "Stop here — I'll review manually" }
      ]
    }])
    ```
-5. If "Show diff" selected, print the diff and re-ask. If "Abort", stop and print the worktree path.
+5. (Interactive only) If "Show diff" selected, print the diff and re-ask. If "Abort", stop and print the worktree path.
+6. If "Commit directly" selected:
+   - All remediation and review fixes are already committed incrementally in the worktree branch `better/{DATE}`. If any uncommitted changes remain, stage and commit them now:
+     ```bash
+     cd {WORKTREE_DIR}
+     git diff --quiet && git diff --cached --quiet || {
+       git add <list of remaining changed files>
+       git commit -m "fix: better audit remediation — remaining changes"
+     }
+     ```
+   - Return to the main repo checkout, merge the worktree branch, and clean up on success:
+     ```bash
+     cd {REPO_DIR}
+     git checkout {CURRENT_BRANCH}
+     if git merge better/{DATE}; then
+       git worktree remove {WORKTREE_DIR}
+       git branch -D better/{DATE}
+     else
+       echo "Merge conflict — resolve in {REPO_DIR}, then run:"
+       echo "  git worktree remove {WORKTREE_DIR}"
+       echo "  git branch -D better/{DATE}"
+     fi
+     ```
+   - Restore stash if needed (`git stash pop`), update PLAN.md, print final summary, then **stop** — this completes the workflow (Phases 5, 6, and 7 are skipped entirely since no PRs or category branches were created)
 
 ## Phase 4c: Test Enhancement
 
@@ -613,7 +650,7 @@ After creating all PRs, verify CI passes on each one:
 
 ## Phase 6: Copilot Review Loop (GitHub only)
 
-Loop until Copilot returns zero new comments (no fixed iteration limit). Sub-agents enforce a 10-iteration guardrail: at iteration 10 the sub-agent stops and returns a "guardrail" status, prompting the parent agent to ask the user whether to continue or stop.
+Loop until Copilot returns zero new comments (no fixed iteration limit). Sub-agents enforce a 10-iteration guardrail: at iteration 10 the sub-agent stops and returns a "guardrail" status. **Default mode**: auto-stop at the guardrail. **Interactive mode (`--interactive`)**: prompt the parent agent to ask the user whether to continue or stop.
 
 **Sub-agent delegation** (prevents context exhaustion): delegate each PR's review loop to a **separate general-purpose sub-agent** via the Agent tool. Launch sub-agents in parallel (one per PR). Each sub-agent runs the full loop (request → wait → check → fix → re-request) autonomously and returns only the final status.
 
@@ -631,13 +668,19 @@ Launch all PR sub-agents in parallel. Wait for all to complete.
 
 For each sub-agent result:
 - **clean**: mark PR as ready to merge
-- **timeout**: inform the user "Copilot review timed out on PR #{number}." and ask whether to continue waiting, re-request, or skip
-- **error**: inform the user and ask whether to retry or skip
-- **guardrail**: the sub-agent hit the 10-iteration limit; ask the user whether to continue with more iterations or stop
+- **timeout**: **Default mode**: skip the timed-out PR and continue. **Interactive mode**: inform the user and ask whether to continue waiting, re-request, or skip
+- **error**: **Default mode**: retry up to 3 times, then skip. **Interactive mode**: inform the user and ask whether to retry or skip
+- **guardrail**: the sub-agent hit the 10-iteration limit. **Default mode**: auto-stop and mark as best-effort. **Interactive mode**: ask the user whether to continue with more iterations or stop
 
 ### 6.3: Merge Gate (MANDATORY)
 
-**Do NOT merge any PR until Copilot review has completed (approved or commented) on ALL PRs, or the user explicitly approves skipping.**
+**Do NOT merge any PR until its own Copilot review has completed (approved or commented with zero unresolved issues).**
+
+### Default Mode (autonomous)
+
+Print the review status summary, then auto-merge all PRs whose reviews completed cleanly. PRs that timed out, hit guardrails, or still have unresolved comments are left open for manual review. Print which PRs were merged and which were left open.
+
+### Interactive Mode (`--interactive`)
 
 Present the review status summary to the user via `AskUserQuestion`:
 ```
@@ -652,7 +695,7 @@ AskUserQuestion([{
 }])
 ```
 
-Only proceed with merging based on the user's selection. Never auto-merge without user confirmation.
+Only proceed with merging based on the user's selection.
 
 ### 6.4: Merge
 

package/commands/do/goals.md

@@ -1,13 +1,18 @@
 ---
-description: Scan codebase to infer project goals, clarify with user, and generate GOALS.md
-argument-hint: "[--refresh] [focus hint, e.g. 'just the CLI']"
+description: Scan codebase to infer project goals and generate GOALS.md (default: fully autonomous; use --interactive to review with user)
+argument-hint: "[--interactive] [--refresh] [focus hint, e.g. 'just the CLI']"
 ---
 
 # Goals — Generate a GOALS.md from Codebase Analysis
 
-Scan the codebase to infer the project's goals, purpose, and direction, then collaborate with the user to produce a comprehensive `GOALS.md` at the repo root.
+Scan the codebase to infer the project's goals, purpose, and direction, then generate a comprehensive `GOALS.md` at the repo root.
+
+**Default mode: fully autonomous.** Scans the codebase, synthesizes goals, and writes GOALS.md without prompting. HIGH and MEDIUM confidence goals are included; LOW confidence goals are included but marked as inferred.
+
+**`--interactive` mode:** Pauses after synthesis to validate purpose, prioritize goals, confirm non-goals, and refine wording with the user.
 
 Parse `$ARGUMENTS` for:
+- **`--interactive`**: pause after synthesis for user validation and refinement
 - **`--refresh`**: re-scan and update an existing GOALS.md rather than creating from scratch
 - **Focus hints**: e.g., "focus on API goals", "just the CLI"
 
@@ -94,29 +99,35 @@ For each goal, assign a confidence level:
 - **MEDIUM** — strongly implied by patterns, architecture, or recent work
 - **LOW** — inferred/speculative, needs user confirmation
 
-## Phase 3: User Clarification
+## Phase 3: Validation
+
+### Default Mode (autonomous)
+
+Skip user clarification. Include all HIGH and MEDIUM confidence goals directly. Include LOW confidence goals but mark them with `(inferred)` so the user can review after generation. Proceed directly to Phase 4.
+
+### Interactive Mode (`--interactive`)
 
 Present the draft to the user and ask targeted questions to resolve uncertainty. Use `AskUserQuestion` for each area that needs input.
 
-### 3a: Purpose Validation
+#### 3a: Purpose Validation
 Show the inferred one-paragraph purpose statement. Ask if it's accurate or needs refinement.
 
-### 3b: Goal Prioritization
+#### 3b: Goal Prioritization
 Present the inferred goals list. For each LOW or MEDIUM confidence goal, ask the user:
 - Is this actually a goal?
 - How would you rephrase it?
 - What priority is it (primary, secondary, stretch)?
 
-### 3c: Missing Goals
+#### 3c: Missing Goals
 Ask: "Are there any goals I missed that aren't yet reflected in the codebase?" Present 2-3 suggested possibilities based on common patterns for this type of project, to prompt the user's thinking.
 
-### 3d: Non-Goals Validation
+#### 3d: Non-Goals Validation
 Present the inferred non-goals. Ask: "Are these accurate? Anything to add or remove?"
 
-### 3e: Target Users
+#### 3e: Target Users
 Present the inferred target user description. Ask if it's accurate.
 
-### 3f: Success Criteria (optional)
+#### 3f: Success Criteria (optional)
 Ask: "Would you like to define measurable success criteria for any of these goals?" Offer examples relevant to the project type (e.g., "support N concurrent users", "< Xms response time", "100% test coverage on core module").
 
 ## Phase 4: Document Generation
@@ -190,9 +201,9 @@ If `--refresh` was passed and `GOALS.md` already exists:
 1. Read the existing `GOALS.md`
 2. Compare existing goals against current codebase state
 3. Identify goals whose status has changed (new progress, completed, abandoned)
-4. Present changes to the user for confirmation
-5. Update the document in-place, preserving user-written content where possible
-6. If any checkbox task lists are found in the existing GOALS.md, flag them and offer to move them to PLAN.md
+4. **Default mode**: Update the document in-place automatically, preserving user-written content where possible. Print a summary of what changed.
+   **Interactive mode (`--interactive`)**: Present changes to the user for confirmation before updating.
+5. If any checkbox task lists are found in the existing GOALS.md, move them to PLAN.md automatically (default) or offer to move them (interactive)
 
 ## Phase 5: Finalize
 
@@ -211,8 +222,8 @@ If `--refresh` was passed and `GOALS.md` already exists:
 ## Notes
 
 - This command is project-agnostic — it reads whatever project signals exist
-- The goal is collaboration: scan first, then refine with the user — never assume
-- LOW confidence inferences should always be validated with the user before inclusion
+- In default mode, scan and generate autonomously; in interactive mode, collaborate with the user
+- LOW confidence inferences are included as `(inferred)` in default mode; validated with the user in interactive mode
 - Preserve the user's voice — if they provide rephrased goals, use their wording verbatim
 - If the project is brand new with minimal code, lean more heavily on user input and less on codebase inference
 - If `gh` CLI is not authenticated, skip issue/PR scanning gracefully — don't halt

package/commands/do/release.md

@@ -1,7 +1,12 @@
 ---
 description: Create a release PR using the project's documented release workflow
+argument-hint: "[--interactive]"
 ---
 
+**Default mode: fully autonomous.** Auto-detects branches, determines version bump from commits, runs review, creates and merges the release PR without prompting.
+
+**`--interactive` mode:** Pauses for branch confirmation, version approval, and merge confirmation.
+
 ## Detect Release Workflow
 
 Before doing anything, determine the project's source and target branches for releases. Do NOT hardcode branch names. Instead, discover them:
@@ -11,7 +16,7 @@ Before doing anything, determine the project's source and target branches for re
    - **GitHub Actions workflows** — check `.github/workflows/release.yml` (or similar) for `on: push: branches:` to find the branch that triggers the release pipeline
    - **Project conventions** (already in context) — look for git workflow sections, branch descriptions, or release instructions
    - **Versioning docs** — check `docs/VERSIONING.md`, `CONTRIBUTING.md`, or `RELEASING.md`
-   - **Branch convention** — if a `release` branch exists, the target is `release`; otherwise ask the user
+   - **Branch convention** — if a `release` branch exists, the target is `release`; otherwise create it from the last release tag (see step 3 below). In `--interactive` mode, ask the user to confirm
 3. **Ensure the target branch exists** — if not, create it from the last release tag:
    ```bash
    git branch release $(git describe --tags --abbrev=0)
@@ -21,7 +26,7 @@ Before doing anything, determine the project's source and target branches for re
 
 Print the detected workflow: `Detected release flow: {source} → {target}`
 
-If ambiguous, ask the user to confirm before proceeding.
+**Default mode**: If ambiguous, use the most likely branch (prefer `release` if it exists). If the target branch does not exist, create it from the last release tag (see step 3 above). If detection still yields `target == source`, abort with an error — a release PR cannot merge a branch into itself. **Interactive mode (`--interactive`)**: Ask the user to confirm before proceeding.
 
 **Important**: The PR direction is `{source}` → `{target}` (e.g., `main` → `release`). This gives Copilot the full diff of all changes since the last release for review. Do NOT create a branch from source and PR back into it — that only shows the version bump commit.
 
@@ -40,7 +45,7 @@ If ambiguous, ask the user to confirm before proceeding.
      - `feat:` → **minor** bump
      - `fix:`, `chore:`, `docs:`, `refactor:`, `perf:`, `style:`, `test:`, `ci:` → **patch** bump
    - Use the **highest applicable level** across all commits
-   - Present the proposed version to the user for confirmation
+   - **Default mode**: Use the determined version automatically. **Interactive mode (`--interactive`)**: Present the proposed version to the user for confirmation
 
 2. **Bump version**: Run `npm version <major|minor|patch> --no-git-tag-version` to update `package.json` and `package-lock.json`
 
@@ -82,7 +87,7 @@ Checklist to apply to each file:
 
 !`cat ~/.claude/lib/code-review-checklist.md`
 
-Verification — confirm before proceeding:
+Verification — self-check before proceeding (no user prompt needed):
 - [ ] Read every changed file in full (not just diffs)
 - [ ] Checked each file against the relevant checklist tiers
 - [ ] Quoted specific code for each finding

package/commands/do/replan.md

@@ -1,212 +1,206 @@
 ---
-description: Review and clean up PLAN.md, extract docs from completed work
+description: Automated audit/triage of PLAN.md — archive completed items to DONE.md, suggest new work, keep PLAN.md lean
+argument-hint: "[--interactive]"
 ---
 
 # Replan Command
 
-You are tasked with reviewing and updating the PLAN.md file to keep it clean, current, and action-oriented.
+Automatically audit PLAN.md against the codebase, prune completed/stale items, archive what's done, suggest new work, and leave PLAN.md lean and actionable.
 
-**This is an interactive process.** Do NOT assume items are still pending or still relevant. Verify with the user.
+**Default mode: fully autonomous.** Scans the codebase, archives done items, removes stale items, adds suggested new items, and commits — no user interaction.
+
+**`--interactive` mode:** Pauses after evidence gathering to present findings and get user approval before making changes.
+
+**Philosophy:** PLAN.md should be short enough to paste into a prompt. Completed items belong in a done log, not cluttering the active plan.
 
 ## Boundary Rule: PLAN.md vs GOALS.md
 
 **PLAN.md is tactical. GOALS.md is strategic.**
 
-PLAN.md answers: *What are we building next? What's the backlog? What's done?*
+PLAN.md answers: *What are we building next? What's the backlog?*
 GOALS.md answers: *Why does this project exist? What does success look like? What will we never do?*
 
-**PLAN.md owns:**
-- Checkbox task lists (`- [ ] Add feature X`)
-- Implementation details, subtasks, and technical steps
-- Known issues and testing gaps
-- Prioritized next-action lists
-- Completed work archive
-- Documentation index
-
-**PLAN.md must NOT duplicate:**
+**PLAN.md must NOT contain:**
 - Mission statements, core tenets, or non-goals (those belong in GOALS.md)
-- Milestone definitions written as outcome prose (GOALS.md territory)
+- Completed items (those belong in `DONE.md`)
+- Detailed documentation (those belong in `docs/`)
 
-**Cross-reference:** PLAN.md should link to GOALS.md for strategic context, and GOALS.md should link back to PLAN.md for tactical details.
+## Phase 1: Automated Evidence Gathering
 
-## Your Responsibilities
+Launch these agents in parallel — no user interaction needed.
 
-### 1. Gather Evidence
-
-Before touching PLAN.md, gather signals about what's actually happened since the plan was last updated. Run these in parallel:
-
-**Agent 1: Git History**
-```bash
-git log --oneline -30
-```
-Look for commits that may have completed items listed in PLAN.md.
+**Agent 1: Git History Analysis**
+- `git log --oneline -50` — identify commits that completed plan items
+- `git log --since="2 weeks ago" --oneline` — surface recent work not yet reflected in the plan
+- Cross-reference commit messages against pending PLAN.md items to auto-detect completions
 
-**Agent 2: Codebase Scan**
-Search for evidence that "pending" items may already be implemented:
-- Grep for function names, component names, or feature keywords mentioned in pending items
+**Agent 2: Codebase Verification**
+- For each pending item in PLAN.md, grep for function names, component names, or feature keywords
 - Check test files for coverage of features listed as untested
 - Look at recently modified files for signs of completed work
+- Build a confidence score per item: `confirmed-done`, `likely-done`, `still-pending`, `stale`
+
+**Agent 3: Opportunity Scanner**
+- Scan for TODOs, FIXMEs, HACKs in the codebase that aren't in PLAN.md
+- Look for test coverage gaps (files with no corresponding test)
+- Check for outdated dependencies (`npm outdated`, `cargo outdated`, etc. as appropriate)
+- Review GOALS.md (if it exists) for strategic goals not yet represented in the plan
+- Identify code quality opportunities (large files, complex functions, missing error handling)
+- Formulate 1-3 suggested new items
 
-**Agent 3: GOALS.md Boundary Check**
+**Agent 4: GOALS.md Boundary Check**
 If `GOALS.md` exists:
-- Read it and check for checkbox task lists or implementation details that leaked in
+- Check for checkbox task lists or implementation details that leaked in
 - Note any items that should be absorbed into PLAN.md
 
-### 2. Interactive Item Review
+## Phase 2: Auto-Triage
 
-**This is the most important step. Do NOT skip it.**
+Using agent results, classify every PLAN.md item:
 
-Walk through PLAN.md with the user, section by section. For each section that has pending items, present your findings and ask the user to confirm status.
+| Status | Criteria | Action |
+|--------|----------|--------|
+| `confirmed-done` | Git commit + code exists + tests pass | Archive to DONE.md |
+| `likely-done` | Strong evidence but not 100% certain | Archive to DONE.md |
+| `stale` | No commits, no code, no recent discussion; item is >30 days old with zero progress | Remove from PLAN.md |
+| `still-pending` | No evidence of completion | Keep in PLAN.md |
 
-**For each group of related pending items**, use `AskUserQuestion` to verify. Batch related items together (don't ask one-by-one for 20 items). For example:
+## Phase 3: Apply Changes (or Checkpoint if Interactive)
 
-```
-I found these items still marked as pending under "Testing Gaps":
-- [ ] Server route unit tests
-- [ ] Aggregate calculation tests
-- [ ] Visual regression tests for charts
+### Default Mode (autonomous)
 
-Git history shows commits for "add server route tests" on Feb 15.
-I also found test files at packages/server/test/routes/.
+Apply all changes immediately without prompting:
 
-Which of these are actually done?
+1. Archive `confirmed-done` and `likely-done` items to DONE.md
+2. Remove `stale` items from PLAN.md
+3. Add suggested new items to the appropriate PLAN.md section
+4. Absorb any tactical items found in GOALS.md
+5. Print a brief summary of what was done:
+
+```
+Replan complete:
+- Archived {N} completed items to DONE.md
+- Removed {S} stale items
+- Added {P} new suggested items
+- {any GOALS.md boundary fixes}
 ```
 
-**How to batch the review:**
-- Group items by section (Next Up, Remaining Work, Future, etc.)
-- Present each group with any evidence you found (git commits, files that exist, grep matches)
-- Ask the user to confirm: which are done, which are still needed, which should be removed or rephrased
-- Use multiSelect questions when asking about multiple items (let the user check off what's done)
-- If a section has no evidence of changes, still ask briefly: "These items under [section] — still accurate, or any updates?"
+### Interactive Mode (`--interactive`)
+
+Present ONE consolidated summary to the user:
 
-**For known issues**, ask whether they're still reproducible or have been fixed.
+```
+AskUserQuestion([{
+  question: "Replan audit complete. Here's what I found:\n\n**Auto-archiving to DONE.md** ({N} items):\n{list of confirmed-done items}\n\n**Likely done — archive?** ({M} items):\n{list with evidence}\n\n**Flagged as stale** ({S} items):\n{list with last-activity dates}\n\n**New suggestions** ({P} items):\n{numbered list of proposed new items with rationale}\n\nHow should I proceed?",
+  multiSelect: true,
+  options: [
+    { label: "Archive confirmed-done", description: "Move {N} confirmed items to DONE.md" },
+    { label: "Archive likely-done too", description: "Also move {M} likely-done items to DONE.md" },
+    { label: "Remove stale items", description: "Delete {S} stale items from PLAN.md" },
+    { label: "Add suggested items", description: "Add {P} new items to PLAN.md" }
+  ]
+}])
+```
 
-**For "Next Actions" / priority ordering**, ask if the priorities still reflect the user's current thinking.
+**Exclusive options** (present only if the user asks, as a separate follow-up):
+- "Show me the details" — print full evidence, then re-ask the above
+- "Just clean up formatting" — only reformat PLAN.md, skip all archive/remove/add actions
 
-### 3. Extract Documentation from Completed Work
+If the user selects "Show me the details" as a response, print the full evidence and re-ask.
 
-For each completed item with substantial documentation:
-- Determine the appropriate docs location (create docs/ directory if needed)
-- Extract the detailed documentation sections
-- Move them to appropriate docs files with proper formatting
-- Follow existing documentation patterns if they exist
+For suggested new items: if the user selects "Add suggested items", present each suggestion individually so they can accept, reject, or modify each one.
 
-**Common docs files to consider:**
-- `docs/ARCHITECTURE.md` - System design, data flow, architecture
-- `docs/API.md` - API endpoints, schemas, events
-- `docs/TROUBLESHOOTING.md` - Common issues and solutions
-- `docs/features/*.md` - Individual feature documentation
-- `README.md` - User-facing documentation
+## Phase 4: Archive to DONE.md
 
-### 4. Clean Up PLAN.md
+`DONE.md` lives at project root. It's the append-only log of completed work.
 
-Using the verified information from the interactive review:
-- Mark confirmed-completed items as [x] and move to archive
-- Remove items the user confirmed are no longer relevant
-- Update wording for items the user rephrased
-- Replace detailed documentation with brief summaries + doc links
-- Remove redundant or outdated information
+### Format
 
-**Example transformation:**
 ```markdown
-Before:
-- [x] Feature X: Authentication System
+# Done Log
+
+Completed items archived from PLAN.md. For release notes, see `.changelogs/`.
 
-### Architecture
-- **Auth Service**: Core authentication logic
-- **JWT Tokens**: Token generation and validation
-[... 50 more lines of detailed docs ...]
+## 2026-03-16
 
-After:
-- [x] Feature X: Authentication System - JWT-based auth with session management. See [Authentication](./docs/features/authentication.md)
+- Implemented feature X — added auth middleware and JWT validation
+- Fixed bug Y — null check on user profile load
+- Refactored Z — extracted shared utilities from monolithic handler
+
+## 2026-03-10
+
+- Added CI pipeline for staging deploys
+- Test coverage for API routes
 ```
 
-### 5. Update Documentation Index
-- Ensure PLAN.md references all relevant docs files
-- Add any new docs files you created
-- Verify all links are correct
-- Add a Documentation section if it doesn't exist
+### Rules
 
-### 6. Rewrite Next Actions
+- Group by date (newest first)
+- One line per item — concise description of what was done, not the original checkbox text
+- If the completed item had substantial documentation (>20 lines), extract it to `docs/` and add a link: `- Feature X — see [docs/features/x.md](./docs/features/x.md)`
+- Do NOT duplicate changelog entries — DONE.md captures plan-item completion, changelogs capture release-level changes
 
-Based on the interactive review, rebuild the "Next Actions" section:
-- Ask the user: "Based on what's left, what are your top 3-5 priorities right now?"
-- Present a suggested ordering based on what you learned, but let the user override
-- Make action items specific and actionable
+## Phase 5: Rebuild PLAN.md
 
-### 7. Absorb GOALS.md Violations
+Rewrite PLAN.md to be lean and actionable:
 
-If you found checkbox items or tactical details in GOALS.md during step 1:
-- Show the user what you found
-- Offer to move them into the appropriate PLAN.md section
-- Update GOALS.md to remove the tactical items (replace with outcome prose or remove entirely)
+### Target Structure
 
-### 8. Commit Your Changes
-After reorganizing (if in a git repository):
-- Commit changes with a clear message like:
-  ```
-  docs: reorganize PLAN.md and extract completed work to docs
+```markdown
+# Development Plan
 
-  - Moved completed feature docs to docs/features/
-  - Updated PLAN.md to focus on next actions
-  - Added Next Actions section
-  ```
+For project mission and milestones, see [GOALS.md](./GOALS.md).
+For completed work, see [DONE.md](./DONE.md).
 
-## Guidelines
+## Next Up
 
-- **Verify, don't assume**: The whole point of this command is to sync PLAN.md with reality. Never mark items as done or still-pending without checking.
-- **Be thorough**: Read all completed items and assess documentation value
-- **Be surgical**: Only move substantial documentation (>20 lines), keep brief summaries in PLAN
-- **Be organized**: Group related content in docs files with clear headings
-- **Be consistent**: Match the style and format of existing docs files
-- **Be helpful**: Make it easy to find information by adding clear references
-- **Respect boundaries**: Tactical items in PLAN.md, strategic items in GOALS.md
-- **Batch intelligently**: Don't ask 20 individual questions — group related items and ask about sections at a time. Aim for 3-6 interactive checkpoints, not 20.
+1. **Item A**: Brief actionable description
+2. **Item B**: Brief actionable description
+3. **Item C**: Brief actionable description
 
-## Example Output Structure
+## Backlog
 
-After running `/replan`, the PLAN.md should have:
-```markdown
-# Project Name - Development Plan
+- [ ] Item D: Description
+- [ ] Item E: Description
 
-The tactical backlog. For mission and milestones, see [GOALS.md](./GOALS.md).
+## Future / Ideas
 
-## Documentation
-- [Architecture Overview](./docs/ARCHITECTURE.md)
-- [API Reference](./docs/API.md)
+- Item F: One-line description
+- Item G: One-line description
+```
 
-## Next Up
-- [ ] Feature C: Brief description with subtasks
+### Guidelines
 
-## Remaining Work
-### Known Issues
-- ...
-### Testing Gaps
-- [ ] ...
+- **"Next Up" is ordered** — numbered list, max 5 items, these are the immediate priorities
+- **"Backlog" is unordered** — checkbox items that are planned but not prioritized
+- **"Future / Ideas" has no checkboxes** — these are possibilities, not commitments
+- **No completed items** — they're in DONE.md
+- **No detailed docs** — link to `docs/` files instead
+- **No section if it's empty** — don't include "Backlog" with zero items
 
-## Future (v2.0+)
-- [ ] Feature D: Brief description of planned work
+## Phase 6: Absorb GOALS.md Violations
 
-## Next Actions
+If tactical items (checkboxes, implementation details) were found in GOALS.md:
+- Move them into the appropriate PLAN.md section
+- Update GOALS.md to remove tactical content
 
-1. **Task 1**: Brief description of what needs to be done
-2. **Task 2**: Brief description of next task
-3. **Task 3**: Brief description of another task
+## Phase 7: Commit
 
-## Completed Work (Archive)
-<details>
-<summary>v0.x Features</summary>
-- [x] Feature A - See [Feature A Docs](./docs/features/feature-a.md)
-- [x] Feature B - See [Feature B Docs](./docs/features/feature-b.md)
-</details>
+Stage and commit all files modified during this replan:
+```bash
+git add PLAN.md
+# Stage optional files only if they exist and were modified
+git add DONE.md 2>/dev/null || true
+git add GOALS.md 2>/dev/null || true
+git add docs/ 2>/dev/null || true
+git commit -m "docs: replan — archive {N} completed items, update priorities"
 ```
 
+Do NOT push unless explicitly asked.
+
 ## Notes
 
-- Don't delete information - move it to appropriate docs files
-- Keep related information consolidated in single docs files
-- Create feature-specific docs in docs/features/ for complex systems
-- Preserve all historical information but organize it better
-- If no PLAN.md exists, inform the user rather than creating one
-- Adapt to the existing structure and conventions of the project
-- If GOALS.md has task lists that belong in PLAN.md, migrate them
+- If no PLAN.md exists, inform the user and offer to create one from codebase analysis
+- The opportunity scanner suggestion is the key differentiator — every replan should surface at least one new idea
+- DONE.md is append-only — never delete entries from it
+- Keep PLAN.md under ~50 lines whenever possible — it should be scannable in seconds
+- Adapt to existing project structure and conventions

package/commands/do/review.md

@@ -73,7 +73,7 @@ With the flow understood, evaluate the changed code against these principles:
 - Function and variable names should communicate intent. If you need to read the implementation to understand what a name means, it's poorly named.
 - Boolean variables/params should read as predicates (`isReady`, `hasAccess`), not ambiguous nouns.
 
-Only flag principle violations that are **concrete and actionable** in the changed code. Do not flag pre-existing design issues in untouched code unless the changes make them worse.
+For this review, only flag principle and design violations that are **concrete and actionable** in the code changed by this PR. However, if you discover a clear, real bug or correctness issue — even in code not directly modified here — call it out and help ensure it gets fixed (in this PR or a follow-up). Never dismiss serious problems as "out of scope" or "not modified in this PR."
 
 </review_instructions>
 
@@ -98,6 +98,27 @@ Check every file against this checklist. The checklist is organized into tiers
 - If the PR adds a new call to an external service that has established mock/test infrastructure (mock mode flags, test helpers, dev stubs), verify the new call uses the same patterns — bypassing them makes the new code path untestable in offline/dev environments and inconsistent with existing integrations
 - If the PR adds a new UI component or client-side consumer against an existing API endpoint, read the actual endpoint handler or response shape — verify every field name, nesting level, identifier property, and response envelope path used in the consumer matches what the producer returns. This is the #1 source of "renders empty" bugs in new views built against existing APIs
 
+**Push/real-time event scoping**
+- If the PR adds or modifies WebSocket, SSE, or pub/sub event emission, trace the event scope: does the event reach only the originating session/user, or is it broadcast to all connected clients? Check payloads for sensitive content (user inputs, images, tokens) that should not leak across sessions. If the consumer filters by a correlation ID, verify the producer includes one and that the ID is generated server-side or validated against the session
+
+**Cleanup/teardown side effect audit**
+- If the PR adds cleanup, teardown, or garbage-collection functions, trace whether the cleanup performs implicit state mutations (auto-merge into main, auto-commit of unreviewed changes, cascade writes to shared state). Verify the cleanup aborts safely if a prerequisite step fails (e.g., saving dirty state before deletion) rather than proceeding with data loss
+
+**Specification/standard conformance**
+- If the PR implements or extends a parser for a well-known format (cron expressions, date formats, URLs, semver, MIME types), verify boundary handling matches the specification — especially field-specific ranges (month starts at 1, not 0), normalization conventions (cron DOW 0 and 7 both mean Sunday), and step/range semantics that differ per field type
+
+**Temporal context consistency**
+- If the PR adds timezone-aware logic alongside existing non-timezone-aware comparisons in the same code flow (e.g., a weekday gate using UTC while cron matching uses user timezone), check that all temporal comparisons in the flow use the same timezone context — mixed contexts cause operations to trigger on the wrong local day/hour
+
+**Status/health endpoint freshness**
+- If the PR adds or modifies a status or health-check endpoint, trace whether it returns live probe results or cached data. Cached health checks mask real-time failures — a cache keyed by URL that survives URL reconfiguration reports stale status. Verify health endpoints bypass caches or use sufficiently short TTLs
+
+**Boolean/type fidelity through serialization boundaries**
+- If the PR persists boolean flags to text-based storage (markdown metadata, flat files, query strings, form data), trace the round-trip: write path → storage format → read/parse path → consumption site. Boolean `false` serialized as the string `"false"` is truthy in JavaScript — verify all consumption sites use strict equality or a dedicated coercion function, and that the same coercion is applied consistently
+
+**Cross-layer invariant enforcement**
+- If the PR introduces or modifies an invariant relationship between configuration flags (e.g., "flag A implies flag B"), trace enforcement through every layer: UI toggle handlers, form submission payloads, API validation schemas, server default-application functions, and persistence round-trip. If any layer allows the invariant to be violated, cascading defaults produce contradictory state
+
 **Error path completeness**
 - Trace each error path end-to-end: does the error reach the user with a helpful message and correct HTTP status? Or does it get swallowed, logged silently, or surface as a generic 500?
 - For multi-step operations (sync to N repos, batch updates): are per-item failures tracked separately from overall success? Does the status reflect partial failure accurately?

package/commands/do/rpr.md

@@ -1,7 +1,12 @@
 ---
 description: Resolve PR review feedback with parallel agents
+argument-hint: "[--interactive]"
 ---
 
+**Default mode: fully autonomous.** Fetches review feedback, fixes issues, pushes, resolves threads, and loops Copilot reviews without prompting. Auto-skips on timeout/errors after retries.
+
+**`--interactive` mode:** Pauses on Copilot review timeout and repeated errors to ask the user how to proceed.
+
 # Resolve PR Review Feedback
 
 Address the latest code review feedback on the current branch's pull request using parallel sub-agents.
@@ -18,6 +23,8 @@ Address the latest code review feedback on the current branch's pull request usi
    ```
    Save results to `/tmp/pr_threads.json` for parsing.
 
+   **Thread-count tracking**: Count and report total unresolved threads upfront (e.g., "Found 7 unresolved review threads"). After resolution, report how many were addressed vs. remaining (e.g., "Resolved 5/7 threads, 2 left unaddressed"). This prevents partial sessions from going unnoticed across context resets.
+
 4. **Spawn parallel sub-agents to address feedback**:
    - For small PRs (1-3 unresolved threads), handle fixes inline instead of spawning agents
    - For larger PRs, spawn one `Agent` call (general-purpose type) per review thread (or group closely related threads on the same file into one agent)
@@ -40,14 +47,14 @@ Address the latest code review feedback on the current branch's pull request usi
    - Stage all changed files and commit with a descriptive message summarizing what was addressed. Do not include co-author info.
    - Push to the branch.
 
-8. **Resolve conversations**: For each addressed thread, resolve it via GraphQL mutation using stdin JSON. **Never use `$variables` in the query — inline the thread ID directly**:
+8. **Resolve conversations**: For each addressed thread, resolve it via GraphQL mutation using stdin JSON. Track resolution count against the total from step 3. **Never use `$variables` in the query — inline the thread ID directly**:
    ```bash
    echo '{"query":"mutation { resolveReviewThread(input: {threadId: \"THREAD_ID_HERE\"}) { thread { id isResolved } } }"}' | gh api graphql --input -
    ```
 
 9. **Request another Copilot review** (only if `is_fork_pr=false`): After pushing fixes, request a fresh Copilot code review and repeat from step 3 until the review passes clean. **Skip for fork-to-upstream PRs.**
 
-10. **Report summary**: Print a table of all threads addressed with file, line, and a brief description of the fix.
+10. **Report summary**: Print a table of all threads addressed with file, line, and a brief description of the fix. Include a final count line: "Resolved X/Y threads." If any threads remain unresolved, list them with reasons (unclear feedback, disagreement, requires user input).
 
 !`cat ~/.claude/lib/graphql-escaping.md`
 
@@ -73,12 +80,13 @@ gh api graphql -f query='{ repository(owner: "OWNER", name: "REPO") { pullReques
 
 **Dynamic poll timing**: Before your first poll, check how long the most recent Copilot review on this PR took by comparing consecutive Copilot review `submittedAt` timestamps (or PR creation time for the first review). Use that duration as your expected wait. If no prior review exists, default to 5 minutes. Set poll interval to 60 seconds and max wait to **2x the expected duration** (minimum 5 minutes, maximum 20 minutes). Copilot reviews can take **10-15 minutes** for large diffs — do NOT give up early.
 
-The review is complete when a new `copilot-pull-request-reviewer` review node appears. If no review appears after max wait, **ask the user** whether to continue waiting, re-request, or skip.
+The review is complete when a new `copilot-pull-request-reviewer` review node appears. If no review appears after max wait: **Default mode**: auto-skip and continue. **Interactive mode (`--interactive`)**: ask the user whether to continue waiting, re-request, or skip.
 
-**Error detection**: After a review appears, check its `body` for error text such as "Copilot encountered an error" or "unable to review this pull request". If found, this is NOT a successful review — log a warning, re-request the review (same API call above), and resume polling. Allow up to 3 error retries before asking the user whether to continue or skip.
+**Error detection**: After a review appears, check its `body` for error text such as "Copilot encountered an error" or "unable to review this pull request". If found, this is NOT a successful review — log a warning, re-request the review (same API call above), and resume polling. Allow up to 3 error retries. After 3 failures: **Default mode**: auto-skip and continue. **Interactive mode (`--interactive`)**: ask the user whether to continue or skip.
 
 ## Notes
 
 - Only resolve threads where you've actually addressed the feedback
 - If feedback is unclear or incorrect, leave a reply comment instead of resolving
 - Always run tests before committing — never push code with known failures
+- **Never dismiss findings as "out of scope" or "not modified in this PR."** If a review identifies a real issue, fix it — regardless of whether the current PR touched that code. Evaluate every finding on its merits. Don't leave trash on the floor.

package/lib/code-review-checklist.md

@@ -16,7 +16,7 @@
    **Runtime correctness**
    - Null/undefined access without guards, off-by-one errors, object spread of potentially-null values (spread of null is `{}`, silently discarding state) or non-object values (spreading a string produces indexed character keys, spreading an array produces numeric keys) — guard with a plain-object check before spreading
    - Data from external/user sources (parsed JSON, API responses, file reads) used without structural validation — guard against parse failures, missing properties, wrong types, and null elements before accessing nested values. When parsed data is optional enrichment, isolate failures so they don't abort the main operation
-   - Type coercion edge cases — `Number('')` is `0` not empty, `0` is falsy in truthy checks, `NaN` comparisons are always false; string comparison operators (`<`, `>`, `localeCompare`) do lexicographic, not semantic, ordering (e.g., `"10" < "2"`). Use explicit type checks (`Number.isFinite()`, `!= null`) and dedicated libraries (e.g., semver for versions) instead of truthy guards or lexicographic ordering when zero/empty are valid values or semantic ordering matters
+   - Type coercion edge cases — `Number('')` is `0` not empty, `0` is falsy in truthy checks, `NaN` comparisons are always false; string comparison operators (`<`, `>`, `localeCompare`) do lexicographic, not semantic, ordering (e.g., `"10" < "2"`). Use explicit type checks (`Number.isFinite()`, `!= null`) and dedicated libraries (e.g., semver for versions) instead of truthy guards or lexicographic ordering when zero/empty are valid values or semantic ordering matters. Boolean values round-tripping through text serialization (markdown metadata, query strings, form data, flat-file config) become strings — `"false"` is truthy in JavaScript, so truthiness checks on deserialized booleans silently treat explicit `false` as `true`. Use strict equality (`=== true`, `=== 'true'`) or a dedicated coercion function; ensure the same coercion is applied at every consumption site
    - Functions that index into arrays without guarding empty arrays; aggregate operations (`every`, `some`, `reduce`) on potentially-empty collections returning vacuously true/default values that mask misconfiguration or missing data; state/variables declared but never updated or only partially wired up
    - Parallel arrays or tuples coupled by index position (e.g., a names array, a promises array, and a destructuring assignment that must stay aligned) — insertion or reordering in one silently misaligns all others. Use objects/maps keyed by a stable identifier instead
    - Shared mutable references — module-level defaults passed by reference mutate across calls (use `structuredClone()`/spread); `useCallback`/`useMemo` referencing a later `const` (temporal dead zone); object spread followed by unconditional assignment that clobbers spread values
@@ -27,13 +27,15 @@
    - Route params passed to services without format validation; path containment checks using string prefix without path separator boundary (use `path.relative()`)
    - Parameterized/wildcard routes registered before specific named routes — the generic route captures requests meant for the specific endpoint (e.g., `/:id` registered before `/drafts` matches `/drafts` as `id="drafts"`). Verify route registration order or use path prefixes to disambiguate
    - Stored or external URLs rendered as clickable links (`href`, `src`, `window.open`) without protocol validation — `javascript:`, `data:`, and `vbscript:` URLs execute in the user's browser. Allowlist `http:`/`https:` (and `mailto:` if needed) before rendering; for all other schemes, render as plain text or strip the value
+   - Server-side HTTP requests using user-configurable or externally-stored URLs without protocol allowlisting (http/https only) and host/network restrictions — the server becomes an SSRF proxy for reaching internal network services, cloud metadata endpoints, or localhost-bound APIs. Validate scheme and restrict to expected hosts or external-only ranges before any server-side fetch
    - Error/fallback responses that hardcode security headers instead of using centralized policy — error paths bypass security tightening
 
    **Trust boundaries & data exposure**
    - API responses returning full objects with sensitive fields — destructure and omit across ALL response paths (GET, PUT, POST, error, socket); comments/docs claiming data isn't exposed while the code path does expose it
    - Server trusting client-provided computed/derived values (scores, totals, correctness flags, file metadata like MIME type and size) when the server can recompute or verify them — strip and recompute server-side; for file uploads, validate content type via magic bytes and size via actual buffer length rather than trusting client-supplied headers
-   - New endpoints mounted under restricted paths (admin, internal) missing authorization verification — compare with sibling endpoints in the same route group to ensure the same access gate (role check, scope validation) is applied consistently
+   - New endpoints mounted under restricted paths (admin, internal) missing authorization verification — compare with sibling endpoints in the same route group to ensure the same access gate (role check, scope validation) is applied consistently. When new capabilities require additional OAuth scopes or API permissions, verify the scope-upgrade check covers all required scopes — a check that only tests for one scope will miss newly added scopes, causing downstream API calls to fail with insufficient permissions
    - User-controlled objects merged via `Object.assign`/spread without sanitizing keys — `__proto__`, `constructor`, and `prototype` keys enable prototype pollution. Use `Object.create(null)` for the target, whitelist allowed keys, and use `hasOwnProperty` (not `in`) to check membership. Also verify the merge can't override reserved/internal fields the system depends on
+   - Push events (WebSocket, SSE, pub/sub) emitted without scoping to the originating user or session — sensitive payloads (user content, tokens, progress data, images) leak to all connected clients in multi-user environments. Scope events to the requesting session via room/channel isolation or include a correlation ID the client provides at request time; verify consumers filter events by correlation ID before updating UI state
 
 ## Tier 2 — Check When Relevant (Data Integrity, Async, Error Handling)
 
@@ -43,7 +45,8 @@
    - Error notification at multiple layers (shared API client + component-level) — verify exactly one layer owns user-facing error messages. For periodic polling, also check that error notifications are throttled or deduplicated (only fire on state transitions like success→error, not on every failed iteration) and that failure doesn't make the UI section disappear entirely (component returning null when data is null/errored) — render an error or stale-data state instead of absence
    - Optimistic updates using full-collection snapshots for rollback — a second in-flight action gets clobbered. Use per-item rollback and functional state updaters after async gaps; sync optimistic changes to parent via callback or trigger refetch on remount. When appending items to a list optimistically, guard against duplicates (check existence before append) — concurrent or repeated operations can insert the same item multiple times
    - State updates guarded by truthiness of the new value (`if (arr?.length)`) — prevents clearing state when the source legitimately returns empty. Distinguish "no response" from "empty response"
-   - Periodic/scheduled operations with skip conditions (gates, precondition checks, "nothing to do" early exits) that don't advance timing state (lastRun, nextFireTime) on skip — null or stale lastRun causes immediate re-trigger in a tight loop. Record the skip as an execution or compute the next fire time from now, not from the missing lastRun
+   - Periodic/scheduled operations with skip conditions (gates, precondition checks, "nothing to do" early exits) that don't advance timing state (lastRun, nextFireTime) on skip — null or stale lastRun causes immediate re-trigger in a tight loop. Record the skip as an execution or compute the next fire time from now, not from the missing lastRun. Also check the initial baseline for never-run items: using epoch (0) or distant-past as the default "last run" makes schedule-based items appear immediately due on first evaluation, while using "now" may cause them to never become due — choose a baseline that correctly represents "first occurrence after activation"
+   - Cached values keyed without all relevant discriminators (base URL, tenant ID, environment, configuration version) — context changes (URL reconfiguration, tenant switch) serve stale cached data from the previous context. Health/status endpoints that return cached results instead of live probes mask real-time failures, reporting "connected" when the service is unreachable. Key caches by their full context and bypass or invalidate caches for availability checks
    - Mutation/trigger functions that return or propagate stale pre-mutation state — if a function activates, updates, or resets an entity, the returned value and any dependent scheduling/evaluation state (backoff timers, "last run" timestamps, status flags) must reflect the post-mutation state, not a snapshot read before the mutation
    - Fire-and-forget or async writes where the in-memory object is not updated (response returns stale data) or is updated unconditionally regardless of write success (response claims state that was never persisted) — update in-memory state conditionally on write outcome, or document the tradeoff explicitly. Also applies to responses and business-logic decisions (threshold triggers, status transitions) derived from pre-transaction reads — concurrent writers all read the same stale value, so thresholds may be crossed without triggering the transition. Compute from post-write state or use conditional expressions that evaluate the stored value. For monotonic counters (sequence numbers, cursors) that must stay in lockstep with append-only storage, advancing before the write risks the counter running ahead on failure; not advancing after a partial write risks reuse — reserve the range before writing and commit only on success. Also check for dependent side effects (rewards, notifications, secondary uploads, resource allocation) executing in parallel with or before the primary write they depend on — if the primary write fails or is rejected (lock contention, dedup, validation), the side effects are irrecoverable (orphaned uploads, unearned rewards, phantom notifications). Gate side effects on confirmed primary write success
    - Error/early-exit paths that return status metadata (pagination flags, truncation indicators, hasMore, completion markers) or emit events (WebSocket, SSE, pub/sub) with default/initial values instead of reflecting actual accumulated state — downstream consumers make incorrect decisions (e.g., treating a failed sync as successful because the completion event was emitted unconditionally). Set metadata flags and event payloads based on actual outcome, not just the final request's exit path. Also check paired lifecycle events (started/completed/failed): if a function emits a "started" event, every exit path — including early returns and no-op branches — must emit the corresponding "completed" or "failed" event, or clients waiting for completion will hang or show stale state
@@ -62,7 +65,7 @@
 
    **Resource management** _[applies when: code uses event listeners, timers, subscriptions, or useEffect]_
    - Event listeners, socket handlers, subscriptions, timers, and useEffect side effects are cleaned up on unmount/teardown
-   - Deletion/destroy and state-reset functions that clean up or reset the primary resource but leave orphaned or inconsistent secondary resources (data directories, git branches, child records, temporary files, per-user flag/vote items) — trace all resources created during the entity's lifecycle and verify each is removed on delete. For state transitions that reset aggregate values (counters, scores, flags), also clear or version the individual records that contributed to those aggregates — otherwise the aggregate and its sources disagree, and duplicate-prevention checks block legitimate re-entry
+   - Deletion/destroy and state-reset functions that clean up or reset the primary resource but leave orphaned or inconsistent secondary resources (data directories, git branches, child records, temporary files, per-user flag/vote items) — trace all resources created during the entity's lifecycle and verify each is removed on delete. For state transitions that reset aggregate values (counters, scores, flags), also clear or version the individual records that contributed to those aggregates — otherwise the aggregate and its sources disagree, and duplicate-prevention checks block legitimate re-entry. Also check cleanup operations that perform implicit state mutations (auto-merge, auto-commit, cascade writes) as part of teardown — these can introduce unreviewed changes or silently modify shared state. Verify cleanup fails safely when a prerequisite step (e.g., saving dirty state) fails rather than proceeding with data loss
    - Initialization functions (schedulers, pollers, listeners) that don't guard against multiple calls — creates duplicate instances. Check for existing instances before reinitializing
    - Self-rescheduling callbacks (one-shot timers, deferred job handlers) where the next cycle is registered inside the callback body — an unhandled error before the re-registration call permanently stops the schedule. Wrap the callback body in try/finally with re-registration in the finally block, or register the next cycle before executing the current one
 
@@ -82,11 +85,13 @@
    - Code reading properties from API responses, framework-provided objects, or internal abstraction layers using field names the source doesn't populate or forward — silent `undefined`. Verify property names and nesting depth match the actual response shape (e.g., `response.items` vs `response.data.items`, `obj.placeId` vs `obj.id`, flat fields vs nested sub-objects). When building a new consumer against an existing API, check the producer's actual response — not assumed conventions. When branching on fields from a wrapped third-party API, confirm the wrapper actually requests and forwards those fields (e.g., optional response attributes that require explicit opt-in)
    - Data model fields that have different names depending on the creation/write path (e.g., `createdAt` vs `created`) — code referencing only one naming convention silently misses records created through other paths. Trace all write paths to discover the actual field names in use. When new logic (access control, UI display, queries) checks only a newly introduced field, verify it falls back to any legacy field that existing records still use — otherwise records created before the migration are silently excluded or inaccessible. Also check entity identity keys: if code looks up or matches entities using a computed key (e.g., `e.id || e.externalId`), all code paths that perform the same lookup must use the same key computation — one path using `e.id` while another uses `e.id || e.externalId` causes mismatches for entities missing the primary key
    - Entity type changes without invariant revalidation — when an entity has a discriminator field (type, kind, category) and the user changes it, all type-specific invariants must be enforced on the new type AND type-specific fields from the old type must be cleared or revalidated. A job changing from `shell` to `agent` without clearing `command`, or changing to `shell` without requiring `command`, leaves the entity in an invalid hybrid state that fails at runtime or resurfaces stale data
+   - Invariant relationships between configuration flags (flag A implies flag B) not enforced across all layers — UI toggle handlers, API validation schemas, server default-application functions, and serialization/deserialization must all preserve the invariant. If any layer allows setting A=true with B=false (or vice versa), cascading defaults and toggle logic produce contradictory state. Trace the invariant through: UI state handlers, form submission, route validation, service defaults, and persistence round-trip
    - Operations scoped to a specific entity subtype that don't verify the entity's type discriminator before processing — an endpoint or function designed for one account/entity type that accepts any entity by ID can corrupt state or produce wrong results when called with the wrong type. Add an explicit type guard and return a structured error
-   - Inconsistent "missing value" semantics across layers — one layer treats `null`/`undefined` as missing while another also treats empty strings or whitespace-only strings as missing. Query filters, update expressions, and UI predicates that disagree on what constitutes "missing" cause records to be skipped by one path but processed by another. Define a single `isMissing` predicate and use it consistently, or normalize empty/whitespace values to `null` at write time. Also applies to comparison/detection logic: coercing an absent field to a sentinel (`?? 0`, default parameters) makes the logic treat "unsupported" as a real value — guard with an explicit presence check before comparing. Watch for validation/sanitization functions that return `null` for invalid input when `null` also means "clear/delete" downstream — malformed input silently destroys existing data. Distinguish "invalid, reject the request" from "explicitly clear this field"
+   - Inconsistent "missing value" semantics across layers — one layer treats `null`/`undefined` as missing while another also treats empty strings or whitespace-only strings as missing. Query filters, update expressions, and UI predicates that disagree on what constitutes "missing" cause records to be skipped by one path but processed by another. Define a single `isMissing` predicate and use it consistently, or normalize empty/whitespace values to `null` at write time. Also applies to comparison/detection logic: coercing an absent field to a sentinel (`?? 0`, default parameters) makes the logic treat "unsupported" as a real value — guard with an explicit presence check before comparing. Watch for validation/sanitization functions that return `null` for invalid input when `null` also means "clear/delete" downstream — malformed input silently destroys existing data. Distinguish "invalid, reject the request" from "explicitly clear this field". Also applies to normalization (trailing slashes, case, whitespace): if one path normalizes a value before comparison but the write path stores it un-normalized, comparisons against the stored value produce incorrect results — normalize at write time or normalize both sides consistently
+   - Validation functions that delegate to runtime-behavior computations (next schedule occurrence, URL reachability, resource resolution) — conflating "no result within search window" or "temporarily unavailable" with "invalid input" rejects valid configurations. Validate syntax and structure independently of runtime feasibility
    - Numeric values from strings used without `NaN`/type guards — `NaN` comparisons silently pass bounds checks. Clamp query params to safe lower bounds
    - UI elements hidden from navigation but still accessible via direct URL — enforce restrictions at the route level
-   - Summary counters/accumulators that miss edge cases (removals, branch coverage, underflow on decrements — guard against going negative with lower-bound conditions); silent operations in verbose sequences where all branches should print status
+   - Summary counters/accumulators that miss edge cases (removals, branch coverage, underflow on decrements — guard against going negative with lower-bound conditions); counters incremented before confirming the operation actually changed state — rejected, skipped, or no-op iterations inflate success counts. Silent operations in verbose sequences where all branches should print status
 
    **Concurrency & data integrity** _[applies when: code has shared state, database writes, or multi-step mutations]_
    - Shared mutable state accessed by concurrent requests without locking or atomic writes; multi-step read-modify-write cycles that can interleave — use conditional writes/optimistic concurrency (e.g., condition expressions, version checks) to close the gap between read and write; if the conditional write fails, surface a retryable error instead of letting it bubble as a 500
@@ -98,7 +103,7 @@
 
    **Input handling** _[applies when: code accepts user/external input]_
    - Trimming values where whitespace is significant (API keys, tokens, passwords, base64) — only trim identifiers/names
-   - Endpoints accepting unbounded arrays/collections without upper limits — enforce max size or move to background jobs
+   - Endpoints accepting unbounded arrays/collections without upper limits — enforce max size or move to background jobs. Also check internal operations that fan out unbounded parallel I/O (e.g., `Promise.all(files.map(readFile))`) — large collections risk EMFILE (too many open file descriptors) or memory exhaustion. Use a concurrency limiter or batch processing for collections that can grow without bound
    - Security/sanitization functions (redaction, escaping, validation) that only handle one input format — if data can arrive in multiple formats (JSON `"KEY": "value"`, shell `KEY=value`, URL-encoded, headers), the function must cover all formats present in the system or sensitive data leaks through the unhandled format
 
 ## Tier 3 — Domain-Specific (Check Only When File Type Matches)
@@ -124,6 +129,7 @@
    **Lazy initialization & module loading** _[applies when: code uses dynamic imports, lazy singletons, or bootstrap sequences]_
    - Cached state getters returning null before initialization — provide async initializer or ensure-style function
    - Module-level side effects (file reads, SDK init) without error handling — corrupted files crash the process on import
+   - File writes that assume the parent directory exists — on fresh installs or after directory cleanup, the write fails with ENOENT. Ensure the directory exists before writing (or create it on demand)
    - Bootstrap/resilience code that imports the dependencies it's meant to install — restructure so installation precedes resolution
    - Re-exporting from heavy modules defeats lazy loading — use lightweight shared modules
 
@@ -167,7 +173,7 @@
    - Completion markers, success flags, or status files written before the operation they attest to finishes — consumers see false success if the operation fails after the write
    - Existence checks (directory exists, file exists, module resolves) used as proof of correct/complete installation — a directory can exist but be empty, a file can exist with invalid contents. Verify the specific resource the consumer needs
    - Lookups that check only one scope when multiple exist — e.g., checking local git branches but not remote, checking in-memory cache but not persistent store. Trace all locations where the resource could exist and check each
-   - Tracking/checkpoint files that default to empty on parse failure — causes full re-execution. Fail loudly instead
+   - Tracking/checkpoint files that default to empty on parse failure — causes full re-execution. Fail loudly instead. More broadly, safety/guard checks that catch errors and default to "safe to proceed" (fail-open) rather than treating errors as "unsafe, abort" (fail-closed) — a guard that silently succeeds on error provides no protection when it's needed most
    - Registering references to resources without verifying the resource exists — dangling references after failed operations
 
    **Automated pipeline discipline**

package/lib/copilot-review-loop.md

@@ -56,8 +56,8 @@ Run the following loop until Copilot returns zero new comments:
    - Error detection: if the review body contains "Copilot encountered an
      error" or "unable to review this pull request", re-request (step 1)
      and resume polling. Max 3 error retries before reporting failure.
-   - If no review appears after max wait, report the timeout — the parent
-     agent will ask the user what to do
+   - If no review appears after max wait, report the timeout.
+     **Default mode**: skip and continue. **Interactive mode (`--interactive`)**: ask the user what to do
 
 3. CHECK for unresolved comments:
    - Filter review threads for isResolved: false
@@ -70,6 +70,7 @@ Run the following loop until Copilot returns zero new comments:
 4. FIX all unresolved review comments:
    For each unresolved thread:
    - Read the referenced file and understand the feedback
+   - Evaluate if the finding is a real issue — if it is, fix it regardless of whether the current PR modified that code. Never dismiss findings as "out of scope" or "pre-existing."
    - Make the code fix
    - Run the build command
    - If build passes, commit: address review: <summary>
@@ -78,8 +79,8 @@ Run the following loop until Copilot returns zero new comments:
    - After all threads resolved, push all commits to remote
    - Increment iteration counter
    - If iteration counter reaches 10, stop the loop and report back with
-     status "guardrail" — the parent agent will ask the user whether to
-     continue or stop
+     status "guardrail". **Default mode**: auto-stop and mark as best-effort.
+     **Interactive mode (`--interactive`)**: ask the user whether to continue or stop
    - Otherwise, go back to step 1
 
 When done, report back:
@@ -89,4 +90,8 @@ When done, report back:
 - Any unresolved threads remaining
 ```
 
-Launch the sub-agent and wait for its result. If the sub-agent reports a timeout or error, **ask the user** whether to continue waiting, re-request the review, or skip — never proceed without user approval when the review loop fails.
+Launch the sub-agent and wait for its result.
+
+**Default mode**: If the sub-agent reports a timeout or error, skip the timed-out review and continue autonomously.
+
+**Interactive mode (`--interactive`)**: If the sub-agent reports a timeout or error, ask the user whether to continue waiting, re-request the review, or skip.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "slash-do",
-  "version": "1.8.0",
+  "version": "2.0.0",
   "description": "Curated slash commands for AI coding assistants — Claude Code, OpenCode, Gemini CLI, and Codex",
   "author": "Adam Eivy <adam@eivy.com>",
   "license": "MIT",