Tasks & Kanban

Tasks are the unit of work in RoboCo — nothing happens without one. The panel gives you three views of them, two of them living on one page: the Tasks page (/tasks) opens on a List | Kanban tab pair — List for searching and filtering everything in a table, Kanban for a pipeline-style board of where work is in flight — and the Task Detail page (/tasks/[id]) for the full state of one task plus your god-mode overrides.

The Tasks table (/tasks)

The master list of every task. It gives you full-text search and multi-select filters across status, team, task type, project, and product, with sortable, paginated, expandable rows. All of that filter/sort/page state lives in the URL query string, so a filtered view is shareable and survives the back button. Expanding or collapsing a row is one of those URL-tracked bits of state, but it's excluded from scroll restoration specifically — toggling a row keeps you exactly where you were on the page instead of bouncing you back to the top.

The Create Task dialog lets you author a task by hand — title, acceptance criteria, project/product, type, and an optional Budget (USD) cap (see Task & project cost budgets; a 0 is rejected, it would silently block everything). If you'd rather describe a rough idea and have an agent read your code and draft a properly-formed task with acceptance criteria, use the conversational Task Assistant at /prompter instead.

Task Detail (/tasks/[id])

The heaviest operator surface in the panel. The header carries the task's metadata; the body is tabbed (notes, commits, acceptance criteria, and more).

Getting around a task

A parent-task breadcrumb sits above the title whenever a task has one — click through to the parent, or follow the chain up one hop at a time. Next to it, prev/next buttons (with Alt+ArrowLeft / Alt+ArrowRight shortcuts) step through the current task's neighbors in whatever order you last saw them in the Tasks list — filtered and sorted the way you left it. Opening a task straight from a link, search result, or notification carries no such order, so both buttons render disabled with a tooltip explaining why rather than guessing.

The tab bar below the header highlights the active tab and persists your selected tab in the URL query string, so a shared task link or the back button returns you to the same tab.

Collapsible sections

Description, per-role Notes, Plan, Progress, and Acceptance Criteria each live in their own independently collapsible card, so a task with a long history doesn't force continuous scrolling to reach the part you actually want. A section starts collapsed or open based on how much is in it — long progress/checkpoint history and long criteria lists default closed, short ones stay open — so nothing you'd normally see at a glance disappears, only the sections that would otherwise dominate the page. Progress updates and notes each show an inline absolute timestamp next to the relative one ("3 hours ago"), falling back to the task's creation time when an entry carries none of its own.

Clickable branch and PR

When a task has a branch or a pull request, the git badges are live links into your repository's web host — the branch jumps to …/tree/<branch> and the PR to …/pull/<n>, derived from the project's git URL. If the URL can't be parsed into a web link, it falls back to a plain label rather than a broken link, so you always see something useful.

Per-role note sections

The Notes tab carries a separate, editable section for each role that touches a task, so the handoff trail is structured rather than a single free-text blob:

Empty sections still render so you can see what's expected — and add a note yourself if you need to. Each written section also shows a written-at timestamp next to its heading, so you can read the hand-off trail in order.

The bounced chip

A task the header shows with an amber bounced xN chip (hover for the count and what it means) has been sent back to needs_revision N times — by QA, the PR-review gate, a PM, or you. It's hidden entirely on a task that's never bounced, so its absence is itself a signal. Click through to the Findings tab below for what specifically drove each round.

Findings and Collision tabs

Two tabs round out the task detail page, alongside Overview, Plan, Progress, Commits, Notes, and Deps:

• Findings — the revision-findings ledger: every structured finding a QA fail, a PR-gate fail, a PM request_changes, or a CEO rejection recorded against this task. Findings are grouped into one collapsible section per review round — the newest round starts expanded, older rounds start collapsed — each carrying a badge for who raised it (QA / PR Review / PM / CEO) and a count of how many findings in that round are still open. Each finding card shows its severity and status (open / addressed / verified / waived, each with an explanatory tooltip), the expected-vs-actual text, the suggested fix, and — collapsed by default — the reviewer's raw evidence. When file is a real repo-relative path, the card also shows an inline code snippet of the surrounding lines pulled live from that file at the task's branch; the handful of legacy findings whose file field carries prose instead (a PR reference, from before the shape was enforced server-side) render their metadata plainly rather than attempting a doomed fetch. A row of per-origin summary badges (e.g. "QA: 1 open · 3 closed") sits above the rounds. An empty task just says no findings have been recorded yet.
• Collision — the sibling collision surface: this task's own declared file globs / migration flag / shared-surface flag, plus every same-parent sibling whose declared surface overlaps it — status, branch, PR number, and sequence badges per sibling, with the overlapping globs highlighted. A sibling that actually touched files it never declared shows a drift callout. Root and standalone tasks (no parent) render an explicit "no collision map" state instead, since they have no siblings to collide with.

See the company's review-and-quality machinery for how findings get raised in the first place, and Sequence ordering below for what the collision map's sequencing badges mean.

CEO god-mode

The lifecycle is normally enforced role-by-role at the gateway, but you are the CEO and can override any of it from this page. The action set covers the whole lifecycle: claim, start, pause, resume, block, unblock, verify, submit-qa, pass-qa / fail-qa, docs-complete, submit-pm-review, approve-and-merge, escalate-to-ceo, ceo-approve / ceo-reject, and cancel. You can also run git directly — create a branch, create a PR, merge a PR — and those operations are performed as agent id ceo.

This page also exposes Approve & Start for a board-reviewed pending task and Re-draft with board feedback, which routes back to the Task Assistant (/prompter?redraft=) — including for a MegaTask's branchless umbrella, which recovers its multi-repo scope from its live root-subtasks. See MegaTask for the full redraft loop.

See the task lifecycle for what each transition means and the merge model for how PRs flow up to master.

The Kanban tab

Switch the Tasks page to its Kanban tab (?tab=kanban) for a swim-lane board of the delivery pipeline, switched with the ?view= query param into four boards:

Each board is a read-at-a-glance view of where work sits in the lifecycle. Switching the top-level List/Kanban tab, or a kanban sub-tab, updates the URL, so a specific board is shareable — and every filter you set on the List tab (search, status, team, task type, project, product) carries straight over to Kanban and back, since both tabs read and write the same URL-driven filter state. Kanban's own team picker is single-select, unlike the List tab's multi-select: when the List tab has exactly one team selected, Kanban's dropdown reflects it; zero or several selected teams show as "All Teams" there instead. Drag-and-drop and the mobile single-column board layout are unchanged.

Project and product progress signals

v0.25.0 adds read-only progress signals to the tables you scan while triaging work, so you can spot a blocked or overloaded repo without opening it.

Project table task counts

The Projects table carries a Tasks column on each row: a status dot followed by done / active / blocked counts for that project's tasks. The dot mirrors the same three numbers — a row with active or blocked work shows an at-risk signal, while a row that's entirely done reads clean. This is a quick health read; click the project name to open its full task list.

Product table cell mappings

The Products table maps each delivery cell to the project it builds for that product. Each row shows its cell-to-project assignments in the Cells column; a cell with no project assigned reads Unmapped. The Progress column rolls up the same done / active / blocked counts across every mapped project, using the same at-risk status dot as the Projects table, so a multi-repo product surfaces its health in one glance.

CI-watch badge

When a project has opted into multi-repo CI-watch, its row in the Projects table shows a CI-Watch badge under the project name. The badge means the project's default-branch CI is being watched and a fix task will be opened automatically if it goes red. It is an opt-in indicator, not a real-time CI status light.

For registering projects, editing the CI-watch opt-in, and setting the monitored workflow file, see Workstation.

Sequence ordering

A PM can stamp sibling subtasks with a sequence number — lower runs first, ties run in parallel — and it's a hard rule, not a suggestion: a lower-sequence sibling has to reach a terminal state before a higher-sequence one can be claimed, whether or not any dependency edge connects them. What you'll actually see on a board: a task that's technically pending (or back in needs_revision) but not yet claimable sits waiting in its lane while an earlier-sequence sibling is still in flight, and a claim attempt on it fails naming the sibling that's holding it — "<title>" (sequence N). This is the same mechanism a MegaTask uses to pace its collision-derived waves (see MegaTask), applied generally to any parent's subtasks.

Next

→ Agents & work sessions to see who's working these tasks, or Git to inspect the branches and PRs they produce.

llms.txt