Task

A task is the atomic unit of work in Colibri. One id, one β state machine, one decision trail, one (optional) Merkle root. A task lives inside a round inside a session; when it closes, its history is frozen in the decision-trail chain and — for proof-grade tasks — anchored in a Merkle tree.

Authoritative GSD contract: ../spec/s15-gsd-contract.md. Authoritative state model: ../spec/s03-state-model.md.

Task vs round vs session

The three units are not interchangeable.

Unit	Duration	Who owns it	Primary artifact
Task	minutes to hours	T3 executor	β FSM + ζ chain
Round	hours to days	T1 sigma	Seal document + Merkle roots
Session	days to weeks	T0 human	Session seal

A session may span many rounds; a round contains many tasks; a task does not span rounds. A task that would outgrow its round is split into a sequential pair of tasks, each within its own round.

Task identity

A task’s id is assigned at task_create. The id is deterministic-given-inputs: SHA-256 over the round id, the task title, the creation timestamp, and the creator’s identity. Two tasks with the same title in the same round produce different ids because their creation timestamps differ.

The id never changes. Status, priority, progress, and links all mutate; the id is immutable.

The 5-step executor chain

Every task run by a T3 executor follows the 5-step chain: audit → contract → packet → implement → verify. Each step produces an artifact and a commit.

Step	Artifact	Commit prefix	β state
1. Audit	`docs/audits/<name>-audit.md`	`audit(<name>)`	GATHER
2. Contract	`docs/contracts/<name>-contract.md`	`contract(<name>)`	ANALYZE
3. Packet	`docs/packets/<name>-packet.md`	`packet(<name>)`	PLAN
4. Implement	source files	`feat(<name>)` / `fix(<name>)`	APPLY
5. Verify	`docs/verification/<name>-verification.md`	`verify(<name>)`	VERIFY

No step may be skipped. The packet gates the implementation: implementation MUST NOT begin before the packet commit lands. Skipping audit or contract produces work with no frame of reference; skipping verify produces work whose outcome is unprovable.

See ../agents/executor-contract.md for the full 5-step contract.

The β state machine

A task moves through the 8-state FSM defined in ../3-world/execution/task-pipeline.md:

INIT → GATHER → ANALYZE → PLAN → APPLY → VERIFY → DONE
                                                  (+ CANCELLED)

The 5-step chain maps one-to-one onto the forward states, plus INIT (task accepted) and DONE (writeback complete).

Tiers involved in a task

A task is touched by multiple tiers in the 4-tier hierarchy:

T0 (human) — specifies the intent that will become a task; merges the PR that closes it.
T1 (sigma) — promotes the task into a round plan; signs the round seal.
T2 (PM) — promotes the task from backlog to todo; dispatches an executor.
T3 (executor) — runs the 5-step chain; writes all five artifacts; produces commits.
T4 (model) — the underlying LLM behind T3. Claude only in Phase 0 per ADR-005.

Only T2 may promote backlog to todo. Only T3 writes code. Only T0 merges. These authority bounds exist to make each tier’s actions provable without the others.

Writeback

Every completed task (whether DONE or CANCELLED) produces, in strict order:

task_update(id=<task_id>, status=<done|cancelled>, progress=100)
thought_record(type=reflection, content=<writeback body>)

For proof-grade tasks — any task in the legitimacy axis or flagged proof_grade=true — the sequence extends:

audit_session_start(...)
  ... work happens ...
audit_verify_chain(...)
thought_record(type=reflection, ...)       ← MUST come before merkle_finalize
merkle_finalize(...)
merkle_root(...)
audit_session_end(...)

The final thought_record MUST precede merkle_finalize. Otherwise the reflection sits outside the Merkle root and the proof does not cover the task’s own closing reasoning. See ../agents/writeback-protocol.md.

Phase 0 enforcement level

In Phase 0, writeback is enforced at convention level: the runtime accepts a task closed without writeback but flags it via an orphan scan. Runtime hard-block is a later-phase upgrade. This mirrors the donor posture described in ../spec/s15-gsd-contract.md.

Task links

Tasks can declare relationships:

blocks — task A cannot leave GATHER until task B reaches DONE.
parent-of / child-of — a task decomposes into sub-tasks.
refines — a task sharpens a prior backlog item.
supersedes — a task replaces an earlier, cancelled task.

Links are set via task_link and removed via task_unlink. They participate in priority scoring: a blocker’s priority propagates to its blocked dependents.

Worktree rule

A task that produces code changes runs in a feature worktree, never in the main checkout:

git worktree add .worktrees/claude/<task-slug> -b feature/<task-slug> origin/main

Forbidden: editing the main checkout directly, committing on main, pushing to main, force-pushing any branch, deleting a branch with unmerged work. See ../agents/executor-contract.md.

What a task is not

Not a ticket. Tickets describe desired outcomes; tasks describe executed work. A task either happens or does not; it cannot be “open indefinitely.”
Not a commit. A task usually produces several commits (one per 5-step stage); the task boundary is larger than any single commit.
Not a PR. A PR is the merge vehicle; tasks and PRs have a many-to-many relation via branches.