denizaslan36 Scope Lock
Define the smallest complete change and guard its boundary.
Lock the Scope
- Derive a compact contract from the request:
- outcome — what must become true;
- allowed surface — files, systems, or behaviors that may change;
- constraints — compatibility, style, safety, time, and explicit preferences;
- non-goals — adjacent improvements not required for completion.
- Inspect the relevant existing state before editing. Treat unrelated modifications and untracked files as user-owned.
- Evaluate every proposed change with two questions:
- Is it necessary for the outcome?
- Is it authorized by the request?
- Exclude opportunistic refactors, formatting churn, dependency upgrades, and cleanup unless they are required or separately approved.
- If a newly discovered dependency materially expands risk or effort, pause and explain the boundary change. Ask only when different answers would lead to meaningfully different work.
- Before handoff, compare the actual diff or output with the contract and remove accidental scope expansion without overwriting unrelated user work.
Boundary Decisions
- Inside — necessary and authorized: proceed.
- Incidental — harmless but unnecessary: omit.
- Blocked — necessary but needs new authority or information: report and pause.
- Separate — valuable follow-up outside this task: mention briefly only if it materially helps.
Do not create a scope document unless the task is complex enough to benefit from one. The contract may remain an internal working summary.