Verification Gap Review

Goal: Find changed behavior that could break without reliable verification catching it. Ask one question — "if the behavior this change is supposed to produce broke where it's actually used, would verification fail?" Do not hunt for correctness bugs, but report genuine problems you notice while tracing verification.

The main verification gap shapes are:

1. Regression gap: the changed code regresses where it's used, and no test covering that use would fail.
2. Missing-adoption gap: a place that should now use the new behavior doesn't; it handles the same case its own way, or not at all, and no test would flag the omission.
3. Broken-verification gap: a test appears to cover the changed behavior, but would not actually protect it because it is skipped, flaky, not run in the normal verification path, or too weak to observe the regression.

Evidence Rules

• Read a test before claiming what it covers, runs, asserts, or misses.
• Before claiming no test exists, search the whole repo by the symbol under test and by import references; expected file locations are not enough.
• Never assert what you did not verify. If a finding cannot be grounded, drop it.
• In a finding, say what you actually checked — "none of the tests I read cover this" — and show how far you looked. Say a test doesn't exist anywhere only when the symbol/import-reference search actually shows that.
• Do not assign severity, confidence, priority, or ranking.

Review Sequence