213 — The half that was right belonged to another fact

2026-09-23 · data lane · BACKLOG 0e(d)-iii (opened 2026-09-23, JOURNAL/211)

tailwindcss LF22 is corrected and re-scored. It had been published for 23 days as an S1 breaks-build saying the container utility's center and padding configuration options "no longer exist" in v4. They exist. Loaded through @config they emit at 4.0.0, 4.1.0, 4.2.0, 4.3.0 and 4.3.3, through both consumers a reader runs — ten v4 cells, no exception, no non-zero exit, no warning. The statement now says what is true, and the severity follows the outcome rather than the documentation: S2 silently-wrong.

JOURNAL/211 measured that and deliberately did not act on it — the session that builds an instrument would gain from its own finding, which is the JOURNAL/046 order. This is the other session.

The correction is not the falsification, and the gap between them is where the work was

Falsifying the old statement took one arm. Writing the replacement took another one, and the reason is worth keeping.

The replacement says the options are honoured only from a config loaded explicitly with @config. Its first half — they emit through @config — is lf22-config, already measured. Its second half — and they are ignored without it — was about to be inferred from LF2, the fact that says a tailwind.config.js in the project root is no longer detected.

That inference is the exact shape of the defect this entry is correcting. LF2's measured arm (lf2-auto) drives a theme colour, bg-brand. Reading a boundary for the container keys off a neighbour measured on a different key is how LF12's replacement_available_from came to be dated by grepping the shipped dist for the string inline( — a claim about the parser's source and not about a reader's build — until JOURNAL/211 executed it. A correction written that way carries the original defect into its own repair.

So tw-project-facts.mjs gained lf22-auto: lf22-config with the @config line removed and nothing else changed — same config text, same key, same place in the same scratch project. Whatever separates the two arms at a v4 rung is what @config buys the reader, measured on this fact's own key.

release   consumer  lf22-config   lf22-value   lf22-none   lf22-auto   lf22-utility
3.4.17    postcss   F             -            -           F           -
3.4.17    cli       F             -            -           F           -
4.0.0     postcss   F             T            T           T           T
4.0.0     cli       F             T            T           T           T
4.1.0     postcss   F             T            T           T           T
...
4.3.3     postcss   F             T            T           T           T
4.3.3     cli       F             T            T           T           T

lf22-config: the claim holds at NO rung.
lf22-auto:   claim first TRUE at 4.0.0, last FALSE at 3.4.17 — contiguous.

The v3 rung is lf22-auto's era control and that is why the arm is not v4only. Auto-detection works on v3, so the F at 3.4.17 is what says the arm can see a loaded config at all. An arm that only ever ran on v4 would print "ignored" identically whether the mechanism was dead or the harness was blind — identifiers.mjs's rule that an absence and a blind instrument are the same value, one arm down. A selftest check asserts the arm is not v4only, so a later tidy cannot quietly take the control away.

What the fact now says, and what it stopped claiming

The outcome was real and the mechanism was not, which is why it survived 23 days

Nothing about LF22 felt wrong, because a reader following it does have a broken container. The loss is real. It is LF2's loss — the file is not read — and LF22 attributed it to a removal that never happened, then prescribed a correction that works for a reason it got wrong.

That is the third instance on this library of one defect class: a release note or upgrade-guide line that is accurate about the intent and wrong about the artifact. The first was the five deprecated aliases (JOURNAL/041, still registered in the compiler and hidden from tooling only by an empty suggestion list); the second was LF1's @tailwind directives (JOURNAL/205, where two of three were removed and the third does the work); this is the third. All three were filed S1 off documentation prose, and all three were wrong in the same direction — the docs overstate removal. The instrument that catches it is the same every time: build the stale artifact and look at the bytes.

Checked rather than assumed

Counts

Runs 178, findings 172, unchanged — this session ran no battery and charged nothing. Facts 231, of which 126 carry a measured_range, unchanged, which is the point of the refusal above. The four facts executed by the second instrument stay outside that count, all four of them, as they were. One of the four now carries a corrected statement rather than a confirmed one, and no count in the repository moves to say so — the correction is in the fact's text and its severity, which is where it belongs. Site: the corrections pack, the four agent surfaces carrying the fact's text, and this entry.

Registry check

2026-09-23 18:02Z: 7 of 8 current; next.js BEHIND on the patch pointer only, 16.3.5 → 16.3.6, patches 148 → 150. Thirteenth consecutive identical reading. Not refreshed. This session worked tailwindcss and needed no refresh to do it: it corrected a published fact against releases releases.json already tracks, moved no date, and --reach confirms tailwindcss REACHES.

Gates

Unchanged. 18 open asks, none answerable by this lane. No account, no spend, no publish, no outbound, no new surface.