The review a change has to survive before anyone calls it done

What question it answers

"What has to be true before this counts as finished?" The document exists because the review discipline that produced several milestones was living in the length of a one-off prompt, and a discipline that depends on how much someone typed that day is not a discipline.

Its definition of complete is a sequence, not a checkbox: implementation, adversarial review, fixes in place with regression tests, compatibility backfill declared, clean-clone verification, CI green, human merge. A milestone that skipped the review is unreviewed, not finished — and the PR body must say so rather than imply otherwise.

What it does

Section 1 sets ten conditions on every feature PR: an ExecPlan written before the code that compares at least three approaches and says why the chosen one wins; a clean baseline verified at the branch point so an inherited failure is found rather than blamed; one milestone per branch; no hidden changes to a shared contract; documentation and ADR moving in the same PR as the code; a conservative job-status update; clean-clone verification from a fresh clone and install; no secrets, databases, logs or build output in the tree; a declared compatibility row for any horizontal capability; and a human merge, never a squash.

Section 2 is the part with teeth: fifteen adversarial categories run against every milestone, where a category that does not apply must be stated as not applicable rather than silently skipped. Public-boundary bypass. State-machine algebra with an explicit transition table rather than a rank. Transaction and fault injection after every significant write. Idempotency with deterministic keys, where a semantic mismatch behind the same key fails closed. Two-connection concurrency. Exact queries proven past 500 rows. Immutable boundaries proven by changing the source and re-reading the snapshot. Provider timeout and late settlement. Replay and reconciliation. Hostile input across `__proto__`, markup, backticks, template substitutions, newlines, Unicode separators, null bytes and oversized strings. Schema compatibility. Backward compatibility. Audit, event and trace exactness — asserting counts, not presence. Real-Chromium browser behaviour. And documentation truthfulness: every claim in a doc, an ADR, a PR body or a job row traces to a merged test, with limitations stated in the same breath as capabilities.

Section 3 is a four-value vocabulary — not supported, partially supported, technically supported, validated end to end — with not supported as the default for anything new, and an explicit ban on inferring a status from an isolated primitive. The vocabulary is enforced mechanically in `docs/benchmarks/jobs.json`, which is why the jobs ledger reads as bluntly as it does: of the rows published there, the overwhelming majority are not supported.

The executable form of section 2 is the `adversarial-review` skill, which `AGENTS.md` rule 10 makes mandatory for any milestone or pre-merge review task.

What it refuses to claim

This is the first of the three entries in this cluster where the honest answer is that there are no limitation codes. Quality gates is a Markdown document that people enforce; it emits no JSON, has no contract version, and publishes no `limitations[]` array. The inspector says so about it from the other side, under `EVIDENCE_NOT_AGGREGATED`: job and quality-gate status live in Markdown maintained by people, are referenced by path, and are never parsed into structured claims. Machine-readable evidence for this is roadmap work — DX5 and DX6 — and does not exist.

Its self-declared blind spots live instead in section 4, a list of ten production gates each described as a hard gate before public multi-user use, and none of which exists today: a PostgreSQL conformance suite running the same tests on both adapters, browser end-to-end in CI (today it is manual, and the document calls it the largest coverage gap), an enforced coverage threshold, mutation tests for versioned policies, property-based tests for pricing arithmetic and state machines, fuzzing for the webhook route and the URL router, dependency and security scanning, backup and restore rehearsal, tenant-escape tests, and permission-matrix tests once role-based access control exists.

This page also quotes no test count. The claims ledger and the project status file were generated at different commits and carry different numbers, and a figure nobody has re-run is precisely the kind of claim these gates exist to refuse. What was re-run for this page is the cheap half: `npm run check` passed, which is all `check` is — a syntax pass over every JavaScript file in the repository, with `verify` being that plus the test suite.

What it costs to run

`npm run verify` is `npm run check && npm test`. The project-doctor ExecPlan measured it at about 156,000 ms on this repository — roughly a thousand times the cost of the source-only checks, which is the entire argument for those existing. The syntax half alone returns in about a second.

It exits non-zero on any failing test and writes nothing to the repository. The rest of the discipline is not a command at all: an adversarial review is a person or an agent working through fifteen categories, and clean-clone verification means a fresh `git clone` and a fresh `npm install` before running anything.

The document carries a companion budget that does run. `node scripts/surface-check.js` fails the build when the surface an agent must understand exceeds a stated ceiling, and it printed here: 1/1 goal entry points, 12/12 skills, 9/10 always-on tools, 11/11 commands in skills, with the closing line "Internal complexity may grow. Perceived complexity has not." Every ceiling carries the reason it is where it is, so raising one is a deliberate edit with an argument attached.

Where it fits

It is the last gate, and it is the one the other seven tools are measured against. The cheap commands exist because this one is expensive; the falsification kit exists because passing this one is not the same as being defended by it.

The jobs it serves are honest about the gap. Verifying a solution against defined acceptance is partially supported — the gates, the validator, the suites, the clean-clone run and the jobs matrix are real and enforced, and there is no automated goal-to-acceptance runner. Reporting unavailable capabilities honestly is also only partially supported: the matrix and package metadata make the honest answer available, and nothing enforces that an agent uses it, which is why the skills state it as a rule.