SPEC accountability protocol

Your AI agent can't close its own work.

An open-source accountability queue for AI coding agents. The agent that does the work can't close it — a second agent verifies it against ground truth first.

works with Claude Code · Cursor · any MCP agent — Postgres + MCP server · MIT

DOER agent · claimer VERIFIER 2nd actor mark done → CLOSED ✓ verified vs. reality close self-close REFUSED verify refuses when verifier == claimer
01 the problem

AI agents will happily do 80% of a task, declare victory, and quietly break something else on the way out.

Coretexa is the queue that catches it.

BEAT 01

It finishes 80% and says done.

The last, hard 20% — edge cases, cleanup, the thing that actually mattered — gets rounded up to "complete" and handed back.

BEAT 02

It broke something adjacent.

The change that passed its own test quietly regressed a file three directories over. Nobody looked, because the agent said it was fine.

BEAT 03

The doer graded itself.

The thing that did the work is the thing that decided the work was good. That's not review — that's a rubber stamp with extra steps.

02 how it works — the lifecycle

A ticket moves through states. It cannot skip the one that matters.

pending → claimed → done → verified → closed, with a blocked branch. A token travels the happy path; the self-close attempt forks and is rejected.

FIG-02 · TICKET LIFECYCLE · statuses = {pending, claimed, done, verified, closed, blocked}
happy path — one ticket, five states pendingqueued claimedactor A doneA marks verifiedactor B closed ✓settled blocked needs input actor A self-close → REFUSED by server 2nd actor verifies ✓
blocked needs input self-close REFUSED 2nd actor verifies ✓ pendingqueued claimedactor A doneA marks verifiedactor B closed ✓settled
pending / queued doer states (actor A) verify (actor B) closed / settled blocked / refused
03 the definition of done — five gates

A ticket isn't closed until it clears all five. Gate 5 is what makes the other four real.

GATE 1

Does what was asked

The requested behavior exists and works — not an approximation of it.

GATE 2

Broke nothing that worked

No adjacent regression. What passed before still passes.

GATE 3

Self-consistent

Internally coherent — names, types, contracts, and docs agree.

GATE 4

Actually finished

The full task — not the easy 80% with the hard part deferred.

GATE 5

A second set of eyes

A different actor confirmed gates 1–4 against reality. Not the doer.

04 the one hard rule

The doer may mark done. Only a different actor may close.

No-self-close isn't a code-review culture you hope people follow. It's an invariant. The server checks the actor id on every close, and refuses when the verifier is the same identity that claimed the ticket.

Enforced by the server, not by convention.

agent-A@session — verify attempt
# agent A claimed and finished ticket #204 agent-A ❯ coretexa verify --ticket 204 --actor agent-A ✗ REFUSED self_close_forbidden verifier (agent-A) == claimer (agent-A) ticket #204 stays in state: done # a different actor verifies against ground truth agent-B ❯ coretexa verify --ticket 204 --actor agent-B ✓ verified by agent-B · gates 1–5 pass ✓ closed #204 → state: closed
05 beyond tickets

Because lineage is data, the queue knows things a to-do list never could.

Regression auto-cut SYSTEM

Something that passed before now fails on verify. The system files a linked follow-up ticket and escalates its priority. The agent can't suppress it — the correction is the system's, not the doer's.

✗ verify #204 failed regression: auth.test ↳ auto-cut #231 origin=regression parent_id=204 · priority↑ high

Spawn depth SIGNATURE

Every ticket carries its parent. So you can measure how many generations of fix-broke-something a change took to settle. A deep lineage is a map straight to the fragile parts of your codebase.

g0 g1 g2 #204 · manual #217 · correction #231 · regression #244 · correction #245 · closed ✓

origin ∈ {manual, spawned, correction, regression} · linked by parent_id. This subtree settled in 3 generations — that's a fragile area worth a human's attention.

06 proof — run 100+ tickets deep

Not a framework looking for a user — a habit, extracted.

100
tickets run on real software
33
spawned by other tickets
75
verified by a second pass

Built by one developer who ran it 100+ tickets deep. 14 MCP tools; a 29-test suite runs the full lifecycle against in-memory Postgres.

07 quick start — three steps
  1. Load the schema

    Postgres owns the queue. One file, one command.

    psql < schema.sql
  2. Add the MCP server

    Register the server twice — once as the doer, once as the verifier. Two distinct actor ids is the whole point.

  3. Work, then verify — from a different session

    Run /work-queue to claim and do. Then /verify-queue from a second session to check and close.

~/project — coretexa setup
# 1 · create the queue in Postgres psql $DATABASE_URL < schema.sql CREATE TABLE tickets, lineage, actors … # 2 · register two actors in .mcp.json "coretexa-doer": { "actor": "agent-A" } "coretexa-verifier": { "actor": "agent-B" } # 3 · do the work, then verify elsewhere agent-A ❯ /work-queue # claim → done agent-B ❯ /verify-queue # verify → closed
08 open source

The protocol belongs to everyone.

MIT licensed. A Postgres schema and a reference MCP server that works with any MCP agent. Take it, run it, break it, send it back better.

★ Star on GitHub Read the protocol

early, solo, and MIT — PRs welcome (they go through the queue).