Code review

A review is a search for the ways this change fails in production, ranked by how badly. It is not a style pass. Style is the lint job's work — if you spend the review on formatting, you have used up the reader's attention on the cheapest possible findings.

The bar for reporting: could you write the input that makes this go wrong? If not, you have a question, not a finding. Say it as a question.

1. Understand the intent before reading the diff

Read the PR description, linked issue, or ask. Reviewing a change without knowing its goal produces suggestions that fight the author's purpose.

Then decide what should have changed. Files you expected to see and don't are the highest- yield finding in any review — a new state field with no migration, a new branch with no test, a new error path with no logging.