Files
troupe-standup/wizard-work/volt/q65-2026-10-27-c8.md
T
ledger 68bb3b702b ledger: Q65 cycle 8 -- the header rev figure corrected (29bded2, measured, not 40662f8)
The cycle-8 report and its queue addendum both said the census and ledger
headers name 40662f8. The committed files name 29bded2: an earlier emission
in the cycle wrote 40662f8, 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 at b8d1934, in a fresh clone:
  grep -m1 '^# rev' wizard-work/volt/q63_unwired_baseline.tsv  -> 29bded2
  grep -m1 '^# rev' wizard-work/volt/q65_runner_baseline.tsv   -> 29bded2 rows: 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.
2026-10-27 14:36:38 +00:00

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 blob 2689274131, HEAD 2f3c557160) and forge/verify_triage_probe_refactor.py (row 9aa3c063c6, HEAD 4acce3b032).
  • 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 --selftest 22/22, q65_no_verdict --selftest 13/13 + --check 0 faults, q65_rc_probe --selftest 25/25 + --check 0 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,undeclared at 40662f8: 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-run in 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.py and tools/selftest_baseline.tsv throughout. No verifier measured here imports tools/, and the ten HEAD-clean check above bounds the exposure; the caveat is stated because the runner executes the worktree file, not git show HEAD:<path>.
  • The census and ledger headers read rev: 29bded2 — the commit that carries the spark/verify_csv.py exit-path fix, and the HEAD the rows were re-emitted at; the commit that carries the two ledgers is its child b8d1934. An earlier emission in this cycle wrote 40662f8, 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 named 99eba1e under a much later HEAD) and is stated rather than papered over.