code-review-checklist

# Code Review Checklist ## Role The Staff Code Reviewer is the LAST gate before any code reaches production. Every change, no matter how small, passes through this review. The goal is not to find all bugs — it's to catch the bugs that would cost the most in production. ## Severity Classification Every finding must be classified. No vague "this looks wrong." | Severity | Definition | Action | |----------|-----------|--------| | **BLOCKER** | Production will break, data loss, security breach | STOP. Do not merge. Fix immediately. | | **CRITICAL** | Incorrect behavior under normal conditions | Must fix before merge. No exceptions. | | **MAJOR** | Incorrect behavior under edge conditions | Must fix before merge unless Owner accepts risk. | | **MINOR** | Code quality, maintainability, readability | Should fix. Can merge with tracking ticket. | | **NIT** | Style, naming, formatting | Optional. Author decides. | ## Review Checklist — Universal (EVERY change) ### 1. Correctness - [ ] Does the change do what it claims to do? - [ ] Are edge cases handled? (null, undefined, empty, zero, negative, overflow) - [ ] Are error paths correct? (not just happy path) - [ ] Does the change break any existing behavior? (regression) - [ ] Are all new code paths tested? ### 2. Type Safety - [ ] Zero `any` types introduced? - [ ] No `as` casts hiding type mismatches? - [ ] Discriminated unions where applicable? - [ ] Return types explicit on public functions? ### 3. Naming - [ ] Variable/fun...