changing-legacy-codelisted

# Changing legacy code Legacy code is code without a safety net. Its current behavior, including its quirks, is what users depend on. Change it the way a careful senior engineer would: pin the behavior first, change as little as possible, and leave it a bit easier to test. ## Rules - **Follow the house style**, even if you would do it differently: its patterns, naming, framework version and error handling. Don't introduce a new paradigm in one corner. - **Keep the diff minimal.** - No reformatting, reordering or renaming outside the change. - Don't upgrade dependencies unless the task needs it. - Delete only what your own change orphaned. - Report other dead code; don't delete it. - **Treat surprises as possible requirements.** An odd branch may be a customer contract, a legal rule or a device workaround. Check `git log -L`/`git blame`, linked issues and tests, and ask before "fixing" behavior nobody asked about. - **Leave generated, vendored and migration history alone.** Add new migrations; never edit applied ones. ## Process 1. **Understand the change point:** callers, data flow, side effects (DB, files, network, devices), and configuration and feature flags. 2. **Pin current behavior with characterization tests.** Call the code with realistic inputs and assert whatever it does *today*, even if it looks wrong, so that any change shows up. Cover the paths you will touch plus their edges. 3. **Find or create a seam** where a test can control dependencies: - p