fix(gate): rule 3b printed an unrunnable remediation, and deferred to a guard the caller can switch off

[wshallwshall]

Rule 3b of the worktree gate printed a remediation command that new.ps1 refuses to run. Fixing it surfaced two defects more serious than the one filed.

Lead finding: command injection into text an agent is told to run

git check-ref-format accepts ;, $, |, " and ' in a refname. The legal branch x';calc;# made rule 3b emit a deny line that parses as two statements, the second arbitrary — injected into a message whose entire purpose is to tell an agent "run this instead". Fixed by quote doubling.

This is not hypothetical shell-quoting hygiene: the deny text is attacker-influenceable output that an agent is instructed to act on, and nothing in the gate treated it as such.

Second: the gate deferred to a guard the caller can switch off

An early return skipped the deny when the destination branch was already checked out elsewhere, reasoning that git refuses that switch anyway. Git has flags that turn its own guard off. Measured, with victim live in another worktree:

command	result
git checkout victim	fatal: already used by worktree
git checkout --ignore-other-worktrees victim	succeeds
git checkout --detach victim	succeeds
git checkout -d victim	succeeds
git switch --detach victim	succeeds
git switch -d victim	succeeds
git checkout --force victim	fatal (does not bypass)
git switch --discard-changes victim	fatal (does not bypass)

Detach bypasses because it never takes the branch lock — while still swapping the other session's files to that commit, which is exactly the harm rule 3b exists to prevent.

The fix is an allowlist, not a flag list. The early return now fires only when there are no flags at all after the verb. A denylist was written twice and wrong twice — --detach was missed while fixing --ignore-other-worktrees, and -d would have been missed while fixing --detach. A future git flag would silently reopen it. The cost is a needless deny on git checkout --quiet main; that trade does not decay, and a flag list does.

The general form, worth keeping: "git already refuses this" is a claim about a configuration, not about git. A guard you do not own can be switched off by its own caller.

Third: the ValidatePattern did not enforce its own stated shape

"abc" + newline matches ^[A-Za-z0-9._-]+$, because .NET's $ also matches before a trailing newline. Fixed to \A..\z in all four copies of that pattern.

The filed defect, and a hazard the fix created

new.ps1 used one parameter for a directory name and a git ref. Now split into -Name (directory) and -Branch (ref), defaulting -Branch to -Name so existing callers are unchanged.

That split would have armed remove.ps1 -DeleteBranch, which assumed branch == directory name. It now reads the branch from git before removal destroys the reflog, and adopts prune-merged.ps1's -d-first lossless discipline. Three sibling worktrees already have HEAD != directory name and all three carry unmerged commits, so this was live rather than theoretical.

Verification

213 tests pass across the nine gate suites. The four hole tests were confirmed FAILING first for both verbs ("expected a DENY, got allow"), and a companion test asserts the no-flag case is still ALLOWED, so the early return was fixed rather than merely deleted. Tests execute the string the gate prints rather than asserting a copy of it.

After merging: the installed gate needs a manual re-install

worktree_gate.ps1 runs from an installed copy that does not update itself. tests/test_gate_installed_parity.py will report STALE from the moment this lands — that is the designed re-install signal, not a regression. Re-install from a plain terminal against the merged checkout, never from a worktree.