By default the build is host-driven, one work item at a time. The planner
records the plan's work items as - [ ] WI-<n>: <imperative title> checklist
lines in the ExecPlan's ## Progress section, and after design approval the
host loops: read the committed checklist, dispatch a builder turn scoped to
exactly the first unticked item, then verify that the turn left the worktree
fully committed and moved the committed checklist forward. A turn that returns
ok without committing a tick is bounced once with the defect named in the
next prompt; two consecutive no-progress turns fail the task. The loop is
bounded by maxWorkItemRounds, and the committed checklist — not the agent's
say-so — decides when the build is done.
Small turns change the failure economics: each builder turn does one work
item's worth of code, tests, docs, gates, and one atomic commit, so the ODW
build adapter can sit on a tight timeout (roughly 3600 seconds) and a hung
stream costs at most one work item plus a warm stageAttempts retry from the
committed ExecPlan — not a whole task. Legacy plans whose Progress section is
prose ticks rather than work items still work: the loop dispatches "the first
unticked item" by its text, and a plan with no checklist at all falls back to
the single-turn build.
The run result's workItemBuild object reports the effective configuration.
Work-item turns appear in the events as implement:<id> wi<n> labels.