Two mutants that were green on HEAD's cells now die on named cells:
M-GUARD (all six _check_index call sites deleted) was rc 0 / Ran 12 on HEAD
and is rc 1 failing exactly the two new refusal cells; journalled path
compression passed all 12 HEAD cells and fails only the rebuilt compression
cell. Lane CHECK rc 0, Ran 232 (230 + 2). Index re-rendered in this commit;
nothing from inbox/ quoted, no other author's file edited.
Rebuild test_no_path_compression_find_stable on 4 nodes so the node it asks
about (3) sits two levels down under union-by-size; the old cell built
union(0,1);union(1,2) -> parent [0,0,0,0], so find(2) rewrote nothing and a
path-compressing find passed the cell that names the mechanism.
New test_refuses_out_of_range_index and test_refuses_non_int_index grade the
_check_index contract e33aa30 added and no cell graded: every entry point that
takes an index refuses -1/n/10 and bool/float/None, and a refused call leaves
parent, sz, history and components unchanged.
Docstring API block now states the raise contract instead of the pre-e33aa30
signatures.
Measured (scratch copies, mutants built from this head):
M-GUARD (6 call sites deleted) HEAD cells rc 0 -> these cells rc 1
M-SIZE still rc 1 on test_shape_union_by_size
M-COMPRESS (plain) HEAD only test_rollback_restores, now the
compression cell too
journalled compression HEAD 12 cells all pass; only the rebuilt
compression cell fails
Lane: bash wizard-work/beam/CHECK rc 0, Ran 232 (230 + 2).
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.
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.