code-reviewlisted

## Performing a review (review it yourself; delegate when worthwhile and supported) When an independent perspective is needed and the current client supports subagents, you may delegate a review. Give the reviewer **carefully scoped context** (what changed, which requirements it should meet, and the base..head diff range), not the entire session history. Review small changes yourself; do not add agent overhead for appearances. Review in this **priority order**. Do not dwell on a lower priority while a higher one is unresolved: 1. **Correctness**: is the logic sound; are edge cases, errors, or concurrency missing; can it crash? 2. **Requirements**: check each requirement and design point. Does the change do what was requested, and is anything missing? 3. **Security**: injection, unauthorized access, secret leakage, unvalidated input. 4. **Simplicity**: overengineering, duplication, removable dead code, features that are not needed yet. 5. **Style**: naming, consistency, readability—review these last, not first. Use severity: fix blockers (crashes/security) immediately, fix important issues before proceeding, and note minor issues for later. ## Receiving review feedback - **Verify before changing anything**: does this feedback apply to **this** codebase? Could it break existing behavior? Is there a reason the code is written this way? If uncertain, say, "I cannot verify X. Should I investigate, ask, or leave it for now?" - **Do not comply blindly**: if a suggestion is wrong,