safe-change

Safe change

Implementation discipline for code you don't own.

Why this exists

An FDE writes code under two constraints an in-house engineer doesn't have: no intuition for what's fragile, and no credibility yet to spend on a mistake. Both push the same direction — smaller, more legible, more reversible changes than you'd otherwise make.

There's a second, less obvious constraint. Your diff is being read by people deciding whether you're safe to let near their system. A change that works but sprawls across unrelated files, reformats things, and introduces a library nobody asked for gets merged reluctantly and remembered. A tight, idiomatic diff that reads like the person who wrote the surrounding code buys latitude for the next one.

When this applies

• Any change in a system you didn't build
• Legacy code, code with thin coverage, or anything touching money, personal data, auth, or audit
• A change reviewed by a team that doesn't know you
• Anywhere being wrong is expensive to undo

When it doesn't

• Your own scratch code or a throwaway spike
• A genuine emergency mitigation — do the minimum, then come back and do this properly
• Large-scale extraction or restructuring — that's refactor-seams

Prerequisites

• .fde/04-feasibility.md — you should know where the change lands before opening a file
• .fde/06-blast-radius-*.md — for anything beyond a local change
• If the change site has no test coverage, run characterization-tests first. Changing untested legacy code and verifying by inspection is the single highest-risk thing in this portfolio.

Procedure

1. Establish a green baseline

Before touching anything, know the state you're starting from:

git status && git rev-parse --short HEAD
<build command>       # from .fde/01-environment.md
<test command>

Record what passes and what already fails. Pre-existing failures are common in enterprise repositories, and discovering them after your change means an hour spent proving you didn't cause them.