The pipeline
AI shouldn't go around your process. It should run it.
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
Work starts from a spec somebody actually finished.
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 server proposes the split. The planner commits it.
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.
- Allocation by tier and lane. A planner asks for cheap or frontier, backend or frontend. The resolver picks the harness and model, and records what it chose and why.
- Delegation is a bound seat. A delegated card goes to one child that claims it at registration and cannot drift onto anything else.
- Dependencies hold. A card whose dependency's PR is still unmerged waits, so work is never built on a base that doesn't exist yet.
3 · Build
One agent, one worktree, one branch.
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.
- Every child gets the same context. The repo's AGENTS.md and skills, the MCP servers the repo names, and the team's published lessons.
- It runs where your agents already run. Outposts are the machines that host fleets: macOS, Linux and Windows, set up from the app.
- The supervisor holds no authority. It can only launch a process on a seat the server issued, to do work the server arbitrates.
4 · Review
Somebody else looks, and brings evidence.
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.
- Evidence, not a thumbs-up. Non-trivial work needs adversarial evidence: a claim, the mutation that should break it, and how many tests failed when it did.
- The reviewer's own tests count. The builder's receipts don't stand in for them, and evidence that denies an acceptance clause blocks sign-off.
- Vendor diversity is recorded. The sign-off receipt says which vendor and model reviewed which, so you can see when a model checked its own family's work.
5 · Verify
CI attests the exact commit.
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.
A check that didn't run is not a pass
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
The branch is published at review. Merging is your call.
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.
- Opt-in auto-merge. Run a wave with --merge and, once a card is signed off and CI is green, the supervisor marks the PR ready and enables squash auto-merge. Without it, a person clicks merge.
- The server never touches git. It tells agents the delivery contract, meaning the base branch and whether they may push to it, or says that the process is unmeasured.
7 · Observe
See what's running, who is working on it, and what it cost.
Stack view
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 →
Live and Activity
Who holds which card right now, what each agent is calling, and a searchable history of every event.
Usage
Tokens and model usage across the deployment, so the cost of AI-built work is a number, not a guess.
OTLP log export
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
Without gates, an absence reads as a clean result.
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.
Rules shipped
The gates are a map, and an unloaded rule is not off.
Build → Rules draws the delivery process as one flow. Each rule says what holds it, and the drawing says how strong that hold is.
Six strengths, drawn apart
Enforced, checked, external, advisory, unmeasured, or not used. A rule the server refuses is not a rule CI reports, and neither of those is a rule nobody has measured.
No pack is not a clean off
library_loaded: false means no rule pack is loaded. It does not mean every rule is off, and it does not mean nothing was adopted.
An agent cannot flip the switch
Turning a rule on or off is a person's action over REST. get_rule_toggles will tell an agent the effective toggle and where it came from. There is no MCP write for it.
Fits the stack you have
Your tools stay. Graphban sits between them and the agents.
| 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.