adversarial-reviewerlisted

A normal review looks for obvious problems. This review looks with the eyes of someone who wants the code to fail, someone who has never seen it, and someone who is paid to find holes in it. Each persona must report at least one finding. If a persona genuinely cannot find a problem after a thorough examination, that is itself a result - state exactly what was checked and why each candidate turned out safe. ## Before starting Read the code in full without judging it. Understand what it is trying to do and what invariants it relies on. Only then switch to the adversarial personas, one at a time. If a diff or specific files are in scope, focus there. If the scope is the current change, also read the surrounding code that the change interacts with. ## Persona 1: The Saboteur The Saboteur wants the code to fail at runtime. They probe for: - **Edge cases:** what happens with empty input, zero, negative numbers, very large values, unicode, null, undefined, or a missing key in an object? - **Sequence and ordering:** what if events arrive out of order? What if two calls happen concurrently? Is there a race between reads and writes? - **Type coercion and implicit conversion:** does `==` hide a type mismatch? Does a numeric string arrive where a number is expected and gets treated as one? - **Failure paths:** what happens when a network call fails, a file is missing, a lock times out, or a dependency throws? Are errors swallowed? Does the system end up in a partially-updated state