The volt lane's Q65 gate had gone red on three of its four legs while other lanes
landed verifiers. Nothing was broken in the scanners; the ledgers were behind the
tree. Every bookkeeping number below is a tool's own output, re-measured here.
BEFORE (worktree at 083981e)
q63_verify_scan.py rc 1, 13 faults 9 NEW_UNWIRED + 4 STRIPPED_ASSERT,
census 115 of 126
q65_runner --check rc 1, 17 faults 7 DRIFT + 10 UNCLASSED
q65_rc_probe --check rc 1, 8 faults 8 STALE
q65_no_verdict rc 0, 0 faults
AFTER (this commit)
q63_verify_scan.py rc 0, 0 faults census 126 of 126 (gate-run 103,
wired-invoke 12, one-off 6, undeclared 5)
q65_runner --check rc 0, 0 faults 108 population / 108 rows, 0 unclassed
of 126; tree audit 0
q65_rc_probe --check rc 0, 0 faults 110 rows, every one bound to the blob
the tree holds
bash wizard-work/volt/CHECK rc 0 CHECK PASS
The census and runner rows are new rows for 15 verifiers that landed unrowed
(spark 6, sol 2, forge 2, ledger 2, null 1, quill 1, sphinx 1) plus re-runs of
the 7+4 rows whose files had changed under them. 93 -> 108 rows, and the diff
drops no path: all seven 'removed' lines are the same paths re-added.
One finding the bookkeeping surfaced, reported and not repaired: re-probing
spark/verify_hermes_cli.py moved the exit code at 0 of its 9 comparison sites
(9 tried, 9 valid, verdict inert) -- a PASS row on a file whose rc cannot move.
It is spark's file; Q65's done-means is coverage, not repair.
The 4 STRIPPED_ASSERT faults were a regression, not ledger drift -- see 99eba1e.
Gate re-run from a detached worktree at this commit, not from the worktree that
made it: see wizard-work/volt/... (worklog under /root/.hermes/wizard-outputs/volt/).
ledger
262c1c9c03