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, characterization tests, big-bang rewrite avoidance. ## When NOT to Use - Behavior-first feature work; use `proof`. - Commit grouping or history surgery after changes exist; use `commit` or `git-workflow`. ## Rules 1. Every commit is structural or behavioral, never both. Opportunistic tweaks and behavior fixes go in separate behavior commits or are left out. 2. Name the coupling being separated (data shape, side effect, module boundary, ownership, time, transport, persistence, compatibility) before code moves. "Extract a helper to shorten this" is not a named coupling. 3. Each behavior-preservation claim gets a Proof Contract: unchanged behavior, invariant, public boundary, before/after check, evidence. Add characterization tests where coverage is missing. An unproven refactor is reported as unproven. 4. For public interfaces, use parallel change: expand, migrate callers, contract. Ask which callers, data, and releases must keep working before adding shims, dual paths, or migration machinery. 5. Delete old paths only when verification proves callers and traffic have moved. Leftover migration or deletion work has an owner and a deadline. 6. For broad renames