headings_missing() scanned every line for ^#{1,6}\s+ with no fence state, so a
check-in that quotes the four-heading contract in a fenced block was graded as
carrying all four headings while carrying none as structure. queue_index.py has
skipped fences since it was written; the check-in reader never did.
Pre-fix on the quoted fixture: headings_missing == [] (false green).
Post-fix: ['next','ask']. Blast radius on the record is zero: over all 74 files
in checkins/ the advisory count is 60 before and 60 after, 0 files change grade.
selftest 27 -> 29 cells (c28 quoted heading, c29 unclosed fence), both advertised
counts updated. verify.py 3/3 rc 0 (sweep 14 tools, 14 OK, 0 fatal).
The old guard cut at the first '**', which is right for '**Status: value**'
and returns '' for '**Status:** value'. Empty is falsy, so the parse stored
None and docs/queue-index.md rendered '--' for Q13:1129, which states
'1 of 8 has a decision and staged correction'. status_value() strips a
leading bold close, then a trailing one, so both forms yield the value.
selftest 54 -> 58 cells (inline fixture, no existing line numbers move).
docs/queue-index.md regenerated: exactly 2 lines (the Q13 cell + its pin).
Independent witness in wizard-outputs: rc 0 on the fixed document, rc 1
naming row 13 on the pre-fix one. verify.py 3/3 rc 0.
Found while demonstrating the NO_PROBE fix: the gate graded selftest-sweep FAULT and
printed 'sweep: 15 tools, 14 OK, 0 fatal' beside it, because pick_detail took the
first hint-matching line and 'fatal' matched a summary asserting zero of them.
- pick_detail: zero-count summaries (' 0 fatal' / ' 0 fault') are second-pass only,
so a clean run keeps its sweep line and a red run names the red axis
- selftest 24 -> 26 cells: c13 a zero-fault summary is not a reason line,
c13b a clean run still gets its sweep line; both advertised counts updated
The read/malformed axes only covered tools named in READ_PROBES / NOT_UTF8_PROBES /
MALFORMED_PROBES. A 15th tool dropped into tools/ produced two advisory NO_PROBE rows
and the sweep still printed '15 tools, 14 OK, 0 fatal' with rc 0: measured on a copy of
the 14 tracked tools plus one probe-free tool, pre-fix rc 0 / post-fix rc 1.
- NO_PROBE joins FATAL_READ; the two rows now say 'ungraded, fatal'
- axis_faults() is the single red predicate, used by report_read
- selftest 28 -> 30 cells: c29 an unprobed tool is NO_PROBE on both axes and counts,
c30 every FATAL_READ verdict is red and OK is not
- two stale counts corrected in this tool's own docstring: 'ten'/'Nine tools must
refuse at rc 2' -> eleven (measured: 11 of 14 tools carry rc 2 probes)
index-current (queue_index --check), append-audit (queue_append_audit --guard
--to HEAD), selftest-sweep (skippable with --fast, printed SKIP and counted as
skipped). rc 0 graded clean / 1 graded a fault / 2 could not grade, with 2
outranking 1 so an ungradable leg cannot be read as a certified run; the fault
count is still printed beside it. Tools resolve from --repo, not from this
file's directory, so a worktree is graded with its own instruments.
selftest 24/24 (stub legs through the real CLI: rc mapping incl. retired rc 3,
missing tool, timeout, --fast, --json, missing repo, fixed order). Added to
both sweep probe axes (read-refusal 19/19, malformed 17/17, 14 tools 14 OK) and
the sweep's stale "15 such probes / nine tools" prose corrected to 17 / ten.
Green at 019b75c: 3/3 pass, rc 0. Red paths on a full 785-commit clone:
0 -> 1 (working-tree append, no re-render) -> 0 (--write) -> 1 (committed
stale: both legs faulted) -> 2 (tool absent; index fault still printed).
Queue tick appended and index re-rendered in this same commit.
WHY: docs/queue-index.md pins WORK-QUEUE.md by sha256, so an append that
skips the re-render is STALE by construction, and nothing obliged a commit to
re-render. f2c3067 and 067afdf each left the gate red until a later repair
(2h37m for the second). Enforcing that rule by hand produced three wrong-slice
counts in one week; the 15:16Z correction names the cause -- a --check in a
working tree at HEAD says nothing about a cited revision.
queue_append_audit.py materialises each commit's own tree with git archive and
runs THAT tree's own tools/queue_index.py --check inside it. Verdicts: PASS
(rc 0), STALE (rc 1 with the tool's STALE line), UNGRADABLE (gate absent at
that rev, or the tool refused rc 2 -- kept out of the stale bucket), ERROR (a
crash wearing the verdict code, or a timeout). House contract: 0 clean, 1 a
graded fault, 2 could not grade. --guard grades the newest queue-touching
commit only, for wiring into a tick's check.sh. Default range begins at the
commit that introduced the index; --all lists the pre-gate commits instead of
hiding them. selftest: 25 cells, 25 passed, 0 failed; the tool advertises that
count on its own --selftest usage line.
Measured at b7e2bfd, /root/troupe-standup: 337 commits touch the queue; the
default range is 9 commits -- 6 PASS, 3 STALE (f2c3067, ece5228, 067afdf),
0 UNGRADABLE -- with 328 earlier commits counted and not listed. That is reply
24's corrected set exactly (its 2 rc-2 commits, 12b4497 and 0bdb9d4, fall
before the index and are UNGRADABLE under --all, not stale). --guard at HEAD
reads 1 PASS, rc 0.
The tool's own fixture found a real defect in queue_index.py: build_doc indexed
payload["nested"][0] unconditionally, so --write died with IndexError -- a
zero-byte document and rc 1, the code that means "graded a fault" -- on any
queue whose ids all carry headings. Fixed in nested_prose(); the non-empty
branch reproduces the old sentence byte for byte, so --check is rc 0 on the
real document and queue_index --selftest is 54/54 before and after.
selftest_sweep.py gains the new reader on BOTH input axes (missing repo path,
not-a-repo) instead of the NO_PROBE advisory: 13 tools, 13 OK, 0 fatal;
read-refusal 18 probes 18 ok, malformed-input 16 probes 16 ok.
The full doc-census gate at 0b67585 went red on this tool's docstring, not on
its behaviour: STALE "tools/checkin_check.py:46 files claimed 70 at HEAD --
printed 71". Two unpinned mutable counts over checkins/ were behind it.
1. The A1 rationale said "52 of 70 files faulty ... 12 real name faults".
Neither figure is reproducible: checkin_check prints 57 missing-heading
files and BAD_NAME 25 at c374a0a, c213a5d, edaef63 and 588784d alike, and
70 files only at c374a0a (the rest carry 69). The sentence now states the
measured triple and pins it to c374a0a, the last revision that touches this
tool. checkin_check takes no --rev, so a rev-named block is REV_UNCHECKED by
the census tool's own rule -- visible, never graded, and it stops drifting
to STALE as check-ins land.
2. The READ-ONLY paragraph said "the 12 BAD_NAME files": the tool counts
BAD_NAME 25 at every revision tested and at HEAD. That sentence is about
policy, not a census, so the count is removed rather than re-pinned --
"the badly named files are the principals' history".
Measured after both edits: selftest 27/27 rc 0; targeted doc-census gate
--tools tools/checkin_check.py rc 0; full 12-tool gate and selftest sweep
rerun at the commit this message lands in (artifacts under
/root/.hermes/wizard-outputs/volt/2026-10-18-vocab-minimal/).
Two defects left open by the 30c8120 vocab gate, both closed here and both
measured rather than asserted.
1. --save-vocab wrote every key the legs printed (422 at 30c8120), including
207 hex-like digests and append_only_audit's diffstat words. Those are
permissions no claim can ever spend: vocab_has() asks keys_for(unit, ...)
over the units ONE docstring claims, so the reachable key set is fixed by
that docstring. spendable_keys() is that same matcher, and the saved file is
now the intersection with it -- 422 keys observed on this tree, 24 written,
the other 398 unspendable by construction.
2. A runless split in a lowercase word printed nothing at all: unit_scope
answered UNCHECKED_NO_ORACLE and the printer showed only the LABEL_ONLY
class, so the vocab-precision fixture's case E (5 above / 7 above, no
vocabulary) exited 0 with no line. Silence is not a verdict; both runless
classes now print ADVISORY with their values and neither is graded.
Measured: fixture A..E rc vector [1,1,0,0,0] before and after, with case E
printing nothing before and its advisory line after; the scoping is
OUTCOME-NEUTRAL by exhaustive check -- for all 96 units the 12 tracked tools
claim, "named by the vocabulary" is the same answer before and after; the fast
gate is rc 0 at 30c8120 on the old 422-key file and rc 0 on the scoped one; and
the fca3f2e 441/471 tooth is still rc 1 from the cache. It does NOT close the
cache's over-reach -- a word the docstring really does claim twice is still
spendable -- and a selftest cell now pins that limit instead of leaving it in a
report. Selftest 72 -> 80 cells, 80/80 rc 0.
Reply 22 ruled the asymmetry a defect and asked that `--fail` never return 1 on
a split it could not verify. 814acc4 met that by making every runless split
ADVISORY -- which also empties the fast gate, measured: on two fixtures (a STALE
claim, an internal split) `--fail --no-run` returns 0 for both, and no path can
return 1, because gate_faults() reads only CHECKABLE splits and STALE verdicts
and neither exists without a run.
So the fast mode gets the oracle it can have. `--save-vocab PATH` (full run)
writes the census vocabulary the run OBSERVED -- unit keys per tool, read off
leg stdout, never off docstrings -- and `--no-run --vocab PATH` grades a split
in a unit that vocabulary names as CACHE_CHECKABLE. What the cache proves is
unit-hood; the graded disagreement is internal to the docstring, so no value is
needed, and no STALE claim can enter this way (pinned by fixture).
Measured at fca3f2e, tools/citation_resolve_check.py, one claim:
--no-run --fail rc 0 ADVISORY UNRESOLVED: 471@82, 441@89
--no-run --vocab V --fail rc 1 0.205s, SPLIT ... (CACHE_CHECKABLE,
vocabulary at fca3f2e): 471@82, 441@89
--fail rc 1 SPLIT (CHECKABLE) + STALE :89
Selftest 60 -> 72 cells (5 vocabulary cells, 6 process-exit cells);
sweep 12/12, read-refusal 17/17, malformed-input 15/15, rc 0.
rc 2 covers an unreadable --vocab and --save-vocab without a run.
A split enters the graded list only via CHECKABLE (a leg ran and printed the
unit with one value). Every other reason is printed with its values as
ADVISORY and never reaches the gate, so --fail --no-run can no longer return 1
on a split it had no oracle for. Ruling: reply 22, 2026-10-18.
Measured at fca3f2e before/after, same tool and rev:
--fail --no-run rc 1, SPLIT UNRESOLVED (LABEL_ONLY): 471@82, 441@89
--fail --no-run rc 0, ADVISORY UNRESOLVED (LABEL_ONLY): ... reported, not graded
--fail (full) rc 1 both times: SPLIT (CHECKABLE) + STALE :89 -- teeth kept.
Selftest 52 -> 60 cells (6 mode cells, 2 process-exit cells); sweep 12/12.
`--fail` moves the verdict into the exit code: rc 0 ran and graded no fault,
rc 1 ran and graded a STALE claim or an INTERNAL SPLIT, rc 2 could not grade
(usage, a --tools filter matching nothing tracked, unreadable input). Before
this, the process exited 0 while printing STALE rows, so nothing could gate on
the one class the tool exists to catch.
Armed at HEAD, the gate went red on its own first run -- on a false claim, not
a defect: `queue_claim_check.py`'s axis list says `39 ACS-only lines carry no
Q<digits> token` (and 12, and 1) and the token read as a unit was the
adjective `ACS` in `ACS-only`; with no oracle to test the label against,
--no-run split 39/12/1. The reader now refuses a unit immediately followed by
`-`, the same refusal it already made for a hyphen behind the number
(`120-char`).
Measured cost of the tightening at bacdead, from --json before/after: 6 claims
no longer read -- queue_claim_check 23 -> 19, checkin_check 8 -> 7,
queue_index 10 -> 9 -- 5 NOT_PRINTED and 1 REV_UNCHECKED, every one of them the
first half of a compound (`ACS-only`, `check-in`, `self-test`, `follow-on`).
The invariant that licenses it holds: MATCHES 26 before and after, identical
rows. A genuinely hyphenated unit (`citations-per-block`) is no longer read;
the tool states that limit in its docstring rather than discovering it.
selftest 41 -> 52 cells (5 decision cells, 4 process-exit cells that prove a
helper returning 1 is not a gate); sweep 12/12 OK, read-refusal 17/17,
malformed 15/15; `--fail` at HEAD: 0 INTERNAL SPLIT, 0 STALE, rc 0; the same
gate on fca3f2e: 1 split, 1 STALE, rc 1.
The full census at 4ce1aed (the run my 2026-10-18 check-in owed) reported two
STALE claims against checkin_check.py:59 -- "read as UTF-8. Never 1, never a
traceback." -- where the 8 is the tail of UTF-8 and the 1 is an exit code.
Both are false defect claims.
Measured over all 12 committed docstrings: 140 claims read, 95 real. The rest
were welded hex (83acffe0 -> 83 acffe0, 11), ordinals/sentence ends (1.
INTERNAL, 8. Never, 5), compound adjectives (120-char, 5), list markers (0
ran, 4) and trailing commas (1, which -> claim 1 of unit which, 8).
Three rules: sep is one space or a closing delimiter + space; num is
[0-9]+(?:,[0-9]{3})*, so a trailing comma is punctuation; ordinal_at() refuses
a line-leading number followed by 2+ spaces. Six cells: 35 -> 41.
Same revision, same docstrings, after: 145 -> 105 verdict rows, STALE 2 -> 0,
NOT_PRINTED 87 -> 52, and the 26 MATCHES are the same 26 rows (lost: [],
gained: []) -- no adjudicated verification was dropped.
selftest 41/41 rc 0; selftest_sweep 12 tools 12 OK 0 fatal; read-refusal 17/17;
malformed-input 15/15.
Named, not fixed: doc_census_check returns 0 with STALE > 0 and has no --fail,
so a gate cannot fail on the class it exists to catch.
The read-refusal axis measured missing paths and non-UTF-8 bytes. The class in
between was unmeasured: a .json that is not JSON, a {} where an audit file should
be, a directory that is not a git repo, a queue with no records -- the inputs
where a tool is most tempted to print 0 and exit 0, which reads like a clean pass
(the doc_census_check --tools bug, 76043b7).
15 probes over all 12 tools, each graded against the answer its OWN contract
states (nine refuse at rc 2; check_lint grades MISSING at 0/1, checkin_check
advisory at 0, queue_claim_check 0 opening records at 0). judge_malformed adds
RC_WRONG, UNEXPLAINED next to TRACEBACK/SILENT, and requires a word, so a silent
0 cannot pass.
15/15 at HEAD -- no tool was wrong, none was measured. Against 461eede's copies
the same axis reads 7 fault (3 tracebacks, 3 wrong codes, 1 NO_TOOL). Against a
copy with one bug reintroduced into append_only_owners.py it reads RC_WRONG while
that tool's own 15-cell selftest stays green.
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.
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).
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.
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.
The repo-wide two-leg docstring-vs-printed-census oracle (tools/doc_census_check.py, the working-tree
revision sha256 ae193f20f10bcceeb1b2c699f0f86ffda02179872f0c32356dc2e182861a2f55 / 723 L, cited here as
the instrument used and NOT committed by this change) reads exactly ONE STALE claim across all six
tools/*.py scanners at HEAD a82130e:
STALE tools/append_only_audit.py:41 cells claimed 13 at HEAD -- printed 18 [selftest]
That is the standing carry the control plane returned in reply 05 ("audit docstring says 13 cells not 18")
and carried in the 12:12Z queue tick ("the one carry standing in an owning lane's file"). The tool is
this lane's, so it is discharged here rather than flagged. Change is docstring-only: `13 cells` -> `18
cells` on line 41.
BEFORE tools/append_only_audit.py 475 L / 22,110 B / sha256 a46b2f96026c738fd6763a5f972bc85d54af53a043ae80bbbd4b69f53bb57087 / blob b45f1a7c11
AFTER tools/append_only_audit.py 475 L / 22,110 B / sha256 81dae4dfecc98bde9b22d8c20ec717d1416248f4603924ac6f84e1d271e65957
Verified: `python3 tools/append_only_audit.py --selftest` -> `selftest: 18 cells, 18 passed, 0 failed`, rc 0.
No measurement moves: the patch touches only the docstring, and the tool's --json output is unchanged (the
docstring is not read by the tool). No item opened or closed; WORK-QUEUE.md untouched.
Subject f5403b2 (the HEAD before this landing): 688 commits, 878 (commit,path)
changes, 314 paths. BYTE NEW=314 APPEND=387 EDIT=177; LINE NO_PARENT=314
SUBSEQUENCE=468 LOSS=96; 277 of 314 files never lost a line. On the
append-sanctioned paths: 27 files, 74 LOSS candidate rows (2 escape
normalisation, 72 REWRITE). The first instrument printed "VIOLATIONS" for those
74; the second instrument falsifies that word -- 65 same-party / 9 other-party vs
the path's previous toucher, 61 / 13 vs its creator -- so the wording is corrected
in the same commit and the count is named CANDIDATE ROWS. Nine cross-party rows,
read from their real diffs: eight are status refreshes, erratum annotations,
single-token corrections or punctuation edits; the ninth is de3bc55e
(2026-09-24, timmy), recoveries/silent-rooms.md 5,289 -> 2,960 B, 48 parent lines
gone, replacing zephyrus-sparkborn's header -- the one cross-party rewrite with
real loss in this history. Author-name normalisation applied first and reported:
10 raw spellings -> 8 folded parties (Timmy/timmy, Zephyrus Sparkborn/
zephyrus-sparkborn); the naive run reads 60/14. selftest 18/18 and 15/15, both
rc 0; the audit JSON is byte-identical before and after the wording patch, so the
patch moved no measurement. Read-only (only --json writes). Queue 15/12/3
reproduced; no item opened or closed; WORK-QUEUE.md untouched.
tools/doc_census_check.py (548 L / 25,058 B / sha256 dbbbdc01bb19dbcbbe87141c90a80e0bff19c98557c80f91c81347c53c98f1c5) checks a scanner's module docstring against the census that scanner PRINTS, two independent ways: (1) INTERNAL SPLIT -- one unit, one revision scope, two values in one paragraph, caught with no subprocess at all; (2) ORACLE -- the tool is re-run at the revision its docstring names and every '<value> <unit>' claim is compared with the value that run prints (MATCHES / STALE / CLONE_LOCAL / AMBIGUOUS / NOT_PRINTED). A unit the tool prints with two values is SECTION_SPLIT_BY_TOOL and no claim is made about it; a unit the tool never prints is NOT_A_CENSUS_UNIT and no claim is made about it either. Selftest 14 fixtures, 14 passed, rc 0; the only write path is --json.
THE DEFECT IT CATCHES, AND THE FIX: the control plane returned it against this lane's own resolver (reply 04, d355395) -- tools/citation_resolve_check.py:82 stated 471 UNRESOLVED while :89 stated 441 UNRESOLVED, over a census the tool prints as 471. That is the first finding of the new tool on its first run (INTERNAL SPLIT UNRESOLVED [babdadc] 471@82 / 441@89; STALE UNRESOLVED claimed 441 at babdadc, printed 471). HERE IT IS FIXED, my file and my edit: 2 insertions / 2 deletions, both on the one line; byte count unchanged at 20,460 B because 441 and 471 are the same width; sha256 7d063b39e2e4f9e5691b720cb57895b29450ece77051a7db6a8584dfd7173237 -> 40314b34f9860c4c42623f669c1339ed1d7b0ffc5fe604d56d6e9112b893e3a6. The fix is docstring-only and changes no measurement: the tool's own selftest is 11 fixtures / 11 passed / rc 0 both ways, and the census at babdadc is byte-for-byte the same after the edit as before it (297 files; EXPLICIT 410 = 113 RESOLVES / 0 STALE_LINE / 297 EXTERNAL_PATH; BARE 1612 = 119 AS_NAMED / 716 AS_SELF / 51 AMBIGUOUS / 255 EXTERNAL_NAMED / 471 UNRESOLVED; 6,961 mentions; 101 distinct targets).
MEASURED COVERAGE, stated narrow rather than rounded up: at d355395 the run read 92 claims across the three scanners -- 12 verified against the run they cite, 8 in units the tool prints with two values (no oracle), 71 in units the tool never prints. The oracle reported exactly one bad claim on that corpus, and it was the returned defect. A WIDER RULE WAS TRIED FIRST AND FALSIFIED BY ITS OWN FIRST RUN: tools/num_agreement_check.py, block-scope same-unit-two-values over the whole archive, flagged 447 restatements at first and 117 after an isolation rule (240 chars) -- too coarse to be read, and it is NOT landed; the file is kept out of the tree as evidence. Read-only in fact: only write path is --json, git status --porcelain clean after every run. No other file touched, no secret printed. Volt <volt@agents.invalid>.
402 -> 407 lines / 20,460 B / sha256 7d063b39e2e4f9e5691b720cb57895b29450ece77051a7db6a8584dfd7173237.
Census at babdadc over 297 markdown files: EXPLICIT 410 cites = 113 RESOLVES / 0 STALE_LINE / 297
EXTERNAL_PATH; BARE 1612 cites = 119 AS_NAMED / 716 AS_SELF / 51 AMBIGUOUS / 255 EXTERNAL_NAMED /
471 UNRESOLVED. The named-file rule was written as a verdict first and falsified by its own first run
(three mis-bind groups, each verified at HEAD), so bare cites carry two candidates and no claim.
selftest 11/11; all 113 in-tree explicit RESOLVES rows re-checked with wc -l, 0 mismatches; read-only
in fact (--json is the only write path, git status clean after every run). No queue item opened or
closed; WORK-QUEUE.md untouched.
Reply 02 (replies/2026-10-15-to-volt-02.md, note 2) called the index counts
clone-local; it is right, and my own `index:` line invited the error by printing a
blob count and a commit count on one line as if they were one population.
Re-measured here at rev 9188dd3, three object stores, corpus held constant:
working clone 871 blobs / 680 commits
git clone --no-local (scratch) 866 blobs / 680 commits
clone off the forge 866 blobs / 680 commits
The +5 are exactly the unreachable loose blobs `git fsck --unreachable --no-reflogs`
lists (5 blob, 14 commit, 14 tree); a true clone carries none. The commit count does
not move because it is a different scope, not a luckier number: build_index takes
blobs from `cat-file --batch-all-objects` (whole local store) and commits from
`git rev-list --all` (ref-reachable only), so unreachable commits are invisible to it
and the count follows the refs (identical in both clones: main = bbe8d0d).
Every token figure carries across clones unchanged: 307 files / 9,355 occurrences /
594 BLOB_OID / 1,062 CONTENT_SHA256 / 222 COMMIT_SHA / 7,477 UNRESOLVED / BOUND 1,034 /
CLASS_MISMATCH 0 / CLASSLESS_AFTER_SIZE 485 / BOUND_UNRESOLVED 615.
Fix: SCOPING LIMITS section in the docstring; the `index:` line relabelled so each
count carries its unit (numbers unmoved); --json gains blobs_scope/commits_scope.
Tool 372 -> 412 L, 17,960 -> 20,675 B, 7d974d5b -> d7770051724b6a178e8a8831e0f38d12e9037a3a216af5e283fdac05b84e9170.
Selftest 19/19 rc 0 after the change; the summary block at 9188dd3 diffs against the
pre-patch run on line 2 only (the label). 7d974d5b stands for the revision reply 02
graded. Evidence: checkins/2026-10-15-volt.md Block 3.
The defect class WORK-QUEUE.md:8510 names in one sentence -- "a token quoted
without its class ... a hash family swapped for its sibling, with no byte figure
moving" -- is invisible to a reader (both families are hex) and cheap for a
script. tools/citation_hash_class.py indexes the whole object store (868 blobs,
678 commits, 0 ambiguous prefixes) and resolves every token by prefix, so
historically-truncated tokens resolve too.
Measured at HEAD, 306 files, 9,296 hex tokens >=8 chars: BLOB_OID 584,
CONTENT_SHA256 1,049, COMMIT_SHA 220, UNRESOLVED 7,443. A class word is BOUND to
a token 1,013 times and contradicts the measurement 0 times. The exposure is a
MISSING label, not a wrong one: 485 occurrences in 54 files where a hash sits
directly after a bare byte figure.
Acceptance: it flags :8467's two tokens (83acffe0, decd3350) as
CLASSLESS_AFTER_SIZE with measured=CONTENT_SHA256 and prints each sibling --
83acffe0 -> blob 4f53c93a70 / 13,218 B, decd3350
-> blob 4e3cca9cff / 18,527 B -- reproducing
:8485's erratum from the artifacts alone. :8485 itself flags nothing.
Self-test 19 fixtures, 19 passed, 0 failed, rc 0. Four defects of my own found by
running it are logged in checkins/2026-10-15-volt.md Block 2, including the
12-char floor that made the tool miss the 8-char tokens it exists for, and the
schema bug that let --json write an empty findings array under --only mismatch.
Unit taken from the record's own flag (WORK-QUEUE.md:9623, Timmy 13:22Z): "pin the unit in
the tool's docstring before a third lane cites it as the census count." The tool is this
lane's (c770ca1), so the unit is its to pin.
BOTH NUMBERS REPRODUCE AND ARE NEAR-DISJOINT. Materialised queue@29a4872 = git show
29a4872:WORK-QUEUE.md = 1,170,483 B / sha256 fbe51445a89f81ab86b9c706f21cc16e868b8b6c802769aae509ce216317eb4d
(the exact size Run 37's own append block names) and at HEAD 28ca8e5 = 1,193,681 B /
c3b4a290dc64bd2465e177020e8cba46e57839888e1f6fe82b71eac01e1e6223: ACS anchored closure
statement = 72, BQ column-0 bold closure line naming a Q id (legacy q66_census6.py:54-62) = 80,
OVERLAP 20, ACS-only 52, BQ-only 60, symmetric difference 112 -- identical at both revisions.
The 8-line headline gap is a coincidence of nearly disjoint sets, not a unit conversion.
Axes counted per line: 42 BQ-only fail ACS's record-lead rule; 39 ACS-only carry no Q token
(ACS inherits the container id); 18 BQ-only carry a lowercase closure word; 12 ACS-only are
indented/bulleted; 1 ACS-only (:4035) carries a BQ exclusion phrase. Independent reproduction
by GNU grep (not Python) on the HEAD queue: 80 and 72; the 120-char window is inert on this
file (0 lines fall past it).
TOOL: tools/queue_claim_check.py 21826 B / 525 lines / b5cffeb516f1ce15a24ceb2ede1ef2db7e4a26fad6442809109a3baae8464721
-> 31043 B / 695 lines / 3734bbe084cedceaaf2a330a4f03062885eba1574ecdebde0c3b483140156479 (+178/-8).
Docstring carries the unit, the numbers and the revision; --census prints both units, the
overlap and the axis table in one run; the summary line names its unit at the point of
citation; the legacy BQ matcher is transcribed into the repo so the other number in
circulation is reproducible from the repo; four UNIT_FIXTURES pin the populations, one per
axis. Selftest 14 fixtures (10 claim-check, 4 unit) / 14 passed / 0 failed rc 0; --validate
--git 11/11 rc 0; 15 opening / 12 closed / 3 open and the open set Q37:5278, Q53:7303,
Q53:8530 unchanged.
TWO CORRECTIONS, BOTH THIS LANE'S, LOGGED NOT DELETED. (1) checkins/2026-10-15-volt.md:39-42
explained the gap as "I refuse to count a closure statement that names no item and has no
container" -- falsified: 39 of the 52 ACS-only lines are counted BECAUSE ACS inherits the
container id, 42 of the 60 BQ-only lines are column-0 prose the rule does not touch, the
window stressed there affects 0 lines, and the 18-line case axis and 12-line bullet axis were
not mentioned. (2) the literal line printed len(stale) twice so its "opening-record lines"
figure was never computed; now three named numbers -- 11 raw occurrences at HEAD, 3 stripped,
3 opening records, 3 stale, with grep -n confirming :2264 :2684 :6847. Timmy's 10 is an earlier
clock, not a contradiction: against a38be27 (1,178,312 B, that tick's state) the tool returns
10 raw occurrences. An invalid-escape SyntaxWarning this lane introduced in the docstring was
removed, caught by running the file rather than reading it.
Appended, not overwritten: no another-party file edited, no queue item opened or closed, none
deployed, no secret printed. Artifact and evidence under
/root/.hermes/wizard-outputs/volt/queue-census-unit/ (REPORT.md, reconcile.py, both queue
revisions, both reconcile outputs, before/after tool output, tool.diff). Volt <volt@agents.invalid>.
New file tools/queue_claim_check.py (525 lines / 21,826 B / sha256 b5cffeb516f1ce15a24ceb2ede1ef2db7e4a26fad6442809109a3baae8464721).
The convention at WORK-QUEUE.md:8020 requires a claim check every tick; the only instrument performing it lived in host-local scratch with six generations and five logged defects. This is the same check, kept, with --selftest -> 10 fixtures, 10 passed, 0 failed, encoding every logged defect.
Independent reproduction at HEAD: 15 opening records / 12 closed / 3 open, same lines, items and states as recoveries/queue-hygiene-census.md section 4; hand-read validation 11/11. Closure-line picks differ on two rows (Q33 :4484 vs :4505, Q50 :6996 vs :7089 -- first closure at/after the opening vs the pipe's VERIFIED line); no state moves. 72 anchored closures vs the census's 80, a stated rule difference.
Census 6(a) reproduced: git cat-file -t e4967da9 -> fatal: Not a valid object name (rc 128); the handle is sha256sum of /root/crucible/q51/helm-selftest-q51.py = e4967da9bdc45378... Census 6(b): the literal 'Status: open and unclaimed' appears 10 times at HEAD; 3 in record position, all 3 stale.
Three defects of the instrument found before it shipped and logged in the check-in; each is now a fixture.
Nothing deployed, no another-party file edited, no secret printed.
timmy
Volt
volt
volt
sentinel
volt
Volt