Sto dziewięć wydań w trzydzieści siedem dni

Pierwszy commit silnika: czwartego sierpnia. Ostatnie wydanie: dziesiątego września. W tym czasie sto dziewięć otagowanych wersji.

$ 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

Średnio wydanie co osiem godzin. To nie jest powód do dumy, tylko konsekwencja jednej zasady: KAŻDA zmiana kodu silnika to nowe wydanie. Nie ma poprawek doklejanych do numeru, który już wyszedł.

Skąd ta sztywność

Z jednej sytuacji. Instancja stała na wersji, której changelog opisywał coś innego, niż faktycznie w niej było — bo poprawkę doklejono do wydanego numeru zamiast wypuścić następny. Diagnoza usterki zajęła wtedy tyle, co jej naprawa.

Wpis w changelogu opisuje to, co dane wydanie faktycznie robiło. Poprawka idzie jako następny numer, nie jako przepisanie poprzedniego. Historia ma być zapisem tego, co się stało, a nie tego, co chcielibyśmy, żeby się stało.

Propagacja i jej dług

Silnik żyje w swoim repozytorium, ale wykonuje się w instancjach. Które pliki do niego należą, mówi manifest — czterdzieści osiem pozycji, katalogi w całości albo pojedyncze pliki.

# w repo instancji, ZAWSZE najpierw kontrola
./claude-tools/scripts/engine-sync.sh <klon-silnika> --check

# dopiero potem synchronizacja
./claude-tools/scripts/engine-sync.sh <klon-silnika>
npm run build

Kontrola przed synchronizacją nie jest opcjonalna. Repozytorium instancji bywa edytowane także innymi narzędziami, a zmiana zrobiona tam w pliku silnika zniknie bez śladu przy najbliższym przebiegu. Ten przełącznik istnieje, bo raz tak zniknęła.

Manifest jest na własnej liście, więc synchronizuje się sam. Bez tego instancja zostawałaby ze starym spisem ścieżek i po cichu przegapiała pliki dołożone w nowszej wersji — co dokładnie przydarzyło się pierwszej instancji między wersjami 0.6.0 a 0.7.0.

Czego to nie rozwiązuje

Propagacja jest ręczna. Przy pięciu instancjach to znaczy pięć razy to samo polecenie przy każdym wydaniu — i wystarczy raz odpuścić, żeby powstał rozjazd. Zdarzyło się: dwie instancje stały na 0.10.16, gdy reszta miała 0.11.10.

Właściwym rozwiązaniem jest workflow otwierający pull requesty do wszystkich instancji przy nowym tagu. Nie ma go jeszcze i to jest największy znany dług w tym projekcie. Wpisuję go tutaj, bo dług opisany publicznie trudniej odkładać.