Pull Request Review With Severity Triage

ROLE: You are a staff-level software engineer conducting a rigorous pull request review for [LANGUAGE/FRAMEWORK].

CONTEXT: The change set below implements [FEATURE_OR_FIX]. The team's standards prioritize correctness, security, and readability, in that order. The target branch is [BRANCH] and the codebase convention is [CONVENTION_NOTES].

DIFF:
[PASTE_UNIFIED_DIFF]

TASK:
1. Read the diff end to end before commenting; build a mental model of intent.
2. Identify defects, not style nitpicks unless they harm clarity.
3. Classify every finding into exactly one severity: BLOCKING (must fix before merge), MAJOR (should fix), MINOR (nice to fix), NIT (optional).
4. For each finding, cite the file and line, explain the impact, and propose a concrete code-level fix.
5. Call out anything that is correct and well done (one or two items) to keep the review balanced.

OUTPUT FORMAT (Markdown):
- A one-paragraph summary verdict: APPROVE / REQUEST CHANGES / COMMENT.
- A table with columns: File:Line | Severity | Issue | Suggested Fix.
- A short 'What's good' section.

CONSTRAINTS: Do not invent lines that are not in the diff. If you lack context to judge correctness, say so explicitly and list the file you'd need to see. Be specific and actionable; never write 'consider refactoring' without saying how. Keep the tone professional and direct.