pr-reviewlisted

# PR Review Systematic approach to reviewing pull requests. Covers correctness, test coverage, code style, and security concerns. ## Before Starting 1. **Understand the scope** — read the task/ticket and diff summary first 2. **Check CI** — if build or tests are red, flag before deeper review 3. **Check for description** — PR should say what and why, not just link a ticket ## Review Checklist ### Correctness - Does the change handle the **happy path** and **error paths**? - Are there **edge cases** (empty input, nil, zero values, overflow)? - Does it **preserve backward compatibility**? If not, is the breaking change justified? - Are there **race conditions**? Look for shared mutable state without sync. ### Tests - Are there **tests for the new code**? Not just the happy path. - Do tests use **table-driven style** (Go) or parameterized (other langs)? - Are tests **deterministic**? No sleeps, no network calls, no time-dependent assertions. - Do **existing tests still pass**? Look for removed/renamed tests. - Is there a **test for the bug fix** that reproduces the issue? ### Code Style - Does the code **follow project conventions**? Check imports, naming, error handling. - Are **errors wrapped** with context (`fmt.Errorf("do thing: %w", err)`)? - Are there **magic numbers or strings** that should be constants? - Are **comments explaining WHY**, not what (the code already says what)? - Is **unused code** removed, not just commented out? ### Safety & Security - Are **