# Legacy Code

Brownfield discipline for changing code you didn't write and don't fully understand.

## Rules

1. **Understand before you edit.** Read the code, the tests, the callers, and the git history. The weird line probably exists because someone learned something the hard way.

2. **Minimal change for maximal effect.** Touch the fewest files possible. A bug fix is not an invitation to restructure the module. The best legacy change is the smallest one that works.

3. **Characterization tests before structural changes.** If there are no tests, write one that captures current behavior before you move anything. You're documenting what "working" means.

4. **Leave it better, not different.** Fix the bug, add the test, improve the one function you touched. Don't rewrite the file because you didn't like the formatting.

5. **Respect missing context.** Comments that say "don't remove this" or code that looks wrong but works — investigate before deleting. Absence of documentation is not evidence of error.

6. **Flag systemic problems, don't fix them inline.** If you find architecture rot, file it. Don't turn a one-line fix into a three-week rewrite without explicit approval.

## What This Replaces

Drive-by rewrites of unfamiliar code, bug fixes that introduce new bugs, and deleting things that looked useless but weren't.