test(gate): attribute an installed-vs-source parity failure to the machine, not the repo (BACKLOG #1367)

[wshallwshall]

Built by Builder 1. Landed by the Lander. Two files, +257/-0: docs/BACKLOG.md and tests/test_gate_installed_parity.py.

Handed over with two full-suite failures on the record, deliberately

The author asked that these be visible rather than buried, and they are right that it matters:

run 1   1 failed  13851 passed   tests/test_ledger_check.py::test_ci_mode_works_on_a_SHALLOW_clone...
run 2   1 failed  13851 passed   tests/test_selfheal_installed_parity.py::test_the_installed_selfheal_payload...

Two consecutive full runs of the same tree, two different tests, neither touched by this branch. A defect in the change would reproduce. These do not, and the non-reproduction across different tests is the evidence -- neither verdict alone would be.

What they established about each, so nobody re-derives it:

Run 1 passes in isolation on this branch, first try. The cause is unnameable from the log: the test runs git clone --depth=1 with capture_output=True, check=True and no handler, so git's stderr lands inside a CalledProcessError whose repr omits it. Exit 128, no message, at exactly the moment the message is the diagnosis. That is a real test defect independent of this run, and it is unallocated.

Run 2 is the installed-vs-source parity family the Cleaner root-caused. The author applied the Cleaner's corrected predicate rather than the retired commit-count one: git diff --quiet origin/main -- <source> reports this checkout's worktree-selfheal.ps1 matches origin/main exactly. So the checkout is not the odd one out -- the installed payload on that machine is. Machine state, not repository state, and precisely the case where reinstalling is the wrong move.

They did not run a third time, and say why: two runs at 47 minutes each already cost more than the finding, and a third could not separate the hypotheses either, since both are environmental and neither is in the diff. I accept that. CI is the arbiter here and it runs on a clean host.

An attribution trap worth more than the change

The author nearly reported this branch as touching three files, including .github/workflows/codeql.yml, which they never went near. It appeared because they were 1 commit behind and a two-dot diff renders main's own new commit as a difference.

git diff --name-only origin/main..HEAD                          3 files  <- wrong
git diff --name-only $(git merge-base origin/main HEAD)..HEAD   2 files  <- right

A two-dot diff against a moving branch conflates "what I changed" with "what main changed", and it reads as scope creep in your own PR. I reproduced both forms; they agree at 2 files now only because the author merged main in first.

Lander verification

ahead of origin/main    3        behind    0
merge-tree vs main      exit 0 (clean)
diff                    2 files changed, 257 insertions(+)
'+## 1367' in ledger    1

Before the push, git branch -r --contains 38f8509d9 named only the private rescue ref. Fourth branch tonight where a count-based check would have read "already pushed."

Not armed

Required approvals are 0, and this touches gate test infrastructure.

Generated with Claude Code