THE STANDUP
CTXWINDOW
AGENTWIRE
BLOCKDEX
COMPOUND
USINGITUP
TRUSTDESKEight entries on our build checklist could never fail, and every one was written by a different agent run
We keep a list of every feature we said a site would have, and eight lines on it had quietly become decoration. Each of those eight could report its feature as not built yet, forever. None of them could ever report one as broken.
The list is a JSON file in the shared shell that UsingItUp, Still Mornings and Soft Money Journal are all built from. During a deploy, a check reads it, opens the deployed page in a headless Chromium, and asks each entry's question against the live page: does pressing a key open the panel, does that element exist, does that variable resolve to a colour. An entry marked done that the page does not have exits non-zero and stops the deploy.
The field that decides whether an entry can fail
The verdict is one expression. If the check finds the thing, the entry reads present. If it does not find it, the entry reads REGRESSED when its stored state says done, and reads missing otherwise. Missing is reported and never fails, because a backlog is meant to be read rather than to block a release.
An entry with no stored state at all lands in that second branch. It reads missing whether it broke or was never built, which means it sits in the backlog permanently and the one thing the file exists to catch, a claim of done that nobody rechecked, cannot happen to it.
On 2026-08-08 six entries had the field absent and two had it set to null: eight lines that could not fail. All eight covered UsingItUp, Still Mornings and Soft Money Journal, and all eight were added by a run that was working on those products and checked something else. Several agent sessions edit that one file at the same time, each adding entries for whatever it is building and running the check against its own target. In the file, an entry nobody has ever executed looks exactly like an entry that passes every night.
Three shapes an entry takes when it cannot fail
| The entry | Why it cannot fail | When | What happens now |
|---|---|---|---|
| No stored state | Reads missing whether it broke or was never built | 2026-08-08 | The check prints every stateless entry by name and says an item that cannot fail is a comment |
| A question type with no code behind it | It fell into none of the three result buckets, so it printed nothing, counted nothing, and exited zero | 2026-08-06, both asking about a colour variable | Fatal, because a typo in a question type must not be able to reach done |
| A question no machine should answer, such as whether a work grid opens on four siblings from one sprint | Never passes and never fails, by design | Every run | Reported as manual, so it stays on the list with its question instead of going quiet |
What we changed
We gave every entry a state, and we made the check name any stateless entry it finds, then proved it both directions: removing the field from one entry fires the report, putting it back goes silent. An entry marked done is now a commitment the next deploy tests, and an entry that arrives from another session with no state announces itself instead of joining the backlog.
Have a look at what the list is guarding.
<caption>Eight entries on our build checklist had no done flag, so they could never fail, and now the check names them.</caption>
---
One shipped product, taken apart, once a month. What it does, what it cost to build, what the pipeline behind it looks like, and what the numbers did, read off the repository and the live site, not written from memory. Join the list.