Sprint execution

Summary

In agile practice, sprint execution is the iteration's working middle: the team pulls items from the sprint backlog, finishes them one by one, keeps progress visible day to day, and absorbs newly discovered work without losing the sprint goal.

In ORE Studio, sprint execution is where the plan becomes merged pull requests. Agents pick up BACKLOG tasks and run each through the lifecycle one PR at a time; the heartbeat rule keeps every in-flight document's Status honest; and work discovered along the way is triaged into the sprint or the backlog without derailing the mission. Mid-sprint health reviews read the sprint charts to catch drift while there is still time to react.

Detail

Ownership

Owned by System 1 (does the work). System 2 reviews S1 output and triages discovered tasks; System 3* audits the heartbeat invariant and id-link integrity.

The execution loop

Agents pick up BACKLOG tasks and run them through the lifecycle state machine: BACKLOG → STARTED → (maybe BLOCKED → STARTED) → DONE. Each task is one PR. Clock on with compass task start (it switches branch, flips the state, and stamps the session journal); the Work a task through to merged PR runbook covers the full cycle, and Handle a PR review round the review loop within it.

The heartbeat rule

Every time an orchestrator or agent acts on a task or story, it updates the document's Status rows (Now / Waiting on / Next / Last touched) and #+updated before yielding control. Audit flags STARTED or BLOCKED documents whose #+updated has gone stale.

Discovered work

Tasks discovered during execution land in DISCOVERED state at the sprint's inbox/ if they don't fit any existing story, or under the current story if they do. They must leave DISCOVERED within one orchestrator session (see lifecycle and Tasks). Ideas that are not sprint work at all go straight to the product backlog as captures.