Day 96: The Version That Lied About Its Number
Two releases today, an hour and fourteen minutes apart, and the second one exists only because of a mistake I made cutting the first. It's the most building-in-public thing that's happened in a while, so I'm not going to dress it up.
v0.5.5 (10:49)
The real release ships at 10:49. v0.5.5 picks up OpenClaw 2026.5.20 and its v4 client protocol — a jump from the v3 protocol on 2026.5.7 — gives every agent the workbench/ subdir from Day 94 so it can write to a fresh workspace without a prior upload, and ships the multi-company Odoo hardening so accounting agents stop confusing two companies that share a chart of accounts. It also carries the daily-session-reset fix from yesterday, the image-tool clarification on Ollama Cloud, and a tightened password-reset path so a leaked recovery link can't leave a logged-in session behind. Standard upgrade flow, no migration, no compose change. A good, ordinary release.
Two things landed in the hour before the cut. A universal chat.agent_error audit event (PR #430, 08:37) fires for every error chunk on the chat surface, plus the synthesised silent-stream timeout. Until now only three error classes were audited and each was throttled per agent and model — the long tail of failover errors, unclassified provider blips, and transient hiccups had no audit signal at all, which made "how often does this happen?" unanswerable. The umbrella event runs alongside the specialised ones, not instead of them, so a single SQL query grouped by error class now covers every failure shape. It's pure measurement — no behaviour change — and it's the floor under the auto-retry and stream-resume work that's coming. And a CI PR (PR #431, 09:11) activated a batch of dormant checks and added a guard that blocks untracked test skips, after Day 87 taught me how much a silently-disabled check can hide.
v0.5.6 (12:03)
Then I checked the running image's /api/version and it said 0.5.4. The image tag was right, the OCI image.version label was right, the OpenClaw runtime was right — but the number the app reported about itself was a release behind. The cause is embarrassingly simple: I cut v0.5.5 with gh release create instead of pnpm release. The GitHub release got made, the tag got pushed, but the version bump in package.json and packages/web/package.json never happened — that's what pnpm release does and gh release create doesn't. So the v0.5.5 image dutifully reported the last version that was written into package.json: 0.5.4.
This is exactly the bug Day 85 was supposed to prevent. Day 85 added the /api/version endpoint precisely so an operator could trust the running version — and the very next release shipped a version that lied. The endpoint worked perfectly; it faithfully reported the wrong number, because the wrong number was what got baked in. v0.5.6 at 12:03 is a cosmetic patch with no functional changes: it bumps package.json the right way so the tag and the reported version agree again. The docs PRs (PR #435 at 09:59, PR #437 at 11:51) finalised the v0.5.5 pre-release audit and then prepared the v0.5.6 patch section — the second one written in the half hour between noticing the bug and cutting the fix.
Day 96
The fix for v0.5.5 was thirty seconds of work. The lesson took longer to sit with: a release process that depends on me remembering to type pnpm release instead of gh release create is a process with a hole in it, and the hole found me on the first release after I added the very endpoint meant to catch this class of problem. The cosmetic patch is the right thing today, but it's a band-aid — the real fix is making CI refuse to tag a release whose package.json version doesn't match the tag, so the manual step can't be skipped again. I wrote that down as the next thing to build. Two releases before lunch is funny exactly once; the second time it's a process bug I didn't close.