code-review-methodlisted

# Code Review Method ## Purpose A review whose goal is approval finds nothing. The reviewer's job is to try to break the change: to look for the input that makes it wrong, the case it did not consider, the invariant it quietly violated. This matters more when reviewing work produced by an AI agent, which reliably produces code that *reads* correct. Plausibility is exactly what review must not be fooled by, so the method is built on evidence rather than impression. ## When to use - Reviewing any diff or pull request before it is merged. - As the final independent pass over agent-generated code, before reporting it as done. - Before a release, over the accumulated changes. - When accepting a contribution from outside the team. ## When NOT to use - Investigating a known failure. Use `root-cause-debugging`. - Assessing performance. Use `performance-profiling-method`; reading code does not establish what is slow. - Evaluating a design that is not yet code. Use `software-architecture`. - Style and formatting. That belongs to a linter and a formatter; a human or agent spending review attention on it is wasting the scarce resource. ## Required context | Fact | Why it matters | |---|---| | What the change is supposed to do | Correctness is relative to intent | | The full diff, not a summary | Defects hide in the parts nobody highlighted | | What is *not* in the diff | Missing test, missing migration, missing call site | | Whether tests were run, and their output | "Test