code-cleanuplisted

# Code Cleanup ## When to Use Tests/build/typecheck pass but the diff is clumsy; feature works but has duplication, over-nesting, dead code, awkward naming; final simplification before review/merge; "broken window" needs boarding up. ## When NOT to Use Behavior is broken or unverified; "cleanup" is cover for redesign; cleanup spreads to unrelated files; can't prove nothing broke. ## Core Principle **Lock behavior first. Then simplify. Then re-verify.** Sequence: behavior locked → simplify → re-verify nothing changed. If any step fails, stop. ## Workflow 1. **Lock behavior.** Run the relevant tests + typecheck + lint. Save the output. This is your "before" baseline. 2. **Identify smell.** Use `fallow` (if available) for dead code, dupes, complexity. Otherwise: read the diff, mark spots that feel off. 3. **Simplify, in order:** - **Delete** (dead code, comments that restate, unused exports), easiest, highest impact - **Rename** (clearer names, remove prefixes/suffixes), cheap, high signal - **Extract** (a variable, a helper), only if nameable and reused - **Inline** (a one-use wrapper), only if the wrapper adds no clarity - **Restructure** (split a function, lift a conditional), last resort, highest risk 4. **Re-verify.** Same tests, same typecheck, same lint. Outputs match "before" baseline. 5. **Diff review.** Anything outside the cleanup scope? Split it out. ## Anti-Simplification Patterns - Adding an abstraction for "future use", speculative, not cleanup - "I