refactoring-safelylisted

# Refactoring safely A refactor is a change that keeps behaviour identical. The moment it also changes behaviour it is no longer a refactor, and the safety argument for doing it in bulk disappears. ## First, get a harness under it You need something that tells you when you broke it. Before touching the structure: - run the existing tests and note exactly what passes; - if the area is untested, write characterisation tests first — tests that capture what the code does today, right or wrong. These are your safety net, not a statement that the behaviour is correct; - if you cannot get a test around it at all, say so before starting. A blind refactor of untested code is a gamble with someone else's repo, and it needs the owner's agreement. ## Then move in small, reversible steps Each step should leave the tests green. Rename, then run. Extract, then run. Move, then run. - Prefer the mechanical transformation: rename a symbol everywhere, extract a function without editing its body, move a file and fix the imports. These are the steps where you are least likely to be wrong. - Do not delete and rewrite. Transform. - Keep the old thing working until the new one is used everywhere, then remove the old one in its own step. If the tests go red, you know which step did it, because it was the last one. ## Keep it separate from the feature Refactor, commit, then change behaviour in a second commit. A diff that both moves three hundred lines and quietly fixes a conditi