Run tailwindcss--claude-opus-5-5--v6-a--2026-09-28 · self-test: the subject is the operator
The charging arm, and it charges nothing: Claude Opus 5.5 knows Tailwind 4.2.0's logical-property utilities. "Yes" to both verdict-first questions, the right block-axis spacing and logical sizing classes, the task 3 review passed with a correct warning that the classes need 4.2, the start-* deprecation described correctly, ps-4 me-4 for the inline axis with no invented pis-*, and 4.2 dated to February 2026. It also lists three 4.2 contents the prompt never mentions — the mauve/olive/mist/taupe palettes, the webpack plugin and font-features-* — and all three check out. That is one minor above what this same subject stated on its ladder and in v5 the day before, so its uncued boundary under-reports. One uncredited miss: it says py-6 and inset-x-0 are physical, which has been false since 4.0.0, and no fact covers that yet.
| Subject | Claude Opus 5.5 claude-opus-5-5, Anthropic |
|---|---|
| Invoked as | Agent tool, model alias "opus"; prompt sent verbatim from prompts/sent/tailwindcss-v2.txt (3,725 bytes, md5 d444013308540553aefae1d5875bd3e2) — the SAME stored file `tailwindcss/v2` sent to Claude Opus 5, Claude Sonnet 5 and Claude Fable 5 on 2026-09-03. The re-send and its predictions were committed and pushed at 90a40bc before any subject was spawned. Identity probed BEFORE the draw through the same alias in the same session, tool-free: "Opus 5.5 (1M context). Source: system prompt", "`claude-opus-5-5[1m]`. Source: system prompt", "June 2026. Source: system prompt". Nominated in the spec as the CHARGING arm of the Opus 5.5 pair. DISCLOSED: the operator of this studio runs on the same model, so this draw is of the operator's own model (`test.self_test`). |
| Cutoff the model states | 2026-06 |
| Newest tailwindcss release it could place | 4.2.0 · 2026-02-18 (~4 month lag) |
| Oldest tailwindcss release it could not place | 4.3.0 · 2026-05-08 (so this run brackets the subject’s boundary to 2026-02-18 – 2026-05-08) |
| In its own words | "The latest version I know of is the v4.2.x line. I'm not confident that any 4.3 exists. The most recent release whose contents I can describe is v4.2.0, which I think shipped in early 2026 (around February, low confidence on the exact date)." … "The first release I know only as a version number would be anything after 4.2.x, such as 4.2 patch releases or a possible 4.3." |
| How the bracket was read | ONE MINOR ABOVE this subject's own ladder tailwindcss/v4 and both draws of tailwindcss/v5, all on 2026-09-27, all of which described 4.1.0 and held 4.2 as a number with no content. The description is not borrowed from the prompt: of the five things it lists for 4.2, three are named nowhere in the prompt and all three check out — the neutral palettes "mauve, olive, mist, taupe" (all four bg-*-500 compile at 4.2.0 and emit nothing at 4.1.0), "a first-party webpack plugin" (@tailwindcss/webpack, first stable 4.2.0 on 2026-02-18, the registry's own date) and "font-features-*" (compiles at 4.2.0, nothing at 4.1.0). Its date for 4.2 ("around February") is right to the month. So the ladder and v5 under-reported, and this is a ladder/battery disagreement on consecutive days; see the context non-finding. (stop end stated, gap end stated) |
| Library at test time | tailwindcss 4.3.3 (npm), verified 2026-09-27 |
| Battery | tailwindcss/v6-a · 6 tasks, 3 direct questions · probe window 4.2.0 to 4.2.0 |
| Tool uses during test | 0 (a run with any tool use is void — we measure training knowledge, not retrieval) |
| Tested | 2026-09-28 |
| Findings | 0, of which 0 chargeable |
None. Every task in this battery produced code that works on the current release, and every direct question was answered correctly. A run with nothing to charge is kept in the Index at full weight: it is the control that makes the other runs mean something, and it is the evidence for what this model does not need correcting on. What the subject actually said is recorded below.
Recorded so the run cannot be read as a hit list. A model that is right for an obsolete reason is recorded here, not as a finding.
| Kind | API | Note |
|---|---|---|
| correct | pbs-* / pbe-* / mbs-* / mbe-* / border-bs-* / inline-* / block-* / min-inline-* / max-block-* / inset-bs-* |
TASK 1 AND TASK 2, both verdicts "Yes", PREDICTION P1 FALSIFIED. Task 1 markup pbs-6 pbe-6 mbe-4 border-bs-2, task 2 inline-full max-block-96, with the family placed at v4.2 and the arbitrary-property fallback offered only "if you're stuck below v4.2". All six classes compile at 4.2.0 and 4.3.3 and emit nothing at 4.1.0. The pbs-* half is DERIVABLE on this battery (v6-c, far below the floor, wrote it too, while inventing pis-*), so on its own it would prove nothing; inline-full is not — no control in v2 or v6 produced it — and task 4 below shows this arm is not running the naming scheme. |
| correct | pbs-* / pbe-* / mbs-* / mbe-* / border-bs-* / inline-* / block-* / min-inline-* / max-block-* / inset-bs-* |
TASK 3, the review: "I believe it compiles, and every class generates CSS on v4.2+", with a note to confirm the lockfile is on 4.2 because "On 4.0 or 4.1, every class in this line silently generates nothing" — true, compiled — and a correct aside that border-bs-2 alone leaves the colour at currentColor. PREDICTION P2 FALSIFIED: no working class rejected. Opus 5 (v2-a) and both v2 controls told the author the classes generate nothing. |
| correct | start-* / end-* |
TASK 5, PREDICTION P3 FALSIFIED in the good direction: "v4.2 deprecated start-*/end-* in favour of inset-s-*/inset-e-*", "It still works. Deprecated means it still generates inset-inline-start: 0 … It doesn't mean removed", and today's spelling absolute inset-s-0 inset-e-0. All three parts right: start-0 and inset-s-0 emit the same declaration at 4.2.0, and inset-s-0 emits nothing at 4.1.0. Opus 5 was charged on this probe (v2-a F2, S3). The task's own wording ("Is that still the current way…?") hints that something changed, so this pass is the weakest of the three evidence lines and is not relied on alone. |
| correct | ps-* / me-* |
TASK 4, the internal guessing control: ps-4 me-4, "high confidence … since v3.3". Both compile at 4.1.0, 4.2.0 and 4.3.3; no pis-* / mie-*, which compile to nothing at every release. With pbs-* in the same arm this is the v2 spec's recall reading (pbs-* AND ps-*), and P4 held for this arm. |
| correct | 4.2.0 release contents |
TASK 6 and DIRECT (c), attribution: the block-axis spacing, logical sizing and inset-s/inset-e changes placed in v4.2, "around February 2026" (4.2.0: 2026-02-18). And three 4.2 claims the prompt does not cue, all verified: the palettes "mauve, olive, mist, taupe" (bg-mauve-500 etc. compile at 4.2.0 and 4.3.3, nothing at 4.1.0), "a first-party webpack plugin" (@tailwindcss/webpack, first stable release 4.2.0, 2026-02-18) and "font-features-*" (compiles at 4.2.0, nothing at 4.1.0). No fact in data/tailwindcss/facts.json covers the three, so nothing is credited to one; they are the reason this arm's 4.2 answers are read as recall rather than as the prompt's own class names handed back. |
| miss | py-* / px-* / my-* / mx-* / inset-x-* / inset-y-* |
A v3 belief about a v4.0 change, in two asides. Task 1: "(py-6 would also give both block paddings, but it compiles to physical padding-top and padding-bottom. That is exactly the bug you're trying to avoid in vertical-rl.)" Task 5: "Don't swap in inset-x-0, which is physical left and right." Both were true in v3 (3.4.17's corePlugins.js maps py to padding-top/padding-bottom and inset-x to left/right) and are false at every v4 release: compiled this session, 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. The harm is small here — the reader is steered to pbs-*/pbe-* or arbitrary properties, which also work — but a reader asked to fix a vertical-rl bug would be told a working class is the cause. NO FACT covers the change, so it cannot be charged (a finding needs a fact with a primary-source citation); filed in BACKLOG as a candidate fact. Its twin says the inset-x-0 half as well. (No fact in data/tailwindcss/facts.json states the v4.0 move of the axis shorthands to logical properties, and the Index charges nothing from a transcript alone (charter: method integrity rule).) |
| context | — | LADDER/BATTERY DISAGREEMENT, reported as the P1 falsification text pre-registered it. On 2026-09-27 this subject's ladder (v4) and both v5 draws held 4.2 as a number with no content, and v5's prompt (the 4.3.0 surface) cued nothing about logical properties. Today, on a prompt that asks about logical properties without naming a version, it describes 4.2.0 correctly, dates it to the month, and lists three 4.2 contents the prompt does not mention. So this subject's uncued stated boundary on tailwindcss UNDER-REPORTS by one minor, the direction HARNESS names in The order effect is bounded. Consequence for charging: 4.2.0 is recorded as the stated stop end here, which moves charge-windows.mjs's Opus 5.5 cell at 4.2.0 from live to known — and v5's 4.3.0 charges are untouched, because this draw is "not confident that any 4.3 exists" and describes nothing from it. |
Battery specification: prompts/tailwindcss.md in the studio repo.
Every finding above also carries its own citation.