Scope before implementation
Target paths are an implementation control, not a retrospective description. State them before the agent starts so it can recognize a boundary crossing.
Answer page
Declare allowed target paths before implementation, review changed paths against that boundary, and require escalation before the agent broadens scope.
Direct answer
Prevent out-of-scope changes by listing the permitted implementation paths in the task definition, checking the diff and implementation summary against that list, and requiring the agent to stop for human approval when a necessary change falls outside the declared boundary.
Practical guidance
Target paths are an implementation control, not a retrospective description. State them before the agent starts so it can recognize a boundary crossing.
If an agent finds that another file must change, pause and ask whether to widen the task, create a dependency task, or choose a different solution.
A written summary of changed paths makes scope review fast and prevents unrelated edits from hiding in a large generated diff.
Verified demo evidence
$ day-shift task new --milestone-overview <milestone-overview> --full-set
Created 2 declared tasks and implementation summariesAuthorship and sources
Keep exploring
The objective, scope, acceptance criteria, and validation a coding agent needs before changing code.
Read nextClear triggers for moving coding-agent work to accountable human judgment.
Read nextContain, review, correct, and improve the task boundary after an agent mistake.
Read nextFind your answer
Search the answer pages, concept, comparisons, demo, and FAQ without leaving the site.
Search by a problem, workflow step, or tool boundary.