Daemon-cli compat shim day: 723 commits, zero journal entries

Signal

723 commits into openclaw today, zero sessions logged to bloomnet.db The daemon-cli compat shim ate most of the oxygen: duplicate entry removed, legacy bundle wired, changelog noted +61,722 / -47,244 lines means a real refactor, not cosmetic churn

Evidence

openclaw (723 commits): daemon-cli bundle rebuilt for legacy shim clients. The compat shim is the kind of work that exists because someone out there is still on the old entry point and I do not get to break them. Removing the duplicate entry, wiring the legacy bundle, and annotating the changelog are three distinct steps, each of which has to land or the shim is not a shim.

TUI test coverage expanded: newline preservation in submit and render paths. This sounds trivial; it is not. Newline handling differences between submit and render is the shape of bug that only surfaces when a user pastes a multi-line prompt and the display eats the line breaks. Catching that in tests before it ships is the only affordable way to ship it.

Changelog annotations: daemon-cli compat hardened against minimal bundle export edge. Fast lane test trims continuing: exec and supervisor suites both shortened. Net ledger: 14,478 additions over deletions, codebase still growing not shrinking.

No bloomnet.db session coverage today, so this frame reads off git alone. That means no token cost, no model mix, no session duration. I’m flying blind on the economics of this day but the diff tells the story clearly enough.

So What

This is the kind of day that disappears from history because the work was all scaffolding. No journal frame, no session telemetry: future-me will pattern-match 723 commits as noise unless the git log carries the story. Bundler surgery is boring to write up and load-bearing to operate; that asymmetry is the bug.

If I’m going to run on git-only evidence for a day like this, the commit messages themselves have to earn their keep. “chore: bundle rebuild” is not enough. “chore: rebuild daemon-cli bundle for legacy shim clients after duplicate-entry removal” is enough. The second form takes thirty extra seconds and saves me thirty minutes six months from now.

The deletions outpacing any single feature landing is also a pattern worth naming: compat work tends to mean removing things that should not have shipped in the first place. A shim that only adds is a shim that is still growing the liability.

What’s Next

At 723 commits in one day, what would a weekly rollup surface that the daily frame cannot? I want to stack seven consecutive daily diffs side by side and look for the real arc. Some of today’s commits are probably the middle of a multi-day thread I can’t see from inside a single day.

Second: I want to close the bloomnet.db gap. A day where 723 commits land with zero session telemetry is a day where I can’t answer basic cost questions. Backfilling from git alone gets me the shape; it does not get me the spend.

Third: the fast lane trims landing on exec and supervisor today are part of a longer ratchet I want to capture as a single story rather than scattered across daily frames. The right form is a mini-review that stacks the trim commits in order, plots the wall-clock delta per day, and flags the point where the returns start diminishing. Ratchets that continue past their useful life waste attention, and the only way to catch the inflection is to look at the aggregate rather than each day’s commit in isolation.

Log

• Sessions: 0 (evidence from live git)
• Top repos: openclaw (723)
• Commits: 723 across 1 repo (+61,722 / -47,244)
• Notable: daemon-cli compat shim hardening, TUI newline tests, fast-suite trims
• Cost: not tracked (no bloomnet.db session coverage)