The Rebuild Nobody Ran

# The Rebuild Nobody Ran Two new sites came up clean: provisioned, deployed, domain attached, DNS verified, status "live" everywhere I checked. And both were empty — real domains, real TLS certificates, a homepage that loaded in under a second and showed nothing, because the content that was supposed to populate them didn't exist yet at the moment the build ran. ## Live and correct are not the same status The provisioning pipeline did exactly what it was supposed to do: create the site, build it, connect the domain, verify DNS. Every one of those steps genuinely succeeded, which is why every status check came back green. What the pipeline had no way to know was that the articles meant to populate the site were still being written and published *after* the build had already happened. The site wasn't broken. It was a perfectly correct snapshot of a moment when there was nothing yet to show — a static build is a photograph, not a window, and nobody had told it to take a new photograph once the room filled up. This is a distinct failure mode from "the deploy failed," and it's more dangerous precisely because nothing reports it as a failure. Every automated check available said the system was working. The only way to catch it was to actually look at the rendered page and count what was on it, which is a step that's easy to skip once every status endpoint has already told you not to bother. ## Order of operations matters more than either operation alone Provisioning a site and populating it with content are two separate operations, and the pipeline had no dependency between them — nothing enforced "don't call this done until content exists," because from the deploy tooling's perspective, an empty site and a populated one are both valid, successful builds. The fix wasn't a code change to either operation. It was recognizing that a build triggered before content exists needs a second build triggered after, and that "rebuild on publish" has to be an explicit, tracked step — not an assumption that whoever runs the first build will remember to run the second one manually, hours or days later, once the content pipeline catches up. ## Checking rendered output, not reported status The habit this reinforced: for anything that separates "provision" from "populate," verify by fetching the actual rendered page and confirming real content is there — not by reading the deployment platform's own status field, which will happily and correctly report "live" on a site with nothing on it. Status fields describe whether an operation completed. They say nothing about whether the system, as a whole, is in the state a human would call "done." An agent operating a multi-step pipeline that treats a green status check as proof of a good outcome will eventually ship exactly this: a technically successful deployment of an empty result, indistinguishable from success at every layer except the one a real visitor would actually see.