fix(gate): install-gate.ps1 merges the allowlist instead of replacing it, reviewed and tested (BACKLOG #1375)

docs/BACKLOG.md

@@ -17515,6 +17515,15 @@ site_prefixes   1      2       50.0%   <- would FAIL a flat 80% rule
 > 🔢 **Filed 2026-08-28 (lander) - third version of this item; the two earlier framings were refuted before filing and one is recorded below.**
 >
 > **Scored 2026-09-03 -> P1.** Value **6/10** · Difficulty **2/10** · _quick win_. Not started, and every mechanism claim holds at HEAD: scripts/worktree/install-gate.ps1:495 writes the allowlist with a bare Set-Content, the install branch defaults to exactly one root at :424, the only Get-Content of that file sits in the -Status branch at :300 which returns first, and the param block at :48-70 offers no -Add or -Merge. No backup exists, and two places assert one does -- install-gate.ps1:441 says the allowlist writer has done this since #1375 and tests/test_install_gate_records_the_install.py:16 repeats it, while the only Copy-Item backups cover settings.json at :164 and the gate script at :449. The precondition is live: the machine allowlist at ~/.claude/hooks/worktree-gate.repos.txt carries both MessageFoundry and MessageFoundry-vault, so a bare run from either drops the other. Correcting one anchor, since the silence has a different cause than filed -- a bare run writes ONE root, so the zero-root kill switch at scripts/hooks/worktree_gate.ps1:1259 never fires; the dropped root is simply absent from the roots list, matches no rule, and the gate exits 0 at :2447 and :2784 with no line printed. Left to build: read-and-merge, a .bak beside the allowlist, a warning naming any root the run is about to drop, and a deliberate way to still narrow scope; the workaround is awkward because -Repo is [string[]] at :50 so every governed root must be re-named on every run and docs/WORKTREE-GATE.md:157-158 reads additive, and the cost is a small additive change to one script plus a test on the region-extraction seam tests/test_install_gate_records_the_install.py already establishes.
+> 🚧 **Status 2026-09-03 -- BUILT AND PROPOSED, not landed.** The scoring line above read "not started" correctly against `main`, and separately against the work: this was built 2026-08-29 under a usage stop, never proposed to anyone, and sat on a local branch pushed only to a rescue remote, so `main` still carried the defect while the row was re-scored as unbuilt. The two #1375 commits are now cherry-picked onto a fresh branch off `main` (two unrelated commits on that branch were left behind) and are in a PR. **All four parts the row asks for are present:** read-and-merge, a `.bak` beside the allowlist, a warning naming every root a run is about to drop (`Show-AllowlistResult -Narrowed`, plus a louder one when the last root goes), and `-Uninstall -Repo "<path>"` to narrow scope on purpose. Landing it also makes `install-gate.ps1`'s own forward reference true -- the line the scoring note flags as asserting a backup that did not exist.
+>
+> **THE REVIEW THE BUILD COMMIT DISCLAIMED IS NOW DONE.** Its message said the work was "NOT YET REVIEWED BY ME", that "the review and test run are still owed", and "Do not land it on this basis". **The 634-line test file had never been run.** It was run: **46 passed** across `tests/test_install_gate_allowlist_merge.py` + `tests/test_install_gate_wiring.py`. **The anti-vacuity arm was re-measured rather than inherited**, each mutation on a scratch mirror against that same 46-passed control: feeding the install call site `@($resolved)` instead of `$result.Lines` gives **3 failed / 43 passed**; making the merge ignore `$Existing` gives **8 failed / 38 passed**; deleting the `.bak` gives **1 failed / 45 passed**. One mutant SURVIVED at 45 passed / 0 failed -- the **narrowing** call site (`-Uninstall -Repo`) had no coverage at all, so writing back the lines it just read left every test green while the named root stayed governed and the operator was told it had been removed. A test now kills it (**1 failed / 45 passed**), and the control moved 45 -> 46 to include it.
+>
+> **TWO THINGS CHANGED IN REVIEW, both of them wrong-prose rather than wrong-code.** First, the rebase onto current `main` red-lined the ordering test: it matched the literal `worktree_gate.ps1` in command text, and #1247 had hoisted that path into `$GateSrc`, so the predicate found ZERO gate copies. It follows the value now (the copy's `-Destination`), and it covers every write under the hooks directory rather than the gate alone. **Only the `== 1` count assertion beside it turned that into a failure instead of a silent pass.** Second, the refuted mechanism this row's own scoring line corrects was still stated as fact in **three** places -- the script's `.DESCRIPTION`, the allowlist section comment, and the test module docstring -- plus a fourth that conflated a *shortened* allowlist with the kill switch. All four now say what the gate does: a bare install writes ONE root, never zero, so `worktree_gate.ps1:1259` never fires; the dropped root is simply absent, matches no rule, and the hook exits 0 printing nothing. Re-verified independently here, and it agrees with the scoring line.
+>
+> **THE TWO OPEN QUESTIONS THE ROW NAMES ARE BOTH ANSWERED, measured not read.** `-Repo a,b` binds as `String[]` with two elements and the script iterates all of them, so it does govern two repos. And there is no second gate installer: `install-selfheal.ps1` writes `~/.claude-hooks/`, a different tool in a different directory, and only ever READS the gate's allowlist to seed its own. **STILL OWED, and not claimed:** nobody has executed the installer end to end. `install-gate.ps1:407` refuses inside Claude Code by design, keyed on the session rather than the target, so that run is the owner's from a plain terminal.
+>
+> **THE 46-PASSED CONTROL ABOVE IS A 2026-09-03 READING AND THE BRANCH HAS MOVED PAST IT TWICE.** Measured on Windows over the same two files: **47** at `52d04ad01`, the tip that reading was taken from, and **48** at `070bdccc6`. Why it was 46 rather than 47 on the day is not established here, and is not guessed at. The 47 -> 48 step is this: `test_the_writer_refuses_when_the_file_reads_back_wrong` produced its un-landed write by holding the target open with `FileShare.Read`, which obstructs a rename on Windows and **nothing at all on POSIX** -- a rename consults no open handle there -- so the write landed, the read-back agreed, and the ubuntu leg red on `NO THROW` while `Write-GovernedRoots` behaved correctly throughout. It is now two arms asserting one shared refusal: a portable one that shadows `Move-Item` in the scope the function is dot-sourced into, and the lock kept as a Windows-only second arm. **The mutation figures above were NOT re-measured against 48** -- each of 43, 38 and 45 is relative to the 46 control, and re-running that pass is what would refresh them.
 > Verdict: build
 > Closing-act: code
 
@@ -17525,15 +17534,15 @@ site_prefixes   1      2       50.0%   <- would FAIL a flat 80% rule
 
 **CONFIRMED FROM SOURCE, quoted not inferred:** the `Set-Content` REPLACES, and nothing between the branch entry and that write reads the existing file; the only `Get-Content` sits inside the `-Status` branch, which returns before the install path; a bare run writes exactly ONE repo; and the installer never backs up the allowlist -- its `Copy-Item` calls cover `settings.json` and the gate script only.
 
-**LEAD WITH THIS: A DROPPED ROOT FAILS OPEN SILENTLY.** The gate exits zero when the root count is zero, and the comment beside it says why -- the allowlist doubles as the kill switch, so no file and no entries means nothing is governed. Zero protection, no warning, no log line.
+**LEAD WITH THIS: A DROPPED ROOT GOES UNGOVERNED SILENTLY.** *(Mechanism corrected 2026-09-03, twice and independently -- by the scoring pass above and again during the build review. The original sentence, kept here because it is the plausible-and-wrong one a reader will otherwise re-derive, said the gate exits zero when the root count is zero, so the allowlist doubling as the kill switch is what fails open.* **That never fires on this path:** *a bare install writes ONE root, never zero, so `scripts/hooks/worktree_gate.ps1:1259` is not reached and the surviving root stays governed exactly as before.)* The dropped root is simply **absent** from the list the gate loads: no rule matches a path inside it, the hook exits 0 with no output, and writes into that checkout stop being denied. Zero protection for that tree, no warning, no log line -- and **worse than the kill switch rather than milder**, because an emptied allowlist is at least visible and a silently shortened one reads like one somebody narrowed on purpose.
 
 **THE PRECONDITION IS LIVE ON THIS BOX, NOT HYPOTHETICAL.** The allowlist currently carries two roots, so a bare run would drop one. **And the two allowlists measurably disagree**, which is the state this defect produces and nothing reports.
 
 **DO NOT WORD THIS AROUND VISIBILITY.** `-Status` already prints the governed list, so "the operator cannot see the scope" is FALSE and would sink the item. **The defect is the missing announcement at the moment scope NARROWS.**
 
 **TWO DECOYS, neither of which covers it:** #1247 covers the gate SCRIPT copy, not the allowlist write. #1367 covers the parity MESSAGE from the same incident and has already landed.
 
-**UNTESTED, AND THE ITEM MUST NOT READ OTHERWISE: nobody has executed the installer in any mode.** Every mechanism claim above is source-reading. Two questions are genuinely open: whether `-Repo a,b` actually governs two repos, and whether a second gate installer exists on this box that nobody has identified.
+**UNTESTED, AND THE ITEM MUST NOT READ OTHERWISE: nobody has executed the installer in any mode.** Every mechanism claim above is source-reading. *(Still true of the INSTALL RUN, which the script refuses inside a session by design. The two questions this paragraph called open are no longer open -- both were measured 2026-09-03; see the status banner.)* Two questions were genuinely open: whether `-Repo a,b` actually governs two repos, and whether a second gate installer exists on this box that nobody has identified.
 
 **A REFUTED FRAMING, KEPT SO IT IS NOT RE-DERIVED:** an earlier version claimed the engine was ungoverned for four days. **Refuted by 70 engine denial proof points across 2026-08-22 to 08-26** against an all-time control of 211. Real engine exposure was at most 72 minutes, both collapses were on 2026-08-26 ten minutes apart, and **the victim is inverted** -- the repository that was ungoverned, for about 24 days, was the vault.