The Script Finished. Where's the Article?

I found twenty live newsletter posts containing only a title and subhead. Their recorded lengths ranged from fourteen to thirty-eight words.

Each post began from a manifest. The publishing script built the article's HTML and copied it to the clipboard. A person still had to paste the body into the newsletter editor because there was no API path for that step.

For twenty posts, the paste never happened.

The script had finished its part. The reader had nothing to read.

A simple “does this post exist?” check could have passed all twenty. A word count would have exposed how little was there, but even that answers a smaller question than the one I needed: did this page receive the article prepared for it?

For that workflow, I'd compare the delivered body with the intended article. Then I'd open the page as a reader. Neither tells me whether the writing is any good, but at least I'm no longer asking someone to review an article that isn't there.

In a system with several services, the same gap is harder to see because each component has a convincing account of its own work.

An audit of Qtown's second version found 194 assigned development tasks marked complete by its autonomous coding loop. The individual services' tests passed. The dashboard pages rendered. None of the three end-to-end flows checked in the audit worked.

Qtown is my town simulation. One of those flows asks whether a proposed change is allowed before the simulation acts on it. The simulation sent a request. Another service received it, checked the rules, and returned its decision. Those steps worked.

There was no service listening for the decision.

The checker could return the right answer indefinitely without the simulation doing anything with it. Its own test could pass. The whole pipeline was missing one requirement: an allowed request must produce the intended change, and a refused request must not.

Those are the outcomes I'd put in the acceptance test. Start with the request and inspect what changed. Keep the input, result, and tested version together so another person can repeat the check.

The newsletter's missing paste and Qtown's missing listener are different kinds of work. Both sit after a component can honestly say it finished.

Now I write down what counts as done, where someone can inspect it, and a failure the check must reject. An empty newsletter body is one failed case. A validator returning an answer nobody acts on is another.

Sometimes the result can't be checked. A page may fail to load; a remote service may be unavailable. Then the useful report is what completed and what remains unverified. A failed attempt to inspect the result isn't evidence that the result is absent.

For the next newsletter post, the completion report should include the opened page and the body comparison. If the page won't load, I stop there.