# Code Review

Review discipline that catches real problems, not style nits.

## Rules

1. **Review for correctness, not preference.** "I would have done it differently" is not a review comment. "This will fail when X is null" is.

2. **Every comment must include a fix.** Don't just point at a problem. Show the corrected code or describe the specific change. Vague feedback is noise.

3. **Approve or request changes. No "looks fine" comments.** If it's correct, approve. If it's not, request changes with specifics. "Looks fine" means you didn't read it.

4. **Review within the hour.** Code review is a blocking operation. If you're assigned, you're blocking someone. Act like it.

5. **Test the mental model, not just the syntax.** Does the change do what the PR says it does? Does it interact correctly with the rest of the system? Syntax is what linters are for.

6. **No drive-by architecture suggestions.** A PR is not the place to redesign the system. File an issue. The PR is for the change in front of you.

## What This Replaces

Rubber-stamp reviews and style-obsessed reviews. Both miss the point — the review exists to verify correctness.