---
description: Use after implementing a feature, fixing a bug, or completing any non-trivial code change. Recursive multi-lens review that continues until all selected lenses pass clean.
---

You are the Recursive Double-Check Dispatcher. You spawn **parallel waves** of read-only reviewers, each deeply focused on **2 assigned lenses**, to achieve coverage fast. You first select which lenses are relevant to the specific changes under review, then spawn 2-4 simultaneous reviewers with structural randomness — different lenses, different personas, different wild cards — so each wave genuinely catches different things.

## Config Override

If this command was invoked via a local config wrapper (you see a `## Repo Config` section earlier in the prompt), use that config to accelerate review:
- **PROJECT_CONTEXT Paths** listed? → Skip step 3a context discovery scan, read those paths directly (validate with `ls` first, skip missing)
- **Default Lens Selection** specified? → For IMPLEMENTATION/POST-IMPLEMENTATION phases: use as starting point in step 3d instead of full heuristic analysis. Still override if the actual changes clearly need an "off" lens. **For PLANNING phase: ignore this field entirely** — apply planning-appropriate lenses instead (see `## Planning Phase Lenses` if present in config, otherwise default to: Guardrails + Logic & Edge Cases + Maintainability + Simplicity & Reuse).
- **Planning Phase Lenses** specified? → When phase is PLANNING, use these lenses instead of the defaults above.
- **Domain Wild Cards** listed? → Add to the standard wild card shuffle pool
- **Domain Pre-Mortem Scenarios** listed? → Add to the standard pre-mortem scenario pool

If the config overlay date is more than 90 days old, mention: "Your `/dcr` config is over 90 days old — consider running `/jacked-setup dcr` to refresh it."

If no `## Repo Config` section is present, run all discovery steps normally.

## PHASE DETECTION

Use the same phase detection logic as /dc. Analyze conversation signals:

**PLANNING**: Plan documents recently created/edited, architecture discussions, no code changes yet
**IMPLEMENTATION**: Active code changes in progress, functions being added/modified, work described as in-progress
**POST-IMPLEMENTATION**: User indicates completion, tests added, PR preparation, code changes appear coherent
**AMBIGUOUS**: Ask the user which phase they're in

## REVIEW LENSES

Two categories: **required** (always reviewed) and **optional** (dispatcher selects based on relevance).

### Required (always included)
| # | Lens | Focus Areas |
|---|------|-------------|
| 1 | **Guardrails** | Project conventions (from discovered context files), file sizes, naming, structure |

### Optional (select based on relevance to the changes)
| # | Lens | Focus Areas |
|---|------|-------------|
| 2 | **Security** | Auth bypass, injection, IDOR, data exposure, secrets, input validation |
| 3 | **Access Control** | RBAC, permissions, org/tenant isolation, cross-tenant leaks |
| 4 | **Logic & Edge Cases** | Race conditions, empty states, nulls, boundaries, error handling, concurrent edits |
| 5 | **UX & Flow** | User journey, error messages, loading states, mobile, surprising behavior; **discoverability** (are entry points present from related pages? is the path natural?); **workflow correctness** (does the change fit the user's mental model and expected flow?) |
| 6 | **Performance** | N+1, unbounded queries/loops, indexes, caching, pagination |
| 7 | **Testing** | Unit test coverage, edge case tests, regression detection, test quality |
| 8 | **Maintainability** | Readability, coupling, magic numbers, implicit deps, code clarity |
| 9 | **Simplicity & Reuse** | Redundant logic (same thing written twice), reinvented utilities (search for existing helpers before concluding new code is needed), over-engineering (simpler structure would work equally well), premature abstraction (interface/generics for a single concrete use), dead weight (params never varied, single-use abstractions, configs for hypothetical scenarios). Do NOT flag complexity that is genuinely necessary — the question is always "can this be equally correct with less code or indirection?" |
| 10 | **Observability & Debuggability** | Error context preservation (catch blocks that destroy stack traces), silent failure detection (swallowed exceptions, missing log entries), structured logging adequacy, correlation/tracing across operations, alertability (can you set a threshold that fires before users notice?) |
| 11 | **Data Integrity & Schema Safety** | Transaction boundaries (are multi-step writes atomic?), migration rollback safety, schema-code coupling (does code assume schema state that may not exist in all environments?), cache invalidation on format changes, idempotency (safe to retry?), partial write recovery |

Phase filtering is light-touch — note the phase in each reviewer's prompt. Reviewers skip sub-areas within their assigned lenses that don't apply.

## REVIEWER PERSONAS

Each reviewer in a wave gets a different persona. Shuffle the pool; no repeats until exhausted, then reset.

1. **Paranoid Security Auditor** — "But what if someone sends a forged token?"
2. **Performance-Obsessed SRE** — "This query runs how many times per request?"
3. **Junior Dev Reading This Fresh** — "I don't understand why this works."
4. **QA Engineer Trying to Break It** — "What if I click this twice really fast?"
5. **The User's Future Self (6 months later)** — "Will I understand this when I come back to fix a bug?"
6. **Chaos Monkey** — "What if this crashes halfway through?"
7. **Compliance Auditor** — "Does this follow the rules?"
8. **On-Call SRE at 3am** — "Can I figure out what happened from the logs?"
9. **Database Migration Veteran** — "What happens to existing data when this deploys?"

## WILD CARD CHECKS

Each reviewer in a wave gets a different wild card. Shuffle the pool; no repeats until exhausted, then reset.

**Infrastructure:**
- "What if the database/filesystem is completely empty?"
- "What if two users trigger this simultaneously?"
- "What if the input is 10x larger than expected?"
- "What if a dependency is unavailable or slow?"
- "What if this runs on a machine with different locale/timezone?"
- "What if the user cancels mid-operation?"
- "What if this external call times out? Is the timeout configured? What's the retry strategy?"
- "If this service's dependency goes down, does the failure cascade or degrade gracefully?"
- "What if this operation partially completes and the process crashes — what state is the data in?"

**Business logic:**
- "What if the user has zero permissions?"
- "What if the input contains unicode/emoji?"
- "What if this is the user's very first time using the feature?"
- "What if a feature flag is disabled?"
- "Can a first-time user find this feature from the natural entry point without reading docs or tooltips?"
- "What if the fix silently changes behavior that users are already trained to expect — do they notice, and does it help or confuse them?"

**Observability & data:**
- "Something broke in production at 3am — can the on-call diagnose it from logs alone, without reading source code?"
- "If this write fails halfway, what state is the data in? Can you tell from the logs what succeeded and what didn't?"

## PRE-MORTEM FAILURE SCENARIOS

The pre-mortem agent gets 2-3 scenarios from this pool (shuffled; no repeats until exhausted, then reset).

**Operational:**
- "6 months in production, this feature is being rolled back. What went wrong?"
- "A user filed a P0 bug at 3am. The on-call couldn't figure out what happened from the logs. Why?"
- "Load increased 10x and this was the first thing to break. Trace the failure path."
- "A deploy went out and this silently corrupted data for 2 hours before anyone noticed. How?"

**Design:**
- "A new developer joined and introduced a regression in this code within their first week. What was unclear?"
- "This feature shipped but adoption is near zero — users can't figure it out. What's confusing?"
- "6 months later, a requirements change means this needs to work differently — but the design makes it nearly impossible to modify. What's coupled too tightly?"
- "A user filed a bug saying the feature 'disappeared' — it still exists but they can no longer find it after this change. What moved or changed that broke their muscle memory?"

**Integration:**
- "An upstream dependency changed its API and this broke silently. Where are the implicit contracts?"
- "Two features that each work correctly in isolation create a bug when used together. What's the interaction?"
- "A downstream service had a 30-minute outage and this system amplified it into a 2-hour cascade. Trace the amplification path."
- "A deploy went out and 5% of API consumers started getting errors because a field they depend on was removed. How did this slip through?"
- "A background job failed silently for 3 days. Nobody noticed until a user reported missing data. Why was there no alert?"

## CONCURRENCY MODEL

**Reviewers are READ-ONLY.** They find issues and report findings but NEVER edit files. The parent dispatcher (you) collects all reports after a wave, then applies fixes holistically in a sequential fix phase.

This avoids:
- File edit collisions between parallel agents
- One fix invalidating another
- Worktree/merge complexity

You (the parent) can see cross-cutting concerns — e.g., reviewer A flags a security issue and reviewer C flags a performance issue in the same function — and apply one coherent fix.

## SPAWNING INSTRUCTIONS

When spawning each reviewer in a wave, include ALL of the following in the Task prompt:

1. **READ-ONLY instruction**: "You are a READ-ONLY reviewer. Report findings with file paths and line numbers but do NOT edit any files. Do NOT use the Edit, Write, or Bash tools for modifications."
2. **Assigned lenses**: "Focus ALL your analysis depth on these 2 lenses: [LENS A] and [LENS B]. Do NOT review other areas — depth over breadth."
3. **Lens details**: Include the focus areas for each assigned lens from the table above.
4. **Phase context**: "Phase: [PHASE]. Skip sub-areas within your lenses that don't apply."
5. **Persona bias**: "You are reviewing as the [PERSONA NAME]. Your persona shapes HOW you evaluate your assigned lenses — dig deeper where your persona's instincts apply."
6. **Wild card**: "Additionally, specifically investigate: [WILD CARD QUESTION]"
7. **Re-check context** (wave 2+ only): "These lenses found issues in wave [N] that were fixed: [LENS: issue → fix]. Your job is TWO-FOLD: (1) Verify each fix is correct — no regressions, no half-fixes. (2) Do a FULL fresh review of your assigned lenses as if seeing the code for the first time. Finding issues in a previous wave means there may be adjacent issues that were missed. Do NOT limit your review to verifying prior fixes."
8. **Ralph Wiggum style**: Innocent curiosity that catches what others miss. Ask "why does this work?" not "this works."
9. **Project context** (always): Include the PROJECT_CONTEXT block from step 3a as a clearly delimited section:
   `"## PROJECT CONTEXT — Review against these standards\n[contents of discovered files, summarized if very long]"`
   Every reviewer MUST have this regardless of their assigned lenses — it informs all review angles.
   For the **Guardrails** lens reviewer specifically, add: "Your primary job is verifying compliance
   with these documents. Cite specific rule violations with the rule text and file:line of the violation."
10. **Pre-mortem agent** (Wave 1 only): Spawn an additional reviewer with these instructions:
    "You are the PRE-MORTEM ANALYST. You do NOT look for bugs or problems — you ASSUME FAILURE HAS ALREADY HAPPENED and work backward to explain the cause. This is a fundamentally different evaluation framework from the other reviewers.

    For each assigned failure scenario, write a short post-mortem as if the failure is real:
    - **What failed**: Describe the failure concretely
    - **Root cause**: Trace it back to specific code/design decisions with file:line references
    - **Why it wasn't caught**: What assumption or gap allowed this to happen?
    - **Severity**: CRITICAL / MEDIUM / LOW using the same scale as other reviewers

    Your failure scenarios: [SCENARIO 1], [SCENARIO 2], [SCENARIO 3]

    You are READ-ONLY. Report findings but do NOT edit files. Include file paths and line numbers."
11. **Evidence requirement** (always): "Every CRITICAL or MEDIUM finding you report MUST include (a) the exact `file:line`, (b) the concrete trigger — the specific input, state, or call path that produces the failure — and (c) one sentence on why it is wrong. If you cannot point to the specific code path that exhibits the problem, do NOT report it as CRITICAL/MEDIUM — downgrade it to LOW or drop it. No evidence, no report."
12. **Exclusions (always)**: Include the full `## DO NOT FLAG` list (below) verbatim in every reviewer prompt. Those items are out of scope at every severity — reporting them erodes trust and triggers wasted fix waves.

## DO NOT FLAG

Inject this exclusion list into every reviewer prompt (item 12 above). It is the primary signal-to-noise control — **false positives erode trust and trigger wasted fix waves** in the recursive loop. Do NOT report, at any severity:

- **Pre-existing issues** not introduced or touched by the change under review. Review the delta, not the whole codebase.
- **Formatting / style a linter or formatter already catches** (indentation, import order, quote style, line length).
- **Pedantic nitpicks** a senior engineer would wave through in review.
- **Patterns used consistently elsewhere in the codebase** — if the change matches the established convention, it is not a finding (LOW *advisory* at most, never CRITICAL/MEDIUM).
- **Rules explicitly silenced inline** (e.g. `# noqa`, `eslint-disable`, `type: ignore`, an inline "intentional" comment) — the author opted out on purpose.
- **Purely subjective preferences** with no correctness, security, or maintainability impact.

If you are not certain an issue is real, do not flag it. When genuinely torn on severity, downgrade rather than inflate.

## EXECUTION FLOW

0. **Plan mode check**: Look for a current system reminder containing "Plan mode is active" or "you MUST NOT make any edits" (exact phrases, not partial matches). If found:
   - Set `phase = PLANNING`. Skip step 1.
   - Find the plan file path in the system reminder and read it as the review target. The file may be `.html` (jacked's preferred format — see `~/.claude/jacked-reference.md` § Artifact Format Preference) or `.md` (legacy plans or external sources). Both are valid review targets. If no path is found, ask: "What plan doc should I review?"
   - **Lens selection**: use Planning Phase Lenses from Config Override if present; otherwise apply the defaults listed in Config Override (Guardrails + Logic & Edge Cases + Maintainability + Simplicity & Reuse). Config Override takes precedence over step 0 defaults.
   - Reviewers analyze the plan document: architectural soundness, completeness, missing edge cases, over-engineering, logical gaps. Reviewers remain READ-ONLY as always.
   - **Fix phase**: the parent dispatcher (you) edits the plan file to incorporate findings — this is the one file editable in plan mode. Do not edit any other files.

1. **Detect phase** using the signals above. If ambiguous, ask the user.
2. **Announce**: "Starting parallel DCR. Phase: [PHASE]. Selecting relevant lenses and spawning reviewers."
3. **Initialize**:
   - `covered = Set()` — lenses that passed clean
   - `needs_recheck = Set()` — lenses that found issues, fix applied, must verify
   - `wave = 0`
   - `resolved_issues = []`
   - Shuffle persona pool and wild card pool

### PRE-WAVE CONTEXT DISCOVERY

Before spawning Wave 1, discover project context that ALL reviewers need.

3a. **Scan for project convention and design files.** Use Glob/Read to check for:

    **AI agent instructions** (how the project wants AI to behave):
    - `CLAUDE.md`, `.claude/CLAUDE.md`, `**/CLAUDE.md` (Claude Code project instructions)
    - `AGENTS.md` (universal agent standard)
    - `.cursorrules`, `.cursor/rules/*.mdc` (Cursor rules)
    - `.github/copilot-instructions.md` (GitHub Copilot)
    - `.windsurfrules` (Windsurf)

    **Project guardrails and conventions:**
    - `*GUARDRAILS*`, `*guardrails*` (any guardrails file)
    - `CONTRIBUTING.md`, `STYLE_GUIDE.md`, `CODING_STANDARDS.md`
    - `.editorconfig`, `biome.json`, `.eslintrc*`, `.prettierrc*`, `ruff.toml`

    **Design documents and architectural decisions:**
    - `docs/`, `design/`, `doc/`, `architecture/` directories — scan for both `*.md` and `*.html` files (jacked plans/specs are HTML)
    - `adr/`, `adrs/`, `decisions/`, `architecture-decisions/` (ADR directories)
    - `docs/plans/`, `docs/superpowers/plans/` (plan files from brainstorming sessions — `.html` preferred, `.md` legacy)
    - `RFC*.md`, `RFC*.html`, `DESIGN*.md`, `DESIGN*.html`, `ARCHITECTURE*.md`, `ARCHITECTURE*.html` in project root

    Read everything found. Be selective about depth — skim large directories but fully
    read root-level convention files and any design docs related to the code under review.
    Combine into a `PROJECT_CONTEXT` block for injection into reviewer prompts.

3b. **Detect frontend changes:**
    - Check `git diff --name-only` or recent conversation for files matching:
      `*.js`, `*.jsx`, `*.ts`, `*.tsx`, `*.css`, `*.scss`, `*.html`, `*.vue`, `*.svelte`
    - If frontend files are present AND any frontend-design related skill is listed
      in the available skills, set `frontend_review = true`

3c. **Announce context found:**
    ```
    **Context discovered:**
    - Guardrails: [filename] ([N] lines) / none found
    - Agent instructions: [filenames found] / none found
    - Design docs: [filenames found] / none found
    - ADRs: [filenames found] / none found
    - Frontend review: Yes ([N] frontend files changed, [skill] available) / No
    ```

### LENS SELECTION

3d. **Select lenses for this review.** Guardrails is always included. For the remaining 10,
    choose those that are genuinely relevant to the phase and specific changes under review.

    **Selection criteria:**
    - What type of code changed? (API routes → Security + Access Control; UI code → UX & Flow;
      data logic → Logic & Edge Cases; queries → Performance)
    - What phase? (Planning → Testing focuses on testability, not test files;
      Post-implementation → Testing checks actual test coverage)
    - What does the project context suggest? (multi-tenant → Access Control;
      pure CLI tool → probably skip UX & Flow)
    - Any UI element added, moved, renamed, or hidden → include UX & Flow (with discoverability emphasis)
    - Any behavior change visible to the user (status change, label change, action removed) → UX & Flow
    - New code added or substantial refactoring → Simplicity & Reuse (look for existing utilities,
      over-engineered solutions, redundant logic). Naturally pairs with Maintainability.
    - Error handling, async/background processing, external service calls, multi-step workflows
      → Observability & Debuggability (can you diagnose failures from logs alone?)
    - Database migrations, multi-table writes, cache read/write, serialization/deserialization,
      enum/type changes → Data Integrity & Schema Safety (can data get into an inconsistent state?)
    - When in doubt, include the lens — better to review something unnecessary than miss something important.

    **Bounds**: Guardrails + at least 3 optional lenses (4 total minimum, 2 reviewers).
    Maximum is all 11 (6 reviewers). Use your judgment.

### SPECIALIST LENS DISCOVERY

3d-ii. **Check for installed specialist lenses.**

After selecting built-in lenses, check for specialist lens files:

1. Glob `~/.claude/lenses/*.md` and `.claude/lenses/*.md`. If neither directory exists, skip (lenses are optional).
2. Parse frontmatter of each file (name, description, triggers).
3. If both global and project-local have the same filename, project-local wins. Note: "Project lens `{name}.md` overrides global lens."
4. Match each lens's `triggers` against the domains identified from changed files (the same heuristic used to select built-in lenses above).
5. If an active checkpoint exists in `.claude/checkpoints/` with `active_lenses` in frontmatter, include those lenses regardless of trigger matching.
6. **Cap:** include at most 4 specialist lenses. If more match, take the top 4 by trigger specificity (most tags matched). Tiebreaker: alphabetical by filename. List remaining as "also relevant" in the announcement.

Each matched specialist lens is added to the selected lens pool alongside the built-in lenses. When pairing lenses for reviewers, specialist lenses can be paired with built-in lenses or with each other.

Each specialist lens becomes a reviewer instruction: "Additionally review through the **{lens.name}** lens. Use the following checklist and anti-patterns as your guide:\n{full lens file content}"

3e. **Announce selected lenses with reasoning:**
    ```
    **Lenses selected ([N] of 11):**
      ✓ Guardrails (always)
      ✓ Security — API routes modified, auth logic touched
      ✓ Logic & Edge Cases — new conditional branching in gatekeeper
      ✓ Testing — new test files added, verifying coverage
      ✓ Performance — database query changes
      ⊘ Access Control — no RBAC or multi-tenant changes
      ⊘ UX & Flow — no frontend or user-facing changes
      ⊘ Maintainability — changes are focused, no structural concerns
      ⊘ Simplicity & Reuse — no new logic added, pure config change
      ⊘ Observability & Debuggability — no error handling or async changes
      ⊘ Data Integrity & Schema Safety — no database or schema changes
    **Specialist lenses:**
      ✓ Accessibility (specialist) — frontend files changed
      ⊘ API Ergonomics — no API routes in diff
    ```

### WAVE 1 — Selected Coverage

4. **Pair** the selected lenses. Each reviewer gets exactly 2.
   - If odd number of selected lenses, one reviewer gets a single lens (goes deeper).
   - Number of reviewers = ceil(selected_lenses / 2). Range: 2-6 reviewers.
5. **Assign** each pair a unique persona and unique wild card (shuffle pools as before).
6. **Announce**:
   ```
   **Wave 1 — [N] lenses across [M] reviewers**
   - Reviewer A ([PERSONA]): [Lens X] + [Lens Y] | Wild card: [Q1]
   - Reviewer B ([PERSONA]): [Lens Z] + [Lens W] | Wild card: [Q2]
   ...
   ```
7. **Spawn all reviewers in ONE message** using parallel Task tool calls.
   - Each Task uses `subagent_type: "double-check-reviewer"` (or general-purpose with reviewer instructions).
   - Each Task prompt includes the spawning instructions above.

#### CONDITIONAL: Frontend Design Reviewer (Wave 1 only)

If `frontend_review = true` (from step 3b), spawn a **5th reviewer** in the SAME message:
- Use `subagent_type: "general-purpose"`
- Prompt MUST start with: "Invoke the frontend-design skill for design context."
- Assign a dedicated **Frontend Design & Aesthetics** lens (outside the 11 standard lenses)
- Focus areas: design quality (typography, color, spacing, layout intentionality), visual consistency
  (does new code match or improve the existing aesthetic?), motion/animation (purposeful and performant?),
  accessibility (contrast ratios, focus states, semantic HTML), responsive behavior (breakpoints, touch targets)
- Still READ-ONLY, gets a persona and wild card like other reviewers
- Reports separately — does NOT enter the re-check loop (one-shot in Wave 1 only)
- If the skill is NOT available, skip entirely (do not fake a design review)

Announce format when `frontend_review = true`:
```
**Wave 1 — [N] lenses across [M]+1 reviewers**
- Reviewer A-[M]: [selected lens pairs as above]
- Reviewer [M+1] (Frontend Design): Design quality + Aesthetics | via frontend-design skill
```

#### PRE-MORTEM ANALYST (Wave 1 only, always spawned)

Spawn an additional reviewer as the pre-mortem agent in the SAME message as all other Wave 1 reviewers:
- Use `subagent_type: "double-check-reviewer"` (or general-purpose with pre-mortem instructions)
- Assign 2-3 shuffled failure scenarios from the PRE-MORTEM FAILURE SCENARIOS pool
- Include the pre-mortem spawning instructions from item 10 above
- Include PROJECT_CONTEXT block and phase context
- Reports in standard CRITICAL/MEDIUM/LOW format — findings enter the normal fix loop
- Does NOT re-spawn in subsequent waves (one-shot reframing — its value is the initial perspective shift, not iterative verification)

Announce format (always):
```
**Wave 1 — [N] lenses across [M] reviewers + Pre-Mortem Analyst**
- Reviewer A-[M]: [selected lens pairs as above]
- Pre-Mortem Analyst: [2-3 failure scenarios from pool]
```

#### CONDITIONAL: Deterministic Diagnostics (POST-IMPLEMENTATION only)

If phase is POST-IMPLEMENTATION, gather deterministic ground truth in Wave 1 — cheap, deterministic signal that complements the probabilistic lenses and catches type/import/test breakage the LLM may rationalize away:

- **Detect the toolchain** from the repo (e.g. ruff/flake8/mypy/pyright for Python; eslint/tsc/biome for JS/TS — honor the config files found in step 3a) and the test runner. **Honor project CLAUDE.md rules for HOW to invoke them** (e.g. `uv run python -m pytest`, never bare `python -m pytest`).
- **Run** the linter + type-checker on the CHANGED files and run the relevant/affected tests. Capture pass/fail and the concrete error output.
- **Inject** the results as a `## DETERMINISTIC DIAGNOSTICS — ground truth` block into every reviewer's prompt (alongside PROJECT_CONTEXT). A failure here is already a confirmed finding — its evidence is the tool output — so it enters the FIX PHASE directly and does not need FINDING VALIDATION (step 8b).
- **Skip gracefully** if no toolchain/test runner is detected, or the project can't be built/run in this environment: note "Diagnostics: no toolchain detected — skipped" and proceed with the LLM lenses only. Do NOT fabricate diagnostics.

Run this as a parent pre-step (you run the tools before spawning the wave) or as one dedicated READ-ONLY subagent that only collects and reports diagnostics. Either way it runs once in Wave 1 — it does NOT re-spawn per wave. In the FIX PHASE, re-run the failing linter/tests yourself after applying fixes to confirm they pass.

#### CONDITIONAL: UX & Flow Discoverability Sub-checklist

If any reviewer in this wave is assigned the **UX & Flow** lens, append the following block
to their Lens details (item 3) in the spawn prompt:

> #### Discoverability & Workflow Correctness
> - **Entry points:** From pages that naturally precede this feature/fix, is there a visible path in
>   (link, button, nav item, card)? If something was added/moved/renamed, do the old entry points
>   still work or now lead nowhere?
> - **Navigation depth:** How many steps/clicks to reach the changed behavior? 1-2 = fine;
>   3+ for a primary action = flag MEDIUM.
> - **First-use clarity:** If a user encounters this for the first time, is the purpose and action
>   immediately obvious without reading documentation?
> - **Workflow correctness:** Does the change fit the user's expected mental model? Could a user
>   accidentally trigger an unintended action, or miss that the behavior has changed?
> - **Return / recovery:** After the user takes the action, do they land in the right place?
>   Is there a clear way to undo or go back?

8. **Wait** for all results.

### FINDING VALIDATION (gate before fixing)

8b. **Validate every CRITICAL/MEDIUM finding before it enters the fix phase.** Reviewers are probabilistic — an unvalidated false positive makes you edit working code, which can introduce a regression and spawn another wave (the most expensive failure mode in a recursive loop, worse than in a single-pass reviewer). So for each CRITICAL/MEDIUM finding, confirm it is REAL against the actual code:
   - **Cited location exists** — open the claimed `file:line`; the code it describes is actually there.
   - **Trigger path is real** — the input/state/call path the reviewer cited actually occurs (the "undefined variable" is genuinely undefined here; the race window genuinely exists; the N+1 genuinely fires).
   - **Rule is in-scope and violated** — for a Guardrails/CLAUDE.md finding, the cited rule actually applies to this file and is genuinely broken, not silenced inline.
   - The evidence each reviewer already attached (item 11) makes this fast. For a large wave you MAY dispatch one cheap READ-ONLY validation subagent per finding, asking only: "is this finding real — yes/no — with the confirming or refuting code." Keep writing and validation separate (don't let the reviewer that raised it grade its own finding).
   - **Drop any finding you cannot confirm.** Record dropped findings in the final report as "unconfirmed — not actioned" with the reason. Never fix a finding you could not validate.
   - LOW findings skip validation (they don't trigger fixes anyway).
   Mirrors Anthropic's per-finding validation pass and dev.to's Gate 5: confirm before acting.

### FIX PHASE (sequential, you the parent)

9. **Read** all reports (lens reviewers + pre-mortem analyst + frontend if applicable). For each lens across all reports, using only the findings that survived FINDING VALIDATION (step 8b):
   - **Clean** (no *validated* CRITICAL/MEDIUM — a lens whose only findings were dropped as unconfirmed counts as clean) → move lens to `covered`
   - **Validated CRITICAL/MEDIUM** → add findings to list
   - **LOW issues** → report them but do NOT block progress
10. **If findings exist**:
    - Apply all fixes holistically (you see the full picture across all reports)
    - Run tests if code was changed
    - Move each fixed lens to `needs_recheck`
    - Add to `resolved_issues` with description of what was found and how it was fixed
11. `wave++`

### SUBSEQUENT WAVES — Re-check + Fresh Review

12. **Check stop**: If `needs_recheck` is empty → **ALL COVERED** → go to step 16.
13. **Check cap**: If the user's project or global CLAUDE.md specifies a wave cap and `wave >= cap`, go to step 17. Otherwise no cap — continue.
14. **Build re-check wave**:
    - Group `needs_recheck` lenses into pairs (or singles if odd number)
    - Each pair gets a NEW persona (different from wave 1) and NEW wild card
    - Include re-check context in spawn prompt. Instruct reviewers to verify fixes AND conduct a full fresh review of their lenses — not just confirm prior findings.
15. **Spawn re-check reviewers in parallel** (1-4 agents depending on how many lenses need re-check). Wait for results. → Go to FIX PHASE (step 9).

### REPORTING

Every report ends with one crisp **Verdict** a human or an autonomous agent (/bhag, /goal-maker) can branch on, plus a one-sentence next step:
- **Ready to Merge** — all selected lenses clean, zero confirmed CRITICAL/MEDIUM open. Next step: commit / open the PR.
- **Needs Attention** — clean of CRITICAL/MEDIUM, but advisory LOW or unconfirmed items remain. Next step: glance at them; merge if cheap-or-irrelevant, otherwise fix first.
- **Needs Work** — wave cap reached with confirmed CRITICAL/MEDIUM still open. Next step: re-run /dcr or fix the listed issues manually before merging.

16. **Report clean pass**:
    ```
    ## DCR Clean Pass ✓

    **Waves run:** [N]
    **Lenses reviewed ([M] of 11):**
      ✓ Guardrails — Wave 1 ([PERSONA])
      ✓ Security — Wave 1 ([PERSONA])
      ✓ Logic & Edge Cases — Wave 1 ([PERSONA]), rechecked Wave 2 (1 issue fixed)
      ✓ Testing — Wave 1 ([PERSONA])
      ⊘ Access Control — skipped (not relevant)
      ⊘ UX & Flow — skipped (not relevant)
      ⊘ Performance — skipped (not relevant)
      ⊘ Maintainability — skipped (not relevant)
      ⊘ Observability & Debuggability — skipped (not relevant)
      ⊘ Data Integrity & Schema Safety — skipped (not relevant)
    **Frontend design:** ✓ Reviewed (N findings) / ⊘ Skipped
    **Pre-mortem analysis:** ✓ [N] scenarios analyzed ([N] findings)
    **Diagnostics:** ✓ lint/type/tests green ([N] tests) / ⊘ no toolchain detected — skipped / n/a (not POST-IMPLEMENTATION)
    **Issues found and fixed:** [count] ([which lenses/pre-mortem])
    **Unconfirmed findings (not actioned):** [list with reason, or "none"]
    **Context sources:** [list of discovered files]
    **Verdict:** Ready to Merge — all selected lenses clean, no confirmed CRITICAL/MEDIUM. (If advisory LOW/unconfirmed items remain, report **Needs Attention** instead and list them.)
    **Next step:** [one sentence — e.g. "Commit and open the PR." or "N LOW items remain; merge if cheap-or-irrelevant, else address first."]

    A clean DCR pass subsumes /dc — no separate /dc needed before committing.
    ```

17. **Report cap reached** (user-configured wave cap hit):
    ```
    ## DCR Cap Reached ([N] waves)

    **Covered:** [list of covered lenses]
    **Still failing:** [list of lenses still in needs_recheck with latest issues]
    **Summary:** [what was fixed vs what remains]
    **Verdict:** Needs Work — wave cap reached with confirmed CRITICAL/MEDIUM still open.
    **Next step:** Re-run /dcr to continue, or fix the listed issues manually before merging.
    ```

## HARD RULES

- Do NOT stop the wave loop early. Do NOT skip re-verification of failed lenses.
- Do NOT ask "should I continue?" — the answer is always yes until all covered or user-configured cap.
- LOW issues: Report them but do NOT block progress. Only CRITICAL/MEDIUM trigger re-checks.
- Reviewers are READ-ONLY. Only you (the parent dispatcher) edit files.
- Spawn all reviewers in a wave in ONE message (parallel Task calls).
- Each reviewer in the same wave MUST have a different persona AND different wild card.
- A clean DCR pass (all selected lenses covered) subsumes /dc — no separate /dc needed before committing.

> **Tip:** Run `/jacked-setup dcr` to pre-configure lens selection, context paths, and domain-specific wild cards for this repo.
