The pipeline
The rule at every stage: a step that didn't happen is not a pass.
Most AI adoption bolts agents onto the side of delivery. A chat produces a diff, and a person squeezes it into the old process. Graphban runs the stages on the board instead, so every piece of AI-built work takes the same path, and each stage leaves evidence a person can read.
1 · Spec
A PRD is graded on four dimensions by the grill, and approval is earned by answering what it asks. It is never a status anyone sets. The approved version is frozen, and every card says which section of it the card implements.
Changing an approved spec is a rebaseline: a new version linked to the old one, so the work already built against the old version is never quietly re-pointed. Spec to done, in full →
2 · Plan
The spec is decomposed into cards with declared touchpoints. Cards that touch the same parts of the code are clustered, so two agents are never handed the same files.
3 · Build
The local supervisor cuts a git worktree for each child from the fetched base branch, not from whatever happens to be checked out, and starts the agent your tier resolved to.
4 · Review
A builder moves its card to review and stops there. Sign-off takes a reviewer who did not build it, either another agent or a person, enforced at two separate gates keyed on authorship, so promoting the builder to reviewer doesn't launder it.
5 · Verify
Your CI posts its result to the card as an attestation tied to a commit. A green run on some other commit isn't evidence for this one, and a sign-off may not attest the commit its branch was cut from.
An acceptance clause nobody tested, a CI job that was skipped and a spec section with no delivery each get their own name. None of them is allowed to read as green.
6 · Ship
When a card reaches review, the fleet supervisor pushes its branch and opens a draft PR, so a reviewer always has something to read. One card per branch, one card per PR.
7 · Observe
A map of the running system derived from the code: what you write, what you run, and the external services you depend on. Code health is drawn on top. More →
Who holds which card right now, what each agent is calling, and a searchable history of every event.
Tokens and model usage across the deployment, so the cost of AI-built work is a number, not a guess.
Send Graphban's logs to the observability stack you already run, with counters for what was exported.
And the loop closes. Customer feedback arrives through the Feedback Kit (public boards, votes, a roadmap and an ingest API) and becomes cards. Lessons mined from finished work are reviewed, published, and handed to every agent on the next wave. The learning loop →
Why every stage is a gate
No spec, so there's no drift to measure. No review, so nothing gets rejected. No check, so it's green. Each silence reads as approval, and they compound.
The longer argument is in the bug that started it and why a folder of Markdown specs says yes to everything.
Fits the stack you have
| Your tool | What Graphban does with it | Status |
|---|---|---|
| Claude Code, Cursor, Codex | Connect over MCP and work the board interactively | shipped |
| Seven fleet harnesses | Run unattended in waves, one worktree each | shipped |
| GitHub issues | Arrive as cards (HMAC webhook, routed by repo) | shipped |
| GitHub branches and PRs | Published at review; opt-in auto-merge after sign-off | shipped |
| GitHub Actions | Attests suite results to the card, per commit | shipped |
| Your observability stack | OTLP log export | shipped |
| A Markdown folder or Google Drive | PRD ↔ folder sync, no OAuth | shipped |
| Linear | Mirror in, constrained write-back | in progress adapter built, not yet connectable |
| Jira | The same bridge | planned after Linear |
Everything else is on the status table.