Validation Before Release

What runs before a publish, which findings block, which only inform — and what a publish that goes through does not prove.

Two features can each work perfectly on their own and still break when combined. That is the characteristic failure of AI-generated software, and it is why publishing in Airbuild is not a file copy.

Everything runs against a frozen snapshot

When you publish, the code is frozen first, and every check runs against exactly that snapshot — not against a working copy that may still be changing while the checks run. What was scanned is what ships.

The checks

• Tests — the generated suites: vitest for the frontend, pytest for the backend. They run against the snapshot when the testing integration's pre-publish gate is switched on for that project. It is off by default, and with it off a red suite does not stop a release.
• Dependencies and secrets — known-vulnerable packages, and credentials that should never be in a repository.
• Static analysis and code quality — security patterns and code quality across the sources.
• API contract — the OpenAPI specification is produced without running the app and then linted. Advisory: findings appear in the Problems panel, they do not block.
• Endpoints without authentication — every backend operation that carries no security requirement is listed, minus the ones that are public by design such as login, signup and health. Confirm-to-proceed: you have to see the list and accept it.
• Optional, per project — SonarQube for deeper quality analysis, and a dynamic security scan against the running application.

Which checks run is a per-project setting; each one is switched on as an integration.

Blocking, advisory, confirm

Not every finding stops a release, and the difference is deliberate. High-severity findings from the analysis gate block. API-lint findings inform. Open endpoints ask.

A check that cannot run does not block. The gates act on what a check reports, not on whether it managed to report at all. If the OpenAPI specification cannot be generated, the open-endpoint gate passes instead of refusing the release, and clean-up steps such as removing a SonarQube analysis project are best-effort as well. A publish that goes through therefore means that nothing blocking was reported — not that every check completed. Which tools actually ran is in the audit record below, and that is where the difference becomes visible.

Before the gates: the live preview

Every workspace has a live preview of the running application, backend and database included. Clicking through the flows that actually matter — especially the ones that cross two features — is the cheapest test there is, and it happens long before any gate.

The record

Every publish keeps an audit entry per tool that ran. Months later you can still answer what was checked, with which scanner, against which version of the code.