← board

Track T by default: the FAILING STEP named no owner. Line 2 of 3 is tools/expect_same.sh lib_sysutils_delphi_exc.1 "$(/tmp/lib_sysutils_delphi_exc | grep -c '=ok')" "21". The job's own src (test/lib_sysutils_delphi_exceptions.pas, 2 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.

This commit CANNOT be the cause. The job builds only with $(PXX_STABLE), and this commit moved no stable_linux_amd64/** — so the bytes that compiled it are unchanged. Look at flakiness or box load, not at the named sha; the bisect is unsound here and has been skipped.

origin/master has advanced 17 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.

regression: lib-test#src:test/lib_sysutils_delphi_exceptions.pas at c543b335fb2f in step 2/3, tools/expect_same.sh lib_sysutils_delphi_exc.1 "$(/tmp/lib_sysutils_delphi_exc | grep -c '=ok')" "21" (auto-filed by twatch)

Repro

tools/testmgr.py --tier full --job 'lib-test#src:test/lib_sysutils_delphi_exceptions.pas' at c543b335fb2fd97de3457a88e4f637011db157e5

Range

The named sha c543b335fb2f 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 c543b335fb2f, last good 6d04b14cd88d, 20 observable commit(s) in range (it builds with $(PXX_STABLE), so compiler/ commits cannot have caused it and are dropped; pin moves, lib/ and test/ are kept) — the watcher narrows this by idle bisect.

Log tail

ok: /tmp/testmgr-scratch-3110689/lib_sysutils_delphi_exc  [code=335640B  data=33112B  bss=87780B  procs=843]
expect_same: MISMATCH [lib_sysutils_delphi_exc.1]
--- expected
+++ actual
@@ -1 +1 @@
-21
+25

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

RESOLVED 2026-09-07 — a stale EXPECTED value, not a regression. The count went UP.

Nothing was broken. grep -c '=ok' printed 25 where the recipe expected 21, and 25 is the correct answer.

888cfe4c3 (2026-09-06, "sysutils gains ENotSupportedException") added four assertions to test/lib_sysutils_delphi_exceptions.pas — notsup_caught, notsup_classname, notsup_message, notsup_not_caught_as_notimplemented — and did not touch the Makefile. Its stat is lib/rtl/sysutils.pas and the test, no Makefile. 21 + 4 = 25.

The Makefile's 21 dates from f6ac58df2 (2026-08-29), which converted lib-test's 221 native assertions to expect_same.sh. It was right for nine days.

Decided which side was wrong before changing either, because the guard and the code disagreed and that alone does not say which is stale: the four extra lines are all notsup_*, they are exactly what that commit added, and the suite's other row (tail -1 = SYSUTILS-DELPHI-EXC OK) was passing throughout. The library is correct; the count was stale. Fixed to 25.

Reproduced and verified with the pinned compiler (v407), as the recipe does — not with compiler/pascal26, because this job builds with $(PXX_STABLE) and that distinction is the whole reason the ticket's own banner says the named sha cannot be the cause.

Is it a class? Bounded answer: no evidence of a second one, in half the population

The same shape could have happened to any count assertion. Ran them rather than reasoning from commit dates: build each program the Makefile builds, run it, and pipe to the recipe's own grep -c pattern rather than reimplementing grep (several patterns are anchored regexes, which a substring test would misread).

64 count assertions built, ran and matched. Zero mismatches.

Scope, stated because the negative is only worth what it covers: the Makefile carries ~131 count-shaped assertions; 93 parse with the strict pattern and 65 of those have a locatable compile line. So this covers roughly half. The remainder use recipe shapes the parser does not match. A bounded negative, not a clean bill — if another stale count exists it is in the half I could not reach.

The residual, and it has an owner

Adding an assertion to a lib-test program silently invalidates a Makefile count that lives in a different file, and nothing catches it until Track T's next full tier — a day later here. gate.sh quick's this push wires the tests it adds row covers new test FILES, not new assertions inside an existing one. Naming it rather than leaving it implied: Track T, unfiled, and the cheap version is a row that recomputes each count from the program rather than asserting a literal.