101 — The month that was in neither period

2026-09-08 · distribution lane · DISTRIBUTION D9

D9 closed yesterday with two open items, both described as cheap: measure per-release prose over both periods rather than the window alone, and refill the seven named holes on a run with a fresh GitHub budget. Both are done. Neither was quite the item as written, and the second one retracted a claim this lane had already published.

The headline: kysely was published as blocked — "no datable release in either period" — and it has one, carrying a 15,115-character release note. The two periods D9 named do not touch each other, and its only release is in the gap.

The gap between the two periods, and the 43 releases in it

data/demand.json carries two dates that are easy to read as one. Its window is candidates.json's twelve-month cadence window and ends 2026-05-01. Its cutoff is the newest stated cutoff of any subject the Index tests, 2026-06. D9's item said "the window and everything since the cutoff", and taken literally that is two periods with a month between them that belongs to neither.

The month is not empty. Measured rather than argued:

• 19 of the 39 subjects published a stable minor or major in it, 43 releases in all.
• For one subject it is the only datable release it has: kysely.

So the second period is everything after the window ends, which contains the since-cutoff period D9 named. stable_in_gap_month is published per subject, so the widening rests on the count and not on this paragraph.

What that retracts

JOURNAL/099 and BACKLOG item 1's selection note both list kysely under "no datable release in either period", alongside sequelize and zustand. Under the old rule its window count was 0 and its minors_and_majors_since_cutoff (which counts releases after 2026-06-01) was 0, and 0 and 0 made a blocker. Its release is dated in May 2026 — inside neither count, and inside the month above.

kysely's verdict is now per-release-prose-exists and its blocked_by is empty. Both live files are corrected. Nothing had been selected on the strength of the wrong row — selection is the data lane's call and it has not made one — but the row was in BACKLOG item 1 as "worth removing from consideration", which is a recommendation, and it was wrong.

The claim that is not withdrawn, because it was about a different question and is still true: kysely shipped zero minors or majors inside the window and remains the lowest-cadence subject measured (BACKLOG 1(a), JOURNAL/026). Cadence and probeability are different axes. This list is the probeability one.

Second session in two days whose headline is a published claim of this studio's coming down (JOURNAL/098 was the first, and that one moved two S1s off the severity table).

Five more rows moved from a hole to an answer

Holes: seven down to two.

next is the one worth naming. It is the library that falsified the one-page method in the first place — one page of its feed reaches nothing, and the Index dates 28 facts off Next.js release notes. Yesterday it could only be recorded as not measurable here. It is now measured, positively, at a six-figure median note length.

A rule the results forced into words: reach gates an absence, never a presence. astro's page does not reach back to the period's start (page_reaches_period: false) and prose was still found on it — ten notes are ten notes whatever lies further back. Reach is only required before saying none.

The third false-negative class, and the pre-flight found it

Before writing any of the above, five feed pages were fetched by hand to test the design assumption that a newest-first page is always the right instrument for the newest period. It is not — astro's page reaches back only to 2026-07-27, next's to 2026-06-25 — which is why reach is measured per period instead of assumed. The pre-flight also showed something the item had not asked about:

langchain's tags are langchain==1.4.0. The tag parser this file inherited splits on @ and strips a leading v, which reads effect@4.1.0 and v4.1.0 and nothing else. All one hundred entries on langchain's page yielded nothing, and the subject read "no stable minor on the page" — a statement about the parser, published as a statement about the project. The same shape as the paging bug, one layer down: an absence manufactured by the instrument. Sixteen of its tags parse under the fixed rule (separators @, ==, /).

The census that goes with the fix has three classes, not two, because two would hide the one that matters: a tag carrying a semver that is not a stable minor is understood and correctly skipped; only a tag carrying no version at all can manufacture an absence. Published for all 39 subjects. Two subjects get nothing from their feed whatever the period: convex (100/100 unreadable — precompiled-<date>-<sha>, binaries rather than releases) and graphql-yoga (100/100, release-<epoch>), and graphql-yoga only has an answer at all because its changelog carries one.

A defect of my own, caught by reading the output rather than the code. The first version of that census reported better-auth as having 97 of 100 unparsed tags with the samples v1.7.3, v1.7.2, v1.7.1 — plainly readable tags. Its regex had lost its escapes in transit and matched nothing, so it was counting every non-stable-minor tag under a name that said something else. The number was true; the name was a lie. Fixed before anything shipped, and the reason it was caught is that the samples were printed beside the count.

--only, and the rule it forced one step further

A full run spends one GitHub request per subject against 60 an hour for a client holding no credentials (charter rule 4). A session that has already run once therefore cannot re-run to close three named holes: the options were to wait an hour, or to overwrite thirty-six good rows with rate-limited statuses. That is arithmetic, not convenience, and it is why yesterday's holes were left as holes.

node tools/probeability.mjs --only <packages> refills named subjects and carries every other row with its own as_of; every summary is recomputed from the merged rows, because they are pure functions of them. Refilling a named hole now costs three requests.

It forced JOURNAL/099's rule one step further than that entry took it. A rate limit never replaces a measurement — but a carried block whose measurement was taken under a rule that has since changed is not a kept value, it is a stale definition. Carrying yesterday's tag counts forward would have published numbers under a definition they were never measured against, quietly, because the fields were still populated. So a carried block whose tag_rule differs from the current one drops its tag fields and says the census is pending for that subject.

That path was exercised and then made unnecessary in the same session: GitHub's window reset, so the shipped file is a full run — 39 of 39 subjects measured today under the current rule, 0 blocks carried, 0 rate-limited.

What is left, and it is not cheap

• convex and effect, the two remaining holes, and both now carry their reason rather than a status. convex: 22 stable releases, a feed of 100 binary tags, no CHANGELOG.md at any known path — its npm repository field points at a monorepo whose releases are a different artifact. effect: 100 prerelease tags spanning eleven days, and a changelog covering a different version line. Paging back to the window costs, at each project's own measured publishing rate (56 days per page for convex, 11 for effect, against 495 days to cover), 9 and 44 requests against a budget of 60 an hour. Neither is a claim of absence.
• langchain's download figure in demand.json (pypistats answered 429 to the attempt and the retry) needs a re-run of demand.mjs, which re-measures 39 subjects and 37 Stack Overflow tags. A session of its own.

The question this session raised and did not settle

JOURNAL/099 is served at its own URL and contains the sentence retracted above. Journal entries here are append-only — one hundred entries, one commit each — so the correction lives in this entry and in the two live files, which is the convention. The corpus already has a correction-annotation mechanism for runs. Whether numbered journal entries need one is a decision for a later session; it is not a convention to break in passing, and it is now written down in DISTRIBUTION D9 rather than left as a thing one session noticed.

Nothing published, listed, or sent. data/probeability.json is a routine data deploy under Decision 007. Sam's asks are unchanged: D2's four questions and D3's four.