Refusals are prompts, not errors

In a project management tool, a state change is a record of work that already happened, typed in afterwards by a person. Dragging a card into Done cannot fail. There is no mechanism by which the system can disagree with the person doing the dragging — and because the action cannot fail, its success tells you nothing.

That is tolerable while a human is the one doing the dragging, because the human read the diff. It stops being tolerable the moment an agent is closing work.

Completion as a predicate

Commission’s done is not a status write. It is a predicate evaluated at the moment of closing: are this task’s children closed, are its acceptance criteria ticked, and does it carry the evidence its gate requires? If any of those is false, the transition is refused and the task stays exactly where it was.

A gate is a named list of evidence kinds — a pull request, a test run, a commit, a benchmark, a rollback plan — declared per project as data rather than as a process document somebody is supposed to remember. Evidence is a recorded, referenceable fact that the condition is met. Gate is the requirement; evidence is the satisfaction; the two words are never used for each other.

So “done” in Commission means something specific: a checked fact, backed by evidence, rather than an assertion by whoever was working last.

The refusal is the interface

Here is the part that took the longest to get right. A refusal is not an error message. It is the next prompt.

Every refusal states three things: what was attempted, what is missing — as a list, itemised, not a summary — and the exact command that supplies it. It exits with code 2, which is distinct from code 1, because “you cannot do that yet” and “something broke” require different responses from the caller.

That shape exists because the reader is usually a machine. An agent that receives a paragraph of prose about acceptance criteria has to infer an action. An agent that receives a missing list and a command runs the command. The same refusal crosses every transport unchanged: exit code 2 on the CLI, 422 with the same body over HTTP, and isError with the same text over MCP. There is one core, so there is one refusal.

Overrides, on purpose

Commission’s gates can be forced past. --force exists, requires a stated reason, and the override is recorded in the event log and surfaces in the standup.

This is not a lapse in rigour. A system that cannot be overridden gets worked around invisibly — in a side channel, in a spreadsheet, in a status document nobody reconciles. A system that makes overrides expensive and legible gets overridden rarely and traceably. The instruction Commission gives agents is explicit: do not force unless a human asked.

Why it matters more as agents get better

The strongest objection to all of this is that a disciplined engineer with a good tracker and a good agent already gets most of the value, and for one human with one agent that is close to correct.

It breaks at the point where an agent that believes it finished moves the ticket to Done, and the ticket is now Done. If you are letting agents close work, the only question that matters is whether “done” is a claim or a checked fact.

The better agents get, the more of them run at once, and the more of the work no human read line by line. Both of those increase the need for evidence-backed completion. Capability raises the value of coordination; it does not substitute for it.

---

The refusal object, the exit codes, and what done evaluates are documented on the technical page, alongside the CLI, the MCP server, and the /v1 HTTP API. Every terminal block there is captured from a real run.

Vocabulary and claims in this post come from docs/positioning.md.