Task states

A task’s status field holds one of two things: one of the six ordinary statuses, or a state belonging to its task type. Both are enforced the same way, by refusing a move that is not in the table.

Ordinary tasks

Status	Means
backlog	Written down, not scheduled. A starting state only
open	Ready to be picked up. What a new task starts at
in_progress	Being worked, usually by a run
blocked	Cannot proceed until something else changes
done	Finished and accepted
cancelled	Deliberately not doing it

Legal transitions

From	May move to
backlog	open, cancelled
open	in_progress, blocked, done, cancelled
in_progress	blocked, done, cancelled
blocked	open, in_progress, cancelled
done	nothing (reopen only)
cancelled	nothing (reopen only)

Anything not in that table is refused with a validation error naming both states. Three consequences follow from it:

• Nothing returns to backlog. It is a starting state.
• done and cancelled are terminal. They change only through reopen, which is a separate action rather than an ordinary move, and always lands on open.
• in_progress cannot go back to open. Route it through blocked if work has genuinely stopped.

Priority

A task also carries a priority, which affects ordering rather than transitions: low, normal, high, urgent.

Typed tasks

A task with a taskType replaces the six statuses entirely. Each type has its own initial state, its own terminal states, and its own transition table.

Terminal means terminal

None of these types has a reopen. A typed task that reaches a terminal state stays there, and the work continues as a new task.

content

The content lifecycle, from a captured idea to a measured result. killed is reachable from every non-terminal state.

From	May move to
captured (initial)	ideating, killed
ideating	drafting, killed
drafting	verifying, killed
verifying	human_review, drafting, killed
human_review	scheduling, drafting, killed
scheduling	measuring, killed
measuring	done, killed

Terminal: done, killed. The two backward edges are the ones that matter in practice: verification and human review both send a draft back to drafting rather than failing it.

verification

From	May move to
pending (initial)	scoring
scoring	passed, failed, needs_revision

Terminal: passed, failed, needs_revision. See verification tasks.

approval

From	May move to
pending (initial)	approved, rejected, expired

Terminal: approved, rejected, expired. See approval and feedback tasks.

feedback

From	May move to
awaiting_window (initial)	collecting
collecting	collected, awaiting_window
collected	learned

Terminal: learned. The edge back to awaiting_window is what lets one feedback task cover several measurement windows.

scheduled_trigger

From	May move to
waiting (initial)	fired, cancelled

Terminal: fired, cancelled. See scheduled triggers.

setup

The blocker a task carries when it needs information from you before work can start.

From	May move to
pending (initial)	collecting, cancelled
collecting	complete, cancelled

Terminal: complete, cancelled.

generic

The type a task has when it has no type. It accepts any state and any transition, which is why an ordinary task is validated against the six statuses above rather than against a graph.

Next steps

• Move a task through its statuses: the same table, with the screens and the unblocking advice.
• Task types: why the specialized types exist.
• Run states: what in_progress usually means underneath.