The production build.
The dev server forgives. The production build does not. This gate makes the build prove itself before users meet the change.
What the check reads
The check runs the full npm run build and requires it to complete; projects without a build script are skipped honestly. On failure the report keeps the last thirty lines of build output. One honest detail: in a plain check run this step only runs when you pass --build, because a full build is slow; the deploy path runs it as a matter of course. A quick run without --build has not proven the build.
Why AI-built code ships this
The dev server tolerates what a production build rejects: a prerender that throws on a page nobody opened locally, an import that only resolves in dev, a value read at build time that is not there. AI-built changes hit these often, because the agent verified against the dev server and called the work done.
Why it blocks
Blocks, whenever it runs. A failed production build is a NO-GO with nothing to weigh or eyeball. The only nuance is when it runs at all: always in the deploy path, on request in the quick check.
In the proof record
A pass line when the build completed, or a fail line with the tail of the real build output, so the breaking error is part of the record.
✓ Production build (npm run build) — Production build completed successfully. ✗ Production build (npm run build) — The production build failed — fix it before shipping.
Honest limits
A green build proves the project compiles and prerenders, not that it behaves. And because the quick check skips this step unless asked, a GO from a run without --build says nothing about the build. The deploy path is where this gate always stands.
Want every change gated like this before it ships?
The same gate runs in every engagement, and each piece of work ends on a plain go or no-go, in writing. The gate itself is open source, so you can read exactly what we run.
The other 6 gates
The whole method, from the controlled zone to the proof record: the methodology.