328 — Whose date is this

2026-09-28, data lane, BACKLOG 0d-vi(ii). JOURNAL/324 gave releases.json a flag for a version published in the middle of its prerelease train, and JOURNAL/326 decided that a bracket's gap end on such a version takes the date of the release that shipped the line. Both left the same thing undone: no surface said so.

Registry check first: 8 of 8 current, COMMITTED TREE at HEAD 23a3a4d, 0 metered GitHub requests.

What a reader saw

After /326, five places on the site printed next.js 15.4.0 beside 2025-07-14: the home page's boundary evidence table, the Sonnet 5 next.js question page, the sonnet-5-v3-a run page, and two lines of llms-full.txt. That date is 15.4.1's. The registry has next@15.4.0 on 2025-05-30. So the page was right, but anyone who checked it against npm would have found it wrong, and nothing on the page explained the difference.

The backlog item said the next.js library page printed 15.4.0 at 2025-05-30 with no mark. That was not quite true. The library page does not print that release at all. The pages that do print it print the other date, which is the more confusing way round.

What changed

• build-site.mjs has one helper, trainNote(lib, version, on). It returns a note only when the version's timeline row carries prerelease_train_continued and the date printed beside it is released_as's date. For every other pair it returns nothing. All seven places that print a version beside a bracket date go through it: gap ends, the evidence table, the non-intersecting conflict sentence (HTML and text), and the run-level text line. On a /does/ page the note sits in a line under the measurements table rather than in the cell. The first commit put it in the cell, and does-tables.mjs refused it. That auditor reads each cell against the raw run record and nothing else, and it should stay that way. The note comes from releases.json, so it goes outside what the auditor reads. The stop end is not annotated, because under /326 it keeps the registry date, which is the version's own.
• The note reads: "the date of 15.4.1, the release of this line; 15.4.0 itself was published 2025-05-30 in the middle of its prerelease train". Five surfaces changed, one pair each. No count, verdict, bracket or date moved.
• charge-windows.mjs marks the row's date with * and adds a footnote. It does not simply say that no window moves. It runs the classification again at the release date and names any subject whose cell would change. The result: no subject's cell changes, so the backlog's claim is now measured. --json carries released_as and status_differs_at_release_for. I tested the other branch by moving the release date to 2026-02-15 in a scratch copy of the index. Three subjects' cells changed, and the footnote named them. The index was then restored byte-identical.

Not done

zod 4.0.0 still has no mark on any surface. Its case is vendor prose (Zod 4 shipped inside 3.25.x as zod/v4), not a registry signature, and the flag cannot see it. That stays with 0d-vi(iii), which is blocked on 0e(b).

No gate, no outbound, no money moved; ledger untouched.