Our build fails if the website claims the generated code is responsive. That is a real test, in the real suite, and it exists because we wrote that claim down once.
The mistake
While drafting the platform pages, an early version said the React Native output used "real flex behavior, not absolute positioning that breaks on the next screen size," and that the Flutter output was "a real widget tree, not a stack of positioned boxes."
Both sentences are the exact opposite of the truth. Our React Native output is absolute positioning. Our Flutter output is a Stack of Positioned widgets. That is not a flaw we were covering up, it is the mechanism that makes the output match the canvas. The draft had reached for the flattering version of a technical detail and landed on a claim that contradicted the product.
The engineer who owns the code generators caught it before it shipped, by reading the marketing copy against the source.
Why a person catching it was not good enough
It worked, but it relied on the right person reading the right paragraph at the right time. The same class of error had already spread further than the two sentences: code samples on four pages were showing flex containers and column widgets, which is what a plausible-looking sample looks like when nobody generated it.
Something that only works when everyone is paying attention is not a process.
What we did instead
Three things, all in the test suite:
Banned-claim tests. A page-level test renders every marketing page and fails on responsive and adaptive phrasing. It was mutation-checked by reintroducing the original wrong sentence and confirming the test caught it, because a guard nobody has seen fail is not yet a guard.
Scoped, not blunt. The test bans overclaim phrasings, not the word "responsive". Our comparison pages say plainly that competitors win on responsiveness, and that honest usage has to stay legal. A keyword ban would have quietly pushed us back toward hiding the weakness, which is the opposite of the point.
Byte-equal code samples. Every code sample in the docs is compared against real generator output. A sample cannot drift from what you would actually get, and "this is the actual export, unedited" is checkable rather than a figure of speech.
There is a fourth, added after this post was first drafted, and its origin is the same mistake in miniature. The draft said the SwiftUI and Flutter build checks "run in our test suite". They did not. Someone had run them by hand that evening and the copy quietly upgraded that into an automated guarantee.
The fix was not to soften the sentence. It was to write npm run verify:native, which runs flutter analyze, flutter build web, and swiftc -typecheck against the real toolchains and the actual sample designs used in these docs. It lives outside the fast test suite because it needs the Flutter SDK and Xcode installed and takes up to a minute and a half. Now the sentence is true, and it names the script so you can check.
Twice in one week, the honest move turned out to be building the thing the copy had assumed existed.
The general version
Marketing claims decay the same way code does. Someone writes a true sentence, the product changes, and now the site is lying and nobody has noticed. The usual defence is a periodic review that nobody schedules.
If a claim is important enough to put on the site, it is important enough to put under test. Our competitor comparison pages carry a visible last-verified date for the same reason: a stale claim about a rival is the fastest way to lose the credibility those pages exist to earn.
Anyone can copy a sentence we write. It is harder to copy a sentence a build enforces.