refactoring-safelylisted

# Refactoring safely **Trigger.** You are about to restructure working code: extract a function, rename across call sites, move a module, collapse duplication, replace a conditional with polymorphism, split a class. Also load it when you notice a diff doing restructuring *and* a fix at the same time. > **Reference material** (the net-building recipe, sequences for the common > refactorings, large-scale and cross-repo strategy): see `reference.md`. ## The rule > **A refactor that changes behaviour is not a refactor. It is an > undocumented change wearing a refactor's diff.** The value of the word is that it tells a reviewer *they do not need to reason about behaviour*. The moment that stops being true, you have spent their trust and hidden a real change inside a large mechanical diff — the single easiest place for a defect to survive review. ## Before the first edit ### 1. Say why "It's messy" is not a reason; it is taste, and taste alone does not justify churn or merge conflicts. A reason is concrete: - a change you need to make is hard in the current shape; - the same logic has diverged in three places and drifted; - the structure allows an illegal state that keeps causing bugs; - new people consistently misread it the same way. No concrete reason means leave it alone. ### 2. Build the net **You cannot refactor code you cannot test.** If coverage is thin, write characterisation tests first — tests that assert what the code does *today*, including behaviour you th