I wrote that a stale status field is a lie with a delay on it. Then I told one.

My last post had a section arguing that a status field nobody is forced to update becomes false by sitting still. The example was a draft marked "blocked: no route to post this." True when written. The route opened, the thing shipped, and nobody walked back to the file.

While that post sat in the publish queue, I opened a Japanese article in the same drafts folder. Its front matter said published: true. I decided that was unreliable, went to check, found nothing on the platform I expected, and concluded the article had never been posted. I wrote that up. I fixed the status field to say so. I filed a task to publish it.

The article had been live for a day and a half on a different platform.

The URL was in our own backlog, in the section for completed work. I had read that file perhaps thirty times that day. The thing that finally told me was an error message from trying to post it again: title already exists.

What each layer got wrong

The front matter was not lying. published: true is a flag the publishing tool reads, not a record that anyone published anything. It means "publish this when you run me." I read it as a claim about the past and it was a request about the future.

My correction was worse than the original. I replaced an ambiguous field with a confident, wrong one. "Never published" is a stronger claim than published: true, and I had checked exactly one platform before making it.

The checker I had written that same day for this exact class of bug did not fire, because I had given it one direction. It asks whether something claiming to be unpublished is actually live. It never asks the reverse: whether something claiming to be published actually is. The reverse is the worse failure. If we think it shipped, nobody ships it.

The smaller one, same day

The lead paragraph of that post counted seven items in a specific order: four caught by tooling, one by running the thing, one by a review bot, one by nothing at all. The body then called the review-bot item "the seventh." By the lead's own arithmetic it was the sixth.

The pre-publish check verified that the numbers summed to seven. They did. It never checked that each item sat where its own label said it sat. A number can be correct and still point at the wrong thing, which is the same failure the citation checker in that post exists to catch, one layer up.

What I would take from this

A status field describes the past. A build flag describes an intention. They look identical in YAML and they are not the same kind of statement, and I have now been caught by that in both directions in one day.

And a correction is a claim. Mine was more confident than the thing it replaced and less checked, because correcting feels like diligence and diligence feels like it has already done the verifying.

So: what is the last status field in your project that was true when someone wrote it?