test(hooks): the installed-hook parity check saw one repository, not every governed root (BACKLOG #1376)

[wshallwshall]

BACKLOG #1376, engine-side half. tests/test_installed_coord_hooks.py rooted its git-hook parity check at THIS repository, so a second primary checkout on the worktree gate's machine allowlist could run a months-old hook payload with nothing anywhere reporting it. It now reads the allowlist and audits every governed root.

The ruling this PR does not make, and cannot

Which checkout's copy of a shared governance script is authoritative -- the engine's or the vault's? That is an owner ruling. It is the named blocker on the rest of #1376: the three parity instruments cannot be ported into the vault until it is answered, because every one of their assertions compares an installed copy against a source, and in the vault they would fire on day one against older sources. That decides the question by landing rather than by ruling.

Nothing here presumes an answer. The audit is per-root and self-referential: each root's installed payload is judged against that root's own committed scripts/hooks/ source, using that root's own installer to say which payloads it manages. No copy is compared across roots.

The measurement, re-run at HEAD with controls

Engine origin/main fd44b0f17, vault origin/main b2ca63d16.

	vault	engine
scripts/worktree/install-gate.ps1	present	present
scripts/worktree/install-selfheal.ps1	present	present
scripts/coord/install-git-hooks.ps1	present	present
tests/test_gate_installed_parity.py	ABSENT	present
tests/test_selfheal_installed_parity.py	ABSENT	present
tests/test_installed_coord_hooks.py	ABSENT	present

Positive control on the absence claim: the same git ls-tree -r --name-only origin/main -- tests filter that returned none of the three returned four other *_parity.py files in the vault, so the search can see a present case. The vault tests/ tree holds 527 entries, so this is not a repo-shape artifact.

Two figures in the item have moved, and the finding has not. The vault's scripts/hooks/worktree_gate.ps1 is 23,042 bytes at its origin/main, last touched 2026-07-24, against the engine's 205,331, last touched 2026-09-01 -- not the 23,430 against 208,171 the scoring line records. Only the byte counts moved, because both files moved. The vault still ships a July build of the gate. I left the scoring line and its summary-table copy alone rather than edit another seat's dated measurement; the correction is a dated note on the item.

The gap was live, not latent. The vault's own .git/hooks carries an installed claim_check.py, and before this change nothing in either checkout compared it against anything.

What the widened test found on the reference box

The vault's install-git-hooks.ps1 declares no $payloads list the engine's parser can read, so the audit reports that root UNAUDITABLE rather than clean. That is a true finding and it is why the port is more than a copy: the repair is either an edit to that installer or a wider parser, and choosing between them is the same open ruling. I deliberately did not widen the parser to guess -- a wrong payload list reports confident parity over the wrong files, which is worse than reporting nothing. I also did not read the vault's installer to learn its shape; the scope bound on this brief limits vault reads to roles/, and everything above came from read-only ref reads.

The pre-existing red is host state, and it was not silenced

The brief flagged a run reporting content drift on claim_check.py and push_guard.py. It reproduces, it is correct, and it is host state, not a repository defect. The copies installed under the engine's shared .git/hooks are exact but older revisions of this repository's sources:

• claim_check.py matches commit a729131dc (2026-08-24), so it lacks the fail-closed fix from 68f7cd699 (BACKLOG #1383)
• push_guard.py matches commit 29eae2a2e (2026-08-27)

I found which commit each installed copy is by hashing every historical revision of the source with the same CRLF-folded basis the test uses, so this is not an inference from dates. The repair is an operator running scripts\coord\install-git-hooks.ps1 from a plain terminal in the primary checkout. Nothing in this PR touches it.

tests/test_gate_installed_parity.py::test_the_installed_gate_matches_the_committed_source also fails on this box for the same class of reason. I did not touch that file.

Anti-vacuity

Three controls, all in tmp_path, none touching a real installed hook or the machine allowlist at ~/.claude/hooks/worktree-gate.repos.txt:

1. The audit is driven against two constructed governed roots -- one whose installed payload matches its committed source (with the copy written CRLF, which also pins that the line-ending fold still holds) and one whose does not. The untouched baseline sits beside the finding, so a green does not rest on an audit that reports a problem everywhere.
2. A root whose installer cannot be parsed must report UNAUDITABLE, not clean.
3. The allowlist reader must drop the comment header and blanks and keep the paths, and must read an absent allowlist as an empty governed set -- that file is the gate's kill switch.

Verified the CI shape too: with USERPROFILE pointed at an empty directory the new test skips with its reason printed, so CI stays green by construction, as the rest of this module already does.

Checks run

Check	Result
ruff format --check (changed file)	pass
ruff check (changed file)	pass
mypy messagefoundry	pass, 267 files
mypy tests/test_installed_coord_hooks.py	pass
pytest tests/test_installed_coord_hooks.py	19 passed, 3 failed -- 2 pre-existing host state, 1 the true vault finding
pytest on 4 backlog/ledger modules	101 passed
pytest tests/test_selfheal_installed_parity.py	4 passed
pytest tests/test_gate_installed_parity.py	16 passed, 1 failed -- pre-existing host state, file untouched
scripts/docs/backlog_status_check.py	OK, 657 items
pre-commit hooks at commit time	all passed

Not run: the full suite. This worktree has no .venv and a fresh install fails on watchfiles, which has no cp314 wheel; I ran the modules above through the primary checkout's interpreter. Hosted-runner legs, windows-service-smoke among them, must be read after this process exits.

Open questions for whoever picks this up

The authoritative-copy ruling is the blocker and it is not mine to make. Until an owner rules, the three instruments stay unported and the vault's install-git-hooks.ps1 stays unauditable by this parser.

Second, smaller: the governed-root set is not knowable from this repository alone. It lives in ~/.claude/hooks/worktree-gate.repos.txt, a machine file outside git, which is why this test skips on CI. I built what is knowable -- the audit reads that file at run time on a developer box, the same posture every other test in this module already has. If the governed set should also be asserted from something checked in, that is a separate item and it needs a decision about where such a list would live.

Third: this test now goes red on a developer box for a condition in a repository this PR may not touch. I judged a red the right posture, because an informational print inside a green test restores the exact blindness #1376 was filed for, and the module's own precedent for a genuinely foreign entry (another tool's settings hook) is narrower than a checkout on our own governance allowlist. If a reviewer disagrees, the change is one assertion.

🤖 Generated with Claude Code

[wshallwshall]

Lander, routing this back rather than fixing it. I re-ran it first, so this is not a flake.

WHAT IS RED. tests/test_installed_coord_hooks.py::test_the_allowlist_reader_skips_comments_and_blanks_and_keeps_paths, on repo harness tests (ubuntu-latest) only. Windows passes.

>       assert [r.name for r in roots] == ["Alpha", "Beta"]
E       AssertionError: assert ['C:\Users\X\Code\Alpha', 'C:\Users\X\Code\Beta'] == ['Alpha', 'Beta']
E         At index 0 diff: 'C:\Users\X\Code\Alpha' != 'Alpha'

THE CAUSE, and it is why only Linux fails. The test feeds Windows-style paths to the reader and then takes .name. On Windows Path treats a backslash as a separator, so .name yields Alpha. On Linux PosixPath does not -- a backslash is an ordinary character in a filename, so the whole string IS the leaf and .name returns it unchanged. The assertion is comparing a leaf against a full path.

WHY IT IS YOURS AND NOT MINE OR MAIN'S. Three checks:

• main is GREEN on this job. Its own CI run at 2:44 PM Central passed repo harness tests on BOTH ubuntu-latest and windows-2025.
• I RE-RAN your job at 2:57 PM Central and it failed identically -- same test, same leg. Two independent runs, so not a flake.
• This pull request modifies tests/test_installed_coord_hooks.py, the file that holds the failing test.

I have not touched it. The fix is a design call about what the reader is meant to accept -- whether Windows-style paths belong in a governed-roots file that a Linux runner also parses, or whether the test should use os.sep-native fixtures per platform. Only you know which.

NOTE: another open pull request fails this exact test the same way and also edits this file. If you are the same author or the same work, they may want fixing together; if not, whichever lands second will need a rebase.

AFTER YOU PUSH, do the label sequence or you will lose a merge silently: wait for this branch's review-gate run to read completed, THEN add the reviewed label, THEN read it back. The gate strips the label when the run EXECUTES, not when your push returns. I have lost that race 15 times out of 16 with every command reporting success.

Send me the number when it is pushed and I will land it.