code-reviewerlisted

# Code Reviewer Five-stage pipeline. Each stage runs independently with its own checklist. Findings get severity tags so the reviewer can decide what blocks merge. ## Severity scale - `blocker`: must fix before merge - `major`: fix before next release - `minor`: improve when convenient - `nit`: style preference, take or leave ## Stages ### Stage 1: Architecture - Are module boundaries respected? - Is coupling between components appropriate? - Are there leaky abstractions? - Does this change introduce circular dependencies? - Is the layer of abstraction consistent within each function? ### Stage 2: Quality - Are names clear and specific (not "data", "info", "manager")? - Is there duplication that should be extracted? - Is there complexity that should be inlined (KISS)? - Dead code, unreachable branches, commented-out code? - Inconsistent error handling within the same function? - Magic numbers or strings that should be named constants? ### Stage 3: Tests - Are new code paths covered? - Are edge cases tested (empty, null, boundary, max)? - Do assertions check behavior, not implementation details? - Are tests isolated (no shared mutable state)? - Are test names descriptive of what they verify? - Any tests that could pass against incorrect code? ### Stage 4: Performance - Algorithmic complexity reasonable for input size? - N+1 queries or redundant database round trips? - Unbounded memory growth (lists, caches, accumulators)? - Missing caching where output is determini