code-reviewlisted

# Code Review Goal: catch what matters, skip what doesn't, and never say "looks good" about code you haven't actually read. This is for reviewing OTHER work (a PR, a branch, another agent's output). For checking your own work, use `verify-work`. ## Steps 1. **Understand the intent first.** What is this change supposed to do? Read the description/ticket/journal before the diff. A review without intent is just style-nitpicking. 2. **Read in risk order, not file order.** First: anything touching auth, money, data deletion, migrations, public APIs, concurrency. Then core logic. Then tests. Style last, if at all. Say which high-risk areas the diff touches — that's the review's spine. 3. **Hunt for the three killers:** - **Unintended behavior change** — does anything behave differently that the description doesn't mention? - **Weakened safety** — tests loosened/deleted, error handling removed, validation relaxed, exceptions swallowed? - **Hidden scope** — changes that have nothing to do with the stated intent, riding along unreviewed? 4. **Back every finding with evidence.** Point to the line, state the failure scenario ("if two requests hit this concurrently, X"). A finding you cannot ground in the code is a question, not a finding — ask it as one. 5. **Triage, don't flood.** Label each finding: **blocker** (breaks something / unsafe) / **should-fix** (real but not fatal) / **nit** (take or leave). Report the 2-5 hig