← board

Track T by default: the FAILING STEP named no owner. Line 2 of 4 is tools/expect_same.sh tidref26/wasm32 "$(tools/run_target.sh wasm32 /tmp/tidref.wasm)" "$(printf 'enums OK\nheader Intege. The job's own src (test/test_cross_typeinfo_dataref.pas, 4 file(s)) is NOT used here on purpose: it is what the job compiles, not what broke, and guessing a lane from it is what sent three reds in one job to the wrong lane. This is a FALLBACK, not a finding — nothing says the defect is Track T's. Re-lane it before working it.

origin/master has advanced 1 commit(s) since this sha. Re-verify at current HEAD before acting — the callback is tagged to the sha that was tested, which may no longer be the state of the tree.

first-ever red: test-core#src:test/test_cross_typeinfo_dataref.pas@2 at 11324ff49f9e in step 2/4, tools/expect_same.sh tidref26/wasm32 "$(tools/run_target.sh wasm32 /tmp/tidref.wasm)" "$(printf 'enums OK\nheader Integ… (auto-filed by twatch)

Repro

tools/testmgr.py --tier native --job 'test-core#src:test/test_cross_typeinfo_dataref.pas@2' at 11324ff49f9e00c05da02bb7bac88079f689a36d

Range

The named sha 11324ff49f9e CANNOT be the cause — it touches no buildable file (docs / tickets / tstate only). It is the sha that was TESTED, i.e. the upper bound of an untested range; the cause is somewhere below it.

bad 11324ff49f9e, and this is the job's first-ever run — there is no earlier passing sha, so no interval contains the cause and every commit a range could name is equally innocent. No idle bisect will happen; a red here is a finding about the job, not a regression from the commits around it.

Log tail

ok: /tmp/testmgr-scratch-1713993/tidref.wasm  [code=8376B  data=8376B  bss=1090908B  procs=319]
wasmtime not found (looked on PATH and in ~/.local/bin)
expect_same: MISMATCH [tidref26/wasm32]
--- expected
+++ actual
@@ -1,3 +1 @@
-enums OK
-header Integer
-header TPoint
+

Stub ticket: signal only. Track T agent (face 2) enriches or a dev track takes it from the repro line.

Not a regression — the host had no wasmtime (frankA, 2026-09-04)

Six auto-filed tickets, six different test names, six different commits, ONE missing binary. This is one of them. The whole set: test-cross-frozen-ptr-narrow, -frozen-ptr-in-field, -typeinfo-dataref, -dynarray-slot-store, -os-entropy-through-the-pal, -futex-through-the-pal.

The log tail of every one of them carries the line wasmtime not found (looked on PATH and in ~/.local/bin) immediately above the mismatch. tools/run_target.sh printed that on stderr and exited 2 — but every Makefile assertion calls it inside "$(tools/run_target.sh wasm32 ...)", and a command substitution captures stdout and discards the exit code. The comparison therefore ran with the empty string, and the diff reads exactly like wasm32 emitting nothing:

-fld16  T [AB] 2 [AB] [xAB] A
 ...
+

Re-measured on a host that HAS wasmtime, at the same tree, all six pass:

ENTROPY OK / DYNSLOTSTORE OK / FROZENPTRFIELD OK / FROZENPTRNARROW OK
enums OK, header Integer, header TPoint / fxpal all three modes

What was fixed, and what was not

tools/run_target.sh now reports an absent runner on stdout as well, as RUNNER-ABSENT: <tool> not found, so target '<arch>' was NOT RUN, for the qemu arms too. It still exits nonzero and the row still goes red — an unrun test is not a passing test — but the row now names the HOST instead of accusing the target, and the next auto-filed ticket will carry that sentence in its own log tail.

What was NOT fixed is the actual gap: host seven has no wasmtime, so every wasm32 row there is unverified. That is a machine, not a tree, and it is not mine to change.

The reading that nearly cost more than it did

Four of these were read as four separate defects in four freshly added tests, because each names its own test and its own commit and nothing in a ticket says "the other five say this too". The distinguishing observation was free and was in the ticket already: the fix a50671107 landed 15:41Z and the test went red at 15:56Z, so the fix was in the tree when the test failed — which no compiler-state story explains. Read the log tail above the diff before reading the diff.