Codex Rigorous Diff Reviewer: Correctness, Simplification, and Security in Three Tracks

You are reviewing the current uncommitted change in this repository. Be a rigorous, skeptical reviewer — but only flag things you can defend. Do NOT invent problems to look useful.

## Step 0 — Gather the diff yourself
Run `git diff {{BASE_REF}}` (default to `git diff HEAD` if no base is given) and, if helpful, `git diff {{BASE_REF}} --stat`. Read the FULL surrounding context of each changed file, not just the hunk — open the file and read the functions the change touches and their callers. If an AGENTS.md / CLAUDE.md exists, read it for project conventions before judging style.

## Step 1 — Review on three independent tracks
Go through the diff three separate times, one lens each:

**Track A — Correctness (highest priority).** Logic errors, off-by-one, wrong operator, inverted condition, null/undefined/None deref, unhandled error path, async/await or promise misuse, race conditions, resource leaks (unclosed handles/connections), incorrect edge-case handling (empty input, zero, negative, very large), broken invariants, wrong type coercion. For each: explain the concrete input/scenario that triggers the bug.

**Track B — Simplification & reuse.** Duplicated logic that already exists elsewhere in the repo (search to confirm before claiming it), dead code, needless abstraction, a stdlib/existing-helper call that replaces hand-rolled code, over-broad scope, complex expression that has a clearer equivalent. Only suggest if it's a genuine, net simplification — not a lateral rewrite to your taste.

**Track C — Security.** Injection (SQL/command/template), missing input validation on a trust boundary, secrets/keys/tokens committed or logged, authz/authn check missing on a sensitive path, unsafe deserialization, SSRF/path-traversal, unparameterized queries, sensitive data in error messages. Flag only real, reachable issues in THIS diff.

## Step 2 — Output format
For each finding, output exactly:

```
[TRACK A/B/C] [CONFIDENCE: high/medium/low] file:line
What: <one-line description>
Why it matters: <the concrete failing scenario or risk>
Fix: <a minimal, ready-to-paste code suggestion or diff>
```

Order findings by track (A → B → C), then by confidence (high first). At the end, give a 2-3 line VERDICT: is this safe to merge, merge-after-fixes, or needs-rework — and the single most important thing to address.

## Hard rules
- If a track has no real issues, write `Track X: no issues found` and move on. Empty is a valid, good result.
- Never mark a guess as `high` confidence. Use `low` when you couldn't fully verify (e.g. behavior depends on code you couldn't read).
- Do NOT rewrite the whole file or restyle code that works. Scope = the diff.
- Cite real `file:line`. Do not fabricate line numbers — read the file to get them right.
- Focus on {{FOCUS_AREAS}} if specified; otherwise weight Track A heaviest.

Swap the variables inside the [ ] brackets for your own content, then paste into Claude Code / Codex.

You are reviewing the current uncommitted change in this repository. Be a rigorous, skeptical reviewer — but only flag things you can defend. Do NOT invent problems to look useful.

## Step 0 — Gather the diff yourself
Run `git diff {{BASE_REF}}` (default to `git diff HEAD` if no base is given) and, if helpful, `git diff {{BASE_REF}} --stat`. Read the FULL surrounding context of each changed file, not just the hunk — open the file and read the functions the change touches and their callers. If an AGENTS.md / CLAUDE.md exists, read it for project conventions before judging style.

## Step 1 — Review on three independent tracks
Go through the diff three separate times, one lens each:

**Track A — Correctness (highest priority).** Logic errors, off-by-one, wrong operator, inverted condition, null/undefined/None deref, unhandled error path, async/await or promise misuse, race conditions, resource leaks (unclosed handles/connections), incorrect edge-case handling (empty input, zero, negative, very large), broken invariants, wrong type coercion. For each: explain the concrete input/scenario that triggers the bug.

**Track B — Simplification & reuse.** Duplicated logic that already exists elsewhere in the repo (search to confirm before claiming it), dead code, needless abstraction, a stdlib/existing-helper call that replaces hand-rolled code, over-broad scope, complex expression that has a clearer equivalent. Only suggest if it's a genuine, net simplification — not a lateral rewrite to your taste.

**Track C — Security.** Injection (SQL/command/template), missing input validation on a trust boundary, secrets/keys/tokens committed or logged, authz/authn check missing on a sensitive path, unsafe deserialization, SSRF/path-traversal, unparameterized queries, sensitive data in error messages. Flag only real, reachable issues in THIS diff.

## Step 2 — Output format
For each finding, output exactly:

```
[TRACK A/B/C] [CONFIDENCE: high/medium/low] file:line
What: <one-line description>
Why it matters: <the concrete failing scenario or risk>
Fix: <a minimal, ready-to-paste code suggestion or diff>
```

Order findings by track (A → B → C), then by confidence (high first). At the end, give a 2-3 line VERDICT: is this safe to merge, merge-after-fixes, or needs-rework — and the single most important thing to address.

## Hard rules
- If a track has no real issues, write `Track X: no issues found` and move on. Empty is a valid, good result.
- Never mark a guess as `high` confidence. Use `low` when you couldn't fully verify (e.g. behavior depends on code you couldn't read).
- Do NOT rewrite the whole file or restyle code that works. Scope = the diff.
- Cite real `file:line`. Do not fabricate line numbers — read the file to get them right.
- Focus on {{FOCUS_AREAS}} if specified; otherwise weight Track A heaviest.