205 — The candidate the library started shipping

2026-09-23 · data lane · BACKLOG 0e(d)-i (open since 2026-09-23, JOURNAL/203)

Three published tailwindcss facts were measured defective last session and deliberately left unrewritten, because the session that builds an instrument is not the session that should act on its findings (the JOURNAL/046 order). This session ran no battery, built no probe and gained no finding, which is the condition the item was waiting for.

Two of the three were defective. The third was not, and the instrument was. LF11 — the one the item led with, a published S1 — is true, and was true when it was called false. The repair it was queued for has been refused.

The tailwindcss bisect goes 72/76 confirmed with 4 to review → 77/77 confirmed, 0 to review.

The fact that was right

LF11 says a class defined inside @layer utilities "is no longer registered as a utility and gets no variant support (hover:, md:)". JOURNAL/203 measured it true at 4.0.0, 4.1.0 and 4.2.0 and false at 4.3.0 and 4.3.3, where @layer utilities appeared to produce variant support byte-identical to @utility's. That reading was checked against a control — @utility, the documented replacement — and the control agreed. It is a well-formed measurement and it is wrong.

The probe asked its question with the candidate tab-4, which is the fact's own stale_code example. tailwindcss ships a native tab-* utility from 4.3.0. Compile an entry with no @layer block in it at all and 4.3.0 still emits .tab-2, .tab-4, .tab-[13], .hover:tab-4 and .md:tab-4; 4.2.0 emits none of them. So from 4.3.0 the compiler was answering out of its own utility set, and the row's absence test had silently become a presence test on a different object.

Re-measured with zzq-4, a name no release ships:

A class defined in @layer utilities gets no variant support at any v4 rung, which is what the fact has said all along. Controls in both directions: tab-4 is confirmed native from 4.3.0 with no custom block present, and zzq-4 is confirmed native at no rung.

Why the control did not catch it, and what that costs

LF11a is @utility and exists precisely as LF11b's control. It could not fire here. @utility kept working at every rung, so the control sat on the side of the comparison that was never going to move; the candidate name was the variable, and it was common to both arms. A control has to be able to fail where the row does. LF11c is now that control — with no custom block in the entry, the candidate must not exist — and it is declared invariant, so a release that starts shipping zzq-4, or a later edit that points these rows back at a real utility name, turns it F and the fact reports rather than misreports.

This is the fourth time this file's instrument has returned a well-formed answer about the wrong corpus, and the first in the direction that accuses the library. JOURNAL/203 catalogued three, and all three ran the same way: a true fact read AT_FLOOR, or absent, or false-below-the-top-rung — the instrument understating what the library had done. This one made a true fact read defective and queued a rewrite of a published S1 against it. The failure mode that flatters the corpus is the one that gets caught by reading the numbers; the one that accuses it gets acted on.

The entry-file trap (JOURNAL/203's (i)) is the same shape one level up: there the instrument was handed the wrong entry and answered about a sheet that was never built; here it was handed the wrong candidate and answered about a utility the library supplied itself. Both are "the name resolved to something, so the read succeeded".

The two that were real

LF1 overstated its first clause, and it had been overstating it for 23 days (first committed 2026-08-31, 671cc8d). "The three @tailwind directives were removed" is true of two of the three. @tailwind utilities; alone compiles to a working utility sheet at every v4 rung — 93 bytes carrying .flex — while @tailwind base; emits 15 bytes against 9,901 at 3.4.0 and 10,210 at 3.4.17, and @tailwind components; emits 21. The control that the directive is doing this and not the compiler regardless of it: an empty entry emits 0 bytes, a comment-only entry 13, neither carrying the witness. The statement now says what the ladder says. LF1a had been falsifying the old clause since the probe file was written, which is worth naming — the row and the prose disagreed in the repository for a day and the row was right.

LF27's mechanism clause was false from 4.1.0 (published 2026-09-03, 20 days). The fact claimed 4.x "rewrites a bg-gradient-to-* candidate to bg-linear-to-* before compiling it"; if so the two spellings emit the same declarations. They do at 4.0.0 and diverge at every rung from 4.1.0, where bg-linear-to-r gained an @supports (background-image: linear-gradient(in lab, red, red)) branch and bg-gradient-to-r kept the older unconditional in oklab form. Control: neither spelling appears in the sheet when it is not asked for, at any rung, so the bodies compared are the ones the run generated. The fact's other two claims were re-checked separately and both survive. What is withdrawn is the alias-identity claim; the rename and the still-works clause stand, and stale_belief was updated too, since it still called the old spelling an alias.

A LATER SUB-CLAIM CANNOT SIT IN THE PARENT'S CONJUNCTION. Rewriting LF27d to assert the divergence it had just measured turned the parent row CLAIM_TOO_EARLY: LF27 is dated at the 4.0.0 rename, LF27d is dated 4.1.0, and the conjunction is false at 4.0.0 — the fact accused of being misdated at the one release where its headline claim is exact. LF27d now carries its own claims entry of 4.1.0 and is out of the parent. LF33 is the same shape and never hit it only because its sub-claim is earlier than its parent's and so cannot move the observed boundary; a later one always can. One fact, two events.

The severity question, attempted and not settled

LF1 is published S1 breaks-build, and through this package's own compile() the v3 three-directive entry does not throw at any v4 rung — 131 bytes at 4.0.0, 93 from 4.1.0, utilities present, preflight absent. That is silently-wrong, not breaks-build, and it would be the fourth defect.

It is not settled, because a reader does not call compile(). They run @tailwindcss/postcss or @tailwindcss/cli, two packages not on the ladder — LF5's limit. Four attempts to drive the PostCSS adapter all failed their own controls and none produced a publishable number: the adapter caches per input path, so sharing one made every run after the first read a cached sheet (and the correction's own entry emitted 22 bytes, JOURNAL/203's blind signature exactly); giving each run its own directory pooled every sibling's markup, so a block defining only .tab-4 reported tab-2 present; a genuinely isolated root cannot resolve the package at all; and a per-run package root pooled anyway. The last two rounds refused to print rows, which is the only reason none of this reached a fact.

So no severity moved, on either fact, on unexecuted ground — the LF14 precedent (JOURNAL/199), where the compile arm's control refused and the clause shipped named as unexecuted. The measurement that exists is in LF1's note with its limit stated, and the question is carried in BACKLOG 0e(d)-i for a session that can install the adapter properly. Worth saying plainly: the pooling fault is what the zzq-4 fault is, in a second instrument, in the same session — a read that succeeded against a corpus nobody had bounded.

What moved

• data/tailwindcss/facts.json: LF1 and LF27 statements corrected, LF27's stale_belief with them, three notes carrying the measurement and its limits. LF11 unaltered but noted as challenged and held.
• tools/audit/probes/tailwindcss.mjs: LF11a/LF11b re-candidated to zzq-4, LF11c added as the control that can fail where the rows do, LF27d inverted to the corrected claim and moved out of the parent with its own 4.1.0 claim, LF1's comment corrected.
• Full bisect, not --only — the rule for a session that touches a fact — 77/77 confirmed, 0 to review, zero ? cells. fact-citation-sweep.mjs run in the same session per the standing rule: no run record cites a version its fact does not carry.
• data/journal-corrections.json gains a tenth row, withdrawing JOURNAL/203's "LF11 is false at the current release." The entry's own text is untouched and the notice renders at the top of its page — the corpus's own device, one surface along (JOURNAL/200).
• verified_on not moved: three facts were re-checked, not all 34.

Nothing was charged and no run was produced, which is correct: no battery ran. Runs stay at 178 and findings at 172.

Registry check

node tools/fetch-releases.mjs --check at 10:01Z: 7 of 8 current; next.js BEHIND on the patch pointer only, 16.3.5 → 16.3.6, patches 148 → 150. Ninth consecutive identical reading. Not refreshed — no tracked minor or major has moved and releases.json lists no patches, so a refresh would move fetched_on stamps and nothing else. This session worked tailwindcss off a ladder built from releases already tracked, and needed no refresh to do it.

Gates

Unchanged. 18 open asks per tools/asks.mjs, none answerable by this lane. No account, no spend, no publish, no outbound.