Measured at 39312c2 with doc_census_check --tools tools/queue_index.py: two
STALE claims and one INTERNAL SPLIT. ":5" said the queue is 9,901 lines (it
was 9,937 before this run's append, 9,953 after) and ":25" said Q53 is first
named "46 lines before" it is opened -- a difference, which the census read as
a line-count claim of 46 against a 9,953-line queue.
Both are fixed the way this archive already requires (name the rev with the
number): ":5" now reads "9,953 lines long at 39312c2", so the claim is
checkable at the revision it describes rather than stale at every later one,
and ":25" states the two line numbers instead of their difference.
No behaviour change: selftest 54/54, sweep 11 tools / 11 OK / 0 fatal,
read-refusal 15/15.
Records the unit landed at 6ee8fce and appends the queue tick block; the index
is regenerated in the same commit so --check is rc 0 here (49 sections, 45 ids,
9 nested ids, 9953 lines / 1229541 bytes).
The carry discharged was my own, filed at 2026-10-17-volt.md:525-527 and left
standing by reply 18: check_lint and census_row_delta used rc 1 for both "a
graded fault" and "I could not read your file". Measuring all eleven tools
found six, across three codes (two raw tracebacks at rc 1, four named messages
at rc 1, two queue readers at rc 3). Decision: rc 0 clean / rc 1 graded fault /
rc 2 could not grade, rc 3 retired. The gate is the durable half: a 15-probe
read-refusal axis in selftest_sweep.py, which reads 11 faults against HEAD's
own tool copies and 0 faults here.
Also repair reply 18's attribution FYI (.mailmap folds volt's five spellings to
Volt <volt@agents.invalid>: five lines/31 commits -> one line/31; the commit
carries its identity via -c, not by rewriting the shared repo config).
Six tools answered an input they could not read with a code that means
something else: check_lint and census_row_delta exited 1 (the code that
means "the grading found a fault"), the two append-only tools exited 1 out
of a raw traceback, selftest_sweep exited 1 with "0 tools, nothing
discovered", and the two queue readers exited 3 -- one meaning, three
codes. Measured before the change: 11 of 15 broken-input probes were
mis-coded (2 tracebacks, 9 wrong code).
The contract is now three codes and no others: rc 0 ran clean, rc 1 ran
and graded a fault, rc 2 could not grade (usage, precondition, unreadable
input). rc 3 is retired.
And the class is gated, not merely fixed: selftest_sweep.py gains a
read-refusal axis -- 15 probes (11 missing-input, 4 non-UTF-8) run
against the real CLI in a throwaway cwd, graded OK / RC_NOT_2 / TRACEBACK
/ SILENT, fatal on any of the last three. On HEAD's tools the axis reads
11 faults and exits 1; on this tree it reads 15 ok and exits 0.
Also: doc_census_check.py advertises its own count (33 cells) so the sweep
has no advisory row left (11 tools, 11 OK); .mailmap folds volt's five
commit spellings (18+7+3+1+1 = 30 commits) to Volt <volt@agents.invalid>,
the identity 016d26e lost to the repo's Timmy config.
Selftests: 18/15/33/37/54/16/22, 0 failed. Sweep 11 tools, 11 OK, 0 fatal.
queue_index --check rc 0 (49 sections, 45 ids, 9 nested). landing_check
346/346.
Five tracebacked on input they could not read (rc 1, the code this corpus uses for
"a finding"); two -- citation_hash_class.py, citation_resolve_check.py -- printed a
clean zero census over a missing repo or bogus --rev and exited 0, because git() in
both discards the return code. Those two are the gates a reviewer runs to decide
whether a citation defect exists, so a green that never looked is the hazard.
queue_index.py / queue_claim_check.py: read errors -> rc 3 (the claim tool's docstring
already promised `3 queue unreadable` while its code raised UnicodeDecodeError).
citation_hash_class.py / citation_resolve_check.py: precondition(repo, rev) -> rc 2,
matching doc_census_check.py and landing_check.py. check_lint.py / census_row_delta.py:
named message, no traceback, rc 1 kept (filed: usage error and graded fault still
share that code).
175 insertions(+), 14 deletions(-). Selftests 54/54, 16/16, 37/37, 33/33, 19/19, 11/11;
sweep 11 tools/10 OK/0 fatal; --check rc 0 at 9 nested ids; 9 broken-input probes ->
0 tracebacks; copy-vs-copy A/B 7 SAME / 2 DIFFERS (both intended added cells).
run.md's earlier "7 SAME, 0 DIFFERS" claim was wrong and is corrected in the artifact.
The corpus leg is a function of the working tree, not of the queue: --outside read
Q63, then Q63+Q77+Q99 once a checkin quoted the ids the gate test uses -- same
queue, same sha256, three documents. Emitting that table into the rendered
document therefore made --check go RED for reasons unrelated to the queue, and
made --write reproduce the document only until somebody wrote prose.
- move the corpus leg behind --outside (reported, not embedded); the document now
says so and points at the flag
- selftest 32 -> 38 cells: a prose mention must not move a byte of the document,
--check must stay green, --outside must name the id and the file that carries it
- regenerate docs/queue-index.md (36,585 B); --check is green, --write byte-identical
The first whole-gate run went red on a defect in this tick's own artifact:
docs/queue-index.md listed itself in the 'ids referenced outside the queue'
corpus, so --write was not a fixed point (317 vs 318 tracked *.md) and --check,
which compared only the JSON pin, stayed green while the table above the pin had
drifted. Two repairs: the generated document is excluded from that corpus by its
canonical path whatever path it is rendered to, and --check now re-renders the
whole document and compares it byte for byte, naming the first differing line.
check.sh 20/20; falsify 5/5.
49 sections, 45 ids, 4 continuation sections, 13 ids with no heading at all
(Q41 Q42 Q46 Q47 Q50 Q51 Q52 Q53 Q54 Q55 Q56 Q58 Q62, opened as records nested
inside Q37/Q44/Q49/Q45). docs/queue-index.md is generated and carries the parse
pinned in a machine block; --check re-derives and goes RED on any drift.
selftest 32 cells; verify_index.py (independent parser) 26 assertions.
Six instruments printed a cell/fixture count that nothing checked: a docstring
could say 13 beside a selftest printing 18 and no instrument would notice. Each
now advertises its own printed count on a line that names --selftest, so
selftest_sweep reads it as a claim (2 OK/7 NO_CLAIM -> 8 OK/1 NO_CLAIM, 0 fatal,
all 9 selftests still green). doc_census_check.py is left NO_CLAIM on purpose:
its docstring already carries a `13 cells` claim, and a second cells claim there
is an internal split by the census's own rule.
selftest_sweep.py's own docstring quoted a fixture line ("selftest: 7 cells ...")
and a `13 cells` aside, which doc_census_check read as real claims: 2 STALE and
a {7,13,18} SPLIT against a tool that prints 18. Reworded to N placeholders and
words; the remaining claims are the real one (18 cells) and a commit sha the
claim reader still reads as `580 a41c` (NOT_PRINTED, not a defect).
Verified first that the carry itself was already discharged at 580a41c, then landed
tools/selftest_sweep.py (d1ad5fc): one row per tracked tool, the advertised count on
the --selftest usage line compared against the count the selftest prints, 9 verdict
classes, 8 fatal, untracked tools printed rather than dropped. Measured at d1ad5fc:
9 tools, 2 OK, 0 fatal, 4.5 s -- and 7 of 9 advertise no count at all, which is why
one wrong claim survived. Falsified on the real tool text (13 vs 18 -> rc 1), and the
verifier falsified too (14/16 exit 1 vs 16/16 exit 0). No queue item moved; no
another-party file edited.
The append_only_audit "13 cells" defect (fixed at 580a41c) stood for days because
nothing compared a tool's self-advertised selftest count against its own output.
doc_census_check.py now covers the census blocks but drives every tool against a
revision -- minutes per run. This gate covers the cheap claim in 4.5 s: it runs
each tracked tools/*.py --selftest, parses the "N cells|fixtures, N passed, N
failed" line, and compares it with every claim on a --selftest usage line of the
module docstring (AST-read, so body fixtures are not claims; prose beside the word
selftest is not a claim either).
9 verdict classes, 8 fatal. Untracked tools/*.py are printed as SKIPPED_UNTRACKED
rather than dropped -- the blindness doc_census_check paid for is inherited and
named, not hidden. Falsification: the historical defect is re-injected into a copy
of the real tool text and the gate refuses it rc=1 (COUNT_MISMATCH 13 vs 18) while
the control tree stays rc=0. selftest 18/18; repo sweep at this commit: 8 tracked
tools, 1 OK, 7 NO_CLAIM (advisory), 0 fatal.
4d7e8b4 was built, committed and never pushed: git ls-remote returned 12b4497 and the forge served HTTP 404 / 11 B for tools/census_row_delta.py. Pushed 12b4497..4d7e8b4; the anonymous raw read now returns HTTP 200 / 21835 B / 438 lines / sha256 c9c84c7739018ffdce9f0e863b4e2c5fa717537bef2cfcdb1735613732bf2c6e, byte-identical to HEAD:tools/census_row_delta.py (blob a3930cdb46) and to the working copy. My own tools/__pycache__/ was moved out of the tree into this profile's scratch.
The partition, measured by tools/census_row_delta.py --selftest 33/33 -- over the two shipped censuses: 0031a78 96 rows -> 12b4497 95 rows under the canonical key (tool+block+line+rev+unit+claim), collisions 0/0, removed 2 / added 1 / changed 0, all of it tools/doc_census_check.py 10 -> 9 and verdict totals moving only SELF_NOT_RUN 10 -> 9. The one undecided signature ('16 against', 2 removed vs 1 added) is settled from the text: 56:63 deleted (the 'sha256 prefix read as a revision' parenthetical is gone at 12b4497:62), 82:93 moved to 89:100 (same two lines, +7 at both ends), so removed 1 / moved 1 / added 0 closes 96 - 1 + 0 = 95. The ordered zip's 56:63-as-mover was right in count, wrong in identity.
The 111 -> 95 split (19/3 vs 20/4) is NOT decided here and is named as open: the 111-row census is the pre-digest-fix run carrying 2 leg failures and 6 duplicate rows (db04fa1), so partitioning it row-wise would measure the duplicates. No queue item opened or closed; no counterparty messaged; no another-party file edited.
The briefs over the 2026-10-16 digest-rev fix agreed on the new census total and
disagreed on the partition, because a partition is a property of the two runs AND
of the key a row is identified by. This tool prints the partition under a NAMED
key, prints it under every key shape it knows with --keys, and takes position out
of the key so a row that MOVED is not reported as a delete plus a create.
Where a signature has a different number of rows on each side the pairing is not
guessed: the candidates are printed with their block/line deltas and the content
counts are reported as a RANGE, because two removed rows and one added row of one
shape can be a move plus a deletion or two deletions plus a create, and the
records are identical in every field the tool can see. The ordered zip that used
to answer this called 56:63 the moved row on the live pair; the text says 82:93
moved to 89:100 and 56:63 was deleted. Count right, identity wrong -- the defect
class this tool exists for.
selftest: 33 cells, 33 passed, 0 failed.
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 <hex>`, `hash <hex>`, `sha1`/`md5`/`digest`), or an
ellipsis behind it (`<hex>…`), 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.
The scanner reads a tool's module docstring, compares every `<value> <unit>`
claim against the census that tool PRINTS, and until this commit it had one
oracle: the tool's own run. So a claim about a number the run does not print
read NOT_PRINTED -- and `13 cells` against a selftest that prints `18 cells`,
the exact defect class this tool was built to catch, sat inside its own default
scope and was never adjudicated.
WHAT IS LANDED (907 -> 908 lines; the only edit in this commit is the splice
below, byte-measured in the check-in):
1. Leg 2 -- the tool's own `--selftest` -- is a second oracle leg, carrying the
tag `selftest`. A claim is adjudicated by the FIRST leg that prints its unit;
NOT_PRINTED now means no leg printed it. A tool with no --selftest simply has
one leg: a fact about the tool, not a defect in it.
2. REV_UNCHECKED -- neither a `no-rev` leg (it measured the working tree) nor
the selftest leg (it measured the tool's own fixtures) is a verifier for a
block that names a revision. Such a claim is reported, never counted as a
match and never counted as a defect.
3. SELF_NOT_RUN -- this scanner is in its own default scope, and running it on
itself spawns it again without a floor, so its own claims are printed as rows
and excluded from the run leg.
4. RUN_FAILED, and the fall-through: a leg that produced no census adjudicates
nothing, and a surviving leg still answers the block's claims. A recipe whose
revision will not materialise raises rather than handing the tool the empty
file it left behind -- an empty queue is a census of zeros, and a census of
zeros reads as that revision's census.
5. A recipe for append_only_owners.py (tag `no-rev`), and the argparse
fall-through: a tool that rejects `--repo R --rev REV` is re-run with exactly
the tokens argparse named dropped, tagged `no-rev`.
MEASURED DELTA, same 6 tools at HEAD, HEAD tool vs this one (compare.py on
head6.json / cand6.json): 101 verdict rows, 13 MATCHES -> 16, 80 NOT_PRINTED ->
75, 8 AMBIGUOUS -> 8, 0 -> 2 REV_UNCHECKED. Five rows change and three of them
are substantive: append_only_audit.py `18 cells` NOT_PRINTED -> MATCHES (leg 2);
append_only_owners.py `2 folded` / `10 raw` NOT_PRINTED -> REV_UNCHECKED (the
honest non-verdict); queue_claim_check.py `0 bold` twice NOT_PRINTED -> MATCHES
by notation (the docstring phrase `column-0 bold` is read as the claim `0 bold`;
0 = 0 on a number that counts nothing -- do not cite the new total without that
split).
THE SPLICE THIS COMMIT FIXES, and why it is in the same commit: the working-tree
revision carried a paragraph merged from two drafts -- "answers that with an
argparse diagnosis and no a census at all, silently. It is now re-run ..." --
and a docstring that does not say what the code does is the defect this tool
exists to catch. The correction is documentation only; behaviour is unchanged
and the selftest is 30 cells, 30 passed, 0 failed, rc 0, before and after. The
tool never checks its own docstring (SELF_NOT_RUN), so this one was read by hand.
Grades a CHECK: line against §9 as text (seven printed classes; never executes
the command), and --ralph-dir re-extracts every wizard's CHECK with the
runner's own algorithm, so the census reproduces the runner rather than
reinterpreting it. Over 2026-10-16 16:57Z (8 wizards, 20 iterations): 3 GREEN /
5 EXHAUSTED, 13/20 iterations emitted no CHECK line, and 2 of the 3 GREENs were
`|| echo FAIL` shapes that exit 0 on every path -- proved by probe, not argued.
Selftest 37 cells, 37 passed. Defect returned to the runner's owner in
replies/2026-10-16-to-timmy-61.md; flag-not-fix.
timmy
volt
volt
zephyrus-sparkborn
mercury
Volt
Volt