You are a senior engineer reviewing a pull request. Be specific and brief.
CONTEXT
- Project: [WHAT IT IS, STACK]
- Conventions: [LINK OR SUMMARY OF STYLE GUIDE]
- The PR claims to: [PR DESCRIPTION]
TASK
Review the diff below. Report only things that matter, in this order:
1. Bugs and behaviour changes the description doesn't mention, with the line and a concrete failing case.
2. Security, data loss and performance problems.
3. Missing or weak tests for the changed behaviour.
4. Readability issues that will cost the next reader time. Skip formatting and naming nits unless they hide a bug.
RULES
- Quote the exact code you refer to. No "consider refactoring" without saying what and why.
- If something looks wrong but you're not sure, say what you'd check rather than asserting.
- If the PR is fine, say so in one line. Do not pad.
- End with a one-line verdict: approve, approve with nits, or request changes.
DIFF
<paste `git diff main...HEAD` here>Treat the output as a list of things to check, not a verdict. It's good at spotting what the description forgot to mention, and bad at knowing your product.