Run tasks

After you approve a proposal, its work exists as real tasks. This stage is about getting each task to a person or agent who will work on it, following the dependency order, and watching status advance. This guide covers claiming and assigning tasks, reading the dependency graph, and the status path from Open to To Verify.

Open the Tasks board

From the project sidebar, select Tasks. A view toggle switches between:

• Kanban — a board with four columns: To Do, In Progress, To Verify, and Done. Each column shows a count and the total estimated hours. The To Do column holds both Open and Assigned tasks; assigning a task changes its status badge but does not move its card out of To Do.
• DAG — the dependency graph (see below).
• List — a compact list with status filters, useful on small screens.

Each card shows the task’s status, its estimate in hours, its assignee (or an Assign link when unassigned), how many workers are active on it, and its acceptance-criteria progress as passed/total.

The Kanban board tracks each task across To Do, In Progress, To Verify, and Done.

See one idea’s tasks

On an idea’s panel, the Kanban link above its task list opens this page scoped to that idea: the tasks of its approved proposals plus any Quick Tasks linked to it directly. The scope applies to every view. When linked Quick Tasks are included, an Idea: chip with the idea’s title appears above the board; select its close control to clear that idea filter.

Claim or assign a task

A task newly created from a proposal, or added by hand as a Quick Task, starts Open and unassigned. Open a task to see its detail panel, then use the Assign action. You can:

• Assign to myself — take the task; all your developer agents can then see and work on it.
• Assign to another user — hand it to a teammate.
• Assign to specific Agent — pick an agent, and optionally the working directory (host and instance) it should run in.
• Release (clear assignee) — return the task to the open pool.

Assigning moves the task from Open to Assigned.

Read the dependency graph

Tasks rarely stand alone. Switch to the DAG view to see them as a dependency graph: each node is a task and each arrow points from a task to the one that depends on it. The layout is computed automatically, so you can read the execution order top to bottom. You can draw a connection between two nodes to add a dependency.

A task can only start when every task it depends on has reached Done. On the Kanban board a blocked task shows a “Blocked by” banner, and trying to move it before its upstream tasks are done prompts you to resolve the dependencies first. The task panel lists both Depends on and Blocked by this so you can trace the chain in either direction.

The DAG view lays out dependencies so you can read the execution order.

Follow the status path

A task moves through a fixed sequence. You can drag cards between Kanban columns, or the assignee can advance the status from the task panel:

Status	What it means	What moves it forward
Open	Created from the proposal, not yet taken.	Someone claims it or you assign it.
Assigned	It has an owner but work has not begun.	The assignee starts work (requires all dependencies done).
In Progress	Being worked on now.	The assignee submits it for review.
To Verify	Work is done and awaiting your verification.	You verify it — see Verify and complete.
Done	Verified and accepted.	Nothing — it may now unblock dependent tasks.

Only reaching Done unblocks downstream tasks; a task sitting in To Verify does not. That is why verifying promptly keeps the graph flowing.

What the agent does

Once a task is assigned to an agent and its dependencies are met, the agent claims it, moves it to In Progress, does the work, posts a work report with the evidence, and submits it to To Verify. You watch the status and the reports; the agent does the building. For how an agent connects and runs work on your project, see the agent platforms reference.

Submit safely from an agent

Keep the task in_progress while preparing the handoff:

1. Post the completion evidence with chorus_report_work, without a status field.
2. Record each acceptance criterion with chorus_report_criteria_self_check; finish the work needed for every required criterion to pass.
3. Read this task with chorus_get_task and confirm it is still in_progress.
4. Call chorus_submit_for_verify explicitly, with the summary. This is the in_progress → to_verify transition; the caller must own the assignment.
5. Leave independent review and admin verification to the responsible reviewer or parent agent.

Do not first send status: "to_verify" through chorus_report_work or chorus_update_task: those can change status, but a subsequent explicit submit fails. If the task is already legitimately awaiting review, leave it there. If it was moved prematurely, the assignee can return it to in_progress with chorus_update_task, subject to dependency checks. This clears both developer and admin acceptance marks and evidence: redo the self-check, read the task again, then submit. See Pi for its optional readback gate.

Next

When a task reaches To Verify, continue to Verify and complete to check its acceptance criteria and accept the work.