Multi-Lens QA Fan-Out: Blind Self-Review Across 5 Lenses, Then Triage

QA reviewFreshClaudeverified 2026-06-21sha e779cd80919c

Born in: the post where it earned its place →

A vendor “review my code” prompt runs one blended pass that quietly merges concerns and lets a strong correctness story bury a security or data-loss issue; this forces five blind, non-overlapping passes with an explicit “fresh slate, no already-covered” rule, then quarantines the cross-pass reasoning into a dedupe+severity triage that also respects a deferrals list – which is exactly the structure that surfaces the bug a single pass talks itself out of. This is the BREADTH variant: reach for it over the single adversarial reviewer on a high-stakes or wide diff, or when one reviewer keeps rationalizing.

You are doing a multi-lens review of this change. The goal is BREADTH: each lens must run as if it is the only reviewer, with no memory of the others, so that no single framing can rationalize away what another lens would catch.

HONESTY NOTE: within a single model context these five lenses are SIMULATED perspectives, not genuinely independent reviewers. Do NOT treat agreement across lenses as independent corroboration the way you would two separate models confirming each other - the same blind spot can suppress a finding in all five. For real independence, run the lenses as separate sessions or with different models.

CHANGE UNDER REVIEW:
{{diff_or_paths}}

RUNTIME / STACK (assume this is how it actually runs):
{{stack_and_runtime}}

KNOWN INTENTIONAL DEFERRALS (do not report scope-only gaps as bugs; but STILL flag any deferral that causes data loss, a security hole, or won't-run behavior on the currently shipped path):
{{intentional_deferrals}}

Run these FIVE passes. Treat each as a fresh slate. Do not let a pass say "already covered above" or reuse another pass's conclusion. If a pass finds nothing, it must say so explicitly and name what it specifically checked for.

LENS 1 - CORRECTNESS: logic errors, off-by-one, wrong operator/sign, inverted conditions, wrong default, mishandled edge cases (empty, null, zero, negative, unicode, huge).
LENS 2 - SECURITY: injection, path traversal, secret leakage, missing authz, unsafe deserialization, SSRF, unvalidated input crossing a trust boundary.
LENS 3 - DATA INTEGRITY: silent data loss, truncation, lossy casts, race conditions, partial writes, non-idempotent retries, ordering assumptions, off-by-one on persisted records.
LENS 4 - WILL-IT-ACTUALLY-RUN: does this import/build/start in the runtime above? Missing dep, wrong path, async not awaited, undefined var, version mismatch, env var assumed present. Be concrete about the exact line that fails.
LENS 5 - CONTRACT / BLAST RADIUS: callers and downstream consumers that this change breaks, API/shape changes, removed-but-still-referenced symbols, behavior changes that pass locally but break someone else.

Then produce a TRIAGE section, and ONLY here are you allowed to look across passes:
1. DEDUPE: collapse findings that are the same root cause flagged by multiple lenses. Keep the clearest statement; note which lenses raised it.
2. SEPARATE: split real bugs from intentional deferrals (cross-check the deferrals list) and from style/taste nits. Deferrals and nits go in their own short lists, not the bug list.
3. RANK the real bugs by severity: CRITICAL (data loss / security / won't run) > HIGH (wrong result on common path) > MEDIUM (edge case) > LOW. For each: one-line description, exact file:line, and the smallest fix.

Rules: cite file:line for every finding or drop it. No speculative findings dressed as facts - if you are guessing, label it "UNCONFIRMED" and say what you'd run to confirm. Do not edit any files; this is review only. End with one sentence: the single finding I should fix first, and why.

Fill in: diff_or_paths stack_and_runtime intentional_deferrals

Shared as is, for reference. Read it and decide what it will do before you run it; using it is your responsibility, under the terms.