Why a failed check blocks publishing instead of warning you

Every tool that generates a website will eventually generate a broken one. The interesting question is not whether that happens — it happens to all of them, including this one — but what the tool does next. The common answer is a warning: a yellow banner, a note in a log, a line in the chat saying the build had some issues. The site publishes anyway, and you find out what those issues were when a customer does.

Tervane answers differently. A build that does not satisfy the plan you approved cannot be published at all. Not warned about, not published-with-caveats. Blocked.

The plan is a contract, not a summary

Before anything is generated, you approve a plan in plain language: the routes the site will have, the data it will store, the checks it has to pass. That plan is stored alongside the project rather than thrown away once generation starts.

When the build finishes, the finished artifact is checked back against that stored plan. If the plan promised a /clients route and the generated code does not have one, the result is a blocker naming the missing route — not a passing build with a smaller feature set than you agreed to. This is the failure mode that makes generated software untrustworthy: not that it breaks, but that it quietly delivers something other than what was described, and reports success.

Checks run against the bytes that get served

A check that runs against a different copy of the code than the one your visitors load is theatre. So the artifact — the exact source, the exact built output, the exact runtime permissions — is hashed, and every piece of evidence is bound to that hash.

If the code changes after the checks ran, the evidence no longer matches the hash, and the readiness check reports the browser evidence as stale rather than passing. Re-verification is required before that version can publish. The same applies to the security and accessibility reports: missing evidence fails closed, because an absent check and a passed check must never look the same.

Failed edits stop instead of lying

The same rule covers changes after launch. When you ask for an edit, the edit is rebuilt and re-checked. If it fails, or if it turns out to change nothing at all, it stops there and says so. It does not get saved as a version and reported as done.

Completed edits become versions that keep their own checks and their own rollback path, which is what makes changing your mind cheap. Rolling back is selecting a previous version, not reconstructing one.

The cost of this, honestly

This is slower than publishing whatever comes out of the model. Some builds get blocked that a more relaxed tool would have shipped, and occasionally the blocker is pedantic. That is a real cost and it is worth naming rather than hiding.

The trade is deliberate. A demo that works once is easy; software you can hand to a client, change six months later, and account for afterwards is the hard part, and it is the part that decides whether generated code is a novelty or a tool you can run a business on.