One core, three machine interfaces

1. plan commission apply -f plan.json
2. dispatch commission next --claim
3. record commission note <id> -m "…"
4. prove commission evidence <id> pr=214 test=<url>
5. close commission done <id>

The whole loop. Every command takes --json, and exits 0 on success, 2 on a refusal.

$ commission readyready frontier (dispatch independent tasks in parallel):  checkout-1 · Verify Stripe webhook signatures  [open · p1 · gate:tier1]  ⚠ touches overlap: checkout-3  checkout-3 · Retry queue for failed captures  [open · p2 · gate:tier1]  ⚠ touches overlap: checkout-1  checkout-4 · Checkout summary page  [open · p2 · gate:tier1]suggested parallel batches (no touches overlap within a batch — dispatch batch 1 together, then 2):  1) checkout-1, checkout-4  2) checkout-3

Readiness and the touches overlaps are computed at query time. Nothing here was set by anyone.

$ commission claim checkout-1! checkout-1 is already claimed by agent:onehint: pick another with 'commission ready', or 'commission release checkout-1' if that claim is stale (lease expires 2026-07-27T21:40:25.657Z) $ commission next --claimclaimed checkout-3skipped: checkout-1 (claimed by agent:one)routing: agent:two is holding it; autonomy autonomous (default); no actors are declared, so nothing is restricted checkout-3 · Retry queue for failed captures  [open · p2 · gate:tier1]project: Checkout criteria:  [ ] 0. a failed capture retries with backoff gate 'tier1' requires: pr, test next:  commission start checkout-3  commission note checkout-3 -m "<progress>"

The second actor is not blocked by the first. It is told the task is taken, given the command that would release a stale claim, and moved on to the next workable thing.

Exit codes

0 ok

the command did what it said

1 error

something broke — a bug, a bad file, an unreachable database

2 refusal

the action is not permitted yet; the message says what is missing and how to fix it

3 not found

no such task, project, or binding

2 is deliberately distinct from 1, because "you cannot do that yet" and "something broke" require different responses from the caller.

The refusal object

error

refusal | not_found | error — the class of the failure

message

what was attempted and why it was declined, in one sentence

missing

the itemised list — criteria, evidence kinds, open children

hint

the exact command that supplies what is missing

done is a predicate

Completion is not a status write. It is evaluated at the moment of closing, and any one of these refuses the transition and leaves the task exactly where it was.

Open children

A parent cannot close over unfinished work. The refusal names each child.

Unchecked acceptance criteria

Criteria are ticked one at a time with commission check <id> <n>, and the refusal lists the ones still open by number.

Missing gate evidence

The task's gate profile names evidence kinds — pr, test, commit, benchmark, docs, rollback. Each missing kind is listed, and the hint is the commission evidence command that attaches it.

Outstanding human approval

Where a task is supervised, a recorded human approval is required and --force cannot override it.

Overrides are expensive and legible

--force exists and refuses without -m "<why>". The reason is written to the append-only event log and surfaces in the standup. Cancellation is held to the same rule: a reason, or the task that supersedes it.

A system that cannot be overridden gets worked around invisibly — in a side channel, in a spreadsheet, in a status document nobody reconciles. One that makes overrides expensive and legible gets overridden rarely and traceably.

Refusals are prompts, not errors — the argument at length →

The MCP surface is deliberately narrower than the CLI: it covers the working loop — claim, record, prove, close — and planning, not project administration or import.

Refusals come back in Commission's standard shape — message, missing, and the exact fixing command — marked isError, so a model can correct itself without a human in the loop.

$ commission standupstandup — Checkout (checkout) what to say (covers since Friday 7:00 AM):  Since Friday 7:00 AM we shipped Verify Stripe webhook signatures.  Next up: Idempotent order creation. done (since Friday 7:00 AM):  ✓ checkout-1 Verify Stripe webhook signatures  (just now)

A standup with nobody to attend it — derived from the same rows the agents were writing to all night.

$ commission log --last 102026-07-27 13:40 agent:one checkout-4 created: Checkout summary page2026-07-27 13:40 agent:one - project: {"action":"apply","created":4,"updated":0}2026-07-27 13:40 agent:one checkout-1 claim: {"via":"next"}2026-07-27 13:40 agent:two checkout-3 claim: {"via":"next"}2026-07-27 13:40 agent:one checkout-1 transition: open→in_progress2026-07-27 13:40 agent:one checkout-1 note: Constant-time compare — the naive === leaks timing. Rejected the stripe-node helper: it pulls the whole SDK for one function.2026-07-27 13:40 agent:one checkout-1 criteria: {"position":0,"text":"signature verified against the endpoint secret","done":true}2026-07-27 13:40 agent:one checkout-1 criteria: {"position":1,"text":"replayed events are rejected","done":true}2026-07-27 13:40 agent:one checkout-1 evidence: pr=214, test=https://ci.example.com/runs/88212026-07-27 13:40 agent:one checkout-1 transition: in_progress→donenext cursor: 15  (commission log --after 15)

History is appended, never rewritten. A status cannot be quietly corrected after the fact, because there is no place to correct it.

Recall, across sessions

The durable parts of a session are data attached to the task, not to the transcript: notes, criteria state, evidence with references, the dependency graph, and the events in between. A different actor arriving days later reads the decision the first one made and the evidence that closed it.

The honest limit: this is not a semantic memory system. There is no embedding store and no inference. Recall is full-text search plus graph traversal over what actors actually wrote down — its advantage is that the workflow makes writing things down the path of least resistance.

Five statuses, moved only by a transition

Nothing can write a status except a transition, so every state change is validated, attributed, and logged. There is no settable blocked status: blocked is derived from dependencies, and a status that can be set can be wrong.

Cancelling requires a reason or the task that supersedes it, because silent cancellation destroys the context the next session needs.

The storage engine is the boring part

One SQLite file in WAL mode. No server, no account, no daemon, and nothing to provision — the database is created on first use at ~/.commission/commission.db, or wherever COMMISSION_DB points.

The interesting parts are the invariants: readiness is derived so it cannot be stale, claiming is atomic so parallelism is safe, done is refusable so completion means something, and events are append-only so history cannot be rewritten.

Configuration is strict and explainable

.commission.json is versioned and validated against a strict schema: unknown keys are refused rather than ignored, because a typo that silently does nothing is the failure mode the file exists to prevent. A solo project's config is two keys — a version and a project slug.

Precedence — last wins

1. defaults
2. db
3. .commission.json
4. .commission.local.json
5. env
6. flags

commission config explain <key> prints the value, the layer that set it, and every layer it overrode. commission config validate exits 2 on an invalid file, which is what makes it usable in CI.

$ commission init checkout --name "Checkout" --gates '{"tier1":["pr","test"]}'created project checkout (Checkout)wrote .commission.json — bare 'commission next' now targets 'checkout' from this repoadd tasks: commission add "..." or commission apply -f plan.json

First run. Two keys in .commission.json, and every bare command in that repository targets the right project.

Environment

COMMISSION_ACTOR

who is acting — recorded on every event, claim, and note

COMMISSION_DB

the database file; defaults to ~/.commission/commission.db

COMMISSION_PROJECT

the project slug, overriding .commission.json

COMMISSION_CONFIG

an explicit config file, skipping discovery

COMMISSION_LEASE

claim lease duration, e.g. 8h

COMMISSION_TOKEN

bearer token required for mutations over HTTP

Commission contains no model, performs no inference, and writes no code. It is not an agent runtime and not a CI system: it never runs a test, it records that a test run happened and where to find it.