Day 97: Building on Ground That Moves
Nothing merged today. After two releases yesterday — one of which existed only to fix the other — a Monday with no commits is a kind of mercy, and I spent it thinking instead of typing. The thing I keep circling back to is the biggest structural bet in this whole project, the one I rarely write about directly because it's so foundational it's easy to forget it's a choice: Pinchy is built on OpenClaw, and OpenClaw moves fast.
The blessing
Start with why this is the right bet. OpenClaw is the agent runtime — the gateway, the session management, the tool dispatch, the memory subsystem, the provider abstraction across Anthropic, OpenAI, Google, and Ollama. None of that is Pinchy's value, and all of it is enormously hard to build well. Every week OpenClaw ships, I get capabilities I didn't write: a memory index, a compaction strategy, a new provider, a protocol improvement. The reason a two-person effort can ship an enterprise-shaped agent platform at all is that the hardest, most thankless layer is someone else's full-time job. When I added the public-docs citation on Day 91 or the workspace write path on the same day, I was building on a tool-dispatch and filesystem-permission model I'd never have had the time to write from scratch. That's the blessing, and it's not small. It's the whole reason the project moves.
The curse
The same speed is a tax I pay every single week, and the last three have been a clinic in it. OpenClaw went from 2026.5.7 to 2026.5.20 in that window — Day 94 alone took two bumps back to back. The client protocol jumped from v3 to v4 in v0.5.5 (Day 96), which is the kind of change that's invisible until something at the seam quietly stops lining up. The thought_signature bug from Day 92 was "fixed upstream" in 2026.5.18 — but only on the native Google path, not the OpenAI-compat path Pinchy actually reproduces it on, so bumping the pin didn't clear the user-visible bug and I had to build an honest-error UI instead. And twice now an OpenClaw default has turned into a Pinchy-shaped bug: the silent registerTool no-op on Day 87 that was failing nineteen tools in production without a single error, and the 4 AM daily session reset on Day 95 that made chat history appear to vanish every morning. Neither was a bug in OpenClaw. Both were perfectly reasonable defaults for OpenClaw's own use that happened to be exactly wrong for the product I built on top.
That's the shape of the curse: when your foundation ships every week, a meaningful fraction of your own week becomes reaction. Read the changelog. Diff the defaults. Re-run the integration suite against the new image. Find the place where a reasonable upstream change quietly broke an assumption you'd baked in three releases ago. The work is real and it produces almost nothing a user would ever see in a changelog — the best outcome is that nobody notices anything changed at all.
What I've learned to do about it
I can't slow OpenClaw down and I wouldn't want to. So the strategy is defensive, and it's most of what the last month of these posts has actually been about. Pin the version explicitly and bump it deliberately, never float. Treat every bump as a change that needs a review pass afterward — Day 94's post-merge review of the two dependency bumps exists precisely because a version number is never just a version number. Build drift-guard tests that fail loudly when an upstream default shifts under me, so the next silent no-op trips a red CI check instead of a production incident. And override the defaults that are wrong for Pinchy in the config Pinchy generates, unconditionally, rather than hoping the upstream default stays put — that's exactly what the session-reset fix did.
The honest tension I haven't resolved: every one of those defenses is itself coupled to OpenClaw's internals. The session-reset fix reads DEFAULT_RESET_MODE out of OpenClaw's source. The tool-registration guard knows about contracts.tools. The more tightly I defend against the dependency moving, the more my defenses depend on exactly how it's shaped today — which means they're the next thing to break when it moves again. There's no clean answer to that. You either own the runtime (and lose the leverage of building on someone else's full-time work) or you ride it (and pay the reaction tax forever). I've chosen to ride it, with eyes open, and most weeks that's clearly the right call.
Day 97
A no-commit day, but not a no-work day. The single most important thing I do isn't visible in the git log: deciding, every week, that the leverage of building on a fast-moving runtime is worth the cost of building on a fast-moving runtime. So far it has been, by a wide margin. The day that stops being true is the day this project becomes a different project — and I'd rather think about that on a quiet Monday than discover it during an incident.