Post-subtask drift: agent breaks containment after mid-project task graph modification

[mrhobbeys]

The failure

When an operator inserts subtasks mid-project (to backfill missing scope or correct an assumption), the agent completes the inserted subtasks but does not cleanly re-enter the original task flow. Instead, it scans ahead in the task graph, sees completed work from prior phases, and begins suggesting fixes or improvements to out-of-scope items. The Lock mechanism, which should restrict the agent to the current task, fails silently after the graph is modified.

How to reproduce

1. Scaffold a project with 8+ tasks across multiple phases.
2. Execute through Phase 1 normally.
3. During Phase 2, identify a gap that requires inserting 2-3 subtasks (e.g., a missing scoping step).
4. Insert the subtasks into TASK-STATE and have the agent execute them.
5. After the subtasks complete, observe what the agent does next.

Expected: Agent returns to the next task in the original flow per the dependency chain.
Actual: Agent scans the full task graph, notices completed work from other phases, and begins proposing out-of-scope changes to that work.

Root cause

There is no re-entry protocol after task graph modifications. The agent completes the inserted work but has no instruction to re-validate its position in the dependency chain before resuming. The "look ahead" behavior that's useful during normal execution becomes a drift vector after the graph changes.

Proposed fix: Re-Entry Protocol

Add a mandatory step after any task graph modification (insertion, removal, or resequencing of tasks):

1. Planner re-validates the dependency chain. After the inserted subtasks complete, the planner reads TASK-STATE and confirms which task is next based on the updated dependency graph.
2. Planner explicitly re-locks the next task. The Lock mechanism is re-engaged with a specific task ID. The agent cannot "browse" the task graph — it receives a single next-task assignment.
3. Any observations from the inserted subtasks are captured as discoveries, not acted on. If the subtasks revealed new issues, they go to DISCOVERIES.md for later triage, not into immediate scope expansion.

This could live as a section in LOCK.md ("Re-entry after graph modification") or as a standalone protocol in reference/.

Mechanisms involved

• Lock (primary) — containment breaks after graph modification
• Atomicity (secondary) — the subtask completion boundary doesn't trigger a clean handoff
• Dependency (secondary) — the modified graph isn't re-validated before execution resumes

Errata

• In my case the agent needed to know about additional settings which represented a 10x increase in expected work for the task #.
• I also found it interesting that the agent named the tasks matching the number with an appended letter.
• Task naming across projects and tests seems to change based on model
• After the harness is built model changes don't seem to impact the flow, but they do change the outcome when the work product is non-deterministic.
• Even on huge tasks and using a single agent instance with lots of compaction I've not seen this happen except mid-project scope changes that lead to creation of new tasks... which is why I think this fix will work.