A staged rename of a decision file clears the commit gate: -U0 with a pinned pathspec renders it as a whole-file add

[thrillmot]

gitcli.DiffCachedAddedHunks runs git diff --cached -U0 -- <path>. With the pathspec pinned to one side, git renders a rename as a whole-file add — so every pre-existing entry in the renamed file reads as newly added, and the gate sees a well-formed decision that this change did not write.

Measured

Binary built from feat/collapse-decision-layout, hook installed, built binary first on PATH:

git mv docs/decisions-branches/feat__rn.md docs/decisions-branches/feat__renamed.md
+ 401 lines of new Go
guard-commit --layer git-hook  →  exit 0   ✓ allowed (decision-recorded)

Control, same tree without the rename → exit 65.

Not a regression

git show main:internal/guardcommit/guardcommit.go:177-179 allowed on the staged path alone, so main passes this too. The hunk-based predicate that replaced it did not introduce the hole; it inherited it from the reader beneath. Filing rather than fixing in the PR that found it, because the PR's own change is verified correct and this is a layer down.

Why it is worth fixing anyway

The gate already ships two documented one-line bypasses — [skip-logmind] and LOGMIND_ALLOW_GIT_COMMIT=1. Both are deliberate, scoped to one commit, and visible in the log. This one is none of those: it is silent, it looks like ordinary refactoring, and renaming a decision file is a plausible thing to do while making a substantive change.

It also interacts with the zero-conflict invariant: branch decision files are named after the branch, so a branch rename is exactly when a decision file gets renamed.

Done when

• A staged rename does not present the renamed file's pre-existing content as added.
• The fix is in the reader, not in each caller — DiffCachedAddedHunks and DiffRangeAddedHunks share this.
• Mutation-tested: the rename case blocks, and a genuine entry added in the same commit as a rename still passes.
• Control the fix against a plain add and a plain modify so the reader has not simply become blind.

Found by the round-17 adversarial panel on #301, which returned MERGE on everything the PR itself changed.

[thrillmot]

Sharpening the fix, measured against origin/dev (4b08123) — the answer is one flag, and this file already ruled on it.

internal/gitcli/gitcli.go:359 sets the line-count reader's flags:

var numstatFlags = []string{"--numstat", "--no-renames"}

Its comment at :340-358 states the rule in general terms and says why:

"a flag one surface passes and another doesn't is that one evaluation quietly becoming two."
"--no-renames is load-bearing, and its absence was a live gate hole."

The very next reader does not pass it — :407:

cmd := exec.Command("git", "diff", "--cached", "-U0", "--", path)

So the two halves of the same gate decision disagree by construction: the line-count half suppresses rename detection, the well-formedness half does not. That asymmetry is the mechanism this issue describes — it is not a second bug, it is the named cause, and the fix is to add --no-renames at :407 rather than to teach anything to parse old => new (which :356-358 already rejects, on the grounds that git has two rename renderings and a parser owes both plus whatever git adds later).

Control for the claim that this is untouched by the open gate PR: git diff --name-only 4b08123...842e7bb | grep -c '^internal/gitcli/' → 0, against a control of 26 files total in that diff — so the probe reaches, and PR #357 does not go near this file. This stays open after #357 merges.

Scope note: I measured :407 only. git grep -n 'exec.Command("git", "diff"' internal/gitcli/gitcli.go returns four call sites (:245, :407, :559, :1034); whoever takes this should check each rather than trusting the two named in the body.