refactoringlisted

# Refactoring ## Iron Law `GREEN BEFORE THE REFACTOR. GREEN AFTER EACH STEP. NEVER MIX STRUCTURE AND BEHAVIOR IN ONE COMMIT.` ## When to Use - Changing structure while preserving behavior: legacy refactors, large renames, extractions, migrations, branch by abstraction, strangler fig, Mikado planning, characterization tests, or big-bang rewrite avoidance. ## When NOT to Use - Behavior-first feature work; use `proof`. - Commit grouping or git history surgery after changes already exist; use `git-workflow`. ## Core Ideas 1. Preserve behavior first; add characterization tests where coverage is missing. Separate structural from behavior changes: every commit is one or the other, never both. 2. Name the coupling before changing structure: data shape, side effect, module boundary, ownership, time, transport, persistence, or compatibility. 3. Make every step small, reversible, and shippable. 4. Validate the target shape before moving large amounts of code. 5. For public interfaces, use parallel change: expand, migrate callers, then contract. Ask which callers, data, and releases must keep working before adding shims, dual paths, or migration complexity. 6. Delete old paths only when traffic/callers have moved and verification proves it. 7. Simplification is refactoring: remove accidental complexity only after naming the behavior preserved and the coupling reduced. ## Workflow 1. Define the current behavior that must not change. Add or identify