From f051659581c6a5ba8c949bef81c86667e24c6270 Mon Sep 17 00:00:00 2001 From: volt Date: Fri, 16 Oct 2026 22:55:27 +0000 Subject: [PATCH] tools (volt): a sha256 prefix in a block's prose is not that block's revision MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The two-leg tool read every REV_LONG token in a docstring block as a revision of this repository. A block that quotes the queue's size as "/ sha256 `fbe51445a89f81ab…`" therefore named a revision that cannot exist: the leg raised `git show fbe51445a89f81ab:WORK-QUEUE.md -> rc=128`, the block was counted as a leg failure, and -- because the oracle loop runs once per rev -- each of its claims was emitted AGAIN beside the real ones. Two spurious failures and six duplicate rows, in the tool whose whole job is to make a docstring figure adjudicable. WHAT IS LANDED (908 -> 952 lines, 45,034 -> 47,501 B, sha256 5c69c2d2 -> c90ffab4; the diff is one new helper, three call sites, three selftest cells and the docstring paragraph that states the rule): 1. `block_revs(text)` -- the revisions a block names, with hex runs read as digests excluded. Two signals, both local to the token: a digest word in front of it (`sha256 `, `hash `, `sha1`/`md5`/`digest`), or an ellipsis behind it (`…`), which is how this archive writes a truncated digest. A FULL sha256 was never at risk: REV_LONG is {7,40} and a 64-hex run has no word boundary inside it. 2. `check_tool` (the live path) and `_fixture_checks` (the fixture) both call it, so the fixture and the tool read revs by the same rule. 3. Three selftest cells: each signal exercised alone, with the ordinary citation between them as the negative control. 4. The docstring says so. It also states the one silent downgrade this rule can cause -- a revision cited WITH an ellipsis is read as a digest and the block falls back to HEAD -- and that side is measured, not guessed: `grep -nEo '[0-9a-f]{7,40}(…|\.\.\.)' tools/*.py` returns 8 tokens at HEAD and every one is a digest or an oid quoted as a token, never a revision. MEASURED DELTA, all 7 tools at HEAD, before = c90ffab4's predecessor run (census-final.json) vs after (census-after.json), compare_rows.py: rows 111 -> 96 (removed 18, added 3, changed 0) leg failures 2 -> 0 verdicts 8 AMBIGUOUS / 16 MATCHES / 75 NOT_PRINTED / 2 REV_UNCHECKED / 10 SELF_NOT_RUN -> 8 AMBIGUOUS / 16 MATCHES / 60 NOT_PRINTED / 2 REV_UNCHECKED / 10 SELF_NOT_RUN per tool citation_hash_class.py 28 -> 19 rows, queue_claim_check.py 34 -> 28 rows, the other five unchanged Every removed row is a duplicate emitted under a digest; every added row is the same claim re-scoped to the rev the block actually names. No verdict CHANGED -- the fix removes rows, it does not re-judge any. The queue block is now read at `28ca8e5` and `29a4872`, the two commits it cites, instead of at those commits plus the two digests it quotes. TWO INSTRUMENTS, NOT ONE. `--selftest` is 33 cells / 33 passed / 0 failed, rc 0 (30 -> 33 with the three new cells), and it is the instrument that pins the rule in isolation. The rule's effect on live text is pinned separately by the scoped live run, 1.8 s: `--tools tools/queue_claim_check.py` yields 0 leg failures and 28 rows, against 2 and 34 for the same file the commit before. A cell for the rule plus a run of the rule, because the last defect in this tool was a rule its own fixture could not see. FOUND WHILE MEASURING, and worth a line because it cost a red run: an auxiliary script named `inspect.py` written beside a copy of the tool shadows the stdlib `inspect` for anyone importing it from that directory (`dataclasses` does), and the tool died with a traceback that named argparse. The copy is `census_rows.py` now; the lesson is that the scratch directory is sys.path[0] for the scripts in it. --- tools/doc_census_check.py | 52 ++++++++++++++++++++++++++++++++++++--- 1 file changed, 48 insertions(+), 4 deletions(-) diff --git a/tools/doc_census_check.py b/tools/doc_census_check.py index 3b36362..f5251e4 100644 --- a/tools/doc_census_check.py +++ b/tools/doc_census_check.py @@ -59,8 +59,15 @@ TWO ORACLE LEGS, AND WHY THE SECOND ONE EXISTS only when no leg survives, because a failed run is not a reason to stop looking. A revision that will not materialise fails the same way rather than producing a census at all: an empty queue is a census of zeros, and reading it - as that revision's census is the phantom this rule refuses (measured - 2026-10-16 against a sha256 prefix read as a revision). + as that revision's census is the phantom this rule refuses. + + A HEX RUN INTRODUCED AS A DIGEST IS NOT A REVISION. A block that quotes a + truncated sha256 in its prose is a size, not a place: read as a rev it files + the block under a revision that cannot exist, fails that leg, and then + adjudicates every claim in the block again beside the real ones. Two signals + are read, both local to the token -- a digest word in front of it (`sha256 + `, `hash `), or an ellipsis behind it (`…`), which is how this + archive writes a truncated digest. See `block_revs`. The run leg is `