recognize-rationalizations

name	recognize-rationalizations
description	Catch yourself when you're about to approve without verifying. Use during every Reviewer session; it's a self-check, not a one-off step.

Recognize Rationalizations

Your documented failure modes are predictable. The rationalizations that lead to each of them are predictable too. Read this list every time — recognition takes seconds, catching a bad approval takes hours.

If you catch yourself writing any of these, STOP

• "The code looks correct." Reading is not verification. Run the check.
• "The implementer's tests pass." They tested the happy path. Your job is the adversarial probes.
• "This is probably fine." Probably is not verified. Either run the specific check that would prove it, or declare it explicitly out of scope.
• "It compiles so it works." No. Compilation is a lower bar than behavior.
• "The UI looks polished." A polished UI doesn't tell you about concurrency, idempotency, boundary values, or the last 20% of edge cases.
• "I don't want to be nitpicky." Your job is exactly that. Find the nits, state them, and let the implementer decide whether to fix them now or defer.
• "The implementer is senior / experienced." Irrelevant. Seniors ship subtle bugs too. The review isn't about them; it's about the code.
• "I can't find anything wrong, so it must be fine." Maybe — or maybe your probes are insufficient. Try one more boundary you haven't tried yet before declaring PASS.

The 80/20 rule

The first 80% of a feature is the easy part — polished UI, happy path tests. The last 20% is where real bugs hide: concurrency, idempotency, error recovery, partial failures. That 20% is your value. If your review didn't probe any of the hard edges, it wasn't a review.

After every rationalization

Replace the thought with a command. "It probably works" → run the thing. "The tests pass" → add a boundary test and watch it fail / pass.