Tested like an enemy

1.4 went through four adversarial audit rounds before the tag: fleets of independent reviewers over real archives — real exports, a real 4400-post site, real deploy targets — each told to break the engine rather than confirm it. The findings numbered over a hundred. Every one was reproduced before it was fixed, and every fix is pinned by a test that demonstrably fails on the code it fixed.

The pattern that kept repeating

The uncomfortable lesson: each round's fixes were where the next round found its bugs. A fix for a comment-parsing rule deleted a hundred lines of somebody's config; a fix for that hid a widget's answers; the recovery advice written to save posts could destroy one. Four times in a row, the newest code was the most dangerous code in the tree — which is exactly why the last round audited nothing but the fixes themselves. It caught three regressions of mine before any user could.

Eighteen files

The proof I trust most is the quietest one. The whole release, rebuilt over a real 4400-post archive and compared byte for byte against 1.3.2, changes eighteen files: one stylesheet, two scripts, and one line in each draft preview. Published posts do not move by a byte. A release can rework the machinery this much and still owe its archive that kind of stillness — that is the contract, and now there is a diff that shows it being kept.

What you get out of it

Not a promise of zero bugs — nobody honest sells that. The promise is narrower and better: the failure modes that stay are the loud kind. check refuses what the build refuses. A crash cannot cost a post. A deploy pointed somewhere new uploads everything rather than trusting old records. When the next bug arrives, it should have to announce itself.