code-reviewlisted

# Evidence-Based Code Review Review the requested code or diff in repository context. Load applicable language/framework skills and follow repository instructions before judging conventions. ## Scope - Review the user-specified target. For uncommitted work, inspect the complete diff and relevant call paths rather than auditing unrelated code. - Distinguish regressions introduced by the change from pre-existing issues. - Use `blast-radius`, when explicitly invoked and available, when the primary task is to trace what a concrete change could break beyond the obvious diff and prove its decision-critical safety assumptions. - Do not broaden a focused review into an architecture, dependency, formatting, or security program without approval. ## Finding Standard Report an issue only when you can explain: 1. The concrete failure or maintainability cost. 2. The reachable code path or credible conditions that trigger it. 3. The actual impact and proportionate severity. 4. The smallest practical correction. Use file paths and line numbers. Do not inflate severity, list theoretical possibilities as defects, or manufacture findings to appear comprehensive. If no actionable issues exist, say so. ## Review Priorities 1. Correctness, data integrity, and user-visible regressions. 2. Cancellation, concurrency, cleanup, and error propagation on realistic paths. 3. Security at actual trust and privilege boundaries. 4. Performance on demonstrated hot paths or where complexity clearly cre