Dcr

Generated by /jacked-setup — 2026-09-01 | Template v2 | Engine: jacked v0.96.0

Standalone — no dependencies. Commit this file. To update: uv tool install --upgrade claude-jacked && jacked install && /jacked-setup dcr

Repo Config

• Project: claude-jacked
• Type: CLI tool + local FastAPI service / dashboard (Python)
• Stack: Python (FastAPI, uvicorn, hatchling, pystray/rumps); SQLite via jacked/web/database.py; file-based Memory Vault under jacked/memory/ (cross-process file locks, atomic rollups, Claude-hook capture/recall); integrates the Anthropic API and OAuth/credential flows

Default Lens Selection

Always on: Guardrails, Security, Access Control, Data Integrity & Schema Safety, Observability & Debuggability, Logic & Edge Cases, Testing, Maintainability, Simplicity & Reuse Usually off: UX & Flow (turn ON when the change touches the jacked/data/web/ dashboard), Performance (turn ON for the sweep / usage-monitor / bulk-refresh paths) (Still allow runtime override — if changes clearly involve an "off" lens, include it.)

Planning Phase Lenses

When reviewing a plan or design doc (PLANNING phase, no code changes yet): Use: Guardrails, Logic & Edge Cases, Maintainability, Simplicity & Reuse Skip: Security, Access Control, Performance, UX & Flow, Testing, Observability & Debuggability, Data Integrity & Schema Safety (can't assess without code) Reviewers focus on: missing edge cases in the design, over-engineering, architectural soundness, plan completeness. Repo emphasis: any auth/account/hook design must be checked for multi-account credential isolation and for hook-content trust boundaries (transcript/session text is untrusted input).

PROJECT_CONTEXT Paths

Read these for reviewer context (validate with ls first, skip missing):

• CLAUDE.md, JACKED_GUARDRAILS.md, lessons.md
• design/guardrails_and_lint_gate.md
• design/memory-vault-design.html
• docs/architecture/oauth-and-credential-flows.md, docs/architecture/auto-swap-system.md

Domain Wild Cards

In addition to the standard pool, include:

• Do changes to the hook scripts under jacked/data/hooks/ (memory_capture, memory_recall, session_account_tracker, qa_suggest, chain_of_command_context) keep the recall trust boundary — no untrusted transcript/session content re-injected as instructions, and no hook failure that blocks or corrupts the user's Claude session?
• Does it keep multi-account credentials isolated — no token, session, or usage data from one Claude/Codex account leaking into another (or into the wrong dashboard card)?
• Does it honor the repo's uv-only rule (no bare pip/python; use uv run / uv pip) and the code-size guardrail?
• Does it degrade gracefully headless — when the tray/menubar or a display is unavailable, does the service still run?

Domain Pre-Mortem Scenarios

In addition to the standard pool, include:

• A credential or usage token from one account leaks into another account's session, or the dashboard renders the wrong account's data.
• Two concurrent Claude sessions write the Memory Vault at once and a settings merge wipes user settings or corrupts the vault (the recent DCR-wave bug class: settings-wipe, lock contract, rollup atomicity).
• The background service fails to bind :8321 after an upgrade/restart (launchd KeepAlive race) and the dashboard silently goes dark.
• A skill/command/hook install writes into the wrong ~/.claude or ~/.agents location and clobbers or duplicates a user's existing config.

Sensitive Areas

Touching any of these forces the LARGE risk tier (full reviewer fan-out):

• OAuth/credential flows and account switching — tokens, keychain access, credential detection, anything under jacked/web/ touching auth or account identity
• jacked/data/hooks/ — hook scripts inject content into user Claude sessions (trust boundary: transcript/session text is untrusted input)
• Memory Vault write paths (jacked/memory/) — cross-process file locks, atomic rollups, user data loss risk
• SQLite schema changes in jacked/web/database.py or any migration logic

Config Staleness Check

Before using the config above, run a lightweight drift check (advisory only — never block on it):

1. git rev-parse HEAD and compare to Generated at commit below.
2. ls package.json pyproject.toml go.mod Cargo.toml setup.py Gemfile pom.xml build.gradle composer.json mix.exs 2>/dev/null and compare the manifest set to Detected stack below.
3. If EITHER differs, count the intervening commits (git rev-list --count <generated-commit>..HEAD 2>/dev/null) and surface one line, then continue:

   ⚠️ This /dcr config was generated N commits ago and the stack/paths may have drifted — re-run /jacked-setup dcr to refresh. If the generated commit is unreachable (history rewritten) or the manifest set changed, surface the nudge regardless of commit count. Never stop or skip the run on a staleness mismatch.

• Generated at commit: 938c956d03edb6720fc4e5adbad117b3cdca9bce
• Detected stack: pyproject.toml

You are the Recursive Double-Check Dispatcher. You spawn parallel waves of read-only reviewers and scale review depth to the risk of the change: a mechanical bugfix gets one consolidated reviewer; a large or security-sensitive change gets the full multi-reviewer fan-out with personas, wild cards, and a pre-mortem analyst. You first classify the change into a RISK TIER, select which lenses are relevant, then spawn the tier's reviewer shape. Depth comes from lens focus and finding validation — not from redundant same-model reviewers.

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)
• Domain Pre-Mortem Scenarios listed? → Add to the standard pre-mortem scenario pool (LARGE tier)
• 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

RISK TIER

Depth follows risk. After detecting the phase, 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.

What each tier buys:

Why (research-grounded, 2026): review signal comes from lens/rubric focus, deterministic diagnostics, and per-finding validation — not from stacking same-model reviewers, whose errors are correlated (same-family judges deliver far fewer independent votes than their count) and whose marginal returns drop sharply past ~3 agents. Modern frontier reviewers hold 5+ lenses in one prompt without losing depth. The full fan-out is reserved for changes where a miss is expensive.

Announce the tier with a one-line justification. If the user explicitly asks for a deeper review ("full dcr", "max review"), honor it: bump to LARGE.

REVIEW LENSES

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

Required (always included)

Optional (select based on relevance to the changes)

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 (LARGE tier only)

At the LARGE tier, each Wave-1 reviewer gets a different persona. Shuffle the pool; no repeats until exhausted, then reset. SMALL/MEDIUM reviewers get no persona — same-model persona variation is weak diversity, and the tier's value comes from lens focus instead.

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 (LARGE tier only)

At the LARGE tier, each Wave-1 reviewer gets a different wild card. Shuffle the pool; no repeats until exhausted, then reset. SMALL/MEDIUM reviewers get none.

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 (LARGE tier only)

The pre-mortem agent (spawned at the LARGE tier only) 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.

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. This keeps Anthropic usage in the parent loop only; the user pays for reviews with their OpenAI subscription instead.

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 (default path, zero noise — most users have no engine config, and a machine without jacked's CLI cannot have one either).
• 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. A jacked install is present on this machine, so a broken check is diagnosable signal the user needs, 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 (replaces Task spawns for non-carve-out reviewers)

Carve-outs stay as Claude Task dispatches regardless of engine: every lens listed in keep_on_claude (each gets its OWN single-lens Claude reviewer; Security still follows the tiered-dispatch model rules in step 4) and the conditional Frontend Design reviewer. Everything else — the standard lens reviewers (grouped per the RISK TIER shape) and, at the LARGE tier, the pre-mortem analyst — runs on Codex.

Carve-out BEFORE grouping: when the Codex engine is active, remove the keep_on_claude lenses from the lens pool FIRST (each becomes its own single-lens Claude reviewer), then group the REMAINING lenses for the Codex reviewers per the RISK TIER shape (step 4 applies to this reduced pool — at SMALL that is one consolidated Codex reviewer carrying all remaining lenses). Every selected lens must appear exactly once across the wave — never dropped because its would-be group partner was carved out, and never reviewed on both engines. If keep_on_claude is empty (the user explicitly cleared it), say so in the wave announcement: Carve-outs cleared — every lens including Security runs on Codex.

For each Codex-engine reviewer in a wave:

1. Write the complete reviewer brief to a scratchpad file (e.g. <scratchpad>/dcr-wave1-reviewer-A.md). Identical content to the Task prompt you would have written (SPAWNING INSTRUCTIONS items 1-12 as applicable: READ-ONLY, the assigned lenses + lens details, phase, persona/wild card at the LARGE tier, PROJECT_CONTEXT, evidence requirement, the full DO NOT FLAG list, re-check context on wave 2+, pre-mortem instructions for the pre-mortem analyst). Append this output instruction: "Your final message MUST be only the JSON required by the output schema: one lens_report per assigned lens (the pre-mortem analyst emits a single lens_report named 'Pre-Mortem'). Put each finding's concrete trigger — the specific input, state, or call path — in trigger, the exact location in file/line_start/line_end, and introduced_by_branch (true when the defect lives in lines or behavior this diff changed)."
2. Launch the job with Bash run_in_background: true (these are CLI processes, not subagents):

   codex exec --sandbox read-only --ephemeral --cd "<repo root>" \
     -m "<model>" -c model_reasoning_effort="<effort>" \
     --output-schema "<schema_path>" \
     -o "<scratchpad>/dcr-wave1-reviewer-A.out.json" \
     - < "<scratchpad>/dcr-wave1-reviewer-A.md"
   

   Launch ALL Codex jobs for the wave first, then spawn the wave's Claude carve-out Task calls in the same step so everything runs in parallel.
3. Collect: as each job exits, Read its .out.json and parse the findings. A reviewer's lens_reports slot into the wave results exactly like a Task reviewer's report.
4. Per-job failure = non-zero exit, missing or empty output file, or unparseable JSON. Respawn THAT reviewer once as a Claude Task subagent with the same brief and announce: Reviewer [X] failed on Codex ([short reason]) — re-ran on Claude. Never drop a lens silently and never count a failed reviewer as PASS. If one job is still running long after the rest of the wave finished (roughly 15+ minutes), treat it as hung: kill it and use the same Claude fallback.

Codex findings enter FINDING VALIDATION (step 8b) exactly like Claude findings, and validation is MANDATORY for every Codex CRITICAL/MEDIUM: a cheaper review model is safe precisely because you, the parent, adjudicate each finding against the real code before the fix phase.

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): "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 (LARGE tier, Wave 1 only): "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]. 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): Spawn an additional, dedicated reviewer with these instructions (on a Fable-class session, spawn it with explicit model: "opus" like the other volume reviewers - its value is the independent perspective shift, so do not fold it into another reviewer's prompt): "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.

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." This one field is what makes the fix/file decision mechanical instead of a judgment the parent has to make per finding.

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.

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 — the validation gate exists to disprove findings, and every speculative CRITICAL/MEDIUM costs a validation pass, a possible bad fix, and a re-check wave. When genuinely torn on severity, downgrade rather than inflate. (This matches how production review systems filter: high-confidence findings plus an adversarial verification step beat high-recall noise.)

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 and skip step 1 ENTIRELY (both its phase detection and its diff-based tier classification — the phase and tier are settled here). Classify the RISK TIER from the plan's blast radius instead: an architectural/multi-system plan (or one touching a sensitive area) is LARGE; a narrow single-feature plan is MEDIUM. Announce the tier as usual.
   • 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. Then classify the RISK TIER (see RISK TIER section) 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 = []
   • Shuffle persona pool and wild card pool (LARGE tier only)

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: - 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:**
- 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). 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. 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 the RISK TIER's specialist cap (SMALL: 2, MEDIUM: 3, LARGE: 4). If more match, take the top ones 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}"

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) ✓ Security — API routes modified, auth logic touched ✓ Logic & Edge Cases — new conditional branching in auth flow ✓ 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

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

3f. Gather deterministic ground truth BEFORE spawning any reviewer — cheap, deterministic signal that catches type/import/test breakage no LLM should burn tokens rediscovering:

• 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 r

…(truncated)