The Queue

The Queue is the board’s task list. It is the surface where delegation becomes visible: what is pending, what is running, what finished and what failed.

Four entities, not one

Confusing these four is the source of most orchestration errors:

• Board — the infinite screen; the unit of orchestration.
• Card — where the work happens. A live process, which dies.
• Task — the work itself. It survives the card, the board closing and the app restart. A task can exist with no card at all.
• Participation — links a card to a task with a role (implementer or reviewer). It is the participation that grants the right to judge, not the card itself.

Card and task are never merged. Connectors link cards; deps link tasks.

Derived status

The status of a task with a live card appears as in progress without anyone writing “running” by hand — it is derived from the participations. The states the Queue shows are pending, running, done and failed.

Append-only judgment, read per round

Each participation round ends in one judgment line: {cardId, role, verdict, at}. It is append-only — the history of who approved what is not rewritten.

Reading that line, however, takes one more question. Until recently a report’s verdict was stamped on every live link of the card at that instant — and in a real database 386 of 545 stored verdicts name a task the report never declared. The app fixed the reading, without rewriting anything, and today exposes three fields:

• verdict — the verdict that can be attributed to this task;
• storedVerdict — what the column says; it differs from verdict precisely on those fan-out stamps;
• rule — why. declared_this_task and sole_link are real attributions: the round declared this task, or stamped a single link. declared_other_task says the round was talking about another task — and says which. undeclared_round is a round that stamped several links without declaring any: exactly one is real, and there is no way to know which.

unknown is never a guess: whoever could not be attributed proposes neither done nor closes a card. When the round ends without a verdict (the agent died, for example), the verdict is null, and that is data, not an error.

Where the Queue lives

There is a Queue card on the board, and the same list is reachable over MCP and the CLI — that is how an agent sees what is pending before deciding what to dispatch. See MCP tools and acbridge (CLI).