giving-code-reviewlisted

# Giving code review **Trigger.** You are reading a change you did not write and are expected to respond: a pull request, a patch, a diff, a colleague asking "does this look right?". > **Reference material** (the correctness pass in detail, severity calibration, > worked comment rewrites, and reviewing agent-authored changes): see > `reference.md` in this directory. ## The rule > **Every comment states its severity. A reviewer who does not distinguish > "this is broken" from "I'd have named it differently" makes both easy to > ignore.** Unlabelled feedback forces the author to guess what blocks the merge, and they guess wrong in both directions — polishing nits while shipping the bug, or dismissing a real defect as taste. ## Read in this order Reading a diff top-to-bottom is how correctness bugs get missed while indentation collects three comments. Work outward instead: 1. **Does it do the right thing?** Read the description and the tests before the implementation. If you cannot tell what the change is *for*, that is your first comment. 2. **Is it correct?** Trace the logic — boundaries, error paths, concurrency, the empty case and the enormous one. 3. **Will it hold up?** Security, performance at real scale, failure modes, backward compatibility. 4. **Is it maintainable?** Naming, structure, duplication, comments that will go stale. 5. **Is it consistent?** House style and formatting. Last, and usually a linter's job rather than a human's. Run out