Review AI-generated code

Review this diff as a senior engineer who cares about correctness first, then clarity.

```diff
{{diff}}
```
Context: {{what_the_change_does}}

Output:
1. **Blocking issues** (bugs, security, data loss, race conditions) with line references and a suggested fix.
2. **Should fix** (error handling, edge cases, missing tests).
3. **Nits** (naming, style): max 5.
4. What's good about the change (1-2 lines).
If you're unsure whether something is a bug, say so and explain what would confirm it. Don't invent issues to fill sections.

Review this diff as a senior engineer who cares about correctness first, then clarity. ```diff {{diff}} ``` Context: {{what_the_change_does}} Output: 1. **Blocking issues** (bugs, security, data loss, race conditions) with line references and a suggested fix. 2. **Should fix** (error handling, edge cases, missing tests). 3. **Nits** (naming, style): max 5. 4. What's good about the change (1-2 lines). If you're unsure whether something is a bug, say so and explain what would confirm it. Don't invent issues to fill sections.

Do a focused security review of this code for a {{app_type}} app:

```
{{code}}
```

Check specifically for: injection (SQL, command, template), XSS, auth/authorisation gaps (IDOR), secrets in code, unsafe deserialisation, SSRF, path traversal, missing rate limits, insecure defaults, and dependency risks you can see.
For each finding: severity (high/med/low), exploit scenario in one sentence, and the fix. If nothing is found in a category, say "none found" rather than speculating.

Do a focused security review of this code for a {{app_type}} app: ``` {{code}} ``` Check specifically for: injection (SQL, command, template), XSS, auth/authorisation gaps (IDOR), secrets in code, unsafe deserialisation, SSRF, path traversal, missing rate limits, insecure defaults, and dependency risks you can see. For each finding: severity (high/med/low), exploit scenario in one sentence, and the fix. If nothing is found in a category, say "none found" rather than speculating.

Write tests for this {{language}} code using {{test_framework}}:

```
{{code}}
```

- Cover: happy path, edge cases (empty, null, boundaries, large inputs), and error paths.
- One behaviour per test, descriptive names ("returns X when Y").
- Mock only external I/O; don't mock the code under test.
- After the tests, list any behaviour that looks like a bug: write a failing test for it and flag it rather than "fixing" the expectation.

Write tests for this {{language}} code using {{test_framework}}: ``` {{code}} ``` - Cover: happy path, edge cases (empty, null, boundaries, large inputs), and error paths. - One behaviour per test, descriptive names ("returns X when Y"). - Mock only external I/O; don't mock the code under test. - After the tests, list any behaviour that looks like a bug: write a failing test for it and flag it rather than "fixing" the expectation.