THE SLUG SAYS 62 AND THAT NUMBER IS FROZEN. It was 62 at filing and is 64 by the next cycle. The slug is not renamed because resolve citations and tstate rows key on it, so a reader must treat the number in the FILENAME as a timestamp, not as a count. Everything in the body is re-derived; the title is not.

Measured 2026-09-11, from devdocs/progress/tstate/pin-shadow.log on origin/master

The red floor, ranked by how many verdicts each blocks

Re-derived WHOLE-LINE 2026-09-11 under a positive control. The first cut of this table said 39 for the lib-test rows and 62 for the denominator; both were wrong, the 39 from counting fragments of a comma-split list:

  64/64  optdiff#shard0/12                                        first seen 2026-09-01
  41/64  lib-test#src:tools/crtl_reachability.py                  first seen 2026-08-16
  41/64  lib-test#src:test/lib_synapse_transitive_unit.pas                  2026-09-01
  41/64  lib-test#src:test/lib_synapse_ssl.pas                              2026-09-01
  41/64  lib-test#src:test/lib_synapse.pas                                  2026-08-27
  23/64  optdiff#shard5/12 · optdiff#shard2/12 · optdiff#shard10/12
   7/64  test-core#src:test/test_generic_delphi_method_header_binds_to_the_generic.pas
   5/64  test-core#src:test/test_generic_nested_inline_specialize.pas
   4/64  size-canary#src:tools/size_canary.py
   3/64  tools-devtest#00
   2/64  test-core#src:test/test_libmanifest.pas

THE 41 IS THE TRAP AND IT HAS ALREADY CAUGHT TWO SEATS. In all 41 verdicts that name the lib-test rows they are named FIRST, which reads as "they block everything" — and in the other 23 they are ABSENT, led by optdiff#shard0/12 instead. lib/rtl/sysutils.pas:549 states it as "named first in every one of the 62": the "named first" half is true without exception, the "every one" half is wrong by 23, and the conclusion it supports (this cliff was blocking the pin that would have ended it) is correct for 41 and not for the rest. Quantifier, not verb.

optdiff#shard0/12 is the only universal blocker, but clearing it alone changes nothing — the floor is 4.

THE SURVIVING NUMBERS, RE-DERIVED UNDER A POSITIVE CONTROL — 2026-09-11

Everything in this ticket came out of pin-shadow.log, and the retraction above is about misreading that exact file. So the numbers that SURVIVED were produced by the instrument I had just been shown to be misreading, and leaving them unchecked would be the same error with a better mood. frankZ named the control and it costs one line: grep the file for a string you know IS in it.

  positive control   WOULD PIN 123 · would NOT pin 558 · optdiff 214 · self-host clean 123
  negative control   ZZnotarealjob 0

Re-derived whole-line, which is also the fix for the 39-vs-41 fragment-counting error:

THE COUNT IS LIVE AND GROWS; THE ZERO DOES NOT. Two more verdicts arrived during the hour I spent writing this ticket, so any bare "62" here is correct-when- measured and stale by the next cycle. State it as "zero of N, N still growing", never as a number — a reader who re-derives 64 against a written 62 has no way to tell a stale figure from a wrong one, and this ticket has already produced one of each.

THE COMPLETE BLOCKER SET — 13 distinct jobs, and the census above named 7

The ranked list above is by frequency and is not the whole population. Every distinct job blocking at least one of the 62 verdicts:

  lib-test#src:test/lib_synapse.pas                 optdiff#shard0/12
  lib-test#src:test/lib_synapse_ssl.pas             optdiff#shard2/12
  lib-test#src:test/lib_synapse_transitive_unit.pas optdiff#shard5/12
  lib-test#src:tools/crtl_reachability.py           optdiff#shard10/12
  test-core#src:test/test_generic_delphi_method_header_binds_to_the_generic.pas
  test-core#src:test/test_generic_nested_inline_specialize.pas
  test-core#src:test/test_libmanifest.pas
  size-canary#src:tools/size_canary.py
  tools-devtest#00

RETRACTED 2026-09-11, SAME DAY: THE PIN-ONLY RED IS IN THE FLOOR, AND THERE IS A CIRCULAR DEPENDENCY

The section below is WRONG and is kept because the instrument that produced it is the point. frankZ said "a red that only a pin can clear, sitting in the floor that is blocking the pin." That is correct. I contradicted it with a grep for TPyDeque / mimic_queue / pinned builds live lib/rtl over pin-shadow.log, got zero, and wrote the retraction below.

pin-shadow.log records job IDENTIFIERS, never error text. A job is named for a SOURCE FINGERPRINT of what changed, not for what fails inside it. So the grep did not error and did not return a wrong answer — it answered a question about job names while I read it as a question about failures. The house failure mode, in a ticket whose own body cites that rule two sections up.

What is actually true, from seven.json's job_reason at a45908bcf68e:

  job:    lib-test#src:tools/crtl_reachability.py      (src: tools/crtl_reachability.py
                                                             tools/gen_crtl_map.py +50)
  fails:  lib-units: FAIL mimic_threading
          pascal26:199: error: __pxxclone (thread creation) requires --threadsafe ...
          in: stable_linux_amd64/default/../../lib/rtl/palthread.pas
  blocks: 41 of the 62 post-arming verdicts

crtl_reachability.py itself prints OK inside that job (frankS). The failing thing is the builtin cliff — clearable only by a pin — and make pin is owner-only. So:

A red that only the owner can clear sits in the floor that stops the machine pinning. The fleet cannot break this cycle by fixing tests.

That changes what this ticket is. It is not "auto-pin refuses until someone fixes some reds"; it is auto-pin cannot fire at all until a human pins once, and the policy fork below is therefore not optional — it is the only exit that does not require him to run make pin by hand.

And my 39 was wrong too: whole-line counting gives 41, not 39. I had counted fragments of a comma-split list.

The one thing that survives from below: the gate.sh:533 step and this tier job are two manifestations of ONE defect, not two defects. Conflating them was not the error; asserting the tier side was absent was.

SUPERSEDED — the retraction that was itself wrong, kept for the instrument

frankZ read that red as "a red that only a pin can clear, sitting in the floor that is blocking the pin", which would be a genuine circular deadlock and would make this an owner emergency rather than a ticket. It is not in the floor. Zero occurrences of TPyDeque, mimic_queue or pinned builds live lib/rtl across the whole shadow log, and the reason is structural: it is a tools/gate.sh step (gate.sh:533), not a tier job, and auto-pin qualifies on the TIER.

So there are two separate problems wearing one shape. The gate.sh row blocks every agent's LOCAL gate and is genuinely only clearable by a pin — an ordinary inert-until-pinned row, bad but bounded. The tier floor blocks auto-pin. Clearing either does nothing for the other. Recorded because the deadlock reading is the one a careful reader arrives at, and it would route this to the owner as urgent when the actionable half is five rows with one bisected cause.

NOT an environmental skip, and I checked because it would have been the cheap answer

Makefile:33568 has a loud SKIP for absent synapse (bug-b-lib-test-unrunnable-in-a-fresh-clone-no-synapse-fetch), so "a missing optional library is being counted as a red" was the obvious hypothesis and it is wrong: external/synapse is PRESENT in the watcher's own clone (/home/seven/trackt-watch/external/synapse) as well as in /home/seven/pxx. The skip path is not taken and these are real failures. Recorded because a future reader will have the same idea.

Why this is not a Track T code defect

pin_shadow() -> pin_now() is doing exactly what pin-armed documents: tier full, no red the current pin does not already carry, a live passing self-host job, two consecutive qualifying shas, clean detached tree. Every one of those is sound. The machinery is correct and the policy is the question.

The tension, stated plainly

Two owner rules now point opposite ways, and both are in CLAUDE.md:

• 2026-09-06: "we NEED regular pinning, green or not"; "sometimes we had a worker stop because it was waiting for a pin that never happened"; a red is a reason to pin SOONER.
• 2026-09-07: "let's get back to 'full green expected'" — a pin RUNS a full tier and EXPECTS it green.

CLAUDE.md already says how to break the tie: "An expectation that cannot be met ESCALATES to him; it does not become an indefinite hold." 62 refusals against a 4-red floor whose members are 10 to 26 days old is an expectation that cannot currently be met. The 19-day gap that the old rule was written to prevent (v354, 08-19, last green) started the same way.

The fork, in goal terms, because that is the form he can answer

When the tests are not all green, do we want the machine to keep the compiler's ground current anyway, or to wait until they are?

He has answered a version of this before ("green or not") and then raised the bar ("full green expected"), and the two answers were given three days apart about different situations. This is the situation where they collide.

ALL FOUR lib-test ROWS ARE ONE CAUSE, AND TRACK T ALREADY BISECTED IT

This is the part that changes the work. TSTATE.md gives every one of the four blocking lib-test rows the same range:

  bad fca28056d8ec, last good 0e3ba86d5208, 4 commit(s) in range
    lib-test#src:test/lib_synapse.pas
    lib-test#src:test/lib_synapse_ssl.pas
    lib-test#src:test/lib_synapse_transitive_unit.pas
    lib-test#src:tools/crtl_reachability.py
    (and test-fpjson#src:tools/install_lib_candidates.sh, same range)

So it is one cause in a four-commit window, not four reds needing three lanes, and the header of this ticket listing them as separate owners was reading a symptom census as a work census — the thing CLAUDE.md warns about two sections apart. Five rows, one fix.

The strongest candidate in the window is 0ffe185bb — "feat(B): six System names FPC keeps in system move out of sysutils, and the unit-level scan was a second hole" — the only commit in the range that touches lib/rtl/sysutils.pas (106 lines). synapse leans on sysutils, and crtl_reachability.py walks the crtl/rtl surface, which is exactly what moving six names between units would perturb. The other three commits in range are Track P argument-loop fixes and a tstate row.

NOT CONFIRMED, and I could not confirm it from this box: external/synapse is ABSENT on plexus, so test/lib_synapse.pas stops at uses: unit source not found: synacode and this host SKIPS rather than reproducing. It is present on seven, which is running the watcher — building there would be touching the instrument mid-measurement, so I did not. Whoever takes this should reproduce on a box with external/synapse fetched (tools/install_externals.sh), or on seven while its tier is idle.

What does NOT need him

The four lib-test rows and the optdiff shards are ordinary reds with ordinary owners, and fixing them clears this without any policy change. That is the better path if anyone is free:

• lib_synapse* (3 rows) — Track B
• crtl_reachability.py — Track C / B
• optdiff#shard* — Track O / T

Nobody should WAIT on this ticket. Per CLAUDE.md's own rule, a session must not hold a seat pending a pin. This is filed so the gap is visible and attributed, not so anyone stops.

Supersedes the closed decide-arm-track-t-autopin-the-evidence-gate-cannot-pass-as-written, which asked whether to arm. It is armed. This asks whether armed-and-refusing is what he wanted.

2026-09-19 — the summary was the fourth stale one found in a day, and it was stale UPWARD

Corrected in place. The slug says 99 hours, this summary said 140, and the measured gap is 39 — a human pinned v411 on 2026-09-17. Nobody had re-measured because the number only ever moved in the alarming direction before, and a headline that overstates a problem is not re-checked by anyone who agrees with it.

What that changes: the body's central claim is a CIRCULAR DEPENDENCY broken only by a human pin, and a human pin has now happened. So the interesting question is no longer "why has nothing fired" but "did v411 clear the floor, and has anything fired since" — neither of which is measured here. The 64-verdict statistics predate v411 and must not be quoted as current.

RE-MEASURED 2026-09-19 (frankH): v411 broke the old cycle and made a new one

Instruments, each checked:

• Pins: pin.log plus the pin commits' bodies, not a --grep over prose. v408 09-12, v409 09-13, v410 09-14 and v411 09-17 were all human-authorised, so "no pin since 09-12" was wrong before v411 too.
• Verdicts: pin-shadow.log whole-line, with controls. "WOULD PIN" appears 157 times elsewhere in the file (so the pattern can match); a made-up job name counts 0. After the colon, a verdict lists ONLY the new reds; its item count equals the N it states.
• Job state: borg.json jobs and job_last_pass.

Since v411 (2026-09-17T17:42:06Z): 16 verdicts, 0 WOULD PIN.

The old floor:

The new floor, as the sequence of verdicts:

09-17T18:11 .. 09-18T09:19   5 consecutive verdicts, new=1: ONLY lib_mimic_xml_sax_xmlreader.npy
09-18T09:55 ..               + test_threadsafe_heap_lock_deadlock_diag (8/16)
09-19T06:28 ..               + optdiff#shard11/12, test-esp-idf#compiler_srchash.sh (4/16)

The xmlreader red was introduced BY the v411 pin. Differential: the row's exact command, each pinned binary with its own frozen builtin extracted from git, run over identical live lib/:

The job last passed at 9b8475d4e, v411's source tree. The one observable commit in its regression range is 8d9d69bdc, the pin itself.

The mechanism (distinct from the one filed above): "inherited from the current pin" is computed at the pin's source tree. There, every job built with $(PXX_STABLE) still ran under the PREVIOUS pin. So a pin-built job that the NEW binary breaks is classed as new for the whole life of that pin. It cannot be cleared at HEAD either, because the job only ever sees the pin. Same circular shape as the builtin cliff, and it will recur with any pin that regresses a pin-built job.

What would have made me conclude the opposite:

• v410 ALSO failing the row over today's lib. Then the cause is a lib change, fixable at HEAD, with no cycle. It passed 25/25.
• The five xmlreader-only verdicts NOT being consecutive. Then that red alone was not what stopped a two-sha qualification. They are consecutive.
• Not verified: whether pin_now's other conditions held at those shas (a live self-host job, a clean detached tree). The verdict names only the red criterion. "Would have fired" is therefore "would have passed the red criterion".

Not a pin, and no action was taken. Whether to pin, and whether the inherited set should be measured under the pin's OWN binary, are for the owner.