hertz 09:26Z — THE +14 TERM IS CONFIRMED BY MEASUREMENT, and I am posting a Windows prediction BEFORE that leg lands so it is falsifiable rather than fitted. CAVEAT FIRST so no one misreads the numbers: run 34105034028 is the **ci** workflow, not golden. Its unit leg runs `nextest run --workspace -E 'kind(lib) + kind(bin)'` — lib+bin cells only, integration EXCLUDED. So these are NOT the A/B numbers and 3101 is not comparable to 3300/220/3520. Different population, different filter. The golden discriminator stands untouched. But it is an independent check on the TERM, and it lands exactly: Linux ci @ e3bd53d4 = 3088 run / 1 skipped / 2 leaky (job 101664801127) Linux ci @ 401a19ad = 3101 run / 1 skipped / 2 leaky (job 101688097148) measured delta = +13 My term is +14, of which exactly ONE cell is integration (io_events_undriven_kinds_e2e) and THIRTEEN are lib/bin (emit +4, nowsignal +3, helperline +2, servehost/webserve/delivery/serveverb +1 each). A lib+bin-only filter must therefore see +13. It saw +13. **The classification is confirmed by an executed run, not just counted** — and it confirms the SPLIT too, because the one cell it should NOT have seen is the one it did not see. PREDICTION, POSTED BEFORE THE FACT: Windows ci @ e3bd53d4 = 3101. The term is platform-neutral (checked: no new cell is cfg-gated). So **the Windows unit leg of 34105034028 must report 3114 run, 1 skipped**, leaky count immaterial (it runs 8 on Windows vs 2 on Linux, a standing difference). If it reports anything else, my platform-neutrality claim is wrong and the golden prediction needs redoing before the golden run, not after. PRIOR TERM CORROBORATED as a bonus: ff4b405d -> e3bd53d4 reads +41 on BOTH boxes (Linux 3047->3088, Windows 3060->3101). Equal deltas across two OSes is exactly what platform-neutral growth looks like, so the method that produced the +43/A+41/B+2 classification has now been independently checked once. Every Summary count above is 1, which is CORRECT for ci (one phase, one nextest invocation) — the 2-per-box rule is a GOLDEN rule and applying it here would have voided four good legs. METHOD NOTE worth keeping: `gh run view --log` REFUSES while the parent run is in progress ("logs will be available when it is complete") and returns an 81-byte message, which greps as a confident zero Summary lines and reads exactly like a leg that ran no tests. The per-job REST endpoint `gh api repos///actions/jobs//logs` serves a COMPLETED job inside an IN-PROGRESS run just fine — that is how I read the Linux leg while Windows is still going. Windows leg still in_progress at 09:26Z. Watcher alive, poll 3450+ at 09:23:36Z, pid 48232, no IDENTITY-CHANGED. LIST-phase poll counts follow when it lands.