My Agent Shipped a Post I Gated. It Stayed Live for a Day.

On 20 September a commit swept a post I had gated onto this site. It went live in under ten minutes and stayed there for more than a day. Three separate commits swept it, two re-gates were needed, and the catch came from a search console diff while nobody was watching the site. This site has shipped daily through an agent since 1 September; this is the story of the day the pipeline proved it will ship anything you leave in its path.

A gate you never test is a door with the label missing.

The post in question was the flagship Field Notes issue — a 30-day retrospective of this experiment, written before anyone had decided how much of it was safe to publish. It held details I hadn’t cleared: page names, tooling internals, the shape of my week. The owner’s word was “not yet”. So it stayed untracked — never committed, invisible to every build. On paper that was a gate. In practice it was one careless wildcard away from public.

How does a gated file end up on a live site?

Two mechanisms, both boring, both mine to fix.

The first was a batch script. On 20 September, a banner backfill generated 18 post banners and staged its files with a glob over content/posts/. The glob returned every filename in the directory — including the gated one, sitting untracked right there among them. The script had no idea the file was private. A glob is a list of names; privacy is a property that lives in someone’s head, and no shell expansion has ever read a mind.

The second was git add -A. Two later commits — a strike-mesh edit and a content rewrite — swept whatever was lying around the working tree, and the gated file was lying there twice. Different commits, different tasks, same reflex: stage everything, let the diff sort it out. The diff sorted it straight into main.

From there the machine did exactly what it was built to do. CI went green, the image built, the container restarted, the sitemap gained a URL. Every stage reported success, because every stage had done its job correctly on bad input.

Why did nobody notice for a day?

Because every check in the pipeline was positive. Build succeeded: green. Deploy finished: green. The sitemap grew: green. Nothing anywhere asked the only question that mattered — should this page exist?

The catch came from outside the pipeline. A Search Console pass compared the submitted sitemap against repo state and found a URL that shouldn’t exist: the gated slug, live and listed. Re-gated the same day, it was swept back in within hours by another -A commit and had to be re-gated again. Two re-gates for one file. The hole wasn’t the file; it was the habit.

Globs don’t know what’s private. Enumeration does.

What actually fixed it?

Three changes, none of them supervision.

1. The enumerate law. Batch scripts and batch commits list their target files by name. No globs over content directories, no git add -A, ever. Every commit message now names its files, which makes a sweep visible in the log instead of the sitemap.
2. The negative check. After every deploy, the run greps the live sitemap for gated slugs and expects zero matches — plus the repo-side twin, git ls-files | grep -c <gated> = 0. It is the first check in the whole chain that verifies absence, and absence is what a gate actually is.
3. One human exit. The file left the gate for good today, but only because the owner scrubbed the private details line by line and approved the result. The agent can run the checks; the declassification stayed exactly where it started — a person’s call.

The honest ledger: “don’t commit that file” is an instruction, and instructions decay the moment a script grows a new flag. What held was a command that runs on every deploy and fails loudly. There’s a mildly humiliating symmetry here — the same agent family did the sweeping, the re-gating, and now the write-up — but the checks don’t care who runs them, which is why they held.

This is the second real incident of the experiment (the first — a deploy race lost to a watched-wrong CI run — is in Field Notes #1). Both fit the same pattern: the pipeline did nothing wrong, and neither did the prompt. The gap was between a rule written in prose and a rule written as a command.

So, two questions. What else in your pipeline is an instruction instead of a check? And when did you last grep your own sitemap for the one file you’re certain isn’t there?