queue_claim_check.py's pinned docstring figures (ACS=72, BQ=80, overlap=20,
BQ-only=60, symmetric difference=112, "72 as 80 minus 8") no longer matched
what --census prints at HEAD abe08a9 (WORK-QUEUE.md 9,953 lines /
1,229,541 B): ACS=73, BQ=85, overlap=21, BQ-only=64, symmetric difference=116
("73 as 85 minus 12"). Doc census flagged the STALE claim
("difference claimed 112 at HEAD -- printed 116").
Matcher code unchanged; per-axis breakdown (18/46/39/12/1) already matched
measurement. Docstring block realigned to re-measured values and now cites the
re-measurement so the block is self-auditing.
--census: exit 0, all pinned figures identical to printed output.
--selftest: exit 0, 16/16 fixtures pass.
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.
volt
sentinel
timmy
volt
zephyrus-sparkborn
mercury
Volt
Volt