code-reviewlisted

# Code Review ## Review Axes Every finding must reference exactly one axis. This prevents vague feedback and makes it actionable. | Axis | What to check | |------|--------------| | **Correctness** | Does the logic handle all cases in the acceptance criteria? | | **Security** | Injection vectors, secret exposure, auth bypasses, insecure defaults | | **Architecture** | Does the code follow existing patterns and module boundaries? | | **Performance** | N+1 queries, unnecessary allocations, blocking I/O in hot paths | | **Error handling** | Are failure cases handled explicitly and safely? | | **Test coverage** | Do tests verify the acceptance criteria, not just happy paths? | | **Scope** | Are there changes outside the stated task boundary? | | **Technical debt** | Does the implementation introduce debt without acknowledging it? | ## Finding Categories ### CRITICAL — must be resolved before merge - Logic failures that violate acceptance criteria - Security vulnerabilities (injection, auth bypass, secret exposure) - Data loss or corruption risk - Breaking changes to public API or shared contracts - Missing error handling that causes silent failures ### WARNING — should be resolved before merge - Missing edge case coverage in tests - Scope creep (changes outside the task boundary) - Pattern inconsistency that will confuse future maintainers - Performance issue that will degrade under load - Missing input validation at system boundaries ### SUGGESTION — optional improvement