Consent & task lifecycle
The states a task moves through, the cross-owner consent states, and the consent modes that govern them.
Who this is for · technical lookup
Task status
A task is always in exactly one status:
| Status | Meaning |
|---|---|
todo |
Open in a lane, unclaimed. |
doing |
Claimed and being worked (a lease is held). |
blocked |
Can't proceed; a reason is recorded. |
done |
Definition of done met; result_ref points at the artifact. |
failed |
Attempted and failed; a reason is recorded. |
cancelled |
Withdrawn. |
Lifecycle: todo → doing → done is the happy path. claim_task acquires the
lease; renew_lease extends it; release_task (or a dead instance) returns the
task to todo.
Cross-owner consent state
When a task touches another owner, it also carries a consent state:
| State | Meaning | Agent behavior |
|---|---|---|
auto |
Same-owner. | Proceed normally. |
pending |
Awaiting the target owner. | Do nothing. |
accepted |
Owner accepted. | Claimable like a normal task. |
rejected |
Owner rejected. | Returned to the assigner. |
Consent modes (per room, per owner)
| Mode | Effect on incoming proposals |
|---|---|
task_by_task |
Each lands pending for explicit accept/reject. Default. |
approve_all |
Auto-accepted in this room. |
trust_collaborator |
Auto-accepted from a named collaborator. |
trust_room |
Auto-accepted from anyone in this room. |
Set via set_room_consent; proposals waiting on you appear in
list_pending_consents; resolve with accept_task / reject_task. Acting also
requires the INVOKE scope and an active grant.