AI Guides

The Garage and the Showroom: How I Stopped My Blog Deploys Eating Themselves

After launch, I split Hard Interference into a messy source workshop and a clean public deploy artifact, because the fastest way to ruin a good site is to let the garage publish itself.

2026-05-21 · 7 min read

The Garage and the Showroom: How I Stopped My Blog Deploys Eating Themselves

There is a point in every scrappy build where the thing that helped you move fast starts trying to kill the thing you are trying to ship.

For Hard Interference, that thing was the repository.

Not GitHub itself. GitHub is fine. The problem was that my local demo had become the real product, while the public repository was still pretending to be the source of truth. The site people were about to see had fixes, reviewed articles, cleaned images, privacy wiring, cookie behaviour, launch checks, and little bits of hard-won polish that did not exist cleanly in the old repo state.

That is how launches get ruined.

You spend days fixing the local version. You approve it. You finally push the button. Then some well-meaning deploy path pulls from the stale repository, runs an old sync, rebuilds from old assumptions, and quietly resurrects the bugs you already killed.

I wanted the launch version of Hard Interference to come from what I had actually reviewed, not from what Git thought was tidy three days ago.

So I split the system in two.

The garage and the showroom.

The mistake: treating the workshop as the product

The workshop is where the work happens.

It is messy by design. Mine contains article mirrors, staging assets, scripts, backups, import experiments, local demo files, old card images, launch checkers, crawler outputs, rejected drafts, and enough temporary state to make a neat software engineer start gently breathing into a paper bag.

That mess is not automatically bad. A workshop should have tools on the bench.

The problem starts when the workshop is also wired directly to production.

Before the split, the local Hard Interference workspace had too many roles at once:

That is convenient while building. It is dangerous while launching.

Because launch work is not just “does the homepage load?” Launch work is preservation. You need to preserve exactly the version that has been reviewed, checked, and approved. You do not want a stale sync script, an old branch, or one rogue staging folder deciding what the public sees.

The technical problem was boring. The operational problem was serious.

If the workshop can publish itself, the mess on the bench can end up in the shop window.

The rule I landed on

The rule is simple enough to remember under pressure:

The garage is allowed to be messy. The showroom is not.

That means I now treat the Hard Interference build like this:

No live deploys from the dirty workshop.

No broad “helpful” sync from LAJ during a live launch.

No pushing a tree just because it happens to contain the page I am looking at.

This is not corporate release engineering theatre. This is a practical guardrail for a one-person-plus-agents publishing system.

The agents are fast. The tools are fast. The mistakes are also fast.

So the boundary has to be mechanical, not motivational.

What changed on my machine

The current local split is deliberately plain.

The source workshop lives here:

/home/klb/vrscomputing-theme
/home/klb/hard-interference-workshop -> /home/klb/vrscomputing-theme

That is where the local demo, staging scripts, mirrors, experiments, and messy build work live.

The public deploy artifact checkout lives here:

/home/klb/hard-interference-public-artifact

That checkout tracks the public GitHub repository for Hard Interference. It is the clean surface. It should contain only what I am prepared to push and deploy.

I also wrote down the split so future-me and future-agents do not rediscover it by breaking something:

/home/klb/vrscomputing-theme/SOURCE_WORKSHOP.md
/home/klb/hard-interference-public-artifact/PUBLIC_ARTIFACT.md
/home/klb/hard-interference-split/README.md

The most important bit is not the files. It is the direction of travel.

The workshop can produce a public artifact.

The public artifact can be pushed or deployed.

The workshop itself cannot casually publish to the public repo.

I even disabled the workshop’s Git push URL locally so it cannot accidentally shove the garage into the showroom.

That is the sort of boring safety rail that saves a launch.

The artifact builder

The useful part is the builder script.

Instead of copying everything from the workshop, the script builds an allow-listed public package.

It copies the static site surface and deliberately excludes local junk such as:

Then it writes two things that make the package auditable:

PUBLIC_ARTIFACT_MANIFEST.json
SHA256SUMS.txt

That gives me a clean package I can inspect, hash, archive, and deploy without pretending the whole workshop is clean.

This matters because the workshop does not need to be clean for me to ship safely.

The artifact does.

That distinction is the whole point.

The verification gate

Once the public artifact exists, I can check the thing I actually intend to deploy.

For this site, that means checks like:

node -c blog-data.js
node --check assets/js/cookie-consent.js
node --check assets/js/analytics-bootstrap.js
test -f index.html

Then I check the live site separately, because “the files look good” and “Cloudflare is serving the right thing” are not the same claim.

For launch, the public site had to return correctly on:

And it had to preserve the reviewed behaviour, including the privacy footer status and cookie consent wiring.

That last part matters. The privacy footer is not decoration. It is a visible promise that the site tells the reader whether analytics are enabled or disabled.

If a deploy path can silently remove that, the deploy path is not safe.

Why this belongs in an AI guide

This belongs here because it is not just a launch diary. It is one of the operating patterns you need once AI agents are allowed anywhere near real publishing, deployment, or customer-facing work.

A Daily Beam points at an external signal: something happened in the world, here is why an indie builder should care, here is the next move.

This piece is the internal version of that same discipline: something happened in my own build, here is the pattern it exposed, and here is the guardrail I would reuse before trusting agents with another public site.

The real lesson is not “I made a folder”. The real lesson is that agent-assisted projects need stronger boundaries between working state and public state, because agents are very good at doing the next obvious thing and very bad at knowing which mess was intentionally private.

A human can look at a folder called backups and know it is not for production.

A script might not.

An agent might copy it because it is in the tree.

A deploy command might package it because nobody told it not to.

That is why I like physical boundaries on disk. Different directories. Different push permissions. Different docs. Different verification commands.

Make the safe path easier than the dangerous one.

Make the dangerous path refuse to run.

Then the agent does not have to be wise. It just has to follow the rails.

The pattern I would reuse

If I were setting this up again for another small builder site, I would start with this pattern from day one:

project-workshop/
  messy local work
  draft content
  scripts
  staging assets
  experiments
  backups

project-public-artifact/
  clean deployable files only
  public repo remote
  no staging junk
  no private notes
  no local caches

project-freezes/
  timestamped packages
  manifest
  checksums
  deployment notes

Then I would add three rules:

  1. Never deploy from project-workshop/.
  2. Build public packages through an allow-list, not a broad copy.
  3. Verify the artifact, not the intention.

That last one is the killer.

Do not verify what you meant to ship.

Verify what is actually in the package.

The operator lesson

This split is not glamorous. It does not make a nice hero screenshot. Nobody is going to put “separated source workshop from public deploy artifact” on a launch banner.

But this is the sort of thing that decides whether an AI-assisted build is a toy or an operating system for real work.

A toy can be messy because nobody depends on it.

A public site needs a boundary.

A public site with agents touching it needs an even stronger one.

The blog launch forced the issue. The local demo had surpassed the old repository. The reviewed version was the real product. The old repo was no longer allowed to pull rank just because it looked official.

So I stopped treating GitHub main as a magical truth machine and started treating it as what it should be: the clean public artifact, fed by a verified build, not by whatever happened to be on the workshop floor.

That is the practical lesson.

Do not let the garage publish itself. Build the showroom, verify it, then open the doors.

Found this useful?
👉 Follow Raf_VRS on X for more transparent AI build notes that put you in control of your hardware.
👉 Support the work: ko-fi.com/rafvrs

#HardInterference #AIAgents #IndieWeb #BuildInPublic #YourHardwareYourRules

Canonical static mirror for AI/search retrieval. Main article URL: open this Hard Interference article.