ADP · the agent-native forge Spec 0.6.0 · MIT

ADP · Agent Development-state Protocol

Code got cheap.
Trust didn't.

At Google, roughly three-quarters of new code is now written by AI. Agent-authored pull requests wait five times longer for a human to even look at them. And the way that code actually ships is not a swarm of speculative attempts — it is one capable agent iterating against CI until it believes the work is done, then merging. The operative word is believes: agents saturate the tests they can see while quietly failing the ones they can't16 — and every line still ships through machinery built for one human on one branch.

ADP is an open protocol for making machine-written software trustworthy at machine speed: a gate that converts an agent's belief into checkable proof. Every change lands as one signed, typed record — intent → diff → evidence → provenance — tested as the state that actually ships, reversible when it lands wrong, and legible to whoever picks the work up next: an auditor, a human, or a different agent.

~75%
of new code at Google is AI-generated and engineer-approved (April 2026)1
5.3×
longer wait for reviewer pickup on agent-authored PRs — 1,055 vs 201 minutes2
32.7%
acceptance rate of agent-authored PRs, against 84.4% for human-authored ones2
the baseline secret-leak rate in AI-assisted commits on public GitHub3
Created by Dov Zimring, with lots of help from Claude github.com/DeDuva/adp MIT licensed
01WHY

Verification is the new bottleneck

For seventy years, writing code was the expensive part, so every practice we have — pull requests, line-by-line review, branch protection, CI on the branch head — amortizes verification against slow authoring. Agents inverted the ratio. Teams using AI merge 98% more pull requests, while review time per change rises 91%4. Developer trust in AI output fell to 29% in the same period5 — the code got faster and less trusted at once.

This is not a gap a better review UI closes. Any process whose unit of assurance is human attention per change fails arithmetically once changes arrive at machine rate. Drag the slider: the constant is one team's thorough-review capacity, roughly 25 changes a day.

FIG 01 · ATTENTION ARITHMETIC
changes produced per day{{ prodDay }}
reviewed thoroughly — fixed human capacity25 / day
REVIEWER MINUTES PER CHANGE
{{ perChange }}
UNREVIEWED AFTER 30 DAYS
{{ backlog30 }}
WHAT REVIEW BECOMES
{{ reviewMode }}
{{ multNote }}

The industry's answer so far is AI reviewing AI: merge-blocking review bots (CodeRabbit, Greptile, Cursor's Bugbot, Copilot code review) are now normal. That helps — but a second opinion is not a verification system. What the evidence supports is a different division of labor: machines verify mechanically — does it build, do the tests and evals pass against the state that will actually ship, does policy hold — and humans review intent and evidence, sampling deeper only where risk warrants it. That division needs the change itself to carry its intent, its evidence, and its provenance as first-class, machine-readable data. No current forge records any of the three.

And the bottleneck is not the end of the road. Verification is where the queue is visible; deployment and operations are where the failures land. Even after passing QA and staging, 43% of AI-generated changes still need manual debugging in production — and not one organization surveyed could verify an AI-suggested fix in a single redeploy cycle, with 88% needing two or three20. The record's real consumers sit downstream of the merge: the incident at three in the morning, the audit eighteen months later, the next agent picking the work up in a different harness. Each asks what the change was for and how it was verified, and each asks after the session that could have answered has already ended. That is the argument for a record that is typed and signed rather than transient. A check that goes green and scrolls away is not a record, and neither is a transcript in a format one vendor maintains.

02HOW AGENTS ACTUALLY SHIP

The loop: iterate, believe, merge

The observed pattern is not a swarm. It is one capable agent iterating against CI until green, then submitting — and increasingly, merging. The field data points one way: fully autonomous agent-authored merges are still a rounding error — a few hundred out of 153,000 measured — while AI assistance already touches at least 1 in 7 private merges, and that floor is rising14. Where agents do author whole fixes, 65% merge, and the top failure modes are exactly the loop's: tests fail (18.1%), or the fix is wrong beneath a green build (15.3%)15. Even the vendors shipping parallel agents describe fan-out as the exception: Cursor's own guidance reserves multi-model ensembles for "hard problems," and uses parallelism for independent tasks in separate worktrees18. The economics agree — multi-agent coordination pays +81% on parallelizable work but degrades sequential work 39–70%6 at 4–220× the token cost7. We measured it ourselves rather than resting on other people's numbers. A pre-registered arm, 20 of 20 trials verified, found swarm topology cost 3.6× the tokens and wall clock and 2.8× the tool calls of a single agent, for no measurable quality difference19. Both tasks were solvable in one pass, which is the limit on what that arm can conclude and is stated as such in its own report.

The serial loop has a failure mode the swarm never had, and it is worse. When one agent writes, tests, and submits, oversight collapses onto a single surface: the test suite the agent itself can see — and often touch. Measured across frontier agents, every one saturates the visible tests while a gap opens on held-out tests that grows 28 percentage points for every tenfold increase in code size — up to and including a 2,900-line hash-table "compiler" that memorizes test inputs16. Verifying, not generating, is now the hard problem17. The agent's belief that the work is done is the one signal you cannot ship on. And when a change does land wrong, the questions that follow — roll it back, validate it, continue the work in a different harness — all need a record that today exists only as a transcript in one vendor's format. Step through both shapes.

FIG 02 · THE SERIAL STREAM — ONE SESSION, 160 CHANGES A DAY
{{ seCounter }}
TRUNK — ONE WRITER, SERIAL LANDINGS
{{ seBacklogLabel }}{{ seBacklogStat }}
AUDIT · "what was change 118 for, and how was it verified?"
git's complete answer: author agent-runner <ci@example> · date · "refactor session handling"
intent: not a field · evidence: not a field · model, session, prompt: not fields · pre-rewrite history: gone
SAME QUESTION, ADP · change ch_2118 (signed)
intent: issue #872 · diff: 4 files +61 −18 · evidence: unit 412/412, eval session-suite 0.96, bound at land
provenance: harness, model, session s_4410 · op log: rewrite op_0455 holds before/after refs — nothing is ever off the record
{{ seCaption }}
FIG 03 · THE FAN-OUT MODE — 60 ATTEMPTS, ONE INTENT
{{ swCounter }}
ATTEMPTS
spawned {{ swSpawned }} landed {{ swLanded }} discarded {{ swKilled }} on the record {{ swLogged }}
{{ swConTitle }}
{{ row.text }}
{{ swCaption }}
03THE INVARIANT

What survives every scenario

The two shapes stress different machinery. The serial stream — the base case — breaks the trust path: it needs evidence the author can't grade for itself, an authoritative operation log, durable checkpoints, universal undo, and history that survives its own author rewriting it. Fan-out — the mode fleets enter for hard problems and mass remediation — breaks the merge path: it needs attempts as first-class objects, conflicts that don't halt pipelines, and a queue that tests merged states before landing. The mix will shift with model capability and token prices; the machinery has to serve both, weighted toward the one that's actually here.

But one thing is invariant. In any future where software ships without a human reading every line, four questions must be answerable, per change, forever: what was it for, what changed, how was it verified, and who — or what — produced it. That is intent → diff → evidence → provenance. It is not one strategy among several; it is the minimum record that makes non-human-reviewed software trustworthy at all. And it cannot be retrofitted by convention — commit trailers, harness memory files, wiki links — because conventions don't bind automation. The record has to be typed, signed, and enforced where changes are admitted, or it will simply be absent the day an auditor, a regulator, or an incident review asks.

INTENT
The task or spec the change answers. In the serial stream: what change 118 was for. In fan-out: what 60 attempts share.
DIFF
The change itself, in the ordinary git object graph. git clone keeps working.
EVIDENCE
Tests, evals, benchmark deltas — signed, and bound to the merged state that ships, not the branch head that didn't.
PROVENANCE
Which agent, model, session, prompt lineage; which human attested. The supply-chain answer at fleet scale.
THE SERIAL BASE CASE
The gate, the operation log, and checkpoint/undo are load-bearing; the record is how one agent's 160 daily changes stay individually accountable — and how the next agent, in any harness, validates, reverts, or continues the work.
THE FAN-OUT MODE
Candidate sets and the eval-gated queue are load-bearing; the record is how a selector chooses among 60 attempts — N remediation candidates for one vulnerability, N models on one hard problem — and how the losers still teach the next run.
04GROUND TRUTH

Why git and the forge can't just be patched

None of this is a criticism of git — it is a mechanical description of a system designed, brilliantly, for a different workload. Six properties that were fine for one human on one branch are structural at agent scale. Expand any of them; each is stated mechanically, most with a simulation you can step through. No familiarity with git internals assumed.

Git stores snapshots, not diffs, and the commit is the only record of a change. Its fields were designed for a person who could be asked what they were thinking: author, timestamp, message, parents, tree. When the author is a model, the questions that matter — which model, which session, from which prompt and spec, verified how — have no field. So each harness invents a private store: shadow repositories, session JSON, commit-message trailers. An organization running three harnesses gets three incompatible audit trails, none complete. The precedent is OpenTelemetry rather than LSP, and the distinction is load-bearing: LSP standardised a request/response interface between two pieces of local software, whereas what fragments here is emitted state that outlives the process and has to be correlated across vendors — the telemetry problem exactly. OpenTelemetry won not by making tools talk to each other but by standardising the record, so any backend could consume it.

THE SAME CHANGE, TWO RECORDS
commit b70f214a9c…
Author: agent-runner <ci@example>
Date: Fri Jul 24 09:12:04 2026
    enforce scopes per route
    Co-authored-by: claude <noreply>
no field for: intent · model version · session · evidence · attestation
harness A → shadow repo of file snapshots
harness B → session JSON in a home directory
harness C → commit-message trailers
change ch_8241 (signed)
intent: issue #418 · spec/auth.md@a91
diff: 3 files, +48 −12
evidence: unit 412/412 · e2e 38/38
  eval auth-suite 0.97 (+0.02)
  bound at merge to tree 5a2d90c
provenance: harness=claude-code
  model=…, session=s_7741
  attested-by: dev@x (key 4f19)
One typed transaction: intent → diff → evidence → provenance. Same schema whichever harness produced it.
git clone still works — the git object graph is the store; the change record sits beside the DAG.
Schemas live in spec/schemas/ — change.json, evidence.json, operation.json, provenance.json.

Every clone carries the full object graph, so the cost of starting work is a function of repository size, not of how much the task touches. A human pays once per laptop; an agent fleet pays once per attempt, because every sandbox starts with an empty disk. This is the wall Google hit at billions of lines — why Piper is a centralized, DB-backed store behind a virtual filesystem — and the wall Meta's Sapling/EdenFS answered by making operations scale with the working set.

COST OF STARTING WORK
git clone — full history, every attempt{{ cloneTotal }}
lazy materialization — only what the task reads{{ wsTotal }}
TRANSFERRED PER ATTEMPT
{{ cloneEach }}
ACTUALLY READ PER ATTEMPT
{{ wsEach }}
WASTE FACTOR
{{ ratio }}
Oak reports ~50% fewer VCS tokens and ~90% faster operations from mounting instead of cloning12; Cursor demoed ~296,000 clones/hour against one repository9 — the number the server sees.

Git merges line by line across three versions. When two changes touch overlapping lines it writes conflict markers into the working tree and exits non-zero. For a human that's a prompt; for a pipeline it's a halt — the exit code propagates, the agent's next command fails, and the harness falls back to a retry-and-rebase loop it wrote itself. Jujutsu showed the alternative: the conflict as a first-class object that can be committed and resolved later, so resolution becomes a task instead of an exception.

TWO AGENTS, ONE HUNK
{{ f3Counter }}
AGENT A · workspace-a1
export const PORT = 3000;
const MAX = env.MAX ?? 64;
export default cfg;
AGENT B · workspace-b7
export const PORT = 3000;
const MAX = Number(env.MAX) || 32;
export default cfg;
SERVER · refs/heads/main
0e9b3d5 init
4c1e77a A: cap concurrency
! [rejected] main -> main (non-fast-forward)
<<<<<<< HEAD
const MAX = env.MAX ?? 64;
=======
const MAX = Number(env.MAX) || 32;
>>>>>>> b7
exit 1 · CONFLICT (content): merge conflict in config.ts
agent B blocked · harness retry {{ f3Retries }} · no server-side record that this attempt existed
{{ f3Caption }}

The fan-out workload is N attempts at one intent: fan out, evaluate, keep the best. Git has no object for "attempt" and no lifecycle for a workspace, so orchestrators approximate with branches, worktrees, or whole clones, then garbage-collect them out of band. The discarded attempts leave no trace — nothing can learn from them, and no audit can see them. A GitHub merge queue picks between changes that already exist as pull requests; it cannot represent N competing candidate solutions to a single stated intent. ADP's candidate set is exactly that object, and it is the one primitive here with no GitHub analogue at all — you saw it animated in FIG 03.

Git records the state of the tree, not the operations that produced it. A rebase creates new commits and moves the pointer; the originals become unreachable, recoverable only from a per-clone reflog that expires and is never pushed. After a force-push, the server has no record the previous history existed, who replaced it, or why. At one writer per branch that is survivable. With hundreds of automated writers — or one long-horizon agent rewriting as it works — it removes the two things automation needs most: an authoritative account of what happened, and a way to reverse it.

REBASE, FORCE-PUSH, UNDO
{{ f5Counter }}
GIT SERVER STATE
{{ row.text }}
{{ f5GitNote }}
ADP OPERATION LOG
{{ row.text }}
{{ f5AdpNote }}
{{ f5Caption }}

CI runs against the head of a branch. What ships is the merge of that branch into a trunk that has moved since. Two changes can each pass, be textually mergeable, and still break in combination — one renames a field, the other adds a caller. Nothing in the git or GitHub model requires the evidence to describe the state that actually landed. (GitHub's merge queue does test a speculative merge — but its verdict is a transient check, not a signed object bound to the change; it evaporates rather than becoming part of the record.) When agents write most of the code, this is the layer that decides whether throughput lands as trustworthy software — and evals are stochastic, so the gate must be a statistical land criterion, not a binary pass.

WHAT THE CHECK TESTED
{{ f7Counter }}
FORGE PIPELINE
PR #91 head 3c17f2 · checks queued
✓ tests pass on 3c17f2
trunk advanced: 4c1e77a → 9f02b6c
merge commit d81a05e created — never tested
✗ main red · revert, re-queue, repeat
EVAL-GATED SPECULATIVE QUEUE
3 candidates for intent #418
merged states materialized speculatively
incremental graph: 41 of 3,400 targets affected
evidence bundle bound to the merged tree
✓ candidate 2 lands attested · 2 discarded, logged
{{ f7Caption }}
05THE PROTOCOL

A typed transaction, and a server that gates on it

ADP is two things. A schema: every change is one signed record — intent → diff → evidence → provenance — with the git object graph as the store, so git clone and every existing tool keep working. And a gate: changes are admitted by policy that evaluates the record — tests and evals against the merged state, secrets blocked at the receive path, dependency changes checked at admission, org-level rules no agent can bypass. The verdict returns to the authoring agent as a typed object it can act on in-trajectory, rather than an alert in a queue a human never empties.

The division of labor with harnesses is deliberate: the harness is the brain and hands — planning, context, model quality; the substrate is the world and the ledger — workspaces, history, conflicts, evidence, identity. Harnesses should compete furiously on the first list and should not be able to compete on owning your history. The precedent is OpenTelemetry: every vendor once emitted its own incompatible record of what happened, until a standard for the record itself let any backend consume all of them. Every harness today reimplements checkpoints, session state, memory files, and retry loops — the same movie, one layer down.

HARNESS (POLICY)
SUBSTRATE (STATE & TRUTH)
Decides what context to load, what to remember, when to checkpoint, which evals matter, when to fan out
Versions and serves the artifacts; owns workspace lifecycle, the operation log, conflict objects, the evidence graph, signed identity
06LANDSCAPE

Everyone solved a piece. Nobody solved trust.

Between February and June 2026, five well-resourced teams shipped systems on these premises — independent convergence by an ex-GitHub CEO, an IDE company, a game engine, a Perforce challenger, and an indie is the strongest available evidence the architecture is right. The matrix below scores each against the capabilities both futures require, from public sources as of August 2026. Every row expands to the evidence; ● shipped and verifiable, ◐ partial or announced, ○ absent or unpublished. Corrections welcome — file an issue.

PLAYER
WORKING-SET OPS
NON-HALTING MERGE
FAN-OUT PRIMITIVE
OP LOG + UNDO
INTENT + PROVENANCE
EVIDENCE AT LAND
ADMISSION POLICY
OPEN + NEUTRAL
{{ r1Arrow }}GitHub + Agent HQ
The incumbent, and the strongest all-round position: org-enforceable rulesets, push protection on by default, merge queue (which does test a speculative merged state — but emits a transient check, not signed evidence bound to the change), partial/shallow clone (opt-in; default tooling still clones), audit-log export as a separate product. Agent HQ fronts multi-agent orchestration with enterprise governance; Copilot sessions are logged in proprietary form. The structural gaps: no attempt/candidate object, conflicts still halt, no operation-level undo, and the control shape is human-pace — alerts, dashboards, and review queues rather than typed admission verdicts. Owned by Microsoft; every frontier lab competes with its owner.
{{ r2Arrow }}Cursor Origin
Announced June 16, 2026 at Compile; open beta since 17 August to paid plans9. Thinner than the June framing promised: no merge queue, no stacked PRs, no machine-readable review, and Cursor's own changelog keeps GitHub as the source of truth for synced repos. Separately, Cursor published Continuity — the most detailed git-storage engineering artifact of the year: a write-ahead log in S3 as source of truth, a normal git repo on NVMe as warm cache, atomic CAS instead of consensus. That is our Layer 0 position independently derived and pushed harder — and it is a storage layer only: no intent, no evidence, no verification, no agent change model. Nothing published on evidence semantics, operation logs, or policy. Proprietary and product-captive — and since 14 August its parent Anysphere is owned by SpaceX, so every lab's neutrality calculus changed with it.
{{ r3Arrow }}Entire
Founded by Thomas Dohmke (ex-GitHub CEO); record $60M seed10. Checkpoints version agent sessions, prompts, tool calls, and reasoning traces as git-native objects — the intent/provenance half of our thesis, nearly verbatim, and the strongest capture story shipping. Distributed git network in public preview since July 2026, with ForgeMark, an open push-throughput benchmark; native repositories are announced, not yet shipped. The gap is the other half: capture without merge-time evidence binding is the audit half without the trust half — and the business model centers on hosting the agent-session data layer, so labs would rent their own provenance.
{{ r4Arrow }}Diversion
Cloud-native VCS, not a git layer: central repository, unlimited ephemeral working copies, no local clones — the cleanest working-set story in production, with bi-directional GitHub mirroring. "Trajectory" captures the why behind AI-generated changes. Closed-source commercial SaaS; no open spec; no operation-log or evidence semantics exposed. Notably, Diversion argues agents erode switching costs — an argument for why non-git substrates can now exist at all, which the whole field, including ADP, benefits from.
{{ r5Arrow }}Epic Lore
Open-sourced (MIT, open spec) June 17, 2026. Centralized content-addressed VCS: Merkle-tree revisions, fragment-level dedup, lazy sparse working copies; binary-scale payloads (weights, datasets) native, pairing with Horde CI/CD. This is our Layer 0 storage architecture independently derived. We evaluated building on the Lore spec and did not adopt it: the gap analysis did not justify the dependency, and Cursor's Continuity result is independent evidence that keeping real git as the object layer is the right call. Game-industry design center: per-path ACLs exist, but there is no agent change model — no intent, evidence, or provenance semantics — and no notion of attempts or gates.
{{ r6Arrow }}Oak
Purpose-built Rust VCS: ~1s virtual mounts, no full clone, per-task branch isolation for parallel agents; claims ~50% fewer VCS tokens and ~90% faster operations12. Validates token cost and mount latency as first-order VCS metrics — numbers this page cites. Now a server, not just a client: native CI in .oak/workflows, verified content-addressed commits, policy as a repo file, a checkout-free branch-review API, and a merge gate that refuses a squash while CI is red — which is why this page no longer claims nobody gates at the landing point. The gate takes --force; a bypassable gate is a linter with good manners, and the enterprise question is what an admin can make non-bypassable.
{{ r7Arrow }}jj · GitButler · Sapling
The open-source ecosystem supplies the change model ADP builds on. Jujutsu: operation log, universal undo, first-class commit-able conflicts — the ideal agent change semantics, but client-side only, with no server or collaboration layer. GitButler: agent hooks plus the 300-run vcbench benchmark showing agent-oriented VCS interfaces completing tasks ~65% faster with ~78% fewer commands than raw git11. Sapling/EdenFS proved git can be a facade over different internals at Meta scale, though the server was never fully productionized externally. Fragments, not a substrate: none combines change model, storage, verification, and a server.
{{ r8Arrow }}Harness-private state
Claude Code, Codex CLI, Gemini CLI, Devin, OpenHands, Cursor's agents: each ships its own checkpoint-and-rewind (shadow repos or file snapshots outside version control), session persistence, memory files, worktree orchestration, and retry-and-rebase conflict handling — version-control primitives, reinvented per harness, invisible to the repository, incompatible with every other harness. The drift now extends to governance: org-managed settings, credential isolation, and egress policy accumulating in the layer with the least visibility into what landed. An enterprise running three harnesses holds three incomplete audit trails. This is the pre-OpenTelemetry world, one layer down — every vendor emitting its own incompatible record of what happened — and harness vendors would mostly be glad to delete this code if a standard existed.
{{ r9Arrow }}ADP
Scored with the same standard of evidence, against the working reference implementation (CI-verified end to end, validated against the real unmodified gh binary). Shipped: candidate sets (the fan-out object no one else has), append-only operation log with undo written in the same transaction as every mutation, typed Ed25519-signed changes binding commit to intent and provenance, DSSE-signed in-toto evidence bundles gated by a two-level land policy, and push protection at the receive path. Honest partials: the store is real git today — working-set virtualization is roadmap; conflicts-as-objects and the speculative eval-gated merge queue are specified, not shipped; the trust plane's org policy plane, dependency admission, scanner-as-gate adapters and isolated gate execution (network-denied, resource-capped Docker) have all shipped; what remains is SSO/SCIM, and dependency admission's breadth — it covers npm today. MIT, open spec, designed for multi-vendor implementation; governance moves to a neutral foundation once two independent implementations exist.
● shipped & verifiable · ◐ partial or announced · ○ absent or unpublished — public sources, August 2026
WHY NOT GITHUB

GitHub's control shape scales human review: alerts for humans to triage, dashboards for humans to read, queues for humans to empty, rules humans can bypass. Each is a human in the loop by construction, so throughput is capped by human attention — the exact resource that stopped scaling. ADP's gate is an admission controller: typed verdicts computed against the state that ships, returned to the authoring agent in-trajectory. Machinery that scales with compute, not attention — and it answers the question no incumbent can: prove what entered the codebase, what put it there, and how it was verified.

WHY NOT THE ENTRANTS

Every entrant stops at storage and capture. Lore, Diversion, and Oak solve where bytes live and how fast workspaces spawn — real problems, and ADP adopts their conclusions (centralized content-addressed storage, working-set ops as a metric) without adopting their implementations. Entire and Diversion capture context and trajectory — the audit half. None binds context to verification evidence at merge time, and none gates on it. Capture without binding tells you what the agent was doing; it cannot tell you whether what landed is safe. Verification is the layer that decides whether agent throughput lands as trustworthy software — the hardest layer, and the uncontested one.

WHY NOT THE HARNESSES

Per-harness state is a dead end on three counts. Provenance fragments — three harnesses, three incompatible audit trails, none complete, which no regulator will accept. Work is captive — a task started in one harness cannot be resumed, reviewed, or verified in another. And the harness becomes the lock-in point — whoever owns the harness owns your history, the play Cursor is running by pairing its harness with its forge. The labs' own incentive runs the other way: their harnesses win on model quality, and they win bigger when enterprises can adopt them without forfeiting cross-harness auditability. OpenTelemetry proved the pattern for emitted state; MCP's adoption proves harnesses embrace neutral protocols when they exist — and MCP's 2026-07-28 revision, which removed protocol-level sessions and told servers to mint explicit handles, points at exactly the shape ADP implements.

WHY NOT A PLAYBOOK

The most common alternative is not a competitor — it is a practice. The published AI-native SDLC playbooks21 have each stage end by committing an artifact the next stage reads: the intent, the spec, the plan, the diff, the review findings, the incident record. That chain is this page's thesis arrived at independently, by people with every reason to know, and a team that adopts one is better off than a team that does not. But every artifact in it is a file held by agreement, and every control that keeps it honest — the hook on a protected path, the policy encoded as a skill, the gate that pauses until a named person approves — runs inside the harness whose behaviour it constrains. The constraint and the constrained share an address space. A convention does not bind automation, and it does not survive the harness changing, the agent declining, or the eighteen months before anyone asks. A playbook says what should be written down; it cannot be the thing that refuses when it wasn't. All six stages, one by one.

What is built, what is partial and what is not started are listed on the front page — the one place that claim is maintained.