Blog: correct the build claim on 3 Aug, and add the follow-up

[kinlane]

Two things. Not merging — yours to read.

1. The 3 August post has a sentence that is now false

It closes with:

The build has still never been verified. Nothing has been published to npm...

That stopped being true the same evening. The build is verified — 1,966 unit tests and all 66 harness scenarios on Node 18, Node 20, headless Chrome and Windows, a job that had never executed once since the fork was made.

This is not cosmetic staleness. "Does this thing even build?" was the most important open question about the fork, and a reader arriving today is told it is unanswered when it is the day's biggest result.

Corrected in a dated block rather than a silent edit, matching the correction already in that post. Everything else in that paragraph still stands and is left alone: nothing published, scope undecided, contributing guide still a note, ten branches still on one laptop.

2. The follow-up, dated 4 August

The afternoon is the better story, and it makes the argument harder than the morning did. Turning CI on did not confirm things were fine — it produced a queue of things that were not, two of them in fixes written hours earlier:

• the lockfile that made the default branch uninstallable, invisible because the only PRs that had ever run here were Dependabot's, which regenerate the lockfile as part of their own change
• a safe.directory fix that replaced one wrong path with a differently wrong one, and went unnoticed because the same change deleted the only git call left to trip over it
• a harness cache serving stale executable content, where the local verification was real and still wrong, because the bug only appears at steady state and deleting the cache between runs — which feels like rigour — is exactly what hides it

The through-line is the part worth publishing:

A cache or filter keyed on the wrong thing does not fail loudly. It hands you yesterday's answer, with a green tick on it.

It ends narrower than "the fork works now" — the claim is that the machinery telling you whether it works is now itself trustworthy, and was not before. The "still not done" list is intact and includes the ten @stoplight/* runtime dependencies, stated as a fair criticism without an answer.

One deliberate choice to check

The forward reference from the 3 August post is not a hyperlink. Future-dated posts are not built until their date, so linking it would ship a 404 on a live page — on the day this project fixed three shipped documentation URLs that returned 404. It reads as a titled reference instead, and the post is discoverable from the blog index once it publishes.

Verified both ways: the normal build produces no references to the unpublished URL, and jekyll build --future renders the new post correctly.

If you would rather both land today, moving the follow-up to 2026-08-03 publishes it immediately — there are already two posts on that date, and the work all happened on the 3rd, so it would arguably be the more accurate dating. I went with the 4th to keep the cadence, but it is a one-line rename.