Dependencies and sprints

Two structural levers of the Queue: what unlocks what, and how the work is sliced in time.

Dependencies

deps are ids of other tasks. A pending task whose dependencies all became done is dispatched on its own on a board in autonomous mode — including at birth, if the dependencies were already ready. That is how you chain investigate → fix → review with nobody in the middle.

The requirements, in the order they usually fail:

1. the board must be in autonomous mode;
2. the task must have a declared provider — it is not inherited;
3. the concurrency cap must have room;
4. the dependencies must really be done — failed does not unlock.

Create the child before marking the parent done. Dispatch happens on the transition; a task created afterwards waits for an event that has already passed.

Sprints

A sprint is a slice of the work with a beginning and an end. Closing a sprint:

• freezes the numbers and the board’s composition;
• migrates what did not finish (todo, doing and interrupted) to a new sprint;
• leaves what finished and the judged failures in the closed sprint.

An empty sprint does not close, and there is no closing by calendar — it is always an explicit decision. The closed sprint becomes an immutable snapshot: its numbers never change afterwards.

What stays open

A task can be born with no card at all: a pending idea that has not become work yet. It sits in the Queue waiting for a provider and a dispatch.

See The Queue for the task and participation model.