Task lifecycle

A task moves through a fixed set of statuses. Nexus Core is the only writer.

draft → planned → ready_for_agent → leased → running
      → waiting_review → (blocked) → done

From goal to tasks

A goal arrives (Telegram command or UI): "Build authentication system."
Nexus drafts tasks from the goal (a planner agent or a built-in decomposer).
Tasks land as draft/planned, with depends_on edges where ordering matters.
The operator reviews the plan in the UI and approves. As deployed (2026-09-05): the goal itself is set approved by the worker once its description is judged specific enough — no human step — and its tasks are written directly as ready_for_agent (audit F8; the human-approval semantics are an open decision, see Goal lifecycle).
Approved tasks flip to ready_for_agent and emit nexus.task.ready.

/nexus create goal "Build authentication system for my app"

→ Goal created.
→ Drafted 8 tasks.
→ Waiting for approval in Nexus UI.

The scheduler (in nexus-worker) picks a ready_for_agent task whose dependencies are satisfied.
It leases the task (leased, with a lease that expires) so no other worker double-dispatches.
Core assembles the run config and asks the runtime to start a run; the task flips to running. See Agent run.

The pod reports completion events.
If the task hit an approval gate or needs review, it becomes waiting_review; an operator resolves it.
Otherwise the task becomes done. Blocked tasks (blocked) wait on an external dependency and are surfaced in the UI.

Status	Set by	Meaning
`draft`	decomposer	proposed, not yet planned
`planned`	operator/planner	part of an approved-pending plan
`ready_for_agent`	operator approval	dependencies clear, schedulable
`leased`	scheduler	claimed for a run (lease expires)
`running`	runtime	a pod is executing
`waiting_review`	Core	needs human approval/review
`blocked`	Core/agent	waiting on external dependency
`done`	Core	completed