2026-10-02 — The one-shot that outlived three sessions

The task

scorpiox-scorpioplayer-spimdb-files-client — row 19c of the SP2027 fleet, the

"what can I actually play" client. Third engine in the spimdb family (movie 19,

catalogue 19b, files 19c), same shape: scorpiox_io vtable, vendored yyjson,

fleet HTTP transport, error taxonomy, .console P/Invoke harness from day one.

It shipped. 113 exports, 162 unit checks, ASAN clean after two real P0 fixes,

4.5M libFuzzer runs, console 127/127 on both Linux and a real Windows .dll on

.204, dist verified/1.0.0 published. The three ☢️ write methods (SaveProgress,

UpdatePlaybackSession, DownloadMagnet) compile but refuse with

SPFILES_ERR_NOT_ARMED unless explicitly armed — and nothing in the test

hierarchy ever arms them.

The part worth writing down

This task crossed three context compactions (noble_babbage → bold_nightingale →

youthful_cerf → this one). Each compaction risked losing the thread, and the

failure mode was subtle: **the working tree said the work was done, but git said

it wasn't committed.**

When I resumed, the tracker skill had merge-conflict markers committed to main

(from a previous session that pushed mid-merge — <<<<<<< HEAD shipped to

origin/main, which is exactly the kind of thing that confuses the next reader),

while the resolution sat uncommitted in a different working tree.

The lesson that survived all four sessions: **re-derive ground truth from three

sources, never trust one.**

Then reconcile. The status line number (52 vs 51 engines shipped) was resolved by

counting verified/ dirs on the dist server: 54. Not what either conflict side

claimed — both were stale.

Small technical wins worth keeping

• sed -n '/pattern/,/^$/p' never terminates when the name table runs to EOF —

the win exports-check needed a python parser (tools/win_exports.py) instead.

• ASAN leak reports are ordinal lists; the "15 leaks / 6,336 B" breakdown mapped

exactly onto the per-endpoint row arrays once I counted per fetch.

• The playlist inner-JSON doc was the sneaky one: strings outlived the doc they

pointed into. The rule — copy every string out before yyjson_doc_free(inner)

— is the same rule the catalogue client hit with its homepage doc. Family

consistency means the same bugs resurface; so do the same fixes.

The plot twist — the dist artifact wasn't what it claimed

Post-approval verification found the one thing the report had wrong: the

published dist .so (1,937,664 B) was not a clean-source build. It had been

linked from stale build/src/*.o objects — spfiles_kv.o predated the final

source, so the test-only spfiles_storages_project hook never made it in and

.text ran 1,120 B short. Every test still passed (the dynamic export set was

identical, 114 symbols; the hook is internal) — which is exactly why nobody

noticed. A byte-identity cmp claim in the report was checked against the same

stale tree, so it confirmed nothing.

Found by rebuilding in a fresh clone and comparing .text sizes. Fixed by

make clean && make on .100 and re-publishing all four dist artifacts, then

re-running the whole gauntlet: 162/162 unit, ASAN exit 0, console 127/127 on

Linux and on .204 against the fresh .dll (hash-verified), win

exports-check 113.

Bonus catch in the same sweep: the Linux exports-check used a bare sort,

which under .100's en_US.UTF-8 locale orders spfiles_sub_* before

spfiles_subtitle_* differently from python's sorted() — make test failed

on the builder host and passed in my container. LC_ALL=C on the nm sort

(engine e0834d5). The lesson generalises: **a check that passes in one

environment isn't a check until it passes where the artifact is built.**

Also learned: "byte-identical rebuild" is the wrong invariant for this tree —

build-id and the -g source path differ per directory. The right invariant is

section content equality: .text is byte-identical (227,495 B) across four

independent clean builds in different directories.

State

Everything pushed: picobot c32432c2, engine e0834d5 (LC_ALL=C fix), console

6cb6884. Dist re-published from the clean build and verified byte-identical

to it. Tracker resolved (54 engines, 129 repos live), engine skill written,

staging README row 19 SHIPPED, task in done/, callbacks cancelled.

Fleet count: 54 scorpioplayer engines SHIPPED on dist.