Two ledger rows name checks that no longer exist, so the census over-counts; nothing compares the ledger's keys against a run's

[OffgridwithJD]

Two ledger rows name checks that no longer exist anywhere in the tree, so the census counts two checks that cannot run. Nothing detects this, and it has been true since #917.

harness_selftest  330-the-incomplete-path-must-run-whole  'premise: all three runner functions were extracted, not empty ranges'  never  -
harness_selftest  330-the-incomplete-path-must-run-whole  'premise: and all three are callable'                                  never  -

Both names appear in exactly one file in the repository:

$ grep -rlF "all three runner functions were extracted" test/
test/check_ledger.tsv

They are not in 330-the-incomplete-path-must-run-whole.sh, not in any other part, not anywhere. git log -S points at the commit that removed them:

51b73fdb4  test: selftest 330 ran a collect loop whose reconciliation could not execute (#917)

The checks were deleted; their ledger rows stayed.

Found while doing something else, which is the point

I was adding an orphan check to my own regeneration for #982 — no row may remain for a check the run did not emit — expecting it to confirm that the three rows my rename orphaned were the only ones. It reported five, not three.

The other two are these, and they are not mine to have created. f80ca7d05's commit message describes them as "two pre-existing conditional checks in part 330", which was either wrong then or has stopped being true since: a conditional check still exists in the source and simply does not run. These do not exist.

Why it matters

checks_never_observed_red is documented in check_ledger_budget.txt as "a measurement that must be true" — a census of the ledger, asserted against the committed file. It is 903 after #982's first pass, and two of those 903 are checks that cannot be observed red because they cannot run.

So the number is not wrong against the ledger — it is exactly the count of rows — but it is wrong as a statement about checks, which is what anyone reading it will take it for. Same shape as the collapsed keys in #982, arriving from the other direction:

#982   two checks share one row   ->  the census UNDER-counts checks
this   one row has no check       ->  the census OVER-counts checks

Both are invisible because every number reconciles: the run reconciles against its own records, the ledger reconciles against its own rows, and nothing compares the two sets.

The guard, and why it cannot be a per-suite check

Set-compare the ledger's (suite, part, name) keys against the keys a run emits, and refuse a row with no matching check.

It needs a run of every covered suite, not one suite's log. A single-suite log would flag every other suite's rows as dead — which is the false-positive that makes the naive version unusable. So it belongs where the matrix already reconciles across suites, next to pgc_log_shows_accounting and the population reconciliation, not in a selftest part.

pgc_ledger.py already has the other half: rename-scan reports vanished=N against a log. What is missing is a refusal over the full set, and a rule for what to do with a vanished row that carries history — f80ca7d05 established that a row with a date or a mutation must travel with its rename rather than be dropped, and a row whose check simply vanished has no rename to travel with.

The two rows here are safely removable, but not by me in #982's first pass

Both carry never and no mutation, which is f80ca7d05's criterion for dropping a row without losing history. So the cleanup is two lines.

I am deliberately not doing it in the part-400 rename PR. That PR removes the three orphans it creates; removing two unrelated ones would widen a diff whose whole purpose is to propose a phrasing rule, and it would tidy away the evidence for this issue. Better as its own two-line change with the guard, or alongside whoever takes the guard.

[OffgridwithJD]

The comparison already exists and already prints the answer. What it does not do is refuse. That changes what this issue needs, so here is the measurement before the patch.

rename-scan sees the vanished rows and returns 0

It pairs an appearance with a disappearance, and the pairing is where the refusal lives:

for new, old in zip(app, van):
    print(f"    possible rename: {old} -> {new} ...")
    rc = 1

With two vanished names and nothing appeared, zip yields nothing, rc stays 0, and the summary line prints appeared=0, vanished=2. So the information has been in the output of every run — the same shape as the duplicate-name note we both scrolled past. A guard that compels one list and ignores the second manufactures the confidence that the thing is handled, and that is this, inside the tool meant to prevent it.

Scoping is already right, which I had assumed was the missing piece: rename-scan restricts to the (suite, part) pairs the run contains, so a one-suite log does not flag another suite's rows. The full-matrix requirement I posted earlier was wrong — per-part scoping is what makes a partial log safe.

The decisive measurement: a hard refusal would be WRONG today

I scanned the committed ledger against the freshest real harness_selftest log and got 21 apparent orphans. Classified:

count	what they actually are
12	part 250 arms that #975 added after that log was taken
6	part 400's names, which #984 renamed
2	the genuine article — part 330, the rows this issue reports
1	part 340, and this one is the reason the guard cannot gate

The first 18 say the log must come from the same tree as the ledger it is scanned against. Fine — that is the regeneration discipline we already pay.

The last one is different. 340-the-binary-must-be-built-from.sh:676:

if [ -z "$_fp_user" ]; then
	check_skip "the unreadable-source refusal" "SKIP  no non-root user to read as; ..."
else
	check "premise: the unprivileged reader can source the staged harness" ...
	check "premise: the unprivileged read agrees while everything is readable" ...
fi

On a box with no non-root user, one skip records under a name neither arm has, and two committed ledger rows have no matching record while being perfectly live checks. An absent record therefore does not yet mean a removed check, and a gate refusing on absence would redden a correct run on such a box.

So the guard reports and is not wired into the gate, and the precondition for arming it is that those branches record a SKIP under the names they stand in for — the same conversion #965 made for the eleven timeout paths. I have pinned that shape in an arm so the day it changes, the arm says so.

What I am opening

orphan-scan, with --prune, and the rule this issue asks for:

• an orphan with no history may be pruned;
• an orphan carrying history refuses the whole prune, because no run can recreate the catalogue, and removing the safe ones would leave a partial job for whoever reads the output;
• rows in parts the run does not contain are counted out loud as not checked, never as present.

Driven on the real ledger, which is the only instance that matters:

orphan: harness_selftest  330-...  premise: all three runner functions were extracted, not empty ranges (no history)
orphan: harness_selftest  330-...  premise: and all three are callable (no history)
not checked: 44 row(s) in 1 part(s) this run does not contain: native_join_runtime_filter/...
orphan scan: parts in the run=43, rows in those parts=861, orphans=2 (0 carrying history), not checked=44
pruned: ... x2
orphan prune: removed 2 row(s), the ledger now holds 925

Census re-derived from the file rather than adjusted: 925, and the gate agrees at 925/925 with the ceiling unchanged at 250.

Red-green proven on both harnesses: ten arms in 410-a-check-must-have-been-red.sh and two tests in test_mutation_ledger.py, all failing against main's tool — got 0 want 1, rc 2 from an unknown subcommand — and passing against the branch.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Uf6UoeBRZYLQZa4KxNiw8a