5. The gate says no

Monday, 07:43 UTC. Eight minutes after the first pull request opened, a comment lands on it. You read the first line: "inspect: fix". The agent's tests all pass. The checks all pass. And a reviewer has just found a way for a stranger's email address to slip into the plan documents.

Three layers of "prove it"

An agent saying "done, all tests pass" is a claim. This chapter is where claims become evidence, or fail to.

1. The merge gate runs in CI on the exact commit that would merge, using the workflow from the base branch, so a pull request cannot weaken its own checks. It runs verify: the floors, fixed checks with fixed thresholds, such as test coverage of the changed lines, security scans, leaked secrets, vulnerable dependencies, accessibility, and page speed (floors).
2. It writes the proof pack: a file that ties each of the story's promises to its evidence, with every check's result (proof packs). The pack, screenshots and recordings included, stays on the CI run, and a comment on the pull request shows each promise's verdict, the checks, and the pack's fingerprint. It opens with a risk line, high, medium, or low, that tells the person who merges where to look first. For a Bug, the gate also runs the proving tests on the code before the fix: a test that passes there does not show the fix.
3. inspect asks a reviewer from a different family, that is, another vendor, than the agent that wrote the code, to review the change. aayu reads its reply as merge, fix, or rebuild, with a verdict for each promise. No reply means no merge.

A pull request gets two rounds of fixes. If it still is not right, aayudha stops spending and asks for a fresh start: the pull request is closed, and the story is built again from the latest code.

The email check that would not die

Remember the routine promise from chapter 3: refuse a seed file with an email address outside example.com. Here is what happened to it.

Four times the agent's own tests passed and the reviewer still found a new way in. Each finding became a test, so the final check refuses all four. That is the privacy stake from the prologue, held by a promise nobody thought was hard.

The same thing happened elsewhere. On the API story, the reviewer sent pull request 151 back twice: once for extra text after the JSON request, once because {"Question": …} with a capital Q returned 200, slipping past the published contract. On the analytics story, pull request 156 went back twice, the second time because the simulated HR answers could land after the end of the measured window. Both were closed and rebuilt, as 155 and 158, with every finding fixed and tested.

In all, five stories took 17 reviews. Your plan for the day allowed 10: one review per story plus one round of fixes. The gate itself allows two rounds before it closes a pull request, and it needed them. Four pull requests (135, 140, 151, 156) were thrown away. No pull request's reviews cost more than 2 USD in total; pull request 148's cost 0.37 USD.

Tip: treat fix as the system working, not failing. Each of these findings was a real defect, and each one now has a test that keeps it fixed.

When the numbers said yes

Not every "no" was right, and aayudha has a rule for that too: a measurement beats a model's opinion.

On the Ask page, the model half of design review flagged the footer text as too faint, "about 4.2:1", below the 4.5:1 that readable text needs. The fixed checks disagreed. The measured ratio of those two colours is 6.46:1, and the merge gate's accessibility scan on the same commit found 0 serious contrast problems. The page shipped on the measured result. The model's note stays on the pull request, where a person can read it and decide.

What passed

Story 131's final commit, pull request 148: 116 of 116 changed lines covered by tests (the floor is 90 %), 0 security findings, 0 leaked secrets, 0 vulnerable dependencies. Then, at 09:31:

In the story: "inspect: merge. The implementation satisfies all three completion criteria. Retrieval returns the full selected passage with its citation, policy screens the specified prohibited questions before retrieval, and unsupported questions return an HR referral without quoted content."

The Ask page, story 134, passed every screen floor: 0 serious or critical accessibility problems, every control reachable by keyboard, nothing clipped at 200 % text size, nothing to tap smaller than 44 by 44 pixels, and a page-speed score of 100 against a budget of 90. Both records are on the ledger branch: the pack for story 131 and the pack for story 134.

Since then: on 12 October the reviewer was a model the merge gate called with a key held in CI. Now the gate calls a review model of another vendor itself, with one key held in the code-review environment, which only the base branches and the default branch reach (code review in the gate). An agent app from another vendor, such as Claude or Codex, can review instead, and aayu reads its reply. The gate can also run behaviour checks from a feature map, which drive your product the way a person would, and for a Bug it shows the proving tests failing on the base commit first. See a pull request is ready and prove a behaviour change.

What you do, and what the agent does

You read the verdict and the proof comment on the pull request. They are short on purpose. Then you go back to your coffee: the fixing is not your job.

The agents and CI do the rest: the gate starts by itself, the builder fixes what the reviewer finds, and a capped pull request is rebuilt.

What you learn

Two reviewers that disagree, one building and one checking, find more than one reviewer that agrees with itself. And when a model and a measurement disagree, believe the measurement.

Needs setup: the merge gate comes with aayu init --gates, which also creates the code-review environment. The review needs your model endpoint's key there, as the secret AAYU_REVIEW_MODEL_KEY (code review in the gate); a reviewer app named in [inspect] reviewer is the alternative. The proof needs nothing else: no bot App or bucket. The pack waits as a file on the CI run for [proof] retention_days (90 by default), and ship checks it came from that run and records it under your name. An agent's own preview, even with screenshots and video in your thread, never counts. See Adopt at your own pace.

The verbs in this step

Under the hood: the workflow, the sandbox verify runs in, and inspect's structured verdict are in the merge gate; every floor's tool and threshold is in floors in detail; the pack's format is in proof packs.

What's next

At 09:03, pull request 142, the plan documents story, is the first to turn green, with a pack and a "merge". One thing is missing, and only a person can give it. You reach for the approve button: chapter 6, the yes.

You are here: chapter 5 of 9. Goal · Plan · Promises · Build · Gate · Yes · Release · Number · Telling