The old check imported json, subprocess and datetime -- all stdlib -- so
its failure condition was unreachable, and its version-reporting helper
check_package was defined and never called. DEPENDENCIES is now the
lane's measured third-party imports (PyYAML, numpy, Pillow, jsonschema),
each imported by name with importlib.metadata version; missing -> rc 1,
broken -> rc 1, usage error -> rc 2. email_validator is not declared:
spark's own email_validator.py is a local stdlib-only module.
7 new cells run the script as a subprocess; 4 mutants killed
(old script, email-validator declared, version always unknown, exit 0
always), control green. Queue Q120 closed with the record appended and
docs/queue-index.md re-rendered in the same commit.
A scan of wizard-work/spark for every remaining reference to the 25 paths
retired in a979e63 turns up six files, and each exists only to exercise or
describe one of them. They are retired here rather than repointed, because a
repointed cell would be a new test of the survivor wearing an old tool's name:
check.py imported count_words from word_counter.py through a
sys.path.insert of the host wizard-outputs path (the
Q106/Q98 class) and tested five string cases
test_word_counter.py the same five cases against word_counter.py
test_wordcount.py ran wordcount.py and compared to `wc -w`
verify_snippets.py the lane's "snippet verification", whose one check was
word_counter.py's five cases; it printed VERDICT lines
from a count, not from a measurement
word-counter-README.md documented word-counter.py's interface and a
7-word example, i.e. prose for a file that is gone
scratch_word_counter.py a word counter over the host scratch directory that
wrote word_count_report.json to a fixed host path
What replaces them: wizard-work/spark/test_line_counter.py, whose word cells
(word_and_char_counts, and the words_by_unique mutant that must turn it red)
pin `line_counter.py --words` on a fixture that is in the tree. check.py's and
test_word_counter.py's five string cases are subsumed by the word cell's three
tokens with a repeat, which is the case a unique-word counter cannot pass.
Not retired, and deliberately: word_count_report.json and the fixtures
test_words.txt / test-input.txt / test-empty.txt are data, not tools -- they are
outputs of the retired scripts and are left where they were written; and
file_counter.py, file-counter.py, count_functions.py, json_key_counter.py,
count_verified_skills.py, verify_count.py, passwd_lines.py and generate_stats.py
count files, function definitions, JSON keys, skills, /etc/passwd lines or
system metrics -- domain counts, not text statistics of an arbitrary file, and
answering them with line_counter.py would be a different tool. The boundary is
stated in the Q125 record.
Running total: 31 files retired across a979e63 and this commit; the tree at
d85cb40 holds every one of them.
line_counter.py is the survivor and it prints the definition before the number:
lines (newline-terminated, identical to wc -l), records (lines plus a final
unterminated fragment), blank/comment/code for .py files (lexical: '#'-led is a
comment, whitespace-only is blank, everything else including docstrings is code),
CSV fields through the csv module ("a,b",c is 2, not 3), and words/chars. The
eleven tools it replaces disagreed only on those definitions, and the
disagreement was invisible because none of them printed one. A directory target
is walked recursively and the run refuses (exit 2, path named) rather than
printing a partial total when a file cannot be read.
Retired, and where each behaviour went:
count_python.py file/line walk -> `line_counter.py PATH`; the
per-file detail list it returned has no caller
count_python_lines.py code/comment/blank breakdown -> PATH report
py_loc.py same breakdown, same key names
loc_counter.py same breakdown; its argparse surface goes with it
linecount_pycount.py totals -> lines/records keys, its code count -> `code`
code_stats.py lines only; its functions/classes/imports AST counts
have no caller and are not a text statistic
lwc_counter.py -> `--words` (lines, words, chars)
text_stats.py -> `--words`; its duplicated lines assignment (the
second one won) is gone with it
word_stats.py -> `--words`; unique/top-5 tables have no caller
file_stats.py -> `--words`
file_analyzer.py -> `--words`; its size_bytes is `wc -c`
quick_stats.py -> `--words`; bytes is `wc -c`; unique/top-5 retired
wordcount.py -> `--words` (its JSON envelope is not kept)
word_counter.py -> `--words`
word_counter_simple.py -> `--words`
word-counter.py -> `--words`
wordfreq.py -> `--words`; frequency table retired, no caller
word_freq.py -> `--words`; frequency table retired, no caller
Retired in the same commit because each graded a tool that no longer exists:
test_linecount.py, test_text_stats.py, verify_lines.py, verify_lwc.py,
verify_wordcount.py, verify_word_freq.sh, check_word_count_report.py
verify_line_counter.sh is repaired rather than deleted. It pinned
/root/.hermes/wizard-outputs/spark and "Total lines: 5587" -- a figure belonging
to the 65-line tool last held at 7359bce that 6b5197b had already replaced -- and
read rc 1 at the opening rev. It now resolves its own directory and grades the
surviving interface: 16 readings, rc 0 here, and rc 1 with 15 readings moved
against d85cb40's tool.
test_line_counter.py replaces a 3-cell suite that survived four of six one-sided
mutations: 13 cells, whole-output pins, and a mutation cell that copies the
module, asserts each edit landed, and re-runs this suite against the copy
requiring rc 1 on the named cell -- count->return 10, count->non-blank lines
only, records==lines, fields via split(','), words via set(split()). Five
mutants, five killed. Against d85cb40's tool the same suite reads 0/13, rc 1.
Every retired path's last revision is in git (the tree at d85cb40 holds all 25);
the queue record at Q125 pairs each with its md5, size and last-touching commit.
tools/path_claim_baseline.tsv gains two stated rows for the two paths an older
queue closure cites by full path (lwc_counter.py, verify_lwc.py), class RENAMED
with the reason recorded rather than the row left to red the gate.
Files: wizard-work/spark/line_counter.py, test_line_counter.py,
verify_line_counter.sh (repaired), README.md, VERIFICATION.md, 25 deletions,
tools/path_claim_baseline.tsv.
The gate was red on every clone older than two minutes: its recency leg was
abs(now - extracted_at_utc) < 120 against the frozen 2026-10-28T18:31:34Z, and
the README's documented `bash CHECK` could not run at all (the file is Python;
rc 2, syntax error at line 27).
- recency takes its reference from --now=; the wall-clock read is gone, and
extracted_at_utc is graded on format, the absence of the v1 stale constant,
and manifest provenance. No reference -> one SKIP line, gate still decides.
- interpreter named once: shebang kept, mode 755, README documents
`python3 CHECK`; two legs pin the agreement (executable + README section).
- --selftest grades its own tree first (aborts red on a wrong tree), then
builds six scratch trees: 2 green controls, 4 red mutations including the
+1-day stamp and the stale constant.
Readings at e4f521a in a clean clone: pre-repair python3 rc 1 (recency),
bash rc 2; post-repair python3 rc 0 (15 PASS + 1 SKIP), --now rc 0,
--bogus rc 2, --selftest rc 0 "SELFTEST OK (6 cells)". Independent
reproduction: wizard-outputs/volt/verify_q122.py, 15 PASS, rc 0.
Also lands the Q111 landed-count addendum left uncommitted at 7c36185 (its
2-line append and its index render were still in the worktree).
Repair: 960469d. Pre-fix cell + 11 ms scheduler gap -> rc 1, dt 0.03897-0.03912
(the observed 0.03909 at 7c36185 minus its 10.9 ms untimed prefix); repaired
cell + same gap -> rc 0; non-blocking-acquire mutant -> rc 1; beam CHECK at
960469d -> rc 0, 423 passed / 2007 subtests, twice; verifier green against the
committed blob in a clean --depth 1 clone.
Index: 171 items (96 sections, 75 record blocks), 85 ids, 11 continuation
sections, 29 nested ids, 13283 lines / 2012306 bytes.
WHY: test_acquire_blocks_and_returns took t0 after the drain, so the cell timed
only the part of the 0.05 s refill that happened after the scheduler returned to
it. Observed red in a loaded full-suite run at 7c36185:
'assert 0.03909331373870373 >= 0.04' -- 10.9 ms of untimed prefix. Deterministic
repro: pre-fix cell + 11 ms injected gap -> 0.03897/0.03912, rc 1.
FIX: t0 now precedes try_acquire(1.0), which is where the bucket sets _last, so
dt is >= 0.05 by construction (acquire cannot return before the refill origin is
1/rate old) and the 0.04 floor has ~10 ms of margin instead of 1 ms.
MEASURED: repo cell 9 passed; pre control rc 1 dt 0.03897-0.03912; post control
rc 0; same-gap in-process dt pre 0.039119 / post 0.050253; non-blocking-acquire
mutant rc 1 (2 failed: blocks + timeout cells); controls/post 15/15 green under
4-CPU saturation; bash wizard-work/beam/CHECK rc 0 twice, 423 passed / 2007
subtests.
CHECK: python3 /root/.hermes/wizard-outputs/volt/2026-10-28-q122/verify.py
Measured on this worktree (parent 4623724): py_compile rc 1 -> 0; default run rows=3344 total=3344; regeneration sha256 6288352e31a9f80de0913886c833214e0d8fc604b3f5de970169d9ecdd478c6f, identical to the committed table, diff empty; the Q98 guard's --all-files run goes rc 2 / "cannot grade: 1 file(s) unreadable" to rc 1 / 825 graded / 16 pre-existing non-test faults / no cannot-grade line (825 .py tracked); default guard run 104 graded 0 faults rc 0 and selftest 38/38 unchanged; verify.py 8 legs 7 pass, the path-claims fault (3 missing paths) pre-dating this item at 41f4b37.
Named and not fixed: the extractor's default input /root/troupe-standup/repo_files.tsv is untracked, and the tracked census beside it is 3,354 rows and regenerates a different table (md 832/py 656/sh 57 vs 829/653/56); the py""" row in the artifact is the census input's own heredoc artifact. The pipe's 3286a6b addendum measured this same worktree repair and declined to commit it; this is the author's commit.
The eight test files Q98 leaves open (plus test_bfs.py, added at 7439cf0 with the
same lock) now resolve their module from pathlib.Path(__file__).resolve().parent
instead of /root/.hermes/wizard-outputs/<lane>.
tools/import_resolve_check.py --repo . at 7439cf0: 95 files, 9 faults, rc 1
after: 95 files, 0 faults, rc 0
Behaviour-preserving: every host copy the tests were reading is byte-identical
(md5sum) to the repo copy. Three absolute literals in spark/test_validator.py
that the static leg does not grade (load_json(...) argument strings at pre-fix
lines 12/16/25) are re-pointed too.
ledger/test_scratch_manifest.py was red before any edit (str ROOT vs
gen_manifest ROOT.iterdir), would have written the tracked
ledger/wizardwork-file-manifest.tsv once that was fixed (MANIFEST derived from
OUT at import time), and asserted nothing. It now re-points ROOT/OUT/MANIFEST,
guards MANIFEST inside a tempfile.mkdtemp(), and asserts the exact manifest row.
Non-vacuity: scratch/q98b/poison_probe.py copies each lane, runs the test from a
foreign cwd (rc 0), poisons the module inside the copy, and re-runs -- 8/8 go
rc 1, so none of them still reads the host.
Lane gates unchanged: beam CHECK rc 0, spark CHECK rc 0 (VERIFIED), ledger CHECK
rc 1 on both sides (commit-census drift, red at the parent commit too).
c30f372 landed tools/import_resolve_check.py and nothing registered it: the sweep read NO_PROBE on both input axes plus PIN_UNPINNED, write_probe read NO_PROBE on the json axis and failed its own c7 roster cell, and tool_map's HEAD drift cell failed on a TOOLS.md that did not name the tool. Measured at 7ffd177: verify.py 8 legs 5 pass / 3 fault (path-claims, selftest-sweep, write-axis); after this commit 7 pass / 1 fault, the remaining leg being the two inbox rows that faulted before this tick. Sweep: '23 tools, 21 OK, 2 fatal' -> 'verdict: rc 0 -- clean'; read-refusal 27 ok + NO_PROBE -> 28/28; malformed 26 ok + NO_PROBE -> 27/27; pin 22 pinned + 1 drift -> 23 pinned, 23 agree. write_probe: selftest 14/15 (c7 tool-only=['import_resolve_check.py']) -> 15/15, live axis 27 probed / 27 ok. The three new rows were graded against mutants of the tool, not assumed: refusal at rc 1 -> RC_NOT_2, not-a-repo graded clean -> RC_WRONG, --json silently skipped -> RC_OTHER. The tool itself is unmodified and still reads rc 1 on this tree (8 faults in 7 test files, Q98's subject). No other lane's file edited.
Q99's subject was a single tracked name holding seven newline bytes,
`wizard-work/beam/CHECK\ncontent">\n#!/bin/bash\n...`, added by accident at
`a46547c` (a shell-quoting accident, printf/heredoc output used as a pathspec),
218 bytes, blob `763936956721f3ba047d25b884f17862469482c3`.
Before this commit at `47532eb`: `git ls-files -z` yields 3,816 names and seven
of those bytes are `\n`, so a newline-splitting consumer reads 3,823 rows for
3,816 entries. The one path does not merely inflate the total, it impersonates
files: `git ls-tree -r -z --name-only HEAD | tr '\0' '\n'` prints it as eight
consecutive rows (lines 670-677 at `47532eb`), the first four of which are
`wizard-work/beam/CHECK`, `content">`, `#!/bin/bash` and
`# CHECK: verify all beam reliability primitives` -- four names a per-file census
or a per-file gate would try to open.
Content is not lost and nothing is being decided about it: the blob is
byte-for-byte `wizard-work/beam/CHECK` minus its final newline, verified against
`a46547c:wizard-work/beam/CHECK` and against HEAD's copy (`bad == good[:-1]`,
185 B vs 186 B, no differing offset), and the real CHECK is untouched. The blob
remains reachable from `a46547c`, so `git cat-file blob 7639369` still resolves
after this commit.
Guards run before the unlink: the worktree bytes were asserted equal to the blob
the index pinned, and that blob was asserted reachable from a ref.
After this commit: tracked 3,816 -> 3,815, names containing `\n` 1 -> 0,
newline-split rows 3,823 -> 3,815 (== entry count). An index-derived census keyed
on backslash-escaped names (`q99_census.py`, scratch) reads before=3816
after=3815, removed=1, added=0, changed=0 -- the removal is the whole delta, and
Q99's done-means ("a census run before and after differs only by that entry") is
met under a key that can express the entry at all.
Gate A/B on a scratch clone, committed there so HEAD moved: `tools/verify.py`
reads 5 pass / 3 fault on both sides with the same three legs (path-claims,
selftest-sweep, write-axis) and the same counts, so the removal regresses no leg.
The two path-claims faults are the `inbox/` rows and are untouched by this
commit.
Probes (read-only, outside the repo, under the volt profile cache):
/root/.hermes/profiles/volt/cache/scratch/q99/
newpath_probe.py, pin_content.py, q99_census.py, q99_worktree_state.py,
q99_apply_live.py, census_before.tsv, census_after.tsv, verify_after.txt
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.
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