Surgical changes

A surgical change reuses the code paths that already exist. The size of the change doesn't matter, and a surgical change can be as big as it needs to be. What matters is that it cuts along the seams the codebase already has, instead of opening new ones.

Before writing code

1. Find the seam. Locate the abstraction this change belongs to: the common type, trait, interface, or module that its siblings already flow through. Read at least two existing siblings (the other harness, the other provider, the other variant) before adding yours. Done when you can name the file and symbol your change hangs off.
2. Check the shape. If your new case needs a field or capability the siblings lack, check whether the siblings actually have it too (unexpressed) before widening the shared type. Widen the common type only when the concept is genuinely common. Done when every field you're adding is justified by more than one case, or is scoped to your case alone.

While writing code

1. Route through existing paths. New behaviour enters through the seam found in step 1 (a new trait impl, a new case in the common type, a new entry in the registry), never as a sibling file that re-implements what its neighbours already do. If you catch yourself copying a block to modify it, stop and extract the shared part first.
2. Touch what the change requires. Refactors, renames, and formatting of surrounding code are separate changes; leave them out.

Completion criterion

The change is surgical when: every new code path is one the existing architecture anticipated (a new impl of an existing interface, a new variant of an existing type), no logic exists in two places, and a reviewer can diff it against a sibling and see the same shape.