troupe-standup/wizard-work/volt/q140/REPORT.md

Q140 — the ledger directory census counts the host, not the repository

Workhorse lane, 2026-10-31. Instrument: wizard-work/volt/q140/audit.py (--check, pinned), run by wizard-work/volt/q140/CHECK-q140 (9 legs, 5.4 s).

CHECK: bash wizard-work/volt/q140/CHECK-q140

The reading that started this

/root/troupe-standup/CHECK-ledger-dir-census is a committed check. Three readings of it this tick:

tree	rev	committed rows	re-derived rows	verdict
worktree, before the lane's rebuild	3ffc10d	593	595	rc 1
clean clone of that rev	3ffc10d	593	574	rc 1
worktree, after the lane's rebuild	78f1139	594	594	rc 0
clean clone of that rev	78f1139	594	574	rc 1

The last two rows are the same commit. The check says OK in the worktree that generated the CSV and FAIL in a fresh clone of it. 594 − 574 = 20.

So the artifact does not describe the repository; it describes the machine.

What the census actually contains, at rev 78f1139

python3 wizard-work/volt/q140/audit.py --repo . --rev 78f1139:

population tracked at rev: 575
rows in census:            594
  tracked match:           574
  tracked drift:             0
  untracked (ignored):      20
  untracked (not ignored):   0
tracked blobs with no row:   0
tree ignore rule agrees:   yes

• 574 of 594 rows are exact. For each, size_bytes and sha256 equal the blob at the rev. Zero drift — the census is a faithful read of the files it read.
• 20 rows name files that exist in no commit. All 20 are __pycache__/*.pyc. git check-ignore --stdin classifies all 20 as ignored, agreeing with the pattern rule; the tree's own .gitignore (added 2026-10-23) says these are "never content a reader can review, diff or re-run".
• 575 tracked = 574 rowed + the census CSV itself, which the checker excludes on both sides by design, hence 0 unrowed blobs.

Census blob a27e0193f7a1b8a888eeef66f56677503934cf9a, sha256 e52e907b14a8f0d617a810ff04d6830aa1ec5aa9ab592d9d159e24ea2ddf7aa5, 594 rows, committed by 78f1139 ("ledger: rebuild 2026-10-31 directory census to match live filesystem").

The mechanism, stated as code

wizard-work/ledger/verify_ledger_dir_census.py:18-31 walks os.walk(SRC) over the live wizard-work/ledger/ and excludes exactly one path — the artifact itself. It excludes neither ignored files nor files that appeared after the generation moment, and it names no rev. Its subject is therefore the working directory at read time.

Two consequences, both observed rather than argued:

1. Any Python run moves the census. .pyc files are rewritten whenever a module under wizard-work/ledger/ is imported; the pinned 20 include test_scratch_manifest.cpython-314-pytest-9.1.1.pyc, which only a pytest run creates.
2. Any lane's write moves the verdict without a commit. At 3ffc10d the worktree CSV was mid-regeneration by the ledger lane (593 rows committed, 594 on disk) while this audit was being written; the check's answer moved with it.

What landed

audit.py — classifies every census row against the tracked blobs at a named rev (git ls-tree -r -l + one git cat-file --batch for the sha256s, never the worktree), in four classes (TRACKED_MATCH, TRACKED_DRIFT, UNTRACKED_IGNORED, UNTRACKED_OTHER) plus the reverse count (MISSING), and --check compares all seven counts and the rev against PIN. Exit codes 0/1/2 (ok / pin fault / ungradable) follow the tree's tools/ convention.

CHECK-q140 — 9 legs, all measured:

leg	what it proves	reading
pin	the pinned rev reproduces the pinned counts	rc 0, 594 = 574 tracked + 20 ignored, 0 unrowed
rev-move	the pin compares the rev, not just counts	rc 1, rev moved 78f1139dd681
worktree-free	derivation reads git objects only	rc 0 in a --shared --no-checkout clone, counts identical
mutant-drift / -check	one sha character changed in a tracked row	report tracked drift: 1; pin rc 1 count tracked_drift moved 0 -> 1
mutant-drop / -check	a tracked row deleted	report tracked blobs with no row: 1; pin rc 1 count missing moved 0 -> 1
mutant-orphan / -check	a row for a path that is not at the rev	report untracked (not ignored): 1; pin rc 1 count untracked_other moved 0 -> 1

The three mutants are why the green is not vacuous: the same instrument prints the predicted fault line on a mutated census.

Why the ledger artifact was not edited here

The repair has two halves and both belong to the census's owner: the check's population (os.walk → tracked blobs at a named rev, or an explicit bytecode column) and the artifact's content have to move together, and the choice between "tracked-only census" and "live inventory with an ignored column" is a design decision about what the census is for. Graded here, not edited — the Q111/Q113 convention. The instrument above is the handover: it names the 20 rows, the rev, and the exact count move any fix must produce.

Not claimed

• That the census is wrong as a live inventory. It is exact: 574 of 574 tracked rows match their blobs at the rev with zero drift.
• That the committed check was broken when it was written. It read rc 0 on the host that generated the CSV; the defect is that its subject is host-local, not that it misreports what it reads.
• That the 20 .pyc rows are the only source of instability. They are the only ones present at 78f1139; a .pytest_cache/, an editor swap file, or any lane's new artifact would enter the same population the same way.
• That CHECK-ledger-dir-census is red at HEAD. In the worktree it read rc 0 at 78f1139; in a clean clone of that rev it read rc 1.
• That this audit is a gate leg. It is not in tools/verify.py; nothing runs CHECK-q140 but a reader or a tick that names it.
• That wizard-work/ledger/ is the only directory censused this way. This item graded one artifact; the os.walk-over-the-worktree pattern is what to grep for, and no census of that pattern was counted here.