scoped-change

Scoped Change

A change has one correct size and the request defines it. Overshooting and undershooting are the same failure — a boundary that was never located — and they fail differently: unrequested edits surface in review or in production, missing edits surface as the user finding them. Locate the boundary first, then be exhaustive inside it and inert outside it.

When the boundary is corrected mid-task, the result reads as though the corrected scope were the only one there had ever been. A title, comment, or rationale that keeps the dropped option alive re-imports the overshoot the correction just removed, and the reader pays for it twice; what belongs in a deliverable is ux-writing.

Outside the boundary

• Edit only the surfaces the request names. A request that names one layer is a request about that layer, and the neighboring layers stay untouched even when they look wrong. Report what you noticed instead of fixing it; a separate observation is cheap, an entangled diff is not. Counter-example: asked to adapt a backend endpoint to an existing signup form, an agent redesigned the form too, and the reviewer had to pull the two apart before either could ship.
• Compatibility is a cost, and someone must already be paying it. Migrations, dual-read paths, deprecated aliases, and version shims are correct only when real users hold the old state. Establish that they exist before writing one; when they don't, a clean break is the smaller change. This is a question of fact, not caution. Counter-example: an unreleased product with no installed base got a save-format migration path for data no user had ever written, and the dead branch still had to be maintained and tested.
• Reuse the existing implementation; never add a second one beside it. If the project already renders this panel, formats this message, or awards this promotion, extend that path. A parallel implementation that looks correct is worse than an obvious gap, because it diverges silently and nothing fails when it does. Counter-example: a new promotion banner was written from scratch next to the existing level-up banner; a release later only one of them had the new animation.
• Prefer changing an existing rule to adding one next to it. A new constant, flag, or branch that coexists with the rule it was meant to replace leaves two sources of truth and doubles the states to reason about. Counter-example: a request to restrict upgrades to a single branch arrived as a new second rule constant; narrowing the meaning of the original constant was the entire change.
• Solve the stated problem, not its general form. Extension points, plugin layers, and configuration surfaces are worth building when a second caller exists, not when one is imagined. The simple implementation is the deliverable unless the request asked for the general one.