ledger
6b1e24fec4
sweep.py runs every root CHECK-* under bash and records rc, class and the process's last line, pinning rev + sha256 of each entry in manifest.json. report.md is the table; TRIAGE.md groups the 12 reds into four causes. check-root-sweep.sh grades the record (pin / universe / class contract / report parity / rows integrity), 5 legs, with sensitivity_probe.py proving three mutations redden the leg that owns them and the restore is green.
5.5 KiB
Root CHECK sweep -- 2026-11-02, handover
Measured at e44d49aeeca2b61c5a03ab33d0b8cef66f423d73 -- see manifest.json for the full
40-hex rev, the UTC stamp and the sha256 of every entry point that was run. The sweep ran 32
root CHECK-* entry points under bash <path>: 20 OK, 12 FAULT, 0 UNEXPECTED,
0 TIMEOUT, 0 could-not-grade (531.3 s). Rows: results.tsv. Table: report.md.
The 12 reds are not 12 defects. They are four causes, measured below, each with the fault line the entry point itself printed in this run.
A. The Q159 landing is in the worktree, not in the tree (q143, q148, q159)
CHECK-q143 rc=1 FAIL: MISSING CHECK-q159 -- baseline names it, the tree does not have it
CHECK-q148 rc=1 FAIL: MISSING CHECK-q159 -- baseline names it, the tree does not have it
CHECK-q159 rc=1 census FAULT rc=1 :: paths: 141 entry point(s), 140 baseline path(s), 3 fault(s)
wizard-work/volt/q143-check-sweep/check_entry_baseline.tsv carries the Q159 guard row and
CHECK-q159 exists on disk, but check_sweep.py discovers tracked entry points and
CHECK-q159 is untracked -- so the baseline names a path the tree does not hold. The same
two commands also report the next cause.
Fix: commit CHECK-q159 with the baseline row that names it (and the Q159 witnesses), or drop
the row until it is committed. Nothing else in this cluster is a code fault.
B. Two tracked entry points have no baseline row (q143, q159)
FAIL: NEW wizard-work/ledger/CHECK-2026-11-02-jobs-table -- in the tree, not in the baseline
FAIL: NEW wizard-work/sol/CHECK-untracked-file-classify-2026-11-02 -- in the tree, not in the baseline
Both are committed and therefore discoverable, but neither has a row a human signed. Fix:
run each once, record its rc and first fault line in check_entry_baseline.tsv through the
row-level re-take path (the file's own convention), or the census is red for every reader.
C. CHECK-q-checkparen pins a tally the rubric outgrew (q-checkparen)
FAULT selftest rc=0 selftest: 51 cells, 51 passed, 0 failed
FAULT pin ['check_lint.py\t51\tcells']
FAULT falsifier rc=1 selftest: 51 cells, 49 passed, 2 failed
The subject is green (51/51) and the falsifier leg proves the rubric can red (49/51 on the
mutated copy), so what is stale is the verifier's expected literal, not check_lint.py. This
is the Q158 shape a second time: a verifier that asserts a cell tally goes red when the
rubric grows, on a tree where the refactor it grades is untouched.
D. Beam lane: coverage and bindings (q149, q153, q85)
CHECK-q149 rc=1 FAIL beam-gate red (rc=1)
CHECK-q153 rc=1 FAIL lane-check bindings: 185 file(s) graded repo-wide at WORKTREE, 109 test file(s) in wizard-work/beam/
CHECK-q85 rc=1 coverage: 118 module(s): ... 2 run by CHECK, 6 exempt, 1 fault(s) (all three live passes)
CHECK-q153's verify leg is green (6/6) and import_resolve_check grades 185 files with 0
faults; the red is the lane-check binding leg (185 graded vs 109 test files in the lane).
CHECK-q85's coverage authority reports 1 fault over 118 modules in every one of its three
live runs, so it is not a flake. These three are one subject: the beam lane's module set is
larger than the set its collected tests and its binding census can account for.
E. CHECK-q150: q65's ledger and rc probe (q150)
FAIL runner-ledger q65: 8 fault(s)
FAIL rc-probe q65_rc_probe: 5 fault(s)
PASS no-verdict q65_no_verdict: 0 fault(s)
Two of three legs red, and the two .tsv files they read
(wizard-work/volt/q65_runner_baseline.tsv, q65_rc_probe.tsv) are modified in this
worktree (uncommitted), so the first question is whether this red is the modification or
the tree. Not settled here.
F. Frozen untracked snapshots (sol-untracked-classify, untracked-triad, untracked-triage)
CHECK-sol-untracked-classify rc=1 frozen path missing on disk: 'verify_wordcount_test.py'
CHECK-sol-untracked-classify rc=1 frozen path not present under repo: 'wizard-work/null/.hermes-tmp.RqZp3z'
CHECK-untracked-triad-2026-11-01 rc=1 id=1 path=CHECK-q146 is not currently untracked
CHECK-untracked-triage-2026-11-01 rc=1 frozen path missing on disk: ['wizard-work/null/.hermes-tmp.RqZp3z']
Three snapshots of "the untracked set at rev X" graded against the live set. Two of the paths
they froze no longer exist (wizard-work/null/.hermes-tmp.RqZp3z is a temp directory;
verify_wordcount_test.py left the root) and CHECK-q146 was committed, so it stopped being
untracked. The classification was never wrong; the universe moved. This is Q157's shape
exactly, in three more files.
G. CHECK-sol-profile-triage-2026-11-02: artifact vs live profile (sol-profile)
CHECK FAIL categories mismatch:
artifact state_db 11 / config_data 1
live state_db 10 / config_data 2
One live profile path moved between the two categories after the artifact was taken. The
baseline already signs this row KNOWN RED: artifact categories != live disk (sol profile changed after the artifact was taken), so this sweep confirms the signed reading rather than
finding a new one.
What this sweep does not claim
- It grades the worktree, not the commit: 106 paths differ from
e44d49a(modified + untracked). A green row is green for those bytes, whichmanifest.jsonpins by sha256. - It does not re-run the checks that were green; it records the process and its last line.
- It does not say a red row is a defect. A, C, F and G are stale instruments on a moved universe; B is unregistered work; D and E are not attributed here.