The actual gate
Generate, validate, compile, then inspect the running build.
This order separates source truth from rendered output. A failure tells us which layer needs work instead of producing a vague red CI job.
01
Generate governed outputs
Create the article manifest and factual audits for graph, tags, images, links, builder contracts, redirects, and documentation boundaries.
02
Reject drift
Compare generated files with the committed versions. A stale report is a source-control problem, not a note for later.
03
Build production
Run the optimized Next build so route, type, and server-rendering failures occur before release.
04
Run Chromium smoke checks
Start the built site, then exercise reader routes, article pathways, the contact safe fallback, and an artifact shell.
What the gate caught
The first visual baseline run was useful because it failed for real reasons.
The initial screenshot setup selected the wrong mobile browser, reused baseline names across viewport projects, and exposed that the article-map control did not have the accessible name the test assumed. None of those were product failures, but each was a weakness in the evidence system.
The fix was not a larger pixel tolerance. The visual suite now uses Chromium for all three viewports, isolates baseline paths by project, waits for fonts, disables reduced-motion effects, and targets the map through its actual accessible control.
61 article records in the current governed corpus.
311 published builder sections with zero derived contracts.
Functional browser checks run against the production build.
Visual baselines remain a separate review process.
Performance evidence
A visible performance signal is useful evidence. It is not enough to diagnose the whole page.
Homepage performance work added a second lesson to the release process. Lighthouse showed the logo in the LCP path, which made it a reasonable place to start. The problem was not that the signal was false. The problem was letting one visible element carry too much of the diagnosis.
The wider delay sat across render-path decisions, CSS cost, hydration, and main-thread work that the first clue did not explain on its own. That is why release evidence has to stay multi-layered. A metric can show where the cost becomes visible without explaining the whole structure that created it.
The first measured improvement moved mobile Lighthouse from 89 to 95.
A later header experiment looked locally sensible and still regressed the page.
The useful correction was wider evidence, not a stronger attachment to the first clue.
Performance review belongs with release evidence when public pages are part of the product.
Evidence boundary
A green local gate proves the repository contract. It does not prove production traffic, mail delivery, or search performance.
Those need preview checks, configured external services, uptime monitoring, and real post-launch evidence. Keeping that uncertainty explicit is more useful than pretending a build result is operational proof.
Bring the release step that still depends on memory.
We can turn it into a visible check without adding ceremony for its own sake.
Bring the page, report, or workflow as it is now.
We reply with the clearest next step, or an honest no.
