pm: the carried-record regeneration test lists a renamed path by its destination only, so a hop that moves a reviewed file out of its face is not seen #33578

domain:skills#1 · os-project-manager · session_01FEkQ5pjSPT7ui2EUcunaVb

Filing gate: ① (an out-of-diff observation of the at-tier delta review 6887175399 of PR #33531, card #33501; its in-diff twin is should-fix SF2 there). reach: a carried contract-review record can survive a regeneration hop that moved a reviewed file out of the reviewed face, because the hop's rename is listed by its destination only.

What is wrong. unexplainedPathsBetween in scripts/pm/record-recognisers.mjs (on main, the names helper inside it) lists a hop's changed paths with git diff -z --name-only FROM TO and no --no-renames. With rename detection on (git's default), a rename is listed by its destination path only. The review measured this on git 2.43 in a throwaway repository: moving skills/a/rules/security.md to content/docs/security.md lists only the docs path. A hop that renames a reviewed file to a path that base explains, or that the carry otherwise admits, therefore never shows the removed source path, and the carried record can stand for a head where a reviewed file has left its face.

What lands. Pass --no-renames to every --name-only diff the carry machinery reads (this helper and any sibling), so a rename reads as a delete plus an add. Pin it with one self-test case that runs real git in a temporary repository (the fake git readers in the battery cannot see what git lists), plus an argument pin. The guard's row enumeration in check-governed-queue-guard.mjs already passes --no-renames; PR #33531 fixes its own new call (SF2).

scripts/pm/** only, skip-changeset. Clause-②: no.

Dedupe (open AND closed): is:issue unexplainedPathsBetween and is:issue no-renames carried record → none. New.