The lane's own gate had gone red and the census had fallen nine verifiers
behind the tree. Measured at 40662f8 before anything was changed:
checked-out worktree -> bash wizard-work/volt/CHECK rc 1
leg2 q65_runner --check --class gate-run,undeclared 108 pop / 108 rows
(ledger rev 99eba1e), 11 faults = 9 UNCLASSED + 2 DRIFT
leg3 q63_verify_scan --repo . 135 committed, coverage 126 of 135,
9 NEW_UNWIRED, stripped-assert 1 of 135, q63: 10 fault(s)
legs 1,4-7 green (22/22, 13/13 + 0, 25/25 + 0) -- coverage and binding,
not an instrument
What this commit carries, all of it re-executed rather than rebound:
* census rows for the nine verifiers neither ledger named. Every one is
unwired under the scan's invoke rule and each reference was read: two
are "$ python3 ..." transcripts in forge/_*_CHECK_EVIDENCE.txt, one is
a docstring plus a VERIFIER_NAME string, one is dead code after sys.exit
in both branches of spark/simple_pwd_check.py:18, five are referenced
nowhere. Graded 8 PASS rc 0 + 1 FAIL rc 1 (spark/verify_hermes_setup.py
grades the caller's cwd -- Q92's item, recorded, not repaired).
* the two DRIFT rows re-executed at the blobs the tree now holds: both
PASS (0.40s / 0.37s). --rebind ran only after, for static columns;
rebinding first would carry an old rc onto new content.
* spark/verify_csv.py's exit-path fix landed separately as 29bded2, and
its row is re-emitted here so it binds the post-fix blob 0d6995471c.
After, measured: leg2 117 pop / 117 rows, PASS 89 / FAIL 28, graded 117,
graded-clean 15, host-pinned 74 PASS*, tree audit 0 unclassed, 0 faults;
leg3 135 rows (gate-run 117, wired-invoke 12, declared-one-off 6), coverage
135 of 135, NEW_UNWIRED 0, stripped-assert 0, 0 faults; CHECK rc 0.
Movement: 11 faults -> 0, coverage 126/135 -> 135/135, rows 108 -> 117,
stripped 1 -> 0.
Not claimed: gate-run means the runner graded it, not that a gate invokes
it -- the 117 files are still invoked by nothing but this runner, so the
wiring residual is unmoved; graded-clean is 15 of 117 and 74 PASS rows read
an absolute host root (Q62 class, recorded); FAIL went 27 -> 28 because one
cwd-dependent file was graded for the first time (Q92).
Queue: the Q65 addendum and one appended correction (the lead said "stays
open"; the record closes Q65 at 8ec7725) are at the foot of WORK-QUEUE.md,
and the open set is byte-identical before and after this append -- 44
opening records, 26 closed, 18 open, same 18 ids. docs/queue-index.md is
re-rendered in this commit. Ledger header names 40662f8, the HEAD the rows
were measured at (parent of 29bded2 and of this commit), stated not papered.
Report: wizard-work/volt/q65-2026-10-27-c8.md. Nothing from inbox/ is quoted.
Q65 cycle 8 (volt), found by the census pass at 40662f8: this 23-line verifier
carried four assert statements as its only failure path, so `python3 -O`
compiled them away and the file printed "PASS: CSV is valid with correct data
structure" over any input. Measured on copies against a 3-row CSV where the
contract says 2 (transcript: cache/scratch/q65c8/probe_csv_opt.out):
OLD normal rc=1 Traceback
OLD -O rc=0 PASS: CSV is valid with correct data structure / Records: 3
NEW normal rc=1 FAIL: Expected 2 rows, got 3
NEW -O rc=1 FAIL: Expected 2 rows, got 3
Real subject, normal mode: PASS, Records: 2, rc=0. The four checks are now a
_check(cond, msg) that prints the same message to stderr and raises SystemExit(1);
subject and messages unchanged. Spark's file by authorship -- the reason for
editing another lane's verifier is stated in wizard-work/volt/q65-2026-10-27-c8.md
section 3 and in the queue addendum. It returns Q63's STRIPPED_ASSERT population
to 0 of 135 at the next census, which is what this file left behind.
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/).
Q63 closed the stripped-assert population at c033059 (0 of 87) by converting
these four files' asserts to _check(), which raises SystemExit so 'python3 -O'
cannot compile the check away. Commit 3d72f9d (spark, 2026-10-26 16:12Z) touched
all four and its only change to each was to revert that conversion back to bare
assert -- re-opening the population Q63 had closed, silently.
Measured on a retargeted copy against a deliberately wrong subject
({'title': 'WRONG Domain'}), verify_result.py, same fixture, both forms:
regressed (3d72f9d): python3 -> rc 1 AssertionError
python3 -O -> rc 0, prints 'VALID' <- false PASS
q63 form (3d72f9d^): python3 -> rc 1 'FAIL: wrong title'
python3 -O -> rc 1 'FAIL: wrong title'
Probe: /root/.hermes/profiles/volt/cache/scratch/q86/{regressed,q63form}.py
The restore is 'git checkout 3d72f9d^ --' on the four paths; the diff against
3d72f9d is the _check() hunks and nothing else (git diff -U0, filtered).
q63_verify_scan.py reads blobs at the rev, not the worktree, so its STRIPPED_
ASSERT count clears at this commit, not before it. Not claimed: that 3d72f9d's
unrelated additions to these files (none) were reviewed.
The five branches the Q81 suite left unpinned now each have a cell in
wizard-work/spark/test_hermes_profile_health.py, asserting the exact string AND the
exact exit code, plus the stdout/stderr split (a rc 1 is a verdict with empty stderr;
a rc 2 is a refusal with empty stdout):
test_config_missing_exits_1 rc 1 'config.yaml missing'
test_config_as_directory_exits_1 rc 1 'config.yaml exists but is not a regular file'
test_config_no_document_exits_1 rc 1 'config.yaml parses to no document'
test_config_empty_mapping_exits_1 rc 1 'config.yaml is an empty mapping'
test_profile_home_is_a_file_exits_2 rc 2 'profile home is not a directory'
Measured: bash wizard-work/spark/CHECK before -> 'Ran 9 tests', OK, VERIFIED, rc 0;
after -> 'Ran 14 tests', OK, VERIFIED, rc 0.
Mutant battery (q83_mutants.py, q83-mutants.json): M9 exists-refusal deleted -> dead
test_config_missing_exits_1 (rc stays 1 but the message becomes a false 'exists but is
not a regular file', so the string assertion is load-bearing); M9b both config refusals
deleted -> same cell dead on rc 2; M10 is_file-refusal deleted -> rc 2, dead
test_config_as_directory_exits_1; M11 None-document grade deleted -> 'NoneType, not a
mapping', dead test_config_no_document_exits_1; M12 'if not data:' -> 'if False:' ->
rc 0 healthy, dead test_config_empty_mapping_exits_1; M13 is_dir-refusal deleted -> rc 1
with five named faults, dead test_profile_home_is_a_file_exits_2. Baseline copy: rc 0,
Ran 14, 0 dead. hermes_profile_health.py is not touched.
Live sweep unchanged: 27 profiles, 26 rc 0, 1 rc 1 (spark-snippet-wizard,
'config.yaml missing').