refactor

# Refactor: restructure without changing behavior A refactor changes the *shape* of code, never what it *does*. The one rule that makes it safe: behavior is pinned by tests before you touch anything, and the same tests stay green after. If behavior needs to change, that is not a refactor — stop and treat it as a feature or a fix. ## Phase 1: Pin the behavior Before restructuring, make the current behavior observable and guarded. 1. Find the tests that cover the code you intend to move. Run them and confirm they pass. This green run is your baseline — write it down. 2. If the code is not covered, **add characterization tests first**: tests that capture what the code does *today* (not what it should do), enough to catch a behavior change. Get them green against the current code before you refactor. 3. If you cannot get the behavior under test at all, say so and stop — an unguarded refactor is a rewrite in disguise, and you would have no way to know you broke something. ## Phase 2: Restructure in small steps Make one structural move at a time, and keep the tests green between moves. - Each step is a single transformation — extract a function, rename a symbol, inline a variable, split a file, unify duplicated blocks — not a pile of them. - Run the tests after each step. If they go red, the last step changed behavior; undo it and make a smaller move. - Change structure only. No new parameters "while you're in there", no bug fixes, no renamed behavior. I...