DOP
GitHub
Menu
Decisions ADR-0005 2026-08-29

No green, no PR — and a merge queue after the green

A pull request opens only when executable acceptance passes and an independent critic has reviewed it, carrying its evidence. After the green, a queue per repository re-verifies each PR against the current main and merges one at a time.

What was on the table

Agents deliver pull requests faster than humans can review them, and parallel demands on one repository produce PRs each verified against an outdated main — the first merge can silently break the others. A merge is a human decision, by product rule; what happens before the human is called, and after the PR is green, are the platform’s to decide.

The paths we weighed

Human-only review. Rejected: review capacity is the bottleneck.

Auto-merge on green. Rejected: the human gate is a product rule.

Optimistic merge, in arrival order. Rejected: semantic breaks reach main.

One file, one owner. Rejected: it serialises the required parallelism.

Only the provider’s merge queue. Rejected as the sole route: not universal, and no cross-demand view.

What we chose, and why

Before the pull request, four rules. Acceptance criteria are executable and live in the demand’s spec — test suites and checks derived from it. No PR opens with acceptance failing; the agent iterates to green, and a persistent failure becomes a question to the human. An independent critic — a strong model, clean context, maximum effort — reviews the diff, the spec and the evidence before the human does. The PR carries the evidence package, so the human reviews the exception, not the rule.

After the green, a merge queue per repository, as a domain concept. A green PR enters the queue; the queue reapplies each PR onto the current main, re-runs verification and merges one at a time. A conflict is first the demand agent’s task, then the human’s. Overlap between demands is detected before the PR by the project orchestrator. The provider’s native queue is used where it exists; the platform’s orchestrates on top.

What it cost

The critic costs tokens, with no saving allowed. Merges are serialised per repository, so queue position and forecast are shown in the cockpit. Re-verification per queue position costs compute. The syntax of the executable criteria is defined in the workflow spec.

Since then

Two records — the rules before the PR and the queue after it — were consolidated on 2026-09-04. The spec artifact got an address in the project’s knowledge repository, and verification got its runner in the verification decision.

Decisions this one leans on

  • ADR-0004
    Every write is an event; everything else is a projectionEvery write in the core emits an immutable event carrying who, what, when and in which context. The dossier, the timeline, auditing, replay and metrics are read from that log — none of them is written separately.
  • ADR-0008
    Measure, cap, route — and design the prompt for the cacheEvery model call emits a cost event; every demand has a budget that pauses rather than kills; a router picks the class of model per kind of work — never cheaper for the critic. And the prompt is laid out so the expensive part is cached.
  • ADR-0011
    A techlead agent per project, and it never pauses a demandWhen a project has two or more active demands, an orchestrator agent watches for overlap, dependencies and interference, plans a solution and brings the developer a decision — without stopping any demand while it waits.
  • ADR-0023
    Verification runs in a runner that builds from sourceAn ephemeral runner pulls the commit, builds the application from source and starts it — no image of the project is ever built, pushed or deployed. The account's cache makes the second run fast; the runner takes the demand's address while it runs.