governance-reusable.yml dupkey helper pin 317101e0 is stale by 45 files — and its sparse-checkout scope is too wide for #962's freshness guard

[hyperpolymath]

Summary

governance-reusable.yml stages the dupkey / TypeScript-allowlist policy helpers from a
hardcoded pin, 317101e03b8fe642589498f4bdb84541ab466062, at three sites (lines 373, 1091, 1178).

That pin is stale by 45 files under scripts/ relative to main, including several of the very
helpers and tests it is meant to supply:

$ git diff --name-only 317101e0 origin/main -- scripts | wc -l
45

among them scripts/check-actions-lock-gate.sh, scripts/update-actions-lock.sh,
scripts/check-ts-allowlist.sh's siblings, and 18 files under scripts/tests/.

This is the same class as the lock-gate pin fixed in #962: a third pin, hardcoded inside the
callee because a called reusable workflow has no context exposing its own commit, and therefore
invisible to both the caller's uses: ref and to actions.lock.

Why #962's guard was not simply pointed at it too

#962 adds scripts/check-lock-gate-pin-freshness.sh, which asserts that a step's pinned commit
already contains everything on the base ref, path-scoped to that step's own sparse-checkout:
list. Applied verbatim here it would be useless, and that is the interesting part:

      - name: Checkout the pinned Standards policy helpers
        with:
          ref: 317101e03b8fe642589498f4bdb84541ab466062
          sparse-checkout: |
            scripts

The dupkey step stages the whole scripts directory. A freshness predicate over that scope is
red the moment any of ~200 scripts changes for any reason, which is permanently — so the guard would
be turned off rather than obeyed, and an always-red gate is worth less than no gate.

The scope has to be narrowed to what the step actually executes before the same predicate can be
applied to it. That is a real change to the workflow, not a change to the guard, which is why it is
this issue and not part of #962.

Acceptance criteria

1. The sparse-checkout: list for Checkout the pinned Standards policy helpers names the specific
   helper scripts that step executes, not the whole scripts directory. Enumerate them by reading
   the steps that consume .standards-checkout, not by guessing from names.
2. The pin 317101e0 is bumped to a commit containing the current version of each of those files.
3. scripts/check-lock-gate-pin-freshness.sh (from fix(governance): gate the lock-gate's own pin on freshness, and bump it past #946 #962) is parameterised over the step name, or a
   sibling guard is added, so this step is covered by the same freshness predicate — and the step is
   named in scripts/tests/governance-reusable-contract-test.sh.
4. A mutant proves it: reverting the pin to 317101e0 must fail the new control. A passing suite is
   not evidence until the defect it claims to catch actually kills it.
5. The other two sites (1091, 1178) carrying the same SHA are bumped in the same change, or the
   issue records why they are allowed to diverge.

Related

• fix(governance): gate the lock-gate's own pin on freshness, and bump it past #946 #962 — the lock-gate instance, with the guard and its 10 mutant controls.
• governance-reusable.yml still has 7 'ref: main' helper checkouts reached by 368 pinned callers #910 — the 7 remaining ref: main helper checkouts in the same file. That issue and this one are
  the two halves of the same problem: a helper checkout is either floating (no review) or pinned
  (silent rot). The freshness predicate is what makes the pinned half safe.

🤖 Generated with Claude Code

https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm