troupe-standup/wizard-work/volt/q65-2026-10-25-c3.md

Q65 census cycle 3 — two unrowed verifiers graded by execution, census 103 of 103, and one stale FAIL class in the census file itself

volt lane, 2026-10-25, driven at rev 8bb1aeb. Every figure below is a reading from this tick; the capture files named in §7 hold the verbatim output with the command that produced it.

§1 What was red, reproduced rather than quoted

The queue entry timmy appended at 8bb1aeb opened this item at a14a132 with two unrowed committed verifiers. I re-derived the state from the committed ledgers (both git shown to scratch, so neither tool read a worktree file) — q65-2026-10-25-c3-red.txt:

$ q63_verify_scan.py --repo . --baseline head_q63.tsv --gate head_gate.tsv
  committed verify_*.py     : 103  (spark 36  forge 29  ledger 16  sphinx 14  sol 5  null 2  beam 1)
  wired by name (invoke)    : 10 of 103
  run by q65_runner         : 84  (FAIL 24, PASS 60)
  unwired (code-grep)       : 9 of 103
  unwired, ledger-tolerated : 8  (1 NEW-UNWIRED, 8 declared-one-off)
  census coverage           : 101 of 103 committed verifier(s) carry a ledger row   <-- 2 UNCLASSED
  unwired, NEW (fault)      : 1
      NEW_UNWIRED  wizard-work/forge/verify_scan_dry_refactor.py
q63: 1 fault(s)                                                                    q63 rc=1

$ q65_runner.py --check --class gate-run,undeclared --q63 head_q63.tsv --ledger head_gate.tsv
  tree audit     : 2 unclassed of 103 committed verifier(s)   <-- named by neither ledger
  UNCLASSED wizard-work/forge/verify_scan_dry_refactor.py
  UNCLASSED wizard-work/sphinx/archive-lcmm-metadata-2026-10-25/verify_lcmm_dossier.py
q65: 2 fault(s)                                                                    q65 rc=1

Two different omissions in one count. The sphinx file was already wired (CHECK.sh:23 invokes it, so the scan counted it as wired by name) and had no ledger row — a bookkeeping gap, not a wiring gap. The forge file was wired by nothing (git grep -F finds it only in its own SCAN_DRY_REFACTOR_VERIFICATION.md, which is prose) and had no row: two faults on one file. Neither was a false claim about the tree; both were a claim the record could not see.

§2 Both files were then executed, not classified by hand

Graded through the runner (--emit --merge --q63 <scratch census carrying the two rows>), so the row carries the interpreter's rc, the wall time and the blob it graded:

path	verdict	rc	seconds	blob	host probe
wizard-work/forge/verify_scan_dry_refactor.py	PASS	0	2.48	d3543efa421d	L38:/root/troupe-standup
wizard-work/sphinx/archive-lcmm-metadata-2026-10-25/verify_lcmm_dossier.py	PASS	0	6.20	3c4b48a678a8	(empty)

By hand, the same two: forge 11/11 checks passed, OK: identical output (exit 0, 4811 bytes), OK: original still exhibits the removed smells (refactor is non-vacuous); sphinx mode: LIVE checks run: 21 failures: 0, VERDICT: dossier holds — the live arXiv API was re-fetched at check time, not compared against the archived copy.

Ledger movement: 85 → 87 rows, PASS 61 → 63, FAIL 24 unchanged, graded-clean 8 → 9 of 87 (the sphinx row is host-independent; the forge row is not — §4).

§3 The re-emit, and the one row it reclassified

q63_verify_scan.py --emit-baseline → 103 rows: gate-run 87, wired-invoke 8, declared-one-off 8, and 87 + 8 + 8 = 103 against 103 committed verifiers at the same rev. The diff against the committed file (q65-2026-10-25-c3-reemit.diff) is four hunks, and I am not going to call it a pure append because one of them is a reclassification:

3c3    # rev: d05d93c  ->  # rev: 8bb1aeb
19c19  gate-run  wizard-work/forge/verify_check_lint_classes_dry.py  q65:FAIL  ->  q65:PASS
36a37  > gate-run  wizard-work/forge/verify_scan_dry_refactor.py  q65:PASS
107a109 > gate-run wizard-work/sphinx/archive-lcmm-metadata-2026-10-25/verify_lcmm_dossier.py  q65:PASS

The FAIL → PASS is derived, and it is bound: the runner row reads PASS rc 0 0.53 s against blob 62082e082a0472546b415219a9180836ac88908b, git rev-parse HEAD:wizard-work/forge/verify_check_lint_classes_dry.py returns that same id, and git diff --stat a70197f..HEAD -- <that path> is empty. So the file has graded PASS since a70197f, while the committed census at d05d93c still asserted FAIL against the pre-fix blob 17a08fe2d2 (4f76eaa:). That is the same DRIFT class cycle 2 recorded for the runner ledger — it lived in the census file too, and the re-emit is what closes it. Nobody should read this hunk as a tolerance: the row still says PASS* (host-pinned, §4), so it does not enter graded-clean.

§4 The PASS on the forge row is a PASS on this host, measured

The static probe prints L38:/root/troupe-standup; the file is REPO_ROOT = "/root/troupe-standup". A static probe is not a demonstration, so I ran the demonstration (-c3-controls.txt §B): a clone at 8bb1aeb with both files that verifier grades appended raise RuntimeError("sabotage") — wizard-work/forge/_scan_dry_refactored.py and tools/check_lint.py — and the clone's copy of the verifier, run from the clone, returns rc 0, 11/11 checks passed. It graded /root/troupe-standup. Q62's class, one line, the forge lane's; the row is PASS* and belongs in that column until the root resolves from __file__.

The matched control on the sphinx row goes the other way, in the same clone: one character of one paper title in dossier.json changed, everything else held fixed → rc 1, mode: LIVE checks run: 21 failures: 6, VERDICT: dossier does NOT hold. So graded-clean 9 of 87 gained a row that is clean because it reads its own tree, and the one that is not clean is named.

§5 The census still bites

A green count is worth nothing unless the same instrument can go red on the same rev, so (-c3-controls.txt §A): drop the forge row from the census copy → census coverage 102 of 103 … 1 UNCLASSED; drop it from both ledgers → tree audit 1 unclassed of 103, q65: 1 fault(s), rc 1, naming the file. The coverage arithmetic is not decorative.

Note what the negative control also shows: q63 alone still printed q63: 0 fault(s) at 102 of 103, because UNCLASSED is the runner's fault class and q63's own fault is NEW_UNWIRED. Two instruments, two fault classes, one of them the gate — which is exactly why volt/CHECK runs both.

§6 Green, measured

q65-2026-10-25-c3-green.txt, captured 2026-10-25T09:36Z:

q63_verify_scan.py --repo .          : 103 committed, wired 10, gate-run 85 (FAIL 24, PASS 61),
                                       code-grep unwired 8, tolerance 8 declared-one-off,
                                       coverage 103 of 103, NEW 0, q63: 0 fault(s), rc 0
q65_runner.py --check                : 87 rows (PASS 63, FAIL 24), graded 87 of 87,
                                       graded-clean 9 of 87, host-pinned 54, tree audit 0
                                       unclassed of 103, q65: 0 fault(s), rc 0
bash wizard-work/volt/CHECK          : CHECK PASS, rc 0
q65_runner.py --selftest             : 22 cells, 22 passed
q63_verify_scan.py --selftest        : 10/10

§7 What this did not do, and whose it is

• The forge file is still wired by nothing. Its census fault clears because it is graded by execution — Q65's own contract, "invoked-and-graded, retired, or declared one-off" — and not because a committed line now invokes it. git grep -F verify_scan_dry_refactor still returns one hit, in its own prose doc. If forge wants a real invocation, that edit is forge's; the row is honest either way, and the diff of the code-grep count (9 → 8) attributes the movement to the grade, not to a new caller.
• 54 PASS* rows remain Q62's class, one per owning lane. This tick added one and measured its remedy (__file__-relative REPO_ROOT at :38).
• 24 FAIL rows remain per-lane findings held open in the ledger. Unchanged by this tick.
• The census is still not a tools/verify.py leg. The class has now reopened three times in two days on nothing worse than a new file landing without a row. Reply 93 §4 left that promotion to the operator; this tick does not re-argue it, and nothing in tools/verify.py noticed either reopening.
• No other lane's file was edited. The only changed files are the two instruments this lane owns (q63_unwired_baseline.tsv, q65_runner_baseline.tsv), the four evidence files beside this one, the checkin, the queue append and the re-rendered index.

§8 Evidence

• q65-2026-10-25-c3-red.txt — red reproduced from the committed ledgers at 8bb1aeb, rc 1 / 1.
• q65-2026-10-25-c3-green.txt — the four green readings above.
• q65-2026-10-25-c3-controls.txt — the census-omission fault, the host-pin sabotage, the one-character title mutation.
• q65-2026-10-25-c3-reemit.diff — the four-hunk diff of the census re-emit, with row counts.
• git diff --numstat: 4 2 wizard-work/volt/q63_unwired_baseline.tsv, 3 1 wizard-work/volt/q65_runner_baseline.tsv.