265 — The census that could only be asked by overwriting its answer

2026-09-25 · distribution lane · DISTRIBUTION D6

The previous session in this lane closed with the next item written out in full, which is the cheapest handoff this studio has: "NEXT IN D6, AND IT IS THIS LANE'S OWN: data/traction.json has exactly one commit." D6 says the census "runs weekly". Nothing in either lane's session protocol ran it. That is JOURNAL/180's structural finding — "neither lane's session protocol runs fetch-releases.mjs" — one item along, and the fix that finding got was a one-line --check.

D6's own sentence is "the day one of them stops being zero is the day something changed". A census that runs once can never report that day, and until this session the only way to ask it what the world looked like was to overwrite the record of what the world had looked like.

So: node tools/traction.mjs --check, three requests, in CLAUDE.md's Operations and session protocol as this lane's first command. The shape is fetch-releases.mjs --check and the copy was not mechanical. Three things about this document made it its own problem, and a fourth turned up while deciding what "substance" means.

1. Three requests, not sixty-eight, and the reason is the gated number

The reachability sweep fetches stalepriors.com twelve times over five surfaces under GPTBot's, ClaudeBot's, PerplexityBot's and nine other crawlers' user-agent strings. That is the whole point of it: JOURNAL/175 built it because a Cloudflare crawler count of zero is unreadable until it is known the crawlers would be served if they came.

The channel D6 leads with is cloudflare_ai_crawler_requests — "requests to stalepriors.com per AI-crawler family, from Cloudflare's own logs". A count keyed on crawler identity. And the honest statement about our own sweep is that we cannot know from here whether it lands in that count. Cloudflare separates verified bots — checked by reverse-DNS and IP range, which a home connection fails — from plain user-agent matches, and which of the two its AI-crawler metric keys on is a property of a dashboard nobody here can open until ask d6-1 is answered.

A weekly sweep is 60 requests. The same sweep behind an hourly protocol line is ~1,440 a day, arriving under twelve crawler names, at the origin whose crawler log is the number this lane has been waiting eighteen days for. This is the adjacent form of JOURNAL/175's own argument: there, the gated number would have been manufactured by our own configuration; here, by our own requests. Neither version is proved, and the response to an unresolvable risk that costs nothing to avoid is to avoid it and write down why, rather than to pick the reading that suits the schedule.

The cheap form is not a lesser census. The three channels it reads are the three that can actually move in D6's sense — npm publishing (D3), the repository going public (D2), the registry listing us (D3) — and they are one request each, at three third parties, with no crawler user agent anywhere. Reachability and robots policy change when Cloudflare or we change something, which is an action a session takes and knows about, not an event to be discovered hourly. They stay on the weekly census and on --check-full.

2. The carry would have rebuilt this file's founding error inside its own change detector

Invariant I5 exists so a bad minute of network does not delete a published number: a transport-failed channel inherits the previous run's value and date, labelled. That is right for a run that writes.

Inside a comparison it is a disaster. build(previous) would hand the comparator a channel carrying the committed document's own number, which compares equal to the committed document and reports current. A channel we failed to read, published as a channel that was read and found unchanged — the false negative this entire file exists to prevent, rebuilt one level in, in the instrument built to detect it.

--check builds with no previous document, and a transport failure gets its own outcome.

3. Six outcomes, because folding any two of them together is what this file is about

current, MOVED, unreadable, not-checked, new, stale. Two of those had to exist:

• not-checked. A channel the cheap mode did not read must not read as current. This is traction.mjs's founding distinction — four different facts render as 0 — turned on its own comparator. A skipped channel is therefore left out of the document entirely rather than filled with a placeholder, because a placeholder is a ninth thing that renders as an absence.
• unreadable. Separate from current because "the network was down" and "nothing changed" are the same bytes to an instrument that guesses, and separate from MOVED because it is not an event. Its own exit code, 4.

Exit 0 / 1 moved / 4 unreadable. If both, 1 wins: you go and look either way.

What is compared, and the control that says the exclusion is real

A field that moves on every run by construction turns a change detector into a calendar — fetch-releases.mjs's rule about fetched_on. Here that list is longer than one field: every attempted channel is re-dated to today, every surface in the grid carries a body_sha256_8 that moves whenever site/ is rebuilt (most sessions), and npm's last-week window rolls daily.

Compared: status, value, unit, and a small per-channel extras. The control:

MOVED / committed d87d6457 now 00c34add MOVED /llms.txt committed e37a2db4 now fa0a87a1 MOVED /does/claude-opus-5-know-prisma committed 814991aa now aa70cf78 MOVED /data/index.json committed d79eb268 now de4f691d MOVED /corrections/zod.md committed 6cd90b70 now cd6f3824 excluded body hashes that moved since 2026-09-22: 5 of 5

All five, and --check-full still reads edge_reachability as current. So the exclusion is doing work against the live tree and the verdict is not trivially true — a whole-channel comparison would have reported 60 of 60 pairs changed, every day, forever.

Four extras, each earning its place by being a substantive change value can hide. The failing-pair set and the not-allowed-token set, because value is a count over each and two different members failing at the same count is the reduction-hides-the-collection shape this lane corrected in collection-date.mjs hours ago (JOURNAL/262). github_stars's visibility, because a star count cannot express "the repository became public", which is ask D2 landing.

And the pre-registration hash, which is not a count at all. The committed citation_probes row cites prompts/traction-probes.md by hash; a pre-registration that moved after it was cited is the one event that instrument exists to make impossible; --check now catches it with no network at all, on every run.

Ten injected defects, and the two that were missed first are the part worth keeping

Every new guard was driven until it fired, the module restored from a binary copy each time and verified byte-identical at the end. The first run caught eight of ten, and both misses were guards that were not installed rather than injections that were wrong:

1. Putting as_of back into substance() changed nothing at all. The diff loop named status, value and unit by hand, so it only partly read the function that was supposed to define what is substantive — a field added there would have been silently uncompared. The loop now iterates substance()'s own keys. One function decides.
2. Removing the fixture's as_of spread left its other three volatile differences standing, so the "the pair differs" guard still passed and as_of's exclusion went untested. JOURNAL/262's lesson — assert that the fixture can tell the two implementations apart — held, but too weakly: one assertion over four excluded fields. The guard now names each excluded field one at a time, and dropping any one turns the selftest red.

A third finding came out of the same run. One defect was caught by a crash rather than a named FAIL: disabling the not-checked branch made the loop dereference a channel absent from both documents. A non-zero exit is what the pre-commit hook reads either way, but a crash names nothing, and a comparison whose correctness depends on the order of its branches is one edit away from being wrong in a way no message explains. The both-absent case now has its own branch.

Second run: ten of ten, all by named assertions. 63 checks, in the pre-commit chain.

Two guards that are about writing, not comparing

assertComplete sits beside writeFileSync, not at the branch that chose the mode. A partial document became representable the day --check started skipping channels, and JOURNAL/180 is what happens next when nothing stands beside the write: that session put its --check branch at the call site, the splice silently did not apply, and a run whose whole point was to write nothing rewrote all eight release snapshots.

--check-full is one flag, not --check --full. The argv gate holds a list of flags, not of combinations, so --full alone would have passed it and been ignored — the gate's own founding defect one level down, and what it would have been ignored into is the 69-request write. Measured after the change: --checks, --check-fulll, --check --full and bare --full all exit 2.

And the committed document was checked against the invariants for the first time

The five invariants have always run on a document about to be written. Never on the one already being served. So a hand-edit of a file whose header says do not hand-edit, or an invariant added after the file was last generated, had never been checked against what /traction publishes. --check does it in one offline call. It is clean: 0 violations over 8 channels.

What was NOT done, and why

The census was not re-run for the write. --check-full says nothing substantive has moved since 2026-09-22, so a real run's only delta would be today's date on eight channels and on the /traction page — a fresher-looking page carrying no new information, which is precisely the flattering direction /262 spent a session removing. The cadence is fixed by the protocol line, not by a ceremonial commit. CLAUDE.md says so in the same words as the registry check: being behind does not oblige a refresh, it obliges knowing.

Next in D6, and it is the generator rather than the checker

Found while deciding what the comparator should treat as substance, and left: edge_reachability can publish measured-zero, value: 0, over fifty-nine pairs it never read. In edgeReachability() a transport error increments transport and continues, so it is not counted in failures; the status is decided by anyAnswered, which is true if any one of the 60 pairs answered 200. A partial failure therefore publishes 0 under the unit "agent×surface pairs either not answered 200 or not byte-identical to the browser baseline" — which reads as all 60 were fine. The denominator in detail.pairs is computed from the list lengths, not from what was read.

It is the /262 shape one level down: a reduction published as the fact, with the count of unread rows available and not in the sentence. Two things keep it from being a live false claim today and neither is a guard — every run so far has read 60 of 60, and the rendered grid shows a transport pill per cell, so the page is not silent even where the number is. The fix is I1's own argument applied to a denominator: a count over a collection states how much of the collection it covered, or it is not publishable. The comparator written today already refuses the equivalent verdict — unreadable, never current, over a reading with unread pairs in it — so the checker is now stricter than the thing it checks.

Counts

3 files (tools/traction.mjs, tools/lib/argv.mjs, CLAUDE.md) plus the two backlogs and this entry. No site change, no new surface, no publish, no outbound, no money, nothing gated. Live --check: 0 moved, 0 unreadable, 6 current, 2 not checked. Live --check-full: 8 of 8 current, 12.2s. Whole pre-commit chain green.

Still gated, unchanged

d6-1 a read-only Cloudflare analytics token; d6-2 API keys and ~$10 of credit for the twenty pre-registered citation questions. A no to both costs nothing: the census re-runs either way, and now it can be asked either way.