🌓

Kanban Workflow

MultiTerminal's task board is a two-level state machine: tasks move through three statuses, and each checklist item runs its own coding/testing cycle. This page describes the lifecycle exactly as it ships — the rules the app and its MCP tools actually enforce.

Task Status & Sub-Status

Every task has a top-level Status with one of three values:

Status	Meaning
todo	Created but not started. The default for a new task.
in_progress	Being worked on.
done	Complete.

While a task is in_progress it also carries a SubStatus of either active (the task you are working on right now) or paused (started but set aside). A task can be claimed by an assignee — the identity that owns it — and records who created it.

Tasks can also be linked to one another with relationships of type blocks, depends_on, or related_to, and carry a priority of urgent, normal (default), or low that influences whether claiming a task interrupts your current work or queues behind it.

AutoStatus is a per-task flag you toggle from the Auto-status checkbox in a task's detail popover on the lifecycle board (it is saved on the task). While it is enabled, the task's top-level status is derived automatically from where its checklist items sit: all items still pending → todo; any item in coding or testing → in_progress; all items done → done. Turning AutoStatus off lets you set the status by hand.

The One-Active-Task Rule

An assignee may have only one active task at a time. Setting a task active (via set_task_active) automatically pauses every other active task held by the same assignee and returns the list of what it paused. This keeps a single, unambiguous answer to “what are you working on right now?” — which is exactly what the auto-cd and worktree features rely on.

Priority interacts with this rule when you claim a task: a normal or low priority task claimed while you already have active work is queued behind it rather than interrupting; the claim result reports that it was queued and what it is queued behind.

The Checklist State Machine

A task's real work happens in its checklist. Each item is more than a checkbox — it has its own status and a trail of transition notes. The valid item statuses are:

Item status	Meaning
pending	Not started.
coding	Being implemented.
testing	Implementation complete, awaiting verification.
done	Verified and finished.

The transition tool (update_task_checklist) enforces the state machine: pending → coding → testing → done, with cycling allowed between coding and testing when testing turns up something to fix. Notes are mandatory on the coding→testing, testing→coding, and testing→done transitions — you must say what you did or what needs fixing.

Every transition appends a note to the item's history recording who made it, when, the transition (e.g. “coding → testing”), and the text. The item also tracks a CycleCount that increments each time it bounces from testing back to coding; once it reaches four or more, that testing→coding bounce posts an escalation notification to the Inbox so a stuck item gets attention instead of looping silently.

Who Marks an Item Done

The coder drives an item up to testing with a note describing what was built. By team convention the testing→done transition is reserved for the PM / tester — the person verifying the work — not the coder who wrote it. This separation is the quality gate: the implementer says “ready for verification,” and someone else confirms it actually works before the item is closed. (The state machine permits the transition with a note; the “only the tester closes it” rule is the workflow discipline layered on top.)

Working solo? You play both roles — coder and tester — on the same task. Nothing stops you moving testing→done yourself, but the gate is only as honest as you make it: actually verify the work before you close the item rather than rubber-stamping your own code.

Plans & Continuation Notes

Two free-text fields keep a task self-documenting across sessions:

• Plan — a markdown field describing the approach and steps. Write it before you start coding so the checklist has a rationale behind it.
• Continuation notes — a short “pick up here” field for session handoffs. It captures the current file, checklist progress, what's next, and any blockers, and is read back when a later session resumes the task. It is updated as checklist items transition and at session end, so the next agent (or the next you) lands with context instead of a cold start.

Tasks additionally support an implementation summary and test-results field used when a task is completed, plus structured review notes written by a human reviewer from the diff viewer.

Helpers

A task's assignee can pull in helpers — other agents (often spawned sub-agents) added to the task to work alongside the assignee. Helpers are notified when added and can receive help requests from the assignee. Individual checklist items can also be assigned to a specific agent, so a helper owns just the items relevant to them while the assignee keeps the task as a whole.

File Traceability

As work touches the codebase, link the files to the task with link_task_file. Each link records the file path, an optional description and line range, and who added it. Links can be task-scoped (the default, applying to the whole task) or scoped to a single checklist item, which drives per-item routing of review notes. The result is a durable record of exactly which files a task changed — useful for review, for the next session, and for tracing why a file changed months later.

A Task, End to End

Putting the pieces together, the shipped lifecycle of a typical task looks like this:

1. Create a task (todo) with a title and description.
2. Claim it so it has an assignee — claiming before working is the rule that keeps ownership clear.
3. Set it active, which pauses any other active task you hold.
4. Plan the approach and add checklist items (all pending).
5. Code each item: pending → coding, then coding → testing with a note. Link the files you touched.
6. Test: the tester/PM verifies and moves testing → done, or sends it back to coding with a note for a fix (incrementing the cycle count).
7. When all items are done, the task reaches done — automatically under AutoStatus, or by hand otherwise.

Throughout, continuation notes and linked files keep the task readable to whoever picks it up next. For where this board fits in the bigger picture, see Getting Started; for the tools agents use to drive it, see the MCP Tools reference.