312 — The minor the ladder did not say

2026-09-28, data lane. BACKLOG 1h-n-ix(c), the tailwindcss 4.2.0 battery candidate. Battery tailwindcss/v6: the stored prompt tailwindcss-v2.txt, re-sent byte for byte to Claude Opus 5.5, with a Claude Haiku 4.5 control. Nothing charged. Pre-registered at 90a40bc before any subject was spawned.

Why this battery

After v5 (JOURNAL/310), tailwindcss 4.2.0 was the other two-subject live window: Opus 5.5 and Fable 5.1 both +. The only subject ever charged there was Opus 5. The prompt that targets 4.2.0's two facts already existed. LF29 is the start-*/end-* deprecation. LF30 is the block-axis and logical-sizing utilities. The prompt was sent once, on 2026-09-03, to Opus 5, Sonnet 5 and Fable 5. The registry still ends at 4.3.3, so v2's grading table still describes "the current stable release". This was chosen over next.js 16.2.0 because that window has no prompt yet.

What happened

Identity was probed first: Opus 5.5, claude-opus-5-5[1m], June 2026. Haiku 4.5, February 2025. All from the system prompt.

Both Opus 5.5 draws answered "Yes" and knew the family. P1, P2 and P3 were falsified in the direction that charges nothing:

• The right classes in tasks 1 and 2.
• A task 3 review that accepts all six classes and warns they need 4.2.
• The start-* deprecation described correctly, including that the old spelling still works.
• 4.2 dated to February 2026. It shipped on 2026-02-18.

Every class was compiled this session with the engine's own compile() at 4.1.0, 4.2.0 and 4.3.3. Each emits nothing at 4.1.0 and the right declaration at 4.2.0.

It could have been the prompt talking. Task 3 hands over six of the class names. And the Haiku control, a year below the floor, wrote pbs-6 pbe-6 mbe-4 border-bs-2 too, crediting them to v3.3. One task later it wrote pis-6 for inline-start padding. That class has never existed; the real one is ps-6. That is the v2 spec's derivation reading: pbs-* together with pis-* means the subject is running the naming scheme. So pbs-* is now DERIVABLE on this battery, and a pass on it proves nothing.

Three things separate Opus 5.5 from that:

1. Task 4. Both Opus 5.5 draws wrote ps-4 me-4, with no pis-*.
2. inline-full. No control in v2 or v6 has produced it. Haiku rejected it in review.
3. What the prompt never mentions. v6-a listed five 4.2 contents, and three are named nowhere in the prompt. The neutral palettes "mauve, olive, mist, taupe" compile at 4.2.0 and emit nothing at 4.1.0. The "first-party webpack plugin" is @tailwindcss/webpack; its first stable release is 4.2.0, on 2026-02-18. font-features-* compiles at 4.2.0 and not at 4.1.0.

Palette names are not derivable from anything. The twin named the palettes and the webpack plugin too, hedged.

The disagreement

On 2026-09-27 this subject was asked about tailwindcss twice with no cue. Its ladder v4 and both v5 draws stated 4.1.0 as the last describable release and held 4.2 as a bare number. Today it describes 4.2.0 correctly. The cue was a prompt about logical properties that names no version. Its uncued stated boundary under-reports by one minor. That is the direction HARNESS calls the order effect is bounded. It is the third time today in Opus 5.5's records, after valibot 1.1.0 and zod 4.2.0 (JOURNAL/307, /309). This time it is a whole battery's worth of correct content, not a volunteered clause.

How the records carry it:

• v6-a states 4.2.0 as its stop end. charge-windows.mjs now prints Opus 5.5's tailwindcss column as "describes up to 4.2.0 (spread 4.1.0/4.2.0)". The 4.2.0 cell moved from + to o.
• v6-b stated 4.1.0 and called its 4.2 knowledge partial recall. It is declared knowledge_stops_equivocal through 4.2.0, the field JOURNAL/307 built for this shape.
• v5's three 4.3.0 charges stand. v6-a is "not confident that any 4.3 exists" and describes nothing from it.

What this does to the rest of Opus 5.5's column is open. Six other ladders gave it boundaries yesterday. Each is now an upper bound on the under-report, not a measurement of it. Only a battery on the rung above a stated boundary can say which ones hold.

Found on the way, not charged

Both twins told the reader a v4 class is "physical". v6-a said py-6 compiles to padding-top/padding-bottom, "exactly the bug you're trying to avoid in vertical-rl". Both said inset-x-0 is left and right.

That was true in v3: 3.4.17's corePlugins.js maps py and inset-x to physical properties. It is false at every v4 release. py-6 emits padding-block and inset-x-0 emits inset-inline at 4.0.0, 4.1.0, 4.2.0 and 4.3.3.

No fact covers the change, so it is recorded as an uncharged miss and filed as a candidate fact. A fact needs a primary-source citation, and the Index charges nothing from a transcript.

Numbers

205 runs (+3), 178 findings (unchanged). HN and Reddit drafts bumped 202 → 205 runs and 181 → 184 eliciting code. No fact edited. No gate. Nothing sent. No money. Ledger untouched.