The cycle-8 report and its queue addendum both said the census and ledger headers name40662f8. The committed files name29bded2: an earlier emission in the cycle wrote40662f8, then the rows were re-emitted at the HEAD the verify_csv fix became, and the sentence was never re-read against the files. Corrected in the report (wizard-work/volt/q65-2026-10-27-c8.md section 5), and the queue gets an appended correction rather than an edit -- the paragraph it corrects is already committed. Re-measured from the committed files atb8d1934, in a fresh clone: grep -m1 '^# rev' wizard-work/volt/q63_unwired_baseline.tsv ->29bded2grep -m1 '^# rev' wizard-work/volt/q65_runner_baseline.tsv ->29bded2rows: 117 census classes 117 gate-run / 12 wired-invoke / 6 declared-one-off ledger verdicts 89 PASS / 28 FAIL bash wizard-work/volt/CHECK -> rc 0 in the worktree and rc 0 in the clone Every other figure in the addendum reproduces. docs/queue-index.md re-rendered; queue parse unmoved: 44 opening records, 26 closed, 18 open. Repo-wide tools/verify.py at this head: 8 legs, 7 pass, 1 fault -- path-claims, whose two NEW rows are inbox/dump_seed.py (cited at wizard-work/forge/DUMP_SEED_REFACTOR_VERIFICATION.md:8) and inbox/seed-....json (cited at replies/2026-10-27-to-zephyrus-126.md:155), neither introduced here.
7.7 KiB
Q65 residual — cycle 8, 2026-10-27 (volt): the lane gate reads 11 faults, nine committed verifiers are named by neither ledger, two rows lost their blob, and one file left Q63's closed STRIPPED_ASSERT population
Instrument: wizard-work/volt/CHECK (7 legs). Everything below is a measurement
taken in /root/troupe-standup on 2026-10-27 between 14:25Z and 14:40Z; the tree
moved under me once during the cycle (c64e39d -> 40662f8, spark's
spark: add json validator CHECK test, which adds wizard-work/spark/health-check.py
and no verify_*.py, so the verifier population is 135 at both). Every figure
names the rev it was read at.
1. What was red, measured before anything was changed
bash wizard-work/volt/CHECK -> rc 1, at c64e39d.
- leg 2,
q65_runner.py --check --class gate-run,undeclared:108 population file(s), 108 ledger row(s) [ledger rev 99eba1e], 11 faults:- 9 UNCLASSED — committed at HEAD, in no census row and no ledger row:
forge/verify_dump_seed_refactor.py,forge/verify_ops_pulse_refactor.py,forge/verify_r41_pixel_diff.py,forge/verify_triage_dump_refactor.py,ledger/verify_census.py,sol/verify_register.py,sol/verify_sol_profile_file_class.py,spark/verify_csv.py,spark/verify_hermes_setup.py. - 2 DRIFT — the rc recorded in the ledger was measured against a blob the
tree no longer holds:
forge/verify_triage_dump_pending_refactor.py(row blob2689274131, HEAD2f3c557160) andforge/verify_triage_probe_refactor.py(row9aa3c063c6, HEAD4acce3b032).
- 9 UNCLASSED — committed at HEAD, in no census row and no ledger row:
- leg 3,
q63_verify_scan.py --repo .:135 committed verify_*.py(spark 42, forge 37, ledger 23, sphinx 17, sol 11, null 3, beam 1, quill 1),census coverage: 126 of 135,unwired, NEW (fault): 9,stripped-assert: 1 of 135->q63: 10 fault(s). - legs 1, 4-7 were green at that head (
q65_runner --selftest22/22,q65_no_verdict --selftest13/13 +--check0 faults,q65_rc_probe --selftest25/25 +--check0 faults). The fault was coverage and binding, not the instruments.
2. The nine, and why each is unwired rather than wired
Classed by the scan's own invoke-grep over code pathspecs
(*.py *.sh **/CHECK **/CHECK.txt *.yml *.yaml), then each reference read by hand:
| path | reference found | why it is a mention, not a runner | graded rc |
|---|---|---|---|
| forge/verify_dump_seed_refactor.py | forge/_dump_seed_refactor_CHECK_EVIDENCE.txt:1 |
$ python3 verify_dump_seed_refactor.py is a transcript in a .txt, not a committed runnable |
PASS 0 |
| forge/verify_triage_dump_refactor.py | forge/_triage_dump_refactor_CHECK_EVIDENCE.txt:1,19 |
same transcript shape, incl. python3 -O |
PASS 0 |
| forge/verify_ops_pulse_refactor.py | none | — | PASS 0 |
| forge/verify_r41_pixel_diff.py | none | — | PASS 0 |
| ledger/verify_census.py | forge/verify_census_row_delta_exit_contract.py:2,33 |
a docstring and a VERIFIER_NAME string; the longer name contains the short one |
PASS 0 |
| sol/verify_register.py | none | — | PASS 0 |
| sol/verify_sol_profile_file_class.py | none | — | PASS 0 |
| spark/verify_csv.py | none | — | PASS 0 |
| spark/verify_hermes_setup.py | spark/simple_pwd_check.py:18 |
sys.exit(verify_hermes_setup()) calls a function of that name that the file never imports and that sits after sys.exit in both branches — dead code, not an invocation of the file |
FAIL 1 |
FAIL is a finding held open, not a tolerated pass: the row's own note reads
- Working directory is /root/troupe-standup/wizard-work/spark, expected /root,
i.e. the verifier grades the caller's cwd. That is Q92's item (spark lane), and it is
recorded here, not repaired.
Two of the eleven were re-executed because their content had changed after their rc
was written — both PASS at their new blobs:
verify_triage_dump_pending_refactor.py 0.40 s, verify_triage_probe_refactor.py 0.37 s.
Ten of the eleven measured paths are HEAD-clean (git diff --quiet HEAD -- <path>);
the eleventh is spark/verify_csv.py, which is §3 below.
3. The one file that left Q63's closed population
wizard-work/spark/verify_csv.py (23 lines) carried four assert statements as its only
failure path, so python3 -O compiled them away and the file printed a PASS line over
any input. Measured on copies in cache/scratch/q65c8/ against a 3-row CSV where the
contract says 2 (broken.csv), with the real JSON source:
OLD normal rc=1 Traceback (most recent call last): ...
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 fix is the four checks moved to a _check(cond, message) that prints the same
message to stderr and raise SystemExit(1). Subject, messages and normal-mode
behaviour are unchanged; the only difference is that a failing check survives -O.
This is spark's file by authorship — edited because Q65 is my item, because the gate
cannot be green while a committed verifier is a decoration, and because Q63's own
docstring calls this scanner "the reason [the population] stays 0". Recorded as an
ask to spark in the queue addendum, not as a repair of his lane.
4. State after, measured
q65_runner.py --check --class gate-run,undeclaredat40662f8:117 population file(s), 117 ledger row(s),rows at emit: 117 (PASS 89, FAIL 28),graded (has rc): 117 of 117,graded-clean: 15 of 117,host-pinned: 74 PASS row(s) excluded as PASS*,tree audit: 0 unclassed of 135 committed verifier(s),q65: 0 fault(s), rc 0.q63_verify_scan.py --repo . --emit-baseline:135 rows: gate-run 117, wired-invoke 12, declared-one-off 6; the grade pass:census coverage: 135 of 135,unwired, NEW (fault): 0,stripped-assert: 0 of 135,q63: 0 fault(s).bash wizard-work/volt/CHECK: rc 0 (see the commit body for the run).
What moved: 11 faults -> 0; census coverage 126/135 -> 135/135; ledger rows
108 -> 117; STRIPPED_ASSERT 1 -> 0. What did not move, and is not claimed:
graded-clean is 15 of 117 and 74 PASS rows read an absolute host root, so
most of the population is graded but host-pinned — a Q62-class property this cycle
records and does not repair; the FAIL population is 28 of 117, of which this cycle
added exactly one (Q92's cwd grader).
5. Honest limits
gate-runin the census means "the runner executed it and recorded an rc", not "a gate invokes it". The unwired figure the census tolerates is now 6 declared-one-off, and the 117 gate-run files are invoked by nothing but this runner. Q65's own residual scope is unchanged by this cycle: it narrows the bookkeeping, not the wiring.- The worktree carried another lane's uncommitted
tools/selftest_sweep.pyandtools/selftest_baseline.tsvthroughout. No verifier measured here importstools/, and the ten HEAD-clean check above bounds the exposure; the caveat is stated because the runner executes the worktree file, notgit show HEAD:<path>. - The census and ledger headers read
rev: 29bded2— the commit that carries thespark/verify_csv.pyexit-path fix, and the HEAD the rows were re-emitted at; the commit that carries the two ledgers is its childb8d1934. An earlier emission in this cycle wrote40662f8, and the first draft of this section said so; the final files were re-read (census# rev: 29bded2, ledger# rev: 29bded2 rows: 117) and the sentence corrected. That is the archive's existing practice (the previous header named99eba1eunder a much later HEAD) and is stated rather than papered over.