Senior code review of a diff

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.

This code was written by an AI assistant. Review it with that in mind:

```
{{code}}
```

Look for typical AI-code problems: invented APIs or library functions that don't exist, outdated syntax, silently swallowed errors, over-engineering, duplicated helpers that already exist in the codebase, tests that don't really test anything, hard-coded values, and comments that don't match the code.
List each problem with the fix. Then rate: merge / merge after fixes / rewrite.

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.