Surface Forks

Systems go wrong where a change had implications past the ones considered. Not a bad decision — an unexamined reach. The change was correct locally and quietly contradicted something the system already committed to elsewhere.

One operation: find the collisions before implementing, then name the routes through them.

What is not a fork

• Preference. Button left or right. Nothing downstream depends on it.
• Convergent ordering. A before B or B before A, same end state, no residue.
• Isolated addition. New code that names no existing concept and no existing rule reads.

These are most changes. Pick and continue silently. A skill that flags everything gets turned off, and that is a worse outcome than never flagging anything.

The test: search, don't forecast

Do not estimate how hard something would be to undo — that is knowable only after knowing the implications, which is the unknown. Instead, before changing anything that names a domain concept, locate every place that concept is already committed to: definitions, constructors, validators, matches over its cases, serialisation, tests that state rules about it.

A fork exists when the change would do any of these to what was found: