Track guessed as C from the FAILING STEP — line 15 of 17, sh test/crtl_declaration_census.sh stable_linux_amd64/default/pinned /tmp, which names test/crtl_declaration_census.sh. Not from the job's name or its src: those describe what the job is ABOUT, and this job's recipe spans 3 source file(s). The ranker reads frontmatter, so this line — not the body — decides who works it; correct it if the guess is wrong.

The SLUG names crtl_atexit, and that is not what broke. The slug is derived from the job's src: selector so that it stays stable across a renumbering — it is the dedupe key and the close key — but src: says what the job is ABOUT. The failing step names crtl_declaration_census. Read the Failing step: bullet, not the file name in the title, before you reproduce anything: the row the slug names may be passing.

origin/master has advanced 3 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/crtl_atexit.c at 934ba04180e9 in step 15/17, sh test/crtl_declaration_census.sh stable_linux_amd64/default/pinned /tmp (auto-filed by twatch)

• Type: regression (auto-filed by Track T watcher, host borg, twatch 1d5c476a6328). Untriaged.
• Found: 2026-09-14T17:57:27Z
• Test source: test/crtl_atexit.c tools/expect_same.sh +1
• Failing step: line 15 of 17 of the job's recipe; it names test/crtl_declaration_census.sh.

  sh test/crtl_declaration_census.sh stable_linux_amd64/default/pinned /tmp
  
  

Repro

tools/testmgr.py --tier full --job 'lib-test#src:test/crtl_atexit.c' at 934ba04180e95d273bc57583fc2d8311cd0a96e8

Range

bad 934ba04180e9, last good b984ad07e38f, 1 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

pascal26:218: error: expected 'begin' before 'weakexternal'
(tail)
ok: /tmp/testmgr-scratch-3543567/crtl_atexit  [code=327448B  data=13304B  bss=76520B  procs=873]
main-returns
h3
h2
h1
via-exit
child-exit
via-_Exit
  lib-test: crtl_atexit is self-contained (no DT_NEEDED)
FAIL: census TU did not compile
pascal26:218: error: expected 'begin' before 'weakexternal'
  in: stable_linux_amd64/default/../../lib/rtl/palthread.pas
  near: ) : Integer ; cdecl ; >>> weakexternal 'libc.so.6' name 

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

STATUS 2026-09-16 (frankb-56) — INERT UNTIL PINNED. Do not claim this; there is nothing to fix.

Three things in the header above are stale. Read this block instead.

1. crtl_atexit is not the subject and it PASSES — the header's own warning said so and it is worth repeating, because the slug is what next shows you.
2. weakexternal no longer fails to parse. That was the 2026-09-14 symptom in the log tail. Pin v410 carries 934ba0418, so the keyword parses now.
3. The cause underneath changed. The census now fails on crtl declares functions it does not define: c_pthread_create — a name that appears nowhere in lib/crtl. It is not a missing definition. It is CWarnImplicitSystemImports warning about a WEAK external, which is not an implicit import at all: unresolved, its GOT slot is zero, the call site takes its guarded branch, and DropWeakOnlyImports can remove it entirely.

THE FIX IS ALREADY LANDED. IT IS NOT IN THE PIN.

Eighteen minutes. The fix missed the pin by eighteen minutes, and a compiler fix is inert until pinned.

The differential — same script, same tree, only the compiler differs:

PINNED  sh test/crtl_declaration_census.sh stable_linux_amd64/default/pinned
        FAIL: crtl declares functions it does not define: c_pthread_create   rc=1
LIVE    sh test/crtl_declaration_census.sh ./compiler/pascal26
        crtl declaration census — 600 declared, all defined, no libc imports  rc=0

The census is not wrong and must not be loosened. Its header records four real defects it caught, and its name list is generated per run precisely so it cannot go stale. The warning was answering about the wrong population; the census faithfully reported what the warning said. Both instruments behaved correctly and the red is real about the PIN.

What clears it: the next make pin. No code change, no action available to a dev seat. Moved out of backlog/ so the ranker stops handing a p70 with no work in it to successive seats — this is the second seat to re-derive it.

Re-laning note: the auto-filer guessed track C from the failing step's path. That guess is not wrong (the guard lives in compiler/cparser.inc, C frontend) but it is also not useful, because no lane can act on this.

RE-VERIFIED 2026-09-16, both instruments — still inert-until-pinned, still nothing to fix

Raised again as one of the rows standing between the tree and goal 1, quoting crtl declares functions it does not define: c_pthread_create. That reason is true of the pinned compiler and false of the tree, which is the whole content of this ticket and is worth re-measuring rather than re-reading.

So the row is not work: it is a fix that exists and is not yet carried by a pin. It clears itself at the next one. Counting it among the things that need FIXING overstates the distance to goal 1 by one.

A grep trap on the way, recorded because it nearly reversed the verdict

git log --grep='pin v410' returned c9af737b5 — a docs(watch) commit that merely mentions pin v410 in its prose. Tested against that, the fix came back as an ancestor, i.e. "the pin contains the fix", which is the opposite of the truth and would have made this look like a live defect. The pin commit is ^chore(stable): pin v410, anchored, and against the real one the fix is correctly NOT an ancestor.

Same shape as the grep -o "663" that matched code=417346B an hour earlier in another seat's hands: a grep for a name matches prose about the thing as readily as the thing. Anchor the pattern to the commit-subject form, and prefer the recorded binary sha — c599e8546121 appears in the pin's own subject line and on disk, and that pair is an identity no prose can imitate.

CORRECTION 2026-09-16 — "missed a pin by 18 minutes" explains the timing, not the CLASS

Everything above is accurate and the mechanism it implies is too small. The sharper account is frankuser's, verified here on this seat's own instruments:

934ba0418 (2026-09-14 19:34:56, "route pxx threads through pthread_create when libc is already linked") adds c_pthread_create as a weak external in lib/rtl/palthread.pas — not in lib/crtl, where the census reports it, and where it has zero hits.

lib/rtl is read from the TREE. The pin snapshots the compiler binary and builtin and nothing else — find stable_linux_amd64 lists pinned, stable_pinned, builtin, VERSION, the logs, and no RTL.

So the declaration went live instantly, with no pin, and met a diagnostic frozen inside one. That is the RTL/compiler split working exactly as designed, in the one direction where it manufactures a red: a tree-live RTL change meeting a pinned compiler's stale diagnostic, producing a RED that names a real symbol, cites a real file, and reports nothing wrong with either.

The 18 minutes explain why nobody caught it. The split explains why the row exists at all, and why this class will recur whenever an RTL change lands between a compiler diagnostic and the pin that carries its fix.

Both good and bad from tstate's pair (b984ad07e 18:55, 934ba0418 19:34) are before pin v410 existed, which is the tell that the bisect range was never going to contain the cause: the cause is not in the range, it is the range's relationship to a binary outside it.

SCOPE CORRECTION — the frozen-diagnostic warning transfers to ONE never-green row, not both

The consequence above ("a bisect whose range predates the pin cannot contain the cause") was stated over "the other never-green rows". That is a quantifier over a population of two, and the two do not build the same way. Measured here, one grep each:

A pin-built row can have its red manufactured by a stale pinned diagnostic. A live-built one cannot, so c_crtl_wait is a genuine unknown and is the only one of the two that a bisect is the right instrument for.

Credit and mechanism: the scope error was mine and the measurement is frankuser's (765aa9fad, 5f729bc7a); both rows re-derived here before being written down. It is worth noting where the error was — the over-wide clause never reached a commit, only a peer message. The reasoning was sound and the quantifier was the invented part, which is CLAUDE.md's own longest-running complaint arriving in the tail of a finding that had just corrected itself once.

And a second thing that grep turned up, which is not this ticket's but is the reason the count wants restating: demos#00's own stored reason ends "demos is a dashboard, not a gate; FAILs -> file a ticket". It declares itself on the grading side while being scored RED in the tier being read as the goal-1 blocker list — and which 5 of 36 demos fail is not recoverable, because the stored reason is truncated to 288 characters and keeps only the tail. So "four blockers" is four red rows of four different kinds, not four fixes.