Closure of Q71 (ledger's commits-table.md). b9e3780 landed the byte-exact row
and the verifier; this commit lands the record and two defects the first cut
produced, both measured:
1. The pin was not reproducible. The first committed body was the 21:53:09Z
fetch verbatim (33844 B, sha256 a7f55e4e). --record then produced a DIFFERENT
body for the SAME five commits (30412 B): same five SHAs, same key set per
record, equal compact size per record (5832/6347/5238/7024/5965), 0 records
differing, 437 newlines vs 0 -- whitespace only, from the request's Accept
header. The committed body is now the compact one (sha256 6694f5ac, response
date 2026-10-25T21:58:56Z) and BOTH --record and a plain curl with the gate's
headers reproduce it byte for byte. The Provenance line names the re-pinned
fetch, because that is the body committed.
2. --record wrote the body it graded from, i.e. the per_page=100 resolution
fetch: measured 597809 B / 100 records into a path the document's own
provenance line calls "5 records, per_page=5". Re-pinning with it would have
swapped a 5-record body for a 100-record one that still graded green. It now
fetches the cited URL exactly (a second request only on that path) and
validates it parses before writing.
Also logged: control cell 14 hard-coded the provenance stamp it mutates, so
after the re-pin the mutation became a no-op and the cell reported rc 0 where it
wanted rc 1 -- a control that silently stopped controlling. It now derives the
substitution from the document; the matrix is 23/23 again.
Measured at this tree:
- bash wizard-work/ledger/CHECK rc 0, 29 lines (23 PASS + 4 INFO + leg summary)
vs 1 line at 0a86c9c before the leg existed; rc 0 with /root/.hermes masked
(unshare -m + tmpfs, 0 entries).
- Clone of b9e3780 at /root/q71-clone-1792965576 with these files: CHECK rc 0;
row 4 corrupted back to kernel_git there -> rc 1, "[FAIL] SUBJECT row 4
differs from feed 44388c8f3e"; restored -> rc 0. The leg proves itself inside
CHECK, not only under its own harness.
- git archive export of b9e3780 (no .git): verifier rc 0 pinned and rc 0 live.
- 23/23 control cells (scratch/q71/controls.txt), including rc 1 on the shipped
pre-fix blob at 6d936be naming SUBJECT at character 68, and rc 2 for the five
could-not-grade inputs.
- python3 tools/verify.py --repo . -> 8 legs, 8 pass, 0 fault, 0 ungradable.
Queue: closure record appended at the foot (pure append, 11 lines, prefix
byte-identical), and item Q71's own status lead rewritten from "open and
unclaimed" to "closed at b9e3780 and the closure commit" -- the state marker, in
the shape 8b9492b used for Q68, so the index does not publish a closed item as
open. queue_claim_check: Q71 out of the open set; docs/queue-index.md
re-rendered in this commit.
Evidence: wizard-work/volt/q71-2026-10-25.md.
Q68 CLOSED at 5a43291: gate rc 0 / Ran 136 / ALL PASS (242 checks) from a clone of that commit, against rc 1 with zero cells and a skipped toposort leg at 5a43291^. 17 cells, six mutants graded (4 flipped from SURVIVED to KILLED, 1 already killed by the old suite -- the item's split does not reproduce, 1 proven equivalent over 3000 graphs and retired by deletion), 3000-graph fuzz 0/0/0/0, six control cells. My own first cut named the host path in a docstring while explaining it was unused; git grep counted it, so the sentence is rewritten here.
q65_no_verdict.py asks the AST whether a verifier can ever return non-zero:
raise / assert / non-zero exit / unittest.main. 15 of the 106 have none (all
spark), and 14 of the runner ledger's 64 PASS rows are rows on such a file, so
Q65's "graded 88 of 88" is rc coverage and nothing more. Four dynamic controls
(corrupted subject, rc unchanged, print changes) and three negative controls on
the instrument (NEW, gains-a-verdict-before-rowed, STALE). Wired as CHECK's
fourth leg. No other lane's file edited; queue addendum appended and the index
re-rendered in this commit.
At 30653c6 the scan read 99 committed verifiers, 7 wired, census coverage 93 of 99, 5 NEW_UNWIRED, q63 5 faults; volt CHECK rc 1 on 6 unclassed. After: wired 8, census 99 of 99, NEW_UNWIRED 0, q63 0 faults, volt CHECK rc 0 (tree audit 0 unclassed of 99). q65_runner ledger 79 rows (PASS 55/FAIL 24) -> 83 (58/25).
Pathspec defect, measured not assumed: sphinx's archive-agentic-memory-5paper-dossier-2026-10-25/CHECK.txt is one line invoking verify_claims.py from its own directory, and CODE_PATHSPECS carried :(glob)**/CHECK and not CHECK.txt -- so a lane with a committed gate was filed as unwired. Patched copy, every other argument held fixed: wired 7->8, code-grep 13->12, NEW_UNWIRED 5->4, and the only file moving between the two NEW lists is that verifier. Scanner selftest 10/10 after the change, c-cell on the referrer-path token included. Readings: q65-2026-10-25-residual-{red,green}.txt.
Census re-emitted: 99 rows = gate-run 83 + wired-invoke 8 + declared-one-off 8, arithmetic against 99 at the same rev. The four files left undeclared were executed: forge/verify_check_lint_classes_dry.py FAIL rc 1 0.39s; forge/verify_repro_bounds_refactor.py PASS 0.35s; forge/verify_smell_check_monotonic_refactor.py PASS 0.58s; spark/verify_env.py PASS 0.06s.
The FAIL is Q65's thesis, found by Q65's own runner and held open as a finding for forge: orig_text() reads git show HEAD:tools/check_lint.py as the 'original', and the refactor it verifies was committed in the same commit that added the verifier (4f76eaa), so original and refactored are the same bytes -- checks 4a/4d fail, and the two BYTE-IDENTICAL checks pass vacuously. Remedy (pin the pre-refactor blob by sha) is forge's; not edited here.
Still open and named: 25 FAIL rows are per-lane findings; 51 PASS* rows read an absolute host root (Q62's class, 48 before this tick); path-claims is forge's two-character citation at SMELL_CHECK_MONOTONIC_REFACTOR_VERIFICATION.md:95-96, so tools/verify.py is 8 legs / 7 pass / 1 fault both before and after; promoting volt CHECK to a tools/verify.py leg stays the operator's call. Index re-rendered in this commit.
Record at wizard-work/volt/q65-2026-10-24.md, queue addendum appended, index re-rendered in the same commit (11096 lines, 52 ids unchanged -- nothing here opens a record).
The item narrows rather than closes: 88 committed verifiers = 71 graded by q65_runner + 4 invoked by a committed line + 8 declared one-off + 5 executed with no rc (TIMEOUT). The five are named, and a per-file window is what grades them.
Q61 was opened by the pipe as open and unclaimed in beam's lane; closed as
queue work. 16 of 16 iterator-form mismatches before, 0 after; the pre-fix blob
reported a 3-cycle delivered as generators as a successful order, which the
opening record did not measure. Suite falsified against blob 4da0d8e and
against the one-token mutation. verify.py 8/8.
The opening line at :10911 still reads open and unclaimed -- append-only, so
undeletable -- and is now the fifth STALE-opening-line, named in the record
rather than smoothed.
3aa745c appended the record and ran queue_index.py without --write, so
index-current read STALE at line 63 and append-audit named 3aa745c
index:no. The re-render alone fixed index-current but not append-audit,
which grades the newest queue-touching commit in its own tree; this
append supersedes it with the render in the same commit. The record's
measurements are unchanged: reply_check 333 files faults 0, path-claims
17 missing 0 new.
My previous commit appended to WORK-QUEUE.md and re-ran queue_index.py
without --write, so the index printed its summary and wrote nothing;
verify.py's index-current leg caught it: "STALE: rendered document differs
at line 63", and append-audit named 3aa745c as the stale commit. This is
the same tree after the one-flag fix -- 11 insertions, 11 deletions, no
hand edit.
timmy
volt
spark
timmy
volt
volt
timmy
beam