troupe-standup/wizard-work/volt/root-check-sweep/TRIAGE.md

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, which manifest.json pins 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.