Dcr

---
name: dcr
description: Use after implementing a feature, fixing a bug, or completing any non-trivial code change. Risk-tiered multi-lens review - the SMALL/MEDIUM/LARGE tier sets reviewer count and agent budget (4/8/16), findings are validated before fixing, and the run stops after two waves by default.
---

First, check if a repo-scoped version exists in the current project:
1. If `.claude/skills/dcr/SKILL.md` exists (Glob) → read and follow it instead of this file.
2. If `.claude/commands/dcr.md` exists (Glob) → read and follow it instead (legacy `/jacked-setup` output).
Otherwise follow the engine below.

<!-- ENGINE -->

## BUDGET FIRST

The RISK TIER sets how wide the review goes and the agent budget caps it. Nothing later in this file widens either.

### RISK TIER

Classify the change under review into ONE tier. Sensitivity beats size: a 20-line auth change is LARGE. When genuinely torn between tiers, take the higher one.

- **SMALL** — mechanical or narrow: roughly under 150 changed lines across fewer than 5 files, no sensitive area touched, no schema/data migration, no new subsystem. Typical: bugfix, config change, copy tweak, contained refactor.
- **MEDIUM** — a normal feature or fix: up to roughly 600 changed lines, OR new user-facing behavior, OR moderate cross-file coupling. No sensitive area touched.
- **LARGE** — any of: a **sensitive area** touched (auth/session handling, credentials/secrets, RBAC/multi-tenancy, payments/billing, schema or data migrations, concurrency/locking, security-relevant input parsing, plus any repo-configured Sensitive Areas), more than ~600 changed lines, a new subsystem, or a PLANNING-phase review of an architectural/multi-system plan. (A narrow single-feature plan reviews as MEDIUM.)

If the **Security** or **Access Control** lens ends up selected, the tier is LARGE by definition — when lens selection (step 3d) picks either AFTER an earlier SMALL/MEDIUM classification, PROMOTE the tier to LARGE at that moment and re-announce it before building Wave 1.

| | SMALL | MEDIUM | LARGE |
|---|---|---|---|
| **Agent budget (whole run)** | at most 4 | at most 8 | at most 16 |
| Reviewers (Wave 1) | 1 consolidated — all selected lenses in one prompt | 2 — lenses split evenly | ceil(lenses/2) — 2 lenses each, full fan-out |
| Personas + wild cards | none | none | yes (references/large-tier.md) |
| Pre-mortem analyst | no | no | yes (references/large-tier.md) |
| Specialist lens cap | 2 | 3 | 4 |
| Re-check waves | fix verification only | fix verification only | fix verification only |

**The agent budget** counts every agent the run spawns, in every wave: reviewers on either engine (Task or Codex job), the Security and Frontend Design reviewers, the pre-mortem analyst, validators, re-check reviewers, and Claude fallbacks. When the next spawn would exceed it, do not spawn: announce the overrun in one line and finish that work inline.

**Two waves by default:** Wave 1, then at most one fix-verification wave. The loop converges when a wave yields no validated branch-introduced CRITICAL/MEDIUM and no critical pre-existing one; file the rest and stop. A third wave runs only at LARGE with a confirmed CRITICAL still open; if it still finds branch-introduced defects, split the PR, never a fourth wave (step 13).

**Incomplete is not clean.** A wave in which any reviewer returned nothing (rate limit, login expiry, crash, user skip, a failed Codex job not yet re-run) is INCOMPLETE: re-run the missing reviewers before counting it clean or reporting a verdict.

**Ultracode is subordinate:** "ultracode", "token cost is not a constraint", and the workflow-authoring quality patterns never override this budget or the wave cap. Only a project or global CLAUDE.md may change the cap (step 13).

Announce the tier with a one-line justification. An explicit "full dcr" / "max review" request bumps to LARGE, inside the LARGE budget. Signal comes from lens focus, diagnostics, and per-finding validation, not reviewer count: same-model reviewers have correlated errors.

**LARGE-tier material:** at the LARGE tier only, Read `references/large-tier.md` (relative to this skill's directory) before building Wave 1; SMALL/MEDIUM never read it. It holds the persona, wild-card, and pre-mortem pools and the pre-mortem analyst prompt. If no copy exists, announce `references/large-tier.md not found — run jacked install` and run the LARGE shape without personas, wild cards, or the pre-mortem analyst.

**Reference path rule (every `references/` file):** read it relative to this skill's directory. A `/jacked-setup` repo copy of this engine or a Codex prompt has no `references/` beside it: read `~/.claude/skills/dcr/references/` (Claude Code) or `~/.agents/skills/dcr/references/` (Codex) instead. If `references/conditional.md` cannot be found, announce `references/conditional.md not found — run jacked install` and continue without that section.

## 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 (LARGE tier, references/large-tier.md)
- **Domain Pre-Mortem Scenarios** listed? → Add to the standard pre-mortem scenario pool (LARGE tier, references/large-tier.md)
- **Sensitive Areas** listed? → Add those paths/domains to the RISK TIER sensitivity list (touching one forces LARGE)

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.

## CONCURRENCY MODEL

**Reviewers are READ-ONLY.** They report findings but NEVER edit files. You, the parent, collect all reports after a wave and apply one coherent, sequential fix phase (no edit collisions, and cross-cutting findings get one fix).

## REVIEW ENGINE (configurable)

/dcr can run its reviewers on two engines. The parent dispatcher (you) ALWAYS stays in this session and keeps lens selection, finding validation, the fix phase, and the verdict — the engine only changes WHO executes the read-only reviewer briefs.

- **claude** (default): reviewers spawn as parallel Task subagents, exactly as described in SPAWNING INSTRUCTIONS and the tiered-dispatch rules.
- **codex**: reviewer briefs execute as parallel OpenAI Codex CLI jobs (the user configures the model, e.g. `gpt-6-astra`; `jacked dcr engine --json` reports the model the installed Codex CLI can actually serve). Review findings come back as schema-validated JSON files. The `keep_on_claude` lenses and the Frontend Design reviewer always stay on Claude.

### ENGINE CHECK (once per /dcr run, before Wave 1)

Skip this entire section when NOT running inside Claude Code (Codex or another runtime: there is no Task tool and you are already the review engine — review inline per the lens instructions).

Run `jacked dcr engine --json` as one fast Bash call, then branch:
- Command not found, or any `"engine"` value other than `"codex"` → use the Claude engine everywhere and do not mention engines at all (the default path, zero noise).
- Command FOUND but it exits non-zero or prints unparseable output → use the Claude engine, but announce one line: `Engine check failed ([short error]) — reviewers run on Claude.` (jacked is installed, so a broken check is signal, not noise).
- `"engine": "codex"` with `"usable": false` → announce one line: `Codex engine configured but not usable ([reason]) — reviewers run on Claude this time.` Then use the Claude engine.
- `"engine": "codex"` with `"usable": true` → use CODEX DISPATCH below for this run and add `Engine: Codex ([model], effort [effort])` to each wave announcement.

Remember `model`, `effort`, `keep_on_claude`, and `schema_path` from the JSON — CODEX DISPATCH uses all four.

### CODEX DISPATCH

When the engine check returns codex usable, Read `references/codex-engine.md` (reference path rule in BUDGET FIRST) and follow it for this run. It holds the carve-out-before-grouping rule, the `codex exec` job shape, collection, and the per-job Claude fallback. If the file cannot be found, announce `references/codex-engine.md not found — reviewers run on Claude.` and use the Claude engine.

## 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 lenses: [LENS LIST]. Do NOT review other areas — depth over breadth." (LARGE tier: 2 lenses per reviewer. MEDIUM: the split half. SMALL: the consolidated reviewer carries every selected lens.)
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** (LARGE tier, Wave 1 only): the persona line from references/large-tier.md.
6. **Wild card** (LARGE tier, Wave 1 only): the wild-card line from references/large-tier.md.
7. **Re-check context** (wave 2+ only): "These lenses found issues in wave [N] that were fixed: [LENS: issue → fix]. Verify each fix is correct and complete — no regressions, no half-fixes — by reviewing the fix diff plus the code it directly touches (the changed functions and their immediate callers). Do NOT re-review the rest of the code from scratch; earlier waves covered it. Report only problems introduced by the fixes or sitting immediately adjacent to them."
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** (LARGE tier, Wave 1 only): the dedicated PRE-MORTEM ANALYST prompt from references/large-tier.md.
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.
13. **Scope and provenance (always)**: "This branch's stated scope is: [SCOPE]. Tag EVERY finding with `introduced_by_branch: true|false` — true when the defect lives in lines this diff added or changed, or in behavior this diff changed; false when the defect was already present before the branch. Say which in one clause (e.g. `introduced_by_branch: false — this branch only reads the helper, the bug predates it`). Pre-existing defects are still worth reporting with full evidence; the tag decides whether this PR fixes them or files them."

## 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**. 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.

Beyond this list, report with confidence discipline: raise a CRITICAL/MEDIUM only when you would stake the review on it — you can cite the exact `file:line`, name the concrete trigger, and you expect validation to CONFIRM it, not complete it. State your confidence on every finding. If you suspect an issue but cannot pin the code path, report it as LOW (advisory), never CRITICAL/MEDIUM. 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). **Plan mode active** → Read `references/conditional.md` § PLAN MODE and follow it: it settles the phase (PLANNING), the tier, the lenses, the review target, and the one editable file. If conditional.md cannot be found: phase = PLANNING; tier from the plan's blast radius (an architectural/multi-system plan or one touching a sensitive area is LARGE, else MEDIUM); lenses = Guardrails + Logic & Edge Cases + Maintainability + Simplicity & Reuse unless a Repo Config sets Planning Phase Lenses; review the plan file named in the system reminder, and edit only that file.

1. **Detect phase** using the signals above. If ambiguous, ask the user. Then **classify the RISK TIER** (see BUDGET FIRST) from the resolved diff: changed-line count, file count, and sensitive areas (grep the diff paths/hunks for auth/credential/RBAC/tenant/billing/migration/lock signals plus any repo-configured Sensitive Areas).
2. **State the scope, then announce**: derive the branch's stated scope in ONE sentence from the strongest source available (the PR title/body, the plan doc, the commit messages, the user's request; last resort, the diff itself) and set `scope = "<sentence>"`. Then: "Starting parallel DCR. Phase: [PHASE]. Tier: [TIER] — [one-line justification]. Scope: [SCOPE]. Selecting relevant lenses and spawning reviewers." The scope line travels into every reviewer prompt (SPAWNING INSTRUCTIONS item 13) and decides which findings this PR must fix (FIX PHASE step 10).
3. **Initialize**:
   - `covered = Set()` — lenses that passed clean
   - `needs_recheck = Set()` — lenses that found issues, fix applied, must verify
   - `wave = 0`
   - `resolved_issues = []`
   - `agents_spawned = 0` — checked against the tier's agent budget before every spawn
   - LARGE tier only: Read references/large-tier.md and shuffle its persona and wild card pools

### 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:

    - **Agent instructions:** `CLAUDE.md`, `.claude/CLAUDE.md`, `**/CLAUDE.md`, `AGENTS.md`, `.cursorrules`, `.cursor/rules/*.mdc`, `.github/copilot-instructions.md`, `.windsurfrules`
    - **Guardrails and conventions:** `*GUARDRAILS*`, `*guardrails*`, `CONTRIBUTING.md`, `STYLE_GUIDE.md`, `CODING_STANDARDS.md`, `.editorconfig`, `biome.json`, `.eslintrc*`, `.prettierrc*`, `ruff.toml`
    - **Design docs and decisions:** `docs/`, `design/`, `doc/`, `architecture/` (both `*.md` and `*.html`; jacked plans are HTML), `adr/`, `adrs/`, `decisions/`, `architecture-decisions/`, `docs/plans/`, `docs/superpowers/plans/`, and root-level `RFC*`, `DESIGN*`, `ARCHITECTURE*` (`.md` or `.html`)

    Read everything found: skim large directories, but fully read root-level convention files and any design docs related to the code under review. Combine them into a `PROJECT_CONTEXT` block for the reviewer prompts.

3b. **Detect frontend changes:**
    - A change is frontend-meaningful when the diff touches how the UI LOOKS or is structured,
      not merely a file with a frontend extension:
      - Any `*.css`, `*.scss`, `*.vue`, `*.svelte`, or UI-template `*.html` file → yes
      - `*.js`, `*.jsx`, `*.ts`, `*.tsx` → yes ONLY if the diff hunks touch markup/JSX/templates,
        class names/styles, DOM structure, or animation/motion code. A pure logic change in a
        `.js` file (data handling, API calls, state math) is NOT a frontend change.
    - If a frontend-meaningful change is 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:**
    - Code type: API routes → Security + Access Control; UI code → UX & Flow; data logic → Logic & Edge Cases; queries → Performance.
    - Phase: Planning → Testing judges testability; Post-implementation → Testing checks actual coverage.
    - Project context: multi-tenant → Access Control; pure CLI tool → probably skip UX & Flow.
    - A UI element added, moved, renamed, or hidden, or any user-visible behavior change → UX & Flow (discoverability emphasis).
    - New code or substantial refactoring → Simplicity & Reuse (pairs with Maintainability).
    - Error handling, async/background work, external calls, multi-step workflows → Observability & Debuggability.
    - Migrations, multi-table writes, cache read/write, serialization, enum/type changes → Data Integrity & Schema Safety.
    - When in doubt, include the lens.

    **Bounds**: Guardrails + at least 3 optional lenses (4 total minimum). Maximum is all 11.
    Reviewer COUNT comes from the RISK TIER, not the lens count: SMALL runs every selected lens
    in one consolidated reviewer; MEDIUM splits them across 2; LARGE pairs them (2 per reviewer,
    up to 6 reviewers). Lens selection decides WHAT gets reviewed; the tier decides HOW WIDE.
    Remember: selecting Security or Access Control makes the tier LARGE.

### SPECIALIST LENS DISCOVERY

3d-ii. **Specialist lenses.** Glob `~/.claude/lenses/*.md` and `.claude/lenses/*.md`. If neither directory exists, skip (lenses are optional). **Either directory exists** → Read `references/conditional.md` § SPECIALIST LENS DISCOVERY and follow it; matched lenses stay inside the RISK TIER's specialist cap (SMALL: 2, MEDIUM: 3, LARGE: 4).

3d-iii. **Engine check.** Run the ENGINE CHECK from the REVIEW ENGINE section (one `jacked dcr engine --json` Bash call; skip when not running inside Claude Code). Its result decides whether this run's non-carve-out reviewers spawn as Task subagents or as Codex CLI jobs. The check runs once and applies to EVERY wave in this run, re-check waves included.

3e. **Announce selected lenses with reasoning:**
    ```
    **Lenses selected ([N] of 11):**
      ✓ Guardrails (always)
      ✓ Logic & Edge Cases — new conditional branching in the parser
      ⊘ UX & Flow — no frontend or user-facing changes
      ... (one line per lens, ✓ or ⊘ with the reason)
    **Specialist lenses:**
      ✓ Accessibility (specialist) — frontend files changed
    ```

### DIAGNOSTIC PRE-GATE (POST-IMPLEMENTATION only — runs BEFORE Wave 1)

3f. Gather deterministic ground truth BEFORE spawning any reviewer, so no reviewer burns tokens rediscovering type/import/test breakage:

- **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 (targeted, seconds). Capture pass/fail and the concrete error output. The FULL suite runs once, on a frozen tree, as the final gate after the last fix wave, not after every micro-fix.
- **Gate**: if anything fails, FIX the mechanical failures yourself NOW (you, the parent) and re-run until green — do not spawn reviewers onto a tree that lint or tests already condemn. A failure you cannot fix mechanically (genuine design question) goes to the user before any wave spawns.
- **Inject** the (now green) results as a `## DETERMINISTIC DIAGNOSTICS — ground truth` block into every reviewer's prompt (alongside PROJECT_CONTEXT).
- **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.

This runs once, before Wave 1 — it does NOT re-run per wave (the FIX PHASE re-runs the relevant tools after applying fixes).

### WAVE 1 — Selected Coverage

4. **Group** the selected lenses per the RISK TIER:
   - **SMALL**: ONE consolidated reviewer carries every selected lens. No persona, no wild card.
   - **MEDIUM**: TWO reviewers, lenses split evenly by affinity (e.g. correctness-ish lenses together, structure-ish lenses together). No personas, no wild cards.
   - **LARGE**: pair the lenses — each reviewer gets exactly 2 (odd count: one reviewer gets a single lens and goes deeper). Number of reviewers = ceil(selected_lenses / 2), range 2-6.
   - **Tiered dispatch (Fable-class session: any session model above Opus):** reviewers are volume work: spawn each with explicit `model: "opus"`. The Fable budget stays in the parent loop, where the judgment happens (tier, lens selection, validation, fixes, verdict). TWO exceptions dispatch on explicit `model: "fable"`: the **Security** lens, which gets its OWN single-lens reviewer (never paired with another lens on a Fable-class session; Fable is materially better at real, exploitable issues in code we own), and the conditional **Frontend Design** reviewer (visual-design judgment). On an Opus-or-below session, use the session's model (never below Opus) and the same tier shape.
5. **Assign** (LARGE tier only) each reviewer a unique persona and unique wild card from references/large-tier.md. SMALL/MEDIUM reviewers get neither.
6. **Announce**:
   ```
   **Wave 1 [TIER] — [N] lenses across [M] reviewer(s)**
   - Reviewer A: [Lens X] + [Lens Y]
   - Reviewer B: [Lens Z] + [Lens W]
   ```
   (SMALL example: `**Wave 1 SMALL — 4 lenses, 1 consolidated reviewer** - Reviewer A: Guardrails + Logic & Edge Cases + Testing + Simplicity & Reuse`. The LARGE format, with personas, wild cards, and the pre-mortem analyst, is in references/large-tier.md.)
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.
   - **Pass the model explicitly on every spawn** per the tiered-dispatch rule in step 4: `model: "opus"` for standard reviewers and the pre-mortem analyst on a Fable-class session; `model: "fable"` for the Security lens reviewer and the Frontend Design reviewer. Never rely on inheritance - an agent definition's frontmatter `model:` pin silently beats parent inheritance.
   - **LARGE tier:** spawn the PRE-MORTEM ANALYST (references/large-tier.md) in this same message.
   - **Codex engine active** (step 3d-iii): non-carve-out reviewers launch as background Codex CLI jobs per CODEX DISPATCH instead of Task calls; the carve-out reviewers (`keep_on_claude` lenses, Frontend Design) still spawn as Task calls in this same step so the whole wave runs in parallel.

#### CONDITIONAL reviewers and prompt blocks

Each condition below triggers ONE read of `references/conditional.md`; skip the read when the condition is false.
- **`frontend_review = true`** (step 3b) → Read § FRONTEND DESIGN REVIEWER. It adds one dedicated Wave-1 reviewer in the SAME message (any tier; explicit `model: "fable"` on a Fable-class session; counts against the agent budget; one-shot, no re-check).
- **UX & Flow lens selected** → Read § UX & FLOW DISCOVERABILITY SUB-CHECKLIST and append it to that reviewer's Lens details (item 3).
- **Security lens selected** → Read § SECURITY LENS DEFENSIVE FRAMING and prepend it verbatim to that reviewer's spawn prompt.

8. **Wait** for all results. If any reviewer returned nothing, the wave is INCOMPLETE: re-run the missing reviewers (inside the budget) before step 8b.

### FINDING VALIDATION (gate before fixing)

8b. **Validate every CRITICAL/MEDIUM finding before it enters the fix phase.** An unvalidated false positive makes you edit working code, which can introduce a regression and spawn another wave. 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. Validate findings YOURSELF in the parent loop by default; adjudication is where the top model earns its price. Only at the LARGE tier, and only when a wave produced many findings, MAY you dispatch ONE READ-ONLY validation subagent per CLUSTER of related findings (`model: "opus"` on a Fable-class session, counted against the agent budget), prompted to strengthen or refute each with evidence; never one validator per raw finding, never N identical refuters. Keep writing and validation separate (don't let the reviewer that raised it grade its own finding).
   - Validation is MANDATORY for every Codex CRITICAL/MEDIUM: a cheaper review model is safe only because you adjudicate each finding against the real code.
   - **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).

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

9. **Read** all reports (lens reviewers + pre-mortem analyst at the LARGE tier + 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**, sort the validated CRITICAL/MEDIUM findings into two buckets by `introduced_by_branch` (verify the tag during validation; a reviewer that got it wrong is corrected, not trusted):
    - **Introduced by this branch** → fixed in this PR, always.
    - **Pre-existing, discovered adjacent to the branch** → fixed in this PR only when it is security-, data-integrity-, or billing-critical, or when the fix is a one-line change. Otherwise FILE it: open an issue (`gh issue create`) whose body is the reviewer's evidence verbatim (file:line, trigger, why, recommendation), link the issue in the PR body and in the final report, and move on. Filing with evidence is not punting; growing a PR past its stated scope is its own review risk. A project or global CLAUDE.md that says otherwise wins over this default.
    - Apply the in-PR fixes holistically (you see the full picture across all reports)
    - Run the targeted tests for what changed (the FULL suite runs once, on a frozen tree, as the final gate before the push; the full-suite gate is per PUSH, not per fix batch)
    - 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 — Fix Verification

Re-check waves VERIFY FIXES; they do not re-review from scratch. Wave 1 already covered the code, and a fresh full review almost always dredges up some new marginal item, which stops the loop from converging.

12. **Check stop**: If `needs_recheck` is empty → **ALL COVERED** → go to step 16.
13. **Check convergence, then the cap**: a review loop CONVERGES; it does not run until nothing new appears (a fresh pass always finds something new by construction). The loop has converged when the last wave yielded no validated branch-introduced CRITICAL/MEDIUM and no critical pre-existing one; everything else it found is filed per step 10, and the run reports clean (step 16) even if `needs_recheck` is not empty for filed items. Default wave cap is **2** (Wave 1 + one fix-verification wave). A third wave is allowed only at the LARGE tier with a confirmed CRITICAL still open; if that third wave STILL finds branch-introduced defects, the fixes are too broad and the answer is to split the PR, not to review again — go to step 17 with that next step. A project or global CLAUDE.md may override the cap in either direction (including "no cap"). If `wave >= cap`, go to step 17. Re-check waves review the fix DELTA only (item 7); a fresh whole-branch completeness pass happens at most once, as the final wave of a LARGE review, never every round. Do NOT ask "should I continue?" between waves: the convergence rule and the cap decide.
14. **Build re-check wave**:
    - Group ALL `needs_recheck` lenses into ONE verification reviewer (two if more than 5 lenses need re-check). Fix verification is narrow — it does not need the Wave-1 fan-out.
    - No personas, no wild cards, any tier.
    - Include the re-check context from SPAWNING INSTRUCTIONS item 7: verify each fix and its immediately adjacent code; do NOT re-review the rest.
    - Exception: if a re-checked fix touched a **sensitive area** (RISK TIER list), the Security lens re-verifies as its own reviewer on `model: "fable"` (Fable-class session).
15. **Spawn re-check reviewer(s) in parallel**. The tiered-dispatch rule from step 4 applies to every wave, not just Wave 1: `model: "opus"` for standard re-check reviewers on a Fable-class session, `model: "fable"` when Security is among the re-checked lenses (own reviewer). The engine decision from step 3d-iii also applies to every wave: with the Codex engine active, non-carve-out re-check reviewers run as Codex jobs per CODEX DISPATCH. 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.

An INCOMPLETE wave never produces a verdict: re-run its missing reviewers first.

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

    **Tier:** [SMALL/MEDIUM/LARGE] — [one-line justification]
    **Waves run:** [N] | **Agents spawned:** [N] of [budget]
    **Lenses reviewed ([M] of 11):**  <!-- the ([PERSONA]) suffix appears at the LARGE tier only -->
      ✓ Guardrails — Wave 1 ([PERSONA])
      ✓ Logic & Edge Cases — Wave 1 ([PERSONA]), rechecked Wave 2 (1 issue fixed)
      ⊘ Access Control — skipped (not relevant)
      ... (one line per lens)
    **Engine:** Codex ([model], effort [effort]; [N] reviewers, [N] Claude fallbacks) / Claude
    **Frontend design:** ✓ Reviewed (N findings) / ⊘ Skipped
    **Pre-mortem analysis:** ✓ [N] scenarios analyzed ([N] findings) / ⊘ skipped (tier below LARGE)
    **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"]
    **Pre-existing findings filed, not fixed here:** [issue links with file:line, 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.
    ```

    **Memory vault (guarded, judgment-based):** on a clean final pass ONLY, if the memory vault is enabled (`jacked memory status --quiet` exits 0; skip silently otherwise), record any notable ARCHITECTURAL decision the review surfaced as a decision note: `jacked memory add --type decision --title "<decision>" --body "<the decision + the reasoning that settled it>"`. This is a rare, high-signal capture: most clean passes surface no such decision and record nothing. Never store a routine fix or a finding. If the vault is off, do nothing.

17. **Report cap reached** (wave cap hit — default 2, LARGE-tier third wave, or the user-configured cap):
    ```
    ## DCR Cap Reached ([N] waves)

    **Tier:** [SMALL/MEDIUM/LARGE] | **Agents spawned:** [N] of [budget]
    **Engine:** Codex ([model], effort [effort]; [N] reviewers, [N] Claude fallbacks) / Claude
    **Covered:** [list of covered lenses]
    **Still failing:** [list of lenses still in needs_recheck with latest issues]
    **Summary:** [what was fixed vs what remains]
    **Pre-existing findings filed, not fixed here:** [issue links, or "none"]
    **Verdict:** Needs Work — wave cap reached with confirmed CRITICAL/MEDIUM still open.
    **Next step:** [If a third wave still found branch-introduced defects: "Split the PR — the fixes outgrew the stated scope." Otherwise: "Fix the listed issues, then re-run /dcr."]
    ```

## HARD RULES

- Depth follows the RISK TIER and stays inside its agent budget: never spawn the LARGE fan-out for a SMALL change, and never skip the Security carve-out (or the LARGE tier) when a sensitive area is touched.
- Do NOT stop the wave loop before it converges, and do NOT skip re-verification of a fixed lens. A third wave that still finds branch-introduced defects means split the PR, never a fourth wave.
- Reviewers are READ-ONLY. Only you (the parent dispatcher) edit files.
- Spawn all reviewers in a wave in ONE message (parallel Task calls; with the Codex engine, all Codex jobs plus carve-out Task calls together).
- The engine never moves judgment: lens selection, finding validation, fixes, and the verdict always run in the parent session regardless of engine.

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