code-quality-principleslisted

# Code Quality Principles ## Iron Law **EVERY CHANGE MUST BE INTENTIONAL. If you can't explain why a line changed, revert it.** ## Before You Write Code Answer first, or return to EXPLORE: which task/criterion this code serves; which files change and why each; which existing project patterns apply; what could go wrong (error cases, edge cases, security); how you will verify it. ## Boy Scout Rule Leave every file you touch better than you found it. Touching a file means owning its known issues. **The proximity test is NOT a deferral mechanism for P1/P2 findings.** It decides *how* a cleanup is committed (alongside the feature fix vs. a separate `improve:` commit), not *whether* it gets fixed. A P1 or P2 in a file the PR modifies is fixed in this PR. **A cleanup is a standalone `improve:` commit when ALL true:** 1. The file is already being modified for the current task 2. The fix is self-evidently correct (lint, format, typo, obvious bug, missing error handling) 3. The fix is small (under ~10 lines) 4. It does not change public API signatures or behavior semantics 5. It needs no explanation beyond "Boy Scout cleanup" **A finding requires expanded scope (still fixed; may need a design note or tests) when ANY true:** 1. Requires modifying files NOT already touched by the task 2. Changes architecture, module boundaries, or public APIs 3. Requires new tests to validate 4. Would benefit from its own issue to explain motivation 5. Is a subjective style preference (P3 at mos