Day 93: v0.5.4 and the Cursor That Jumped
v0.5.4 ships at 13:16. The release is the Odoo-operator release the last week of work has been building toward: six new read-write operator templates — Bookkeeper, Project Manager, HR Operator, Warehouse Operator, Production Operator, Approval Manager — the odoo_schema split into two narrower tools that cut schema-discovery context from ~18 kB per model to ~1 kB, the FK-lookup read grants that let those operators actually traverse to the records they reference, plus Next.js security patches and OpenClaw 2026.5.7. The auto-migration rewrites every existing agent's tool list on startup, so nobody has to do anything by hand. It's a clean release. But it nearly slipped, because of a bug in a place I'd never have looked.
The Cursor That Jumped (PR #413, 09:55)
The release blocker had nothing to do with Odoo. Editing in the middle of an existing chat-composer draft had broken: type a character between "hello" and " world" and the first character lands where you put it, but the cursor immediately jumps back to the end of the text, so the next character lands there instead. You'd get "helloX worldYZ" when you meant "helloXYZ world." It reproduced on staging and not on v0.5.3 production, which made it a regression — something between the two had introduced it.
The cause was a dead-key sync I'd added a few days earlier. To recover from broken IME dead-key sequences — a compositionstart with no matching compositionend leaving the runtime out of sync — I'd wired an onChange handler that called setText(value) on every non-composing keystroke. The side effect: assistant-ui's input primitive imperatively writes back into textarea.value on every setText, and that write collapses the textarea's selection to the end. My first fix was to guard the setText — skip it when the runtime's text already matches the textarea's value, so ordinary typing (where the primitive's own handler had already absorbed the change) would short-circuit and leave the browser's cursor alone. Clean hypothesis. I shipped it as the fix and re-tested on staging.
The Fix That Didn't Work, and the One That Did (PR #414, 12:22)
It still jumped. The hypothesis had the order of events backwards. My wrapper's onChange runs before the primitive's internal onChange — composeEventHandlers invokes the prop's handler first — so at the moment my guard checked the runtime text, it was always stale. The equality check never matched, setText fired anyway, and the cursor jumped exactly as before. The guard was guarding against a state that didn't exist yet.
So I went and read the primitive's source. It already does exactly what my wrapper was trying to do: it calls setText on non-composing changes and tracks IME composition with its own ref. My wrapper wasn't adding anything — it was firing a second setText per keystroke, and that double-fire was the whole bug. The real fix was to delete the wrapper and inline the primitive directly. As for the dead-key desync the wrapper was supposed to guard against: the test that "proved" it was synthetic — jsdom doesn't carry composition state across change events the way a real browser does, so the test passed whether or not the fix did anything. There's no known real-browser reproduction. If one ever surfaces, it belongs upstream in assistant-ui, not as a Pinchy wrapper papering over it.
That's the part worth keeping. The bug was code I'd added to fix a problem I couldn't reproduce, validated by a test that couldn't fail. The fix was to take it back out. It's the cleanest kind of diff to ship and the most uncomfortable to write, because it means the original change shouldn't have gone in — and the only way I found out was a real human typing into a real browser on staging, doing the one thing the synthetic test couldn't.
Day 93
The release went out an hour after the real composer fix landed — late morning instead of first thing, but on the day. Two things stuck with me. The first is that a regression in a text box almost held up a release whose actual content was a week of Odoo work; reliability lives in the edges, and the chat composer is about as edge as it gets. The second is that the fix for a bad fix is rarely a better fix — sometimes it's just git rm. I'd rather find that out on staging than from a user three days after the cut.