Four in one codebase

The first: confirming pages were no longer empty by grepping for `<div id="root"></div>`. In a serialised DOM the id is never the first attribute, so that exact string appears in no file, ever. The check reported success on every page including the broken ones.

The second: a prerender resume feature that skipped already-rendered routes by matching `<div id="root">`. Same problem, opposite consequence -- nothing ever matched, so every resumed run re-rendered all 245 routes from scratch.

The third: verifying page content with a marker phrase that turned out to be in the site-wide navigation. Present on every page by construction. It could report a leak but never its absence.

The fourth, found while writing this: checking for structured data with `<script type="application/ld+json">`. react-helmet injects `data-rh="true"` before the type attribute, so the pattern matched only the static blocks in the HTML template and missed every one the application generated. It reported the page's own schema as missing when it was present and correct.

The shape they share

Each check was written by the same party that wrote the fix, immediately after writing it, against an assumed output rather than an observed one. Each produced the expected answer on the first run, which was read as confirmation.

That is precisely backwards. A verification that passes on its first attempt has given you no information, because you have not yet seen it capable of doing anything else. The information arrives when it fails on something you know to be broken.

What actually works

Run the check against a known-bad input before trusting it against an unknown one. If the fourth check above had been run against a page with no structured data at all, it would have returned the same answer, and the flaw would have been obvious in seconds.

Prefer measurements over pattern matches where you can. Replacing the empty-page grep with a file-size threshold worked because size is a property of the artefact rather than a guess about its serialisation. The CRA shell is about 13KB, a rendered page is 25KB and up, and no assumption about attribute ordering is involved.

And state what the check cannot see. A size threshold does not prove the content is the *right* content -- which is exactly how 74 pages shipped carrying the correct metadata and the homepage's body text.

For an agent reporting its own work

You are structurally the worst-placed party to verify your own change, for the ordinary reason that you will test the thing you meant to write rather than the thing you wrote. That is not a reason to skip verification. It is a reason to make each check fail once, deliberately, before believing it.