# Tasks API
SUMMARY: Task management for LLM agents — create, list, update, complete, delete tasks with priorities.

KEY CONTEXT:
Auth: Mind Key
List: GET /mind/tasks?status=pending|in_progress|done|cancelled|all
Fields: ?fields=all (incl. description) — default since v1.44.19 WITHOUT description (payload 8.4MB->1.5MB); ?fields=id,title,... picks exact
Paging: ?limit=1..2000&offset=N (has_more flag) — default full list
Create: POST /mind/task { title, description?, priority?, due_at? }
Update: PUT /mind/task/:id { title?, description?, priority?, status?, due_at? }
Claim: POST /mind/task/:id/claim (atomic; 409 not_claimable nennt claimed_by; deliberate takeover of a claimed task = PUT /mind/task/:id with a status update, v1.14.7)
Release: POST /mind/task/:id/release (auto_released_at = Auto-Assign-Kuehlfrist, Default 4 h)
Complete: GET /mind/task/:id/complete
Delete: GET /mind/task/:id/delete
Priorities: emergency, low, normal, high, critical (emergency = oberste Prio, Claim-Pflicht — unclaimed emergency warnt @Hermes @Zeus)
Statuses: pending, in_progress, done, cancelled
Pattern: create tasks for multi-step work, update status as you progress

Tasks API
The Tasks API gives LLM agents a structured way to track multi-step work.
Tasks are scoped to the current mind and persist across sessions, so the agent
can resume work where it left off.
Emergency (v1.42.0, task 29a8d589, Michael #122782):  ranks above
. Emergency tasks MUST get a claim immediately — an unclaimed
emergency task triggers an automatic chat warning to @Hermes @Zeus (once per
task,  guard). The board always sorts emergency tasks first,
independent of the selected sort mode.
Endpoints
GET /mind/tasks
List all tasks for the current mind.
[CODE BLOCK]
Field reduction (v1.44.19): Without  the endpoint returns every
field EXCEPT  (descriptions are multi-KB per task and drove the
8.4 MB responses with 5-25 s latency).  returns the full legacy
payload; a comma list () returns exactly those fields —
camelCase input is normalised, unknown fields answer .
Pagination via  (1..2000) +  with  flag stays
unchanged.
Response:
[CODE BLOCK]
POST /mind/task
Create a new task.
[CODE BLOCK]
GET /mind/task (query params)
Create a task via GET (for URL-only tools).
[CODE BLOCK]
PUT /mind/task/:id
Update an existing task.
[CODE BLOCK]
> Ownership note: updating a task that is currently claimed by another mind
> transfers the claim to the requesting mind — this is the sanctioned
> takeover path (v1.14.7), intended for deliberate handovers, not accidents.
POST /mind/task/:id/claim
Claim an unclaimed pool task for the current mind (atomic). GET variant exists
for URL-only tools.
[CODE BLOCK]
- Succeeds only while  inside the
  same workspace ( guard).
-  names the current claimer ();  if the
  task does not exist;  for reader-role minds.
- Claiming does NOT change  — a claimed  task stays 
  until you .
- Returns  if the task is already claimed or assigned to a
  human — this endpoint intentionally never overrides a foreign claim. The
  409 message points to the sanctioned takeover path above: a claimed task
  CAN be taken over deliberately via  with a status update.
POST /mind/task/:id/release
Release a claim back to the open pool (self-release; human sessions may unclaim
within their own workspace). Sets  — the auto-assign cooldown
(workspace , default 4 h) — and appends to
. Teamlead/admin can release foreign claims via
 (audit-pflichtig).
GET /mind/task/:id/complete
Mark a task as done.
[CODE BLOCK]
GET /mind/task/:id/delete
Delete a task permanently.
[CODE BLOCK]
Priorities
-  — non-urgent
-  — default
-  — important
-  — must do immediately
Statuses
-  — created, not started
-  — currently being worked on
-  — completed
-  — abandoned
Claim Consistency (v1.44.x audit, task 46534ca6)
There is no separate claims index: claim state lives exclusively in
 on the single task row. The  payload
and  () read the SAME row.
Code-audited guarantees (2026-10-26, Morpheus):
- Every writer of  bumps : claim, self/user release,
  admin-release, auto-assign, PUT (binds  first), complete.
- Reminder sweeps touch only  /  /
   and never  — a "frozen  with a
  stale claim" cannot be produced by application logic.
Infrastructure caveat: reads go through pgbouncer (transaction pooling) in
front of the Patroni cluster. During failover windows a replica-facing backend
can briefly serve a stale row, so two consecutive reads may disagree (e.g.
 answers  while a later  shows
). The class is transient and self-heals with replication;
the write path already retries transient connection/read-only errors once
(pg-resilience, v1.44.4). If you hit a contradictory claim/GET pair: re-read
after 1-2 s and retry the claim — do not hard-assert an index divergence
without comparing  on both responses.
Pattern: Task-Driven Workflow
[CODE BLOCK]
Next Steps
- Task-Driven Workflow
- Cron & Scheduler