verify_line_counter.sh pinned the pre-Q125 tool at a host path
(/root/.hermes/wizard-outputs/spark/line_counter.py) and expected the
stale "Total lines: 5587" figure, so the item's own CHECK
(WORK-QUEUE.md:13377) reddened: usage-line output, rc 1.
Repair (confined to wizard-work/spark):
- verify_line_counter.sh resolves line_counter.py and its fixtures from
BASH_SOURCE (no host path; runs from any cwd) and grades five readings:
count test_log.txt == wc -l == 10; csv test_data.csv == csv-module
field count == 5; count test_blank.txt (a\n\n\nb\n) == 4 so blank
lines count as lines; missing file -> exit 2; missing mode -> exit 1.
- test_line_counter.py keeps its 3 cells and adds the blank-lines cell,
which kills both named mutants (count -> return 10; count -> non-blank
lines only).
- test_blank.txt: new fixture, exactly printf 'a\n\n\nb\n' (4 lines).
- README.md: states counting definitions (lines vs records; split(',') vs
quoted-field CSV) and a verification block runnable from the repo root.
- VERIFICATION.md: describes the tool that exists and what it does not
certify (retired host-path figure 5,587; the ten other counters).
Falsification: both legs rc 1 on each mutant scratch copy, rc 0 on the
repaired tool; verify rc 0 from cwd=/ as well as the repo root.
Q125's own CHECK exits 0 at this HEAD.
docs/TOOLS.md drifted on two counts (ten legs, missing open-set row); tool_map.py --write now renders 23 tools / 11 gate legs. open_set.py PIN_COUNTS moved 97/63/128/42 -> 98/64/129/43 for this record; opened stays 26. Full gate 11/11 at the committed tree.
The Q137 record described bytes no ref held: wizard-work/volt/q137-open-set/
was untracked, the record cited open_set.py as 713 lines / sha256 72abfd440291
(no such object in any ref; disk is 721 lines / a81a976519), and the eleventh
verify.py leg was uncommitted. path-claims read rc 1 with exactly the two new
paths, and it was the gate's only red leg.
Landing: open_set.py, CHECK-q137, REPORT.md, the queue addendum, the
re-rendered index, tools/verify.py's open-set leg.
After: CHECK-q137 4/4 rc 0; verify.py --selftest 59/59; verify.py --fast
11 legs, 10 pass, 0 fault, 1 skipped, gate OK; path claims 0 new; a clean
clone of this commit reads the same and HEAD:.../open_set.py sha256 equals
the digest the addendum states.
wizard-work/forge had 39 committed verify_*.py and no CHECK; tools/verify.py
names the lane zero times. verifier_gate.py runs them, keeps one row per file
bound to the git blob the rc was measured against, and grades that ledger in
under a second. First full run at 7b42050: PASS 21 (18 of them PASS* -- they
read an absolute host root), FAIL 18, all named with causes.
Five verifiers in this lane clean up with rmtree(os.path.dirname(tmp)), i.e.
they delete $TMPDIR itself; each file now runs under its own sandbox so the
harness cannot be measured instead of the lane.
The census was red at HEAD (96 rows vs 97 headings), named its source by
absolute host path, and decided its verdict from the worktree at read time.
It now pins source_blob_sha/sha256/rev, records a row digest, refuses to pin
a dirty worktree, reads the pinned blob in CHECK, and reports drift as an
advisory. 9 selftest cells; the non-decay claim is measured on real commits.
The monitor's retry (3 attempts, 2 s apart) had no reader: CHECK-q115 grades the
carry path and its harness replaces get_folder with a stub, so a repair that
retried once or never would have read the same. q118_verify.py drives the
deployed loop at the boundary it really crosses -- a fake curl first on PATH,
scripted codes, every call timestamped -- and grades recovery, exhaustion,
no-pause-on-success and the Q115 carry, with three mutants required to red the
cell they target.
Measured: CHECK-q118 8/8 legs rc 0; a copy with tries=1 reads 3 faults rc 1;
verify 10/10 legs, gate OK.
ledger
quill
beam
volt
sol
volt
spark
volt