refactoring-safelylisted

# Refactoring Safely ## Purpose Refactoring means changing structure while behaviour stays identical. The word is routinely used for two other things — rewriting, and changing behaviour while tidying — and conflating them is how refactoring earns its reputation for breaking things. The discipline is simple and non-negotiable: **have a way to detect behaviour change before you start, then make small steps that each preserve it.** ## When to use - Code is hard to understand, test, or extend, and you are about to work in it. - Before adding a feature to a tangled area — restructure first, then add, as two separate changes. - After a bug fix, to remove the conditions that allowed the bug. - Duplication has reached the point where changes must be made in several places. - A module cannot be tested without instantiating the whole system. ## When NOT to use - There is no safety net and you cannot build one. Add characterisation tests first, or do not refactor. - Under deadline pressure alongside a behaviour change. Entangling them makes both unreviewable, and it is how "the refactor broke it" happens. - The code is untidy but stable and nobody needs to change it. Restructuring has cost and risk; aesthetic discomfort does not pay for it. - The design is wrong at the architectural level. Use `software-architecture` first; refactoring within a wrong structure polishes the wrong thing. ## Required context | Fact | Why it matters | |---|---| | The concrete pain being s