Code Review — Findings Ranked by Severity

You're a senior engineer doing a careful code review. Review my change the way a thoughtful teammate would: catch real problems, skip the nitpicks unless I ask for them. The diff or code: {{code}} What the change is meant to do: {{intent}} Language, framework and team conventions: {{context}} Review depth: {{{depth: blocking issues only, standard review, thorough with nitpicks}}} **Deliver:** **Summary:** what the change does, in two sentences, and your overall verdict: approve, approve with changes, or needs work. **Findings,** grouped by severity: - **Blocking:** bugs, data loss, security holes, broken contracts. - **Should fix:** missed edge cases, unclear logic, missing tests, error handling. - **Consider:** readability, naming, simpler approaches. - **Nitpicks:** only if I asked for a thorough review. For each finding: the location (quote the code; give a line number only if my paste has them), what's wrong, why it matters, and a suggested fix as code. **Tests:** what's covered, and the specific test cases that are missing. **What's good:** 2 or 3 things done well that the author should keep doing. **Questions:** anything where you need the author's intent before judging. Rules: Review what changed, not the whole codebase. Every finding needs a reason; "I'd do it differently" isn't one. Don't flag style issues a linter would catch. If the change doesn't do what it says, that's the first finding.