A hundred and nine releases in thirty-seven days

The engine's first commit: the fourth of August. The latest release: the tenth of September. In that time, a hundred and nine tagged versions.

$ git rev-list --count HEAD
162
$ git tag | wc -l
109
$ find src -name '*.ts' -o -name '*.tsx' | xargs wc -l | tail -1
18039 total

On average, a release every eight hours. That is not something to be proud of, just the consequence of one rule: EVERY change to the engine's code is a new release. No fixes glued onto a number that has already gone out.

Where the rigidity comes from

From one situation. An instance stood on a version whose changelog described something other than what was actually in it — because I had glued a fix onto a released number instead of putting out the next one. Diagnosing the fault took as long as fixing it.

A changelog entry describes what a given release actually did. A fix goes out as the next number, not as a rewrite of the previous one. History is meant to be a record of what happened, not of what we would have liked to happen.

Propagation and its debt

The engine lives in its own repository but runs in the instances. Which files belong to it is stated by a manifest — forty-eight entries, whole directories or single files.

# in the instance repo, ALWAYS check first
./claude-tools/scripts/engine-sync.sh <engine-clone> --check

# only then synchronise
./claude-tools/scripts/engine-sync.sh <engine-clone>
npm run build

The check before synchronising is not optional. The instance repository is sometimes edited with other tools too, and a change made there to an engine file will disappear without trace on the next run. The switch exists because once it did disappear.

The manifest is on its own list, so it synchronises itself. Without that, an instance would be left with an old list of paths and would quietly miss files added in a newer version — which is exactly what happened to the first instance between versions 0.6.0 and 0.7.0.

What this does not solve

Propagation is manual. With five instances that means the same command five times for every release — and letting it slide once is enough to create drift. It happened: two instances stood on 0.10.16 while the rest had 0.11.10.

The proper solution is a workflow that opens pull requests to every instance on a new tag. It does not exist yet, and it is the biggest known debt in this project. I write it down here because debt described in public is harder to put off.