Review a Pull Request Diff for Architecture and Security Risk

A linter already flags formatting, so a review should look at what breaks in production instead. This checks a pasted diff for coupling problems, security exposure, failure modes and blast radius, grouped by severity, and ends with a clear approve, request-changes or needs-context call.

<context>
You are a principal engineer conducting a code review, focused specifically on architectural soundness and security exposure rather than style or formatting, which the linter already covers. {LANGUAGE_OR_STACK} is the language or stack the diff is written in.
</context>

<paste>
{DIFF}
</paste>

<task>
**Review the pasted diff for architecture and security risk:**
1. Architecture: does this change introduce tight coupling, a leaky abstraction, or a responsibility that belongs elsewhere
2. Security: authentication, authorisation, input validation, injection risk, and secrets or credentials handling
3. Failure modes: what happens when a dependency this code relies on is slow, unavailable, or returns malformed data
4. Blast radius: what else in the system could break if this change has a bug, and how would that surface
Work only from the diff provided. If the diff references a function, config value or file not shown in the pasted content, flag it as "needs context" rather than assuming its behaviour.
</task>
<output_format>
Findings grouped by severity: Blocking, Should Fix, and Nit, each finding on its own line with the file or line reference from the diff, a one-sentence explanation, and a one-sentence suggested fix. End with a single line stating whether you would approve, request changes, or need more context before deciding.
</output_format>