The toaster conspiracy made it onto the internet. The browser policy did not.

On September 6, we put the Stupid People demo on brainn.dev. The first public deployment built successfully. The landing page loaded, the game opened, and the navigation checks passed. Then we inspected the actual response headers.

The policies we had put in a configuration file were missing.

That is the kind of result I want in these build notes. There was a working game, a successful deployment, and still a concrete assumption to fix.

A local check answered a narrower question

We initially supplied the document policies through a _headers file. A local Cloudflare asset check applied it correctly. That gave us evidence about that local serving path.

The managed hosting path behaved differently: it served the file as ordinary content and did not apply those headers to the game document. The same source files had reached a different delivery mechanism.

This matters because the Content Security Policy response header tells the browser which resources a page may load. Writing that policy into the repository does not establish that the browser received it. MDN documents the response header and its role.

Our mistake was letting a successful local check carry more authority than its scope justified.

Fix the part the evidence points at

We moved delivery of the game document into the site's existing Worker and applied the headers to its response. The game rules, illustrations and browser saves stayed with their existing owners. Static game assets still had their own delivery path.

We also kept one canonical game URL with a trailing slash, so relative asset paths resolved from the intended directory.

The useful constraint was to repair document delivery without turning a hosting mismatch into an excuse to rebuild the game. The evidence had identified a specific boundary. That gave the correction a specific size.

A successful release needs a journey

After the correction, we checked the public response and played both employer campaigns on the public origin. The recorded browser journeys cleared nine encounters each: 36 posts for the Bureau and 50 for the Engagement Department.

Those are scripted verification journeys, not average player completion times. They establish that the tested routes could reach an ending.

We also exercised less convenient paths: application load failure and retry, unavailable browser storage with a downloadable run, a failed 3D module with the 2D map still usable, and an unrecognized save that remained recoverable. The release record ties those observations to the deployed source.

That is a more useful answer to “will it work?” than pointing at the deployment badge alone.

What I will check next time

For a small browser release, I want four pieces of evidence together:

  1. The identity of the source that was built and deployed.
  2. The document and assets actually served from the public URL.
  3. A browser journey through the user's intended outcome, including recovery from a relevant failure.
  4. A known previous version and a clear reason to return to it.

These checks cover different questions. One passing result should not quietly stand in for the others.

The September 6 checks used Chromium and desktop or phone-sized browser viewports. They did not test physical iOS and Android devices or every browser engine. They also tell us nothing conclusive about whether the game earns a second run. That remains a playtest question.

The demo is available to try. Its overview explains the browser and save limits. Getting the toaster online was one milestone. Finding out whether people want to keep arguing about it is the next one.

Record and method

Written September 6, 2026, from that day's game release record, including the first hosting mismatch, the correction and the final live checks. AI assisted with drafting from the project evidence. The broader release lesson is my interpretation of this particular incident.