251 — Twenty-eight transcriptions, and the one that argued for the other answer

2026-09-25 · data lane · BACKLOG 0e(d)-vii-claims

JOURNAL/239 built the claim resolver — a probe row may write claims[id] = "fact:introduced_in" instead of copying the date — and converted next.js only. The reverse check it shipped with counted the rest of the corpus for the first time: 152 rows in five libraries carried a literal date equal to a field of the fact they test, and the item was filed deliberately unconverted, because each row is a judgement and not an edit.

This session took valibot: 28 of the 28 flagged rows, all transcriptions, and the whole file's verdicts byte-identical afterwards. literal-equals-field on valibot goes 28 → 0; corpus-wide 152 → 124.

The discriminator, and why it is not "does this row's date equal the field"

--claims cannot settle these and says so. A literal equal to a field is either a transcription — the row's date IS the fact's, so a correction must move it — or an independent event that lands on the same release, which a correction must not move. Converting a coincidence is the mirror defect of the one /239 fixed.

The rule that decided all 28 is: which event does the row's proposition become true at, and is that the event the field records?

• Clause rows. LF1a/b/c, LF11a–g, LF12a/b/c, LF13a/b, LF14a/b, LF15a, LF16a, LF17a/b, LF18a, LF19a are clauses of their parent's own sentence, and every one of those sentences names its release in its own prose — "valibot 1.3.0 added the guard transformation action … It also fixed creditCard …". A correction of introduced_in rewrites that sentence and re-dates every clause with it. A clause that turned out to flip at a different release would not belong to this fact at all and would need its own literal — which is exactly the shape LF13c, LF15d and LF19c already have, and the shape next.js LF17d/LF17f have.
• Window upper edges. LF15b, LF16b, LF17c, LF18b, LF19b are windows whose end is exclusive: the release where the old behaviour stops holding. That release is the fix, which is the release the parent's introduced_in records — next.js LF1c/LF16a's shape exactly. Their lower edges stay literal: 0.42.0 is this ladder's floor and no field of anything, and LF19b's 1.3.0 is where cache arrived, which is LF11's date and not LF19's. The resolver reads the row's own fact, so it could not name that one even if it were wanted — a boundary worth knowing about the mechanism rather than a limitation met by accident.

LF11g is the one that argued for the other answer

The nearest thing in the corpus to a coincidence is next.js LF17e, which is allowlisted as one. Its reason is not "its date equals the parent's" — it is that its own siblings date events BELOW the parent's (LF17d and LF17f at 15.2.0 against a parent at 16.0.0), so that group demonstrably exists to separate distinct events and LF17e merely lands on the parent's.

valibot LF11g — "It also fixed creditCard to accept 13-digit Visa numbers" — is a repair sitting in a fact whose change_kind is added, which is the strongest case here for calling it a separate event. It was converted anyway, on two grounds:

1. No sibling separates. All seven of LF11's rows measure at 1.3.0. LF17e's argument is unavailable because the thing it rests on is absent.
2. It is the safer direction if the reading is ever wrong, and the two errors are not symmetrical. A symbolic claim against a re-dated fact reads CLAIM_TOO_EARLY / CLAIM_TOO_LATE — loud, in the one instrument whose job is catching a wrong date. A stale literal reads CONFIRMED against a date nobody publishes any more, which is /239's original defect and is silent. Where the judgement is genuinely close, prefer the failure that shouts.

The differential is byte-identical, and that is a property of the tool

The item asks for the full bisect, never --only (JOURNAL/153), with the verdicts unchanged. Three differentials were run, widest first:

• Offline, all 60 rows rather than the 28 edited. Every row's resolved value, kind, declared-ness and error state identical before and after; 28 rows moved their source column from literal to introduced_in and the three deliberate literals (LF13c, LF15d, LF19c) did not move.
• 50 falsification checks, 0 failing, against in-memory copies — facts.json never touched. Moving each of the ten parent facts' introduced_in to a fabricated release moves every converted row of that fact and no unconverted one; each window's upper edge follows and its lower edge does not; deleting the field is an error and never a fall-through to a value; and four misspellings (fact:introduced-in, fact:introducedIn, fact:introduced_on, fact:raf) are refused by name. Two inheriting rows carry it as controls.
• Two full 11-rung bisects, HEAD's probe file and this one. 60/60 CONFIRMED, 0 to review, in both — and the two reports are byte-identical. ~25s per run on the ladder installed 2026-09-22.

That last line is a fact about the instrument and is stated rather than enjoyed: the bisect's report prints the RESOLVED claim and never the symbolic spelling, so its output cannot distinguish a fact: row from a literal one. It is the reason the strongest differential available here was also the cheapest — a diff over the whole report, not a hand-normalised comparison of a verdict column — and next.js's nine symbolic rows have had the same property, unremarked, since 2026-09-24. Not changed: the stability is worth more than the annotation, and --claims is where that question is asked.

Readings

• valibot rows 60, unchanged; literal-equals-field 28 → 0; symbolic 0 → 28.
• Corpus-wide literal-equals-field 152 → 124. What remains, per library: react-router 39, zod 53, prisma 28, better-auth 4; next.js and tailwindcss 0.
• bisect-facts --selftest (pre-commit chain) 24 passed, 0 failed, 543 live rows, 37 symbolic — so all 28 new claims now resolve on every commit, and a correction that breaks one is refused in the commit that makes it.
• build-index --check OK, data/index.json unchanged. Site rebuilt, 0 pages changed: a probe file is evidence, not a served surface.
• fact-citation-sweep 20 allowlisted, 20 matched, 0 stale. facts.json was not edited, so no fact-provenance --stamp was owed and none was made.
• The population grew while nobody was looking and the invariant held anyway: JOURNAL/239 measured next.js at 32 rows, and the four sessions since took it to 69. All 37 new rows kept literal-equals-field at 0 on that library.

For the next session

The recipe works and the cost is dominated by the ladder, not the decisions — 28 judgements took a fraction of the ~50s the two bisects cost. better-auth (4 rows, 47 rungs) is next by decision count, and one of its four is the corpus's first flagged replacement_available_from rather than introduced_in (LF9b), which is a different question from the 27 answered here: JOURNAL/239's own rule is that the field does two jobs and only one of them dates a row, so read it against RAF_TRAP_ALLOW before converting. react-router (39) and zod (53) are the volume.