loop

Activate a goal with a contract and plan, then invoke the loop skill. It groups remaining tasks into dependency-ordered waves, dispatches each task to an isolated git worktree subagent, and advances only after reviewer and verifier approval.

It uses three dependency signals: produces/consumes edges as the primary topological signal, explicit depends_on overrides, and scope_paths file-overlap detection as a safety net. Tasks with disjoint scope and satisfied dependencies run in the same wave.

Yes. Set execution.style to serial in contract.json to run tasks one at a time in the main checkout. Wave-based parallel execution remains the default because it suits large migrations with many independent file slices.

The engine persists state.json, an append-only journal.nav, and checkpoints before irreversible transitions. On restart it reloads the last persisted state, re-runs drift checks, re-validates tracking commits against git log, and resumes from the wave cursor.

Passing mechanical verification commands is only one signal. The engine also requires a whole-contract /verify verdict of COMPLETE from an independent verifier subagent, and it blocks CLOSE if a KB_GAP surfaces owner-curated content the engine cannot write.

It cannot start without an ACTIVE goal and valid contract, cannot modify the contract or plan itself (changes require a RECONTRACT), halts on unresolvable dependency cycles, and escalates rather than auto-completing when token, loop, or retry budgets are exhausted.