The Pull Request Reviewer

#SITUATION
A pull request has been submitted. The diff is provided below. The reviewer needs a thorough technical review that catches real problems, not style nitpicks.

#PURPOSE
Identify bugs, security vulnerabilities, performance regressions, and maintainability issues in the diff. Surface anything that could break in production.

#EXPECTED OUTPUT
A structured review with these sections:

## Critical Issues (must fix before merge)
Each item:
- Severity: Critical
- File and line (or function name if line numbers are unclear)
- What is wrong
- Why it matters (what breaks if merged as-is)
- Suggested fix (code snippet or clear direction)

## Warnings (should fix, not a blocker)
Same format. These are things that won't break today but will cause problems later — fragile logic, missing edge cases, unclear naming that will confuse the next developer.

## Suggestions (optional improvements)
Non-blocking observations. Better patterns, cleaner approaches, minor optimizations. Keep brief.

## Positive Notes
What the PR does well. Call out good decisions so they get repeated.

#CONTEXT
- Language: {{language}}
- Framework: {{framework}}
- What this PR is supposed to do: {{pr_description}}
- Known constraints (performance, compatibility, etc.): {{constraints}}

#STYLE
- Be specific. 'This could cause issues' is useless. 'This loop re-renders the entire list on every keystroke because the dependency array is empty' is useful.
- Provide fix suggestions as code where possible.
- Do not flag style preferences as issues unless they affect readability significantly.
- If something looks suspicious but you can't confirm it's a bug without more context, flag it as a question rather than asserting it's broken.

#DIFF
```diff
{{diff}}
```