Q65 residual, cycle 2 — the census is 101 of 101 again, one stale FAIL was re-earned, and the ledger's PASS on the GDP table is a host-pinned pass

volt lane (Workhorse) · 2026-10-25 · measured at d05d93c (pre) and in the worktree carrying this record (post) · readings in q65-2026-10-25-r4-red.txt and q65-2026-10-25-r4-green.txt beside this file

§0 The claim in one paragraph

When Q65 last closed (8ec7725, 02:21Z) the census read 93 of 93. It has reopened twice since, each time because a verifier landed and no ledger row followed it. At d05d93c the census read 99 of 101: wizard-work/ledger/verify_gdp.py (unwired, unrowed, a NEW_UNWIRED fault) and wizard-work/sphinx/archive-mmlongcite-2026-10-25/verify_mmlongcite.py (invoked by its own CHECK.sh, so wired, but unrowed). Both are now graded by execution and every figure below is an rc, not a reading. In the same pass the lane gate reported a third fault the census could not see: a DRIFT row — forge's verify_check_lint_classes_dry.py carried a FAIL measured against blob 17a08fe2d2, while the tree at HEAD has held 62082e082a since a70197f. That row was re-run and now holds a PASS earned on the bytes that exist.

§1 The state before anything was changed (red)

Captured in a detached worktree at d05d93c (git worktree add --detach), so the reading is the committed tree and not my worktree's residue:

committed verify_*.py     : 101
run by q65_runner         : 83  (FAIL 25, PASS 58)
census coverage           : 99 of 101 committed verifier(s) carry a ledger row   <-- 2 UNCLASSED
unwired, NEW (fault)      : 1
    NEW_UNWIRED  wizard-work/ledger/verify_gdp.py
q63: 1 fault(s)            (q63 rc=1)

q65_runner -- rev HEAD, 83 population file(s), 83 ledger row(s)
  content-bound  : 1 row(s) not bound to the tree at HEAD (DRIFT/UNBOUND)
  tree audit     : 2 unclassed of 101 committed verifier(s)   <-- named by neither ledger
  DRIFT wizard-work/forge/verify_check_lint_classes_dry.py: rc measured against blobs 17a08fe2d2, tree at HEAD has 62082e082a
  UNCLASSED wizard-work/ledger/verify_gdp.py
  UNCLASSED wizard-work/sphinx/archive-mmlongcite-2026-10-25/verify_mmlongcite.py
q65: 3 fault(s)

Three faults, three different instruments: one unwired file (census), two files in no class row (tree audit), one rc bound to a blob that is not at HEAD (content-bound). None of them is bookkeeping an operator could wave through — the first two are "nothing notices if this is deleted", the third is "this verdict is about bytes that no longer exist".

§2 The census re-read is a pure append, and that is measured, not asserted

q63_verify_scan.py --repo . --rev HEAD --emit-baseline was first written to a scratch path and diffed against the committed q63_unwired_baseline.tsv, comments excluded:

36a37
> undeclared  wizard-work/ledger/verify_gdp.py  no invocation, no declaration, no graded run
95a97
> wired-invoke  wizard-work/sphinx/archive-mmlongcite-2026-10-25/verify_mmlongcite.py  HEAD:.../CHECK.sh:26:if python3 verify_mmlongcit...

Two added lines, no row reclassified, no row dropped. That matters because a re-emit is the one operation that could launder a fault: a census that rewrites its own classes can quietly turn a NEW_UNWIRED into a tolerated row. Here the only change is the two files that were actually invisible. The scan's own arithmetic then read 101 rows: gate-run 83, wired-invoke 9, declared-one-off 8 before grading, and gate-run 85, wired-invoke 8, declared-one-off 8 after — the ledger's verify_gdp.py moved undeclared -> gate-run by being executed, and the sphinx file moved wired-invoke -> gate-run for the same reason. Nothing was promoted by editing a label.

§3 The two files, graded by execution

q65_runner.py --emit --merge --only <path> — the runner executes the file, records the rc, the seconds, the git blob id it graded, and a static host-pin probe of the committed blob:

path	verdict	rc	s	blob	host probe
`wizard-work/ledger/verify_gdp.py`	PASS	0	0.10	`ba577cd8ae`	`L3:/root/troupe-standup`
`wizard-work/sphinx/archive-mmlongcite-2026-10-25/verify_mmlongcite.py`	PASS	0	2.28	`c1f03701bf`	—

The sphinx row is a graded-clean pass and it survives a negative control. In the scratch worktree, one sha256 pin in manifest.json was flipped (flip_pin.py, key sha256), and the verifier re-run: rc 1, checks run: 39 failures: 1, FAILED: sha256 atom.xml == 1b90f676437a…, VERDICT: archive does NOT hold. So the PASS 0 is a pass on the archive it names, not a print.

The ledger row is a host-pinned pass, and the pin is measured in both directions. In the same scratch worktree the United States IMF cell of that tree's gdp_nominal.csv was rewritten 32,642,373 -> 1,000:

python3 verify_gdp.py (no argv, as the runner invokes it) → rc 0, result: PASS. The row graded the host's file (/root/troupe-standup/wizard-work/ledger/gdp_nominal.csv), not the tree that ran it.
python3 verify_gdp.py "$PWD/gdp_nominal.csv" (the same corrupted bytes, named explicitly) → rc 1, result: FAIL. The checks are real; the default is what is pinned.

verify_gdp.py:3 is PATH = sys.argv[1] if len(sys.argv) > 1 else '/root/troupe-standup/wizard-work/ledger/gdp_nominal.csv'. One line — os.path.join(os.path.dirname(os.path.abspath(__file__)), 'gdp_nominal.csv') — and the row stops being a PASS*. That line is the ledger lane's to take; it is not edited here. Until then the row is a row, a verdict, and not coverage of the tree, which is exactly what the PASS* column exists to say.

§4 The DRIFT row: a FAIL that had outlived its bytes

q65_runner_baseline.tsv carried undeclared wizard-work/forge/verify_check_lint_classes_dry.py FAIL 1 0.39 17a08fe2d230…. That blob is 4f76eaa: — the commit that added the verifier. a70197f pinned ORIG_REF to the pre-refactor blob and repaired the vacuous equivalence, changing the file to 62082e082a…; git rev-parse HEAD:wizard-work/forge/verify_check_lint_classes_dry.py and git hash-object of the worktree both return 62082e082a0472546b415219a9180836ac88908b, and git diff --stat a70197f..HEAD for that path is empty. The ledger's FAIL therefore described a file that has not existed at HEAD for several commits — a held-open finding that had already been fixed, which is the mirror image of the defect the blob column was added to prevent.

Re-earned by execution at d05d93c:

PASS       0.53s wizard-work/forge/verify_check_lint_classes_dry.py
row: gate-run  .../verify_check_lint_classes_dry.py  PASS  0  0.53  62082e082a0472546b415219a9180836ac88908b  L44:/root/troupe-standup

That row remains PASS* (host-pinned at :44) and so does not enter graded-clean. It is honest either way: the pin is real, and the verdict now belongs to the bytes under it.

§5 The state after (green)

committed verify_*.py     : 101  (spark 36  forge 28  ledger 16  sphinx 13  sol 5  null 2  beam 1)
run by q65_runner         : 84  (FAIL 24, PASS 60)
census coverage           : 101 of 101 committed verifier(s) carry a ledger row
unwired, NEW (fault)      : 0
q63: 0 fault(s)            (q63 rc=0)

q65_runner -- rev HEAD, 85 population file(s), 85 ledger row(s)
  rows at emit   : 85  (PASS 61, FAIL 24)
  graded (has rc): 85 of 85
  graded-clean   : 8 of 85  (PASS on a host-independent verifier)
  tree audit     : 0 unclassed of 101 committed verifier(s)
q65: 0 fault(s)

bash wizard-work/volt/CHECK → CHECK PASS: census covers every committed verifier; runner ledger grades clean., rc 0, selftest 22 of 22. Ledger movement: rows 83 → 85, PASS 58 → 61 (three: the two new files and the re-earned forge row), FAIL 25 → 24, PASS* 53 of 61 PASS rows, graded-clean 8 of 85 (was 7 of 83).

§6 Two display caveats, stated so the next reader does not re-derive them

The ledger's # rev: line is the last emit's rev, not every row's. Rows here were measured at 30653c6 (83 of them) and d05d93c (2 plus the re-earned one); the header reads d05d93c. The binding guarantee is not that line — it is column 7, the blob id per row, which --check recomputes at its own --rev. A reader who wants "when was this rc taken" must read the blob, not the header. Recorded, not fixed: changing the header's meaning would break every ledger read that pins it.
The runner ledger's class column is historical. It says undeclared for all 83 rows that were emitted under that class; the current classification is q63_unwired_baseline.tsv, re-emitted at d05d93c with 85 gate-run. The column records where a row came from at emit time, and it is not refreshed by --merge. No gate reads it as current (--check reads the q63 ledger and the tree), so this is cosmetic — but it reads wrong at a glance.

§7 What stays open, and whose

24 FAIL rows. Per-lane findings held open in the ledger, unchanged in kind from reply 93. A FAIL is the file's claim being false at this tree; the runner's job is to make it visible, not to make it untrue.
53 PASS* rows (host-pinned). Q62's class, one per owning lane. This tick added one (verify_gdp.py) and measured its remedy to the line (§3), which is more than a row.
path-claims is still red, and it is not this item's. tools/verify.py --repo . at this tree reads 8 legs / 7 pass / 1 fault: two missing paths off forge's SMELL_CHECK_MONOTONIC_REFACTOR_VERIFICATION.md:95-96 (the leading-underscore pair) and their copies in the append-sanctioned record. Adjudicated at a259960; unchanged here.
No tools/verify.py leg runs this census. Q65's closure recorded that hole; it remains the operator's call (reply 93 §4) and is not re-argued. The reason it matters is §0: the census reopened twice in two days and nothing red outside this lane's own CHECK noticed either time.

Nothing from inbox/ is quoted. No other lane's file was edited: the two changed files are wizard-work/volt/q63_unwired_baseline.tsv and wizard-work/volt/q65_runner_baseline.tsv.

§8 The one-line gate, and the reading that says it can fail

The command that certifies this tick is

cd /root/troupe-standup && bash wizard-work/volt/CHECK >/dev/null 2>&1 \
  && python3 wizard-work/volt/q63_verify_scan.py --repo . | grep -q 'census coverage *: 101 of 101'

Measured three ways so the rc 0 is not a print:

tree	command	rc
this commit (`008bb24`)	as written	0
detached worktree at `d05d93c` (pre-change)	as written	1 — `CHECK` itself reads 1 there, and the census half reads 1
this commit	same, with the figure changed to `101 of 102`	1 — the grep is not vacuous

Both halves fail on their own evidence: CHECK on the pre-change tree returns rc 1 from the q63/DRIFT faults, and the census half returns rc 1 from a figure that is not in the output. A gate whose red state has never been observed is the class this whole item exists to catch, so the red reading is part of the artifact rather than a footnote.

11 KiB Raw Blame History