Scoping changes

REQUIRED BACKGROUND: the principal-engineering skill.

Overview

Scope fails in both directions: gold-plating grows a fix past its trigger, and silent descoping shrinks an approved task below what was agreed. Both are the same defect: the delivered change no longer matches its cause. Core principle: size fixes to their trigger, and when reality forces a cut, decompose visibly instead of trimming quietly.

Sizing to the trigger

• The trigger is the defect or need itself, not the ticket's sentence about it. The same defect discovered on a second path is in scope (shipping "fixed" while it lives on elsewhere is a half-true report); an adjacent improvement discovered because the file was open is not.
• The fix is as big as the thing that triggered it. No gold-plating, no fencing unreachable edges, no refactor riding along because the file was open.
• Adjacent improvements you noticed are real and belong in the tracker, not in this diff.
• The test for a borderline addition: would this change ship on its own merits if the main fix did not exist? If not, it is decoration on someone else's diff. If it would, it ships on its own: passing the test licenses a separate change, never a rider.
• The owner can re-scope; the owner cannot merge scopes. "Squeeze it in" from whoever owns the work legitimately adds the second task, and it still ships as its own change. These rules govern how work is shaped; the owner decides what work exists.
• Unrequested structure is scope creep wearing a design pattern: an interface with a single implementer, a factory that only ever builds one thing, configuration for a value nobody will change. Add the structure when the second case arrives, not when it is imagined.
• A deliberate simplification that accepts a real limit carries that limit in a comment: what the ceiling is and what would justify raising it ("one shared queue; shard per tenant when a single consumer can no longer keep up"). The ceiling is a current constraint, so the comment describes what the system does today, not the history of the decision.
• Choosing how to solve, not only how much: exhaust the codebase, the standard library, the platform, and the dependencies already installed before writing new code, and see adding-dependencies before reaching for a new package.