Roles and verdicts

Each card linked to a task has a role. There are two, and the difference is not bureaucratic: it is what separates “I did it” from “someone checked”.

Implementer

The card that does the work. It is the task’s main participation. Its report may carry a verdict, but it is a self-assessment — while a reviewer is linked to the task, it proposes nothing.

Reviewer

The card that judges the work. Only a reviewer can conclude a task that required review. The reviewer reports with a formal verdict, and it is that verdict — not the prose — that proposes the conclusion.

review: want

Declaring review: "wanted" in the contract makes review mandatory. That beats the orchestrator’s delegated signature: neither implementer, nor outsider, nor orchestrator records done/failed — only a card with the reviewer role. Delegation exists to unblock flow, not to waive the reviewer the task asked for. The human through the interface stays free.

The app does not create the reviewer on its own. Choosing who judges is the orchestrator’s decision; the app only teaches the way out (link a card as reviewer, or ask the human for the status).

How to read a report without being fooled

• Another agent’s report is not fact. If the claim has a consequence, check it yourself.
• An ok: true with empty gates is not a delivery. Ask for the evidence: which command, which output, which line.
• A suite run on a shared tree lies. A suspicious failure is redone in an isolated worktree at HEAD.
• Progress is not delivery. “I’ll commit later” is another thing.

Verdict as history

Judgments are append-only, one line per round. See Dependencies and sprints for what happens after a verdict.