troupe-standup/wizard-work/volt/q65-2026-10-25-c7.md

Q65 residual, cycle 7 — 2026-10-25 (volt, at eb34583)

Cycle 6 landed the rc-probe leg and graded wizard-work/forge/verify_probe_forge_refactor.py (the file q65-2026-10-25-c7-red.txt shows the census rc 1 on before that row existed: 1 unclassed of 110, named). This cycle asks four questions the ledger cannot ask about itself, using that new row as the subject: does its PASS cover the committed tree, can its one odd branch fail, what happens to the two ledgers when a row is dropped, and what happens when a verifier is edited after it was rowed. The instrument is wizard-work/volt/q65_c7_controls.py — every cell a fresh clone of --rev, no edits to the graded tree.

Result: 12 of 12 cells as expected at eb34583; the control found one false statement in my own scan's printer, which is fixed in this commit, and 13 of 13 cells pass after the fix. Two findings are in forge's file and are recorded, not edited.

1. The PASS does not cover the committed tree — a pin at two levels

verify_probe_forge_refactor.py runs the two probe subjects (_probe_forge.py, _probe_forge_refactored.py) as subprocesses. Both subjects import chunker through a host path of their own:

wizard-work/forge/_probe_forge_refactored.py:34:  sys.path.insert(0, "/root/.hermes/wizard-outputs/forge")
wizard-work/forge/_probe_forge.py:3:              sys.path.insert(0, "/root/.hermes/wizard-outputs/forge")

So the verifier grades the chunker in /root/.hermes/wizard-outputs/forge, not the clone's wizard-work/forge/chunker.py, and neither the verifier's source nor its docstring contains a /root/ string for the runner's static host-pin scan to find (measured: grep -n "/root/" over the verifier → none). The four cells, all in clones of eb34583:

A  clone, subject untouched                  rc 0  expect 0  9/9 checks
B  clone's chunker.py sabotaged              rc 0  expect 0  9/9 checks -- sabotage invisible
C  sabotage + subject import un-pinned       rc 1  expect 1  8/9, FAIL: probe output does not
                                                             report 'equal: True'; round-trip not lossless
D  import un-pinned, chunker restored        rc 0  expect 0  9/9 checks

B is the finding: reconstruct() in the clone returns its own output plus "SABOTAGE", and the verifier still prints 9/9 checks and exits 0, because the import resolved to /root/.hermes/wizard-outputs/forge/chunker.py and resolves inside the clone: False. C is the matched control: rewriting the two subjects' one sys.path line to the clone's own directory turns the same sabotage into rc 1, with a named FAIL; D restores the chunker and returns rc 0. The difference between B and C is the pin, not the sabotage.

This is the first row measured as graded-clean and host-dependent in substance at once: the verifier has no host path in its own text, so the runner counts it among the 11 graded-clean rows of 91, while the thing it exercises is read from the host. The static scan reads one level (the verifier); the pin sits one level down (the subject). The remedy belongs to forge: either point both subjects at an in-repo chunker.py, or accept a PASS* class the runner can only assign if it also scans the subjects. Recorded, not edited — another lane's file.

2. The for called in (...) block cannot fail

verify_probe_forge_refactor.py:146..154 is a for called in (...) loop whose body is an if with an empty consequence (pass). Its AST body holds no Raise, no Return, no assignment and no exit (And, Attribute, BoolOp, Call, Compare, GeneratorExp, If, List, Load, Name, NotIn, Pass, Set, Starred, Store, comprehension; effectful of those: none). Dynamically, in a clone at eb34583:

green subject, block intact      rc 0   |  block deleted  rc 0   identical output
main() no longer calls helper    rc 1   |  block deleted  rc 1   identical output
                                 message: FAIL: main() does not call _find_first_diff()

Deleting the block changes no rc and no message in either state. The enforcement the check claims is done by the attr_calls/name_calls blocks below it; this loop is Q65's inert class (a branch no input can fail) inside a verification file. Harmless, kept, recorded.

3. The omissions: what the ledgers say when a row is removed — and one false print, fixed

Four removals, each in its own clone, all at eb34583:

census row dropped alone                     scan rc 0, unwired NEW 0, coverage 109 of 110
ledger row dropped                           runner rc 1, UNGRADED, named
verifier edited+committed after rowing       runner rc 1, DRIFT named; rc-probe rc 1, STALE named
untouched clone, bash wizard-work/volt/CHECK rc 0, CHECK PASS

The first cell is by contract not a fault: "unwired" means no invocation and no runner row, and the dropped census row leaves the runner's gate-run row in place. But the scan's printer called that state UNCLASSED, invisible to both instruments — false, because the runner had graded the file, and it is exactly the state the census-count tightening exists to report honestly. Fixed in this commit: the coverage line now says carry a census row and names the file as CENSUS_ROW_MISSING, with its runner verdict, while UNCLASSED is printed only for a path in neither ledger. Before and after, same clone, same dropped row:

before (eb34583):  109 of 110 committed verifier(s) carry a ledger row   <-- 1 UNCLASSED, invisible to both instruments
after:             109 of 110 committed verifier(s) carry a census row
                       CENSUS_ROW_MISSING  wizard-work/forge/verify_probe_forge_refactor.py
                         (no census row; a runner row (PASS) still classes it -- the coverage NUMBER drops, no fault)

The fault arithmetic is unchanged (q63: 0 fault(s), rc 0); the false label is gone and the control now asserts the corrected wording rather than merely printing it. --selftest stays 10 of 10.

4. What changed, and what stays open

Changed in this commit, all in this lane: q65_c7_controls.py (new, 13 cells), q63_verify_scan.py (the coverage printer, 7 lines, selftest 10/10), this record, and the evidence files named below.

Open, and not this lane's to close:

• forge's verify_probe_forge_refactor.py: the both-levels pin (§1) and the inert loop (§2). Two findings, one file, handed over in the queue addendum.
• The census is still not a tools/verify.py leg (reply 93 §4). Nothing in the 8 legs runs q63_verify_scan.py, so a verifier landing without a row is red only in this lane's CHECK. The operator's call, not re-argued here.
• 24 FAIL rows are per-lane findings; 56 of the 67 PASS rows are PASS* (host-pinned) and unchanged by this cycle.

5. Evidence

• q65-2026-10-25-c7.md — this record.
• q65_c7_controls.py — the instrument; selftest is the run (--rev, --keep).
• q65-2026-10-25-c7-controls.txt — the 12/12 run at eb34583, pre-fix; §3's "before" line is visible in it.
• q65-2026-10-25-c7-after.txt — the 13/13 run and the lane CHECK at the commit carrying the fix (provenance line in the file).
• q65-2026-10-25-c7-red.txt — CHECK rc 1 at 6e8f577, 1 unclassed of 110, named.
• q65-2026-10-25-c7-green.txt — CHECK rc 0 at eb34583, after the row was added.
• q63_verify_scan.py, q65_runner.py, q65_rc_probe.py — the three ledgers' gates; this cycle edits only the first, and only its printer.