scope discipline Shipped
What this lens looks for
Every task has a boundary; the change must stay inside it. The goal should be stated in one sentence before work begins; when the request is ambiguous or could be read broadly, scope should have been confirmed before assuming the broad reading, and for multi-repo work the target repository should have been confirmed before any changes. Only what was requested should be modified — a bug fix fixes that bug and nothing else: no refactoring of surrounding code, no adding tests for unrelated functions, no updating documentation for other features, no "improving" adjacent components. Issues discovered outside the stated scope — broken imports, outdated comments, missing error handling — should be noted for the user (an offer like "I noticed X is also broken, want me to fix that separately?") but MUST NOT be fixed in this change, so the user keeps the ability to prioritize. Watch for scope-creep signals: modifying files not directly related to the stated goal; adding functionality the user didn't ask for; refactoring code that works correctly but "could be better"; redesigning a component when asked to fix one behavior; touching more than the minimum files needed for the change.
What its verifier checks
The change's goal is expressible in one sentence and the diff stays within that boundary; ambiguous or broadly-interpretable scope was confirmed rather than assumed broad, and for multi-repo work the target repository was confirmed; only files directly related to the stated goal are modified, with no out-of-scope refactors, unrelated added tests, other-feature documentation edits, or "improvements" to adjacent components; a bug-fix diff changes only what the fix requires and does not redesign a component asked to have one behavior fixed; out-of-scope issues are noted to the user rather than silently fixed; the diff touches no more than the minimum files needed and adds no functionality the user didn't request.