Adversarial Review
Assume the change is wrong until a concrete input proves it right. Hunt correctness bugs the change introduced — not style, not security. One finding you can trigger beats ten you cannot.
Stance
- Default to distrust. The diff is guilty until a named input clears it.
- No credit for good intent, partial fixes, or "probably fine."
- Happy-path-only is a defect. If code only works on the example input, that is the finding.
- A specific attack angle ("what input makes this throw?") finds bugs. "Review this code" produces polite nothing.
Scope
Review the change, not the codebase.
- Read the supplied frozen review target. If none was supplied, use
git diff. Every finding ties to a changed line.
- Trace the blast radius: for each changed signature, return shape, nullability, or unit, read its callers. A rename or a newly-nullable return breaks stale callers the diff never shows — the regression pure-diff review structurally misses.
- Hand off, do not duplicate. Style →
simplify. Comment intent → code-comments. Type design → parse-dont-validate. Security → security-review. Framework idioms → typescript / no-use-effect / macos-swift-desktop.
This is read-only. Propose fixes; do not apply them, and do not touch code outside the change.
What to hunt
| Bug class |
The tell |
| Null / optional |
A value from an API, map lookup, regex match, or DB row is dereferenced without a guard |
| Boundary / off-by-one |
Index math, slice bounds, < vs <=, empty or single-element input |
| Swallowed error |
Empty catch, catch-log-continue, ignored error/Result return, un-awaited rejection |
| Happy-path gap |
Works on the demo input; empty / zero / negative / huge / missing-field / dependency-down untested |
| Race / ordering |
Shared mutable state, check-then-act, an await between a read and its write |
| State mutation / aliasing |
Mutates a passed-in object, array, or default arg the caller still holds |
| Async / await |
A promise used as its value, a forgotten await, async inside forEach, sequential-vs-parallel slip |
| Type coercion |
== vs ===, truthy 0 / "" / [], implicit string↔number, NaN |
| Result-type loss |
A generic closure or callback silently produces Void/unit, an optional, or a wider type than the caller expects |
| Type-erasure boundary |
A value flows through Any, unknown, catch-all overloads, dynamic JSON, IPC, persistence, or plugin APIs before its shape is checked |
| Resource leak |
Acquire (file, socket, lock, listener, subscription) with no release on every path — especially the error path |
| Inverted logic |
Flipped boolean, wrong operator, bad default, De Morgan slip — plausible, but takes the wrong branch |
| Contract mismatch |
Signature / units / nullability / return shape changed but not all callers; or a call with wrong or hallucinated args |
| Partial change |
One branch updated but not its twin; a flag without the gated code; a migration without its reader; leftover TODO |
Weight the hunt: fresh, often agent-written code skews to happy-path gaps, missing null and edge guards, swallowed errors, mismatched or hallucinated APIs, and half-finished refactors. Look there first.
Trace result flow before type erasure
At every generic closure, callback, actor hop, transaction, lock helper, retry wrapper, or task body whose result is consumed:
- State the concrete result type the caller expects.
- Verify every value-producing path actually returns that type. In Swift, when a generic closure result is inferred from its body without a concrete non-
Void context, a multi-statement ordinary closure with no explicit return can infer Void even when its final expression produces a value. A concrete expected result usually turns the omission into a compiler error instead.
- Follow the result through overload resolution and type erasure.
Any, catch-all overloads, and dynamic serializers can turn a compile-time mistake into a runtime failure.
- If the API has side effects, verify the side effect and returned success/error response separately. "The mutation happened" does not prove the protocol response succeeded.
Do not apply ordinary closure-return rules to result builders or intentionally side-effect-only closures. Prefer a concrete expected type at serialization, IPC, persistence, and plugin boundaries so accidental widening fails compilation.
Technique
For each changed function:
- State its contract in one line before reading the body — inputs, output, side effects. Then check the body actually delivers it.
- Assume every variable can be null and every external call can fail. Find the first line that does not survive that assumption.
- Construct one concrete failing input and trace it line by line to the suspect spot. Verify it actually reaches that line — not a plausible neighbor.
- Ask "if I deleted this change, what breaks?" — tests whether it is necessary and what it regresses.
- For every added regression test, ask whether restoring the defect makes that test fail. A helper-level test that bypasses the changed production boundary is not regression coverage.
Report only what you can trigger
The gate that keeps findings high-signal:
- Name the input or path that triggers the bug. Cannot name it → do not report it.
- Do not speculate about breakage you cannot trace to a specific code path.
- Read the surrounding context first — callers, guards, sanitizers. A line that looks unsafe alone is often safe in context.
- Tag each finding with severity and a confidence: high / medium / low.
- Exception: high-impact bugs (data loss, corruption, crash on common input) — report even at lower confidence, and state what is uncertain.
- Prefer one strong finding over five weak ones. Do not pad.
Self-verification
Before surfacing anything, attack your own findings. For each, try to prove it false: re-read the trigger path, confirm the guard you assumed was missing really is missing, confirm the input really reaches the line. Drop anything you cannot defend.
This pass is what separates real findings from plausible noise. Do not skip it.
Output
For each surviving finding:
- Location — file and line in the diff
- The bug — one sentence
- The trigger — the concrete input or sequence that makes it fail
- Severity + confidence
- Suggested fix — propose, do not apply
If the change holds up under attack, say so plainly. Finding nothing is a valid, honest result — do not invent bugs to look thorough.
1---2name: adversarial-review3description: Adversarially hunt for correctness bugs and regressions in a change set. Use when reviewing a diff before finalizing, during a cleanup pass, or when asked to find bugs, pressure-test, or stress-test recently modified code. Triggers on "find bugs", "what could break", "review for correctness", "did I break anything", "hunt regressions", "adversarial review", or "pressure-test this change".4---56# Adversarial Review78Assume the change is wrong until a concrete input proves it right. Hunt correctness bugs the change introduced — not style, not security. One finding you can trigger beats ten you cannot.910## Stance1112- Default to distrust. The diff is guilty until a named input clears it.13- No credit for good intent, partial fixes, or "probably fine."14- Happy-path-only is a defect. If code only works on the example input, that is the finding.15- A specific attack angle ("what input makes this throw?") finds bugs. "Review this code" produces polite nothing.1617## Scope1819Review the change, not the codebase.2021- Read the supplied frozen review target. If none was supplied, use `git diff`. Every finding ties to a changed line.22- Trace the blast radius: for each changed signature, return shape, nullability, or unit, read its callers. A rename or a newly-nullable return breaks stale callers the diff never shows — the regression pure-diff review structurally misses.23- Hand off, do not duplicate. Style → `simplify`. Comment intent → `code-comments`. Type design → `parse-dont-validate`. Security → `security-review`. Framework idioms → `typescript` / `no-use-effect` / `macos-swift-desktop`.2425This is read-only. Propose fixes; do not apply them, and do not touch code outside the change.2627## What to hunt2829| Bug class | The tell |30|---|---|31| Null / optional | A value from an API, map lookup, regex match, or DB row is dereferenced without a guard |32| Boundary / off-by-one | Index math, slice bounds, `<` vs `<=`, empty or single-element input |33| Swallowed error | Empty catch, catch-log-continue, ignored error/`Result` return, un-awaited rejection |34| Happy-path gap | Works on the demo input; empty / zero / negative / huge / missing-field / dependency-down untested |35| Race / ordering | Shared mutable state, check-then-act, an `await` between a read and its write |36| State mutation / aliasing | Mutates a passed-in object, array, or default arg the caller still holds |37| Async / await | A promise used as its value, a forgotten `await`, `async` inside `forEach`, sequential-vs-parallel slip |38| Type coercion | `==` vs `===`, truthy `0` / `""` / `[]`, implicit string↔number, `NaN` |39| Result-type loss | A generic closure or callback silently produces `Void`/unit, an optional, or a wider type than the caller expects |40| Type-erasure boundary | A value flows through `Any`, `unknown`, catch-all overloads, dynamic JSON, IPC, persistence, or plugin APIs before its shape is checked |41| Resource leak | Acquire (file, socket, lock, listener, subscription) with no release on every path — especially the error path |42| Inverted logic | Flipped boolean, wrong operator, bad default, De Morgan slip — plausible, but takes the wrong branch |43| Contract mismatch | Signature / units / nullability / return shape changed but not all callers; or a call with wrong or hallucinated args |44| Partial change | One branch updated but not its twin; a flag without the gated code; a migration without its reader; leftover TODO |4546Weight the hunt: fresh, often agent-written code skews to happy-path gaps, missing null and edge guards, swallowed errors, mismatched or hallucinated APIs, and half-finished refactors. Look there first.4748## Trace result flow before type erasure4950At every generic closure, callback, actor hop, transaction, lock helper, retry wrapper, or task body whose result is consumed:51521. State the concrete result type the caller expects.532. Verify every value-producing path actually returns that type. In Swift, when a generic closure result is inferred from its body without a concrete non-`Void` context, a multi-statement ordinary closure with no explicit `return` can infer `Void` even when its final expression produces a value. A concrete expected result usually turns the omission into a compiler error instead.543. Follow the result through overload resolution and type erasure. `Any`, catch-all overloads, and dynamic serializers can turn a compile-time mistake into a runtime failure.554. If the API has side effects, verify the side effect and returned success/error response separately. "The mutation happened" does not prove the protocol response succeeded.5657Do not apply ordinary closure-return rules to result builders or intentionally side-effect-only closures. Prefer a concrete expected type at serialization, IPC, persistence, and plugin boundaries so accidental widening fails compilation.5859## Technique6061For each changed function:62631. State its contract in one line before reading the body — inputs, output, side effects. Then check the body actually delivers it.642. Assume every variable can be null and every external call can fail. Find the first line that does not survive that assumption.653. Construct one concrete failing input and trace it line by line to the suspect spot. Verify it actually reaches that line — not a plausible neighbor.664. Ask "if I deleted this change, what breaks?" — tests whether it is necessary and what it regresses.675. For every added regression test, ask whether restoring the defect makes that test fail. A helper-level test that bypasses the changed production boundary is not regression coverage.6869## Report only what you can trigger7071The gate that keeps findings high-signal:7273- Name the input or path that triggers the bug. Cannot name it → do not report it.74- Do not speculate about breakage you cannot trace to a specific code path.75- Read the surrounding context first — callers, guards, sanitizers. A line that looks unsafe alone is often safe in context.76- Tag each finding with severity and a confidence: high / medium / low.77- Exception: high-impact bugs (data loss, corruption, crash on common input) — report even at lower confidence, and state what is uncertain.78- Prefer one strong finding over five weak ones. Do not pad.7980## Self-verification8182Before surfacing anything, attack your own findings. For each, try to prove it false: re-read the trigger path, confirm the guard you assumed was missing really is missing, confirm the input really reaches the line. Drop anything you cannot defend.8384This pass is what separates real findings from plausible noise. Do not skip it.8586## Output8788For each surviving finding:8990- Location — file and line in the diff91- The bug — one sentence92- The trigger — the concrete input or sequence that makes it fail93- Severity + confidence94- Suggested fix — propose, do not apply9596If the change holds up under attack, say so plainly. Finding nothing is a valid, honest result — do not invent bugs to look thorough.
caidanw