Tasks

Tasks are the durable unit for work that must outlive a conversational turn. They are used when the objective requires implementation, repository inspection, file changes, tests, builds, or another result that needs a stable status and proof trail.

From request to durable work

The thread remains the place where you state intent. When that intent requires durable execution, Atoi creates a task linked to the thread and, when available, the project workspace. The task runs through the product-owned implementation runtime while chat continues through the conversational runtime.

Task states are presented as Queued, Running, Blocked, Done, Failed, or Canceled. A blocked task can carry an approval or a question that needs operator input. A failed task keeps its output and suggested next safe action rather than collapsing into a generic error.

Continue the same task when you are refining completed or interrupted work. That preserves the connection among the original objective, later instructions, changes, checks, and receipts.

Read the receipt

The task receipt is the durable account of what happened. Its detailed view can include:

• Changes with a file count, additions and deletions, and per-file diffs when materialized changes exist.
• Checks derived from recorded gates and proof claims, each with pass, fail, warning, or not-run state.
• Output and artifacts for the result and linked deliverables.
• Technical details for source references, evidence, task identity, runtime links, timestamps, and related task structure.

Receipts appear beside the work they belong to. In a thread, the task handle and receipt provide the quiet path from conversation to proof. In a project, Tasks rows lead to the same detail rather than a second summary model.

Open task detail in place

The canonical task address is ?task=<id>. It can be added to a thread, project, inbox, or other product-spine route. Opening the detail preserves the surrounding context and develops the receipt in place.

/c/<thread-id>?task=<task-id>
/p/<project-id>/tasks?task=<task-id>

The legacy ?run= parameter is compatibility input; current links use ?task=.

Treat change sets as proof-bearing

A completed task may materialize a change set. Atoi verifies that the task is done, the task proof is verified, file changes contain an unambiguous baseline, and the workspace has repository, branch, and revision truth. The receipt’s expected file count must also agree with the materialized files.

Applying a change set is a separate action from preparing it. The CLI checks repository and branch identity, stale revisions, changed preimages, path traversal, and symlink traversal before writing. Draft pull requests likewise require explicit publication. A prepared receipt is evidence of prepared work, not evidence that files were applied or a pull request was published.

Use the checks and technical detail to decide what to trust. The status tells you where the task is; the receipt tells you what the status means.