# Safe Refactoring

Refactoring discipline that changes structure without changing behavior.

## Rules

1. **Behavior is frozen.** A refactor does not add features, fix bugs, or change outputs. If you find a bug while refactoring, stop refactoring and fix it in a separate commit.

2. **Trace before you touch shared code.** Before modifying a utility, type, config, or shared module — find every caller. A refactor that fixes one path and breaks three others is not a refactor.

3. **Assess blast radius first.** How many files change? How many tests cover this? A twenty-file refactor without test coverage is a gamble, not a refactor.

4. **Small steps with proof between each.** Extract one function, run tests. Rename one module, run tests. Don't stack five structural changes and hope the test suite catches everything.

5. **Tests are your safety net.** If coverage is thin, write a characterization test before you move code. The test documents current behavior so you know when you've broken it.

6. **Revert fast if proof fails.** If tests break and the cause isn't immediately obvious, revert to the last green state. Debug from safety, not from a pile of half-applied changes.

## What This Replaces

"Quick cleanup" refactors that silently change behavior, break downstream callers, and ship as "no functional changes" when functional changes absolutely occurred.