Kanban, queue and relations

A project’s tasks can be seen as a list or as a Kanban board, and both share one order: the project’s work queue. Agents use that same queue to know what to pick up next.

Kanban by status

In a project’s Tasks tab, switch between List and Kanban. The board has one column per status, in the order of your status catalog (Settings → Task statuses).

• Drag a card to another column to change its status. Moving it to a “done” status dates it as completed and takes it out of the queue.
• Drag inside a column to reorder it. That order is the queue order (queuePosition): there is no separate “manual order” for the board.
• Filters (status, priority, environment, version, assignee, tag and text) apply to the board as well as the list.
• Archived tasks and ideas never show up on the board.

The work queue: In progress → Next → Later

The project page and My tasks show three sections:

Section	What’s in it
In progress	Tasks in an animated status (“Working”): someone, or an agent, is on them right now
Next	The first task in the queue that isn’t blocked: highlighted, it’s what gets picked up next
Later	The rest of the queue, in order (blocked tasks included, marked with who blocks them)

Rules:

• queuePosition is the only source of order (queue and Kanban). 1 is the first.
• Only unfinished tasks are queued. Finishing or archiving a task takes it out; ideas and loose tasks (without a project) can’t be queued.
• A task blocked by an unfinished task is never “Next”: the next unblocked one is.
• Reorder by dragging in the web app, or from the terminal:

fxc tasks queue <taskId>                     # at the end
fxc tasks queue <taskId> --first
fxc tasks queue <taskId> --after <otherId>
fxc tasks queue --remove <taskId>
fxc tasks queue --project-id <projectId>     # show In progress / Next / Later
fxc tasks next --project-id <projectId>      # the task to pick up now (--mine: assigned to me or unassigned)

The agent loop

1. Take the task from fxc tasks next --project-id <id> (MCP: next_task).
2. Move it to “Working”, work on it, and close it with fxc tasks finish <id>.
3. Ask again with fxc tasks next. If the queue is empty, stop and say so.

Over MCP the same tools exist: next_task, queue_task and get_queue, in both the local and the remote server.

Relations between tasks

Type	Meaning
relates_to	Related (symmetric)
blocks / blocked_by	One can’t move until the other is done. blocked_by is stored as blocks read from the other side
duplicates / duplicated_by	One is a duplicate of the other (merging leaves this relation)

• Both tasks must belong to the same project.
• Creating the reverse of an existing block (B blocks A when A already blocks B) returns 409. Creating one that already exists returns it unchanged.
• A blocked task shows who blocks it in the list, on the board and in its detail, as long as the blocker is unfinished and not archived.

fxc tasks link-task <id> --blocked-by <otherId>
fxc tasks link-task <id> --relates-to <otherId>
fxc tasks relations <id>
fxc tasks unlink-task <id> --blocked-by <otherId>     # or --relation <relationId>

In the web app, relations are managed from the task detail. Over MCP: link_tasks and unlink_tasks; get_task returns relations, blockedBy, parent and subtasks.

Subtasks

A task can have a parent (parentId, same project). The parent shows its subtasks and each subtask shows its parent. Cycles are rejected (a task can’t be the parent of its own ancestor), and moving a task to another project drops its parent, its relations and its queue position.

fxc tasks create -t "Login form" --project-id <id> --parent-id <parentId>
fxc tasks list --parent-id <parentId>     # its subtasks (--parent-id none: top-level only)

Saved views

Save the filters you use (status, priority, environment, version, assignee, tag, text) along with the grouping and the layout (list or Kanban) under a name. Views are personal and per project: nobody else sees or edits yours. API: GET|POST /tasks/views, PUT|DELETE /tasks/views/:viewId.

Bulk operations and merging duplicates

Select several tasks in the list (or on the board) to change their status, priority, assignee, environment, version or tags, archive them, or merge them.

fxc tasks update --ids a,b,c --status Working --priority Alta --add-tag sprint-3 --remove-tag backlog
fxc tasks archive <id> <id> …      # archived tasks leave lists, progress and the MCP
fxc tasks unarchive <id>
fxc tasks list --archived          # only archived (--archived all: everything)
fxc tasks merge <targetId> <sourceId> <sourceId> …

Merging moves comments, attachments, links, linked notes, linked client requests, subtasks and relations from the sources to the target, merges their tags, archives the sources and leaves a “duplicate of” relation. All tasks must belong to the same project.

Requests linked to an existing task

A client request that matches work you already have doesn’t need a new task: link it. It becomes “Accepted” and closes by itself when the task is finished, just like a converted one.

fxc requests link <requestId> --task <taskId>

From the web app, use Link to task on the request; over MCP, link_request.

API

Endpoint	What it does
GET /tasks?archived=true|all&assignee=&changelogId=&parentId=	Filters (plus priority, environment, version, status, tags, search)
PATCH /tasks/bulk	{ ids, taskStatusId?, priorityId?, assignedUserId?, assignedPersonId?, environment?, version?, changelogId?, addTags?, removeTags?, archived? }
POST /tasks/:id/merge	{ fromIds }
GET / POST /tasks/:id/relations	{ type, taskId }
DELETE /tasks/:id/relations/:relationId	Or ?type=blocks&taskId=<other>
POST / DELETE /tasks/:id/queue	{ after? } or { position: "first" | "last" }
GET /tasks/queue?projectId=	{ inProgress, next, later }
GET /tasks/next?projectId=&mine=1	{ task, inProgress, queued, blocked } (task: null = empty queue)
POST /client-requests/:id/link	{ taskId }