diff-analysis

Diff Analysis

A diff-shaped review: it only looks at what changed, not the whole file, and produces one risk verdict. Run all three tracks over the same diff, then synthesize — don't review them one after another as separate passes, since a single line often matters to more than one track (a deleted nil-check is both a Track A complexity signal and a Track C security signal).

Track A: complexity

For each changed file:

1. Cyclomatic complexity change — did the diff add nested conditionals, new loops, new goroutines?
2. Function length — is any new or modified function longer than ~40 lines?
3. Removed safety guards — were any validation checks, nil-checks, or early-returns deleted?
4. New external dependencies — does the diff add new imports? Are they necessary, or does an existing dependency already cover this?

Track B: style and convention

1. Naming — do new identifiers follow the language's naming convention?
2. Error handling — are new errors returned/wrapped properly? Any new _ = suppressions?
3. Documentation — are new exported symbols documented?
4. Test additions — does the diff include tests for the new behavior?
5. Dead code — does the diff add unreachable code or unused variables?

Track C: security impact

1. Removed auth checks — did the diff delete or comment out authentication/authorization code?
2. New SQL/command strings — does the diff introduce a new string-built query or shell command?
3. Weakened validation — did any input validation become less strict (a must check turned into a warning, a bound loosened)?
4. New exposed endpoints — are new routes/handlers added without the same security middleware as their neighbors?
5. Dependency updates — if a lockfile/go.mod changed, are the new or updated dependencies from a trusted source with no known critical CVEs?

Synthesis

## Risk Level: LOW | MEDIUM | HIGH | CRITICAL

### Risk justification
<One paragraph explaining the overall rating, referencing which track(s) drove it>

## Key Changes
- <What the diff actually does, in plain language>

## Required Actions (must complete before merge)
1. <Specific action with file:line reference>

## Recommended Improvements (should do)
1. ...

## Nice-to-have
1. ...

## Merge verdict: APPROVE | REQUEST_CHANGES | BLOCK