scripts: check-hook-exec-form and check-hook-userconfig-argv duplicate the manifest trust-boundary walk - extract a scripts/lib seam

[kyle-sexton]

Context

Found by the repo-wide /code-tidying:batch-simplify sweep (62 groups / 986 files, branch claude/repo-code-tidying-batch-twhddw). Deferred from the sweep as dedicated-PR-shaped work: the consolidation crosses file or contract boundaries a behavior-preserving sweep must not cross.

scripts/check-hook-exec-form.sh:227-289 and scripts/check-hook-userconfig-argv.sh:84-139 duplicate the scan_manifest_path trust-boundary check and manifest hooks_type walk nearly verbatim. Cross-file seam extraction is dedicated-PR shape (precedent #3144, #3181) and needs fixture-staging changes in both suites.

Proposed work

• Extract the shared walk into scripts/lib with both gates consuming it; keep per-gate output contracts byte-identical.

Acceptance criteria

• One shared implementation; both gate suites green with unchanged transcripts.

References

• scripts/check-hook-exec-form.sh:227
• scripts/check-hook-userconfig-argv.sh:84

Filed by the /code-tidying:batch-simplify closeout (Phase 8).

[kyle-sexton]

This was generated by AI during triage.

Cross-reference: this is a concrete instance under a general pair, but the parent is #3414, not #3413

This issue is untriaged and carries no links. Two sibling issues filed the same day cover the general patterns it instantiates. Both were re-verified against current main on 2026-09-06 and routed as delegable.

#3414 ("gate test fixtures re-derive each gate's private source list by hand") is the closer fit, and the evidence is on the page: #3414's body names check-hook-userconfig-argv.test.sh:18 explicitly as one of the suites that hand-transcribes its gate's lib copy list. That is one of the two suites this issue must change. This issue's own deferral reason is that the consolidation "needs fixture-staging changes in both suites", and fixture staging is precisely what #3414 owns. Once #3414's staging interface derives a gate's transitive lib set by reading the gate, the fixture half of this work disappears rather than being done by hand.

#3413 ("gate entry protocol is re-derived per gate") is adjacent but is not the right parent, contrary to what a first read suggests. Its scope is the entry protocol only: mode dispatch, parent-shell base-ref validation, target discovery, and the fail-closed 0/1/2 mapping. Its triage comment states the boundary directly: "Changing what any gate checks. This is entry-protocol only; a gate's scan body is untouched." The manifest trust-boundary walk this issue wants to extract is scan body, so it falls outside #3413 by that issue's own stated exclusion.

Recommendation for a human:

• Make this a child of scripts: gate test fixtures re-derive each gate's private source list by hand (deepening candidate) #3414, or at minimum sequence it after scripts: gate test fixtures re-derive each gate's private source list by hand (deepening candidate) #3414 lands. Doing it first means writing the fixture-staging changes twice.
• Cross-link scripts: gate entry protocol (mode dispatch, base-ref validation, exit-code policy) is re-derived per gate (deepening candidate) #3413 as context rather than as parent. scripts: gate entry protocol (mode dispatch, base-ref validation, exit-code policy) is re-derived per gate (deepening candidate) #3413 and scripts: gate test fixtures re-derive each gate's private source list by hand (deepening candidate) #3414 already carry sequencing notes to each other (take scripts: gate entry protocol (mode dispatch, base-ref validation, exit-code policy) is re-derived per gate (deepening candidate) #3413 first if both are picked up), so the whole set reads as one scripts/ consolidation effort.
• If the owner prefers a single container for all three, that is a reasonable alternative to three separate edges.

This issue also still carries both priority: needs-triage and needs-triage and has no work-class or priority tier. That is a labeling gap for a triage pass to close, not something this cross-referencing pass changed. Nothing was relabeled, closed, or linked by this comment.

---

Generated by Claude Code

[claude]

---

Generated by Claude Code

[claude]

This was generated by AI during triage.

Triage verification (2026-09-06)

Claim holds. Both hook gates define their own scan_manifest_path function performing the same trust-boundary check and manifest hooks-type walk, and each calls it from two places in its own scan loop. The two copies are near-verbatim, including their explanatory header comments. Duplicating a trust-boundary check is the part that matters: the two gates decide independently what counts as inside the boundary, and a hardening applied to one leaves the other as filed.

Agent Brief

Type: Task (refactor)

Summary: Extract the duplicated manifest trust-boundary walk into a shared script library seam that both hook gates consume, keeping each gate's output contract byte-identical.

Current behavior:
Two hook-checking gates each define their own copy of a function that resolves a manifest-declared hooks path, applies the trust-boundary check, and walks the manifest's hooks entries. The copies are near-verbatim and each gate calls its own from two sites. Because the trust-boundary decision is duplicated, a correction to it has two homes and can be applied to one gate only. Each gate also has its own suite with its own fixture staging for this walk.

Desired behavior:
One implementation of the trust-boundary check and the manifest hooks walk lives in the shared script library. Both gates consume it. Each gate's own output remains byte-identical to what it emits today, since the gates' transcripts are asserted by their suites and by downstream consumers. Fixture staging for the shared walk is tested once at the seam rather than restaged in both gate suites.

Key interfaces:

• A shared manifest-walk seam in the repository's script library, exposing the trust-boundary check and the hooks-entry walk.
• The two hook gates that consume it, each retaining its own distinct finding output and exit-code contract.
• The manifest hooks-type structure the walk traverses.

Acceptance criteria:

• One shared implementation exists; neither gate defines its own copy.
• Both gate suites are green with unchanged transcripts, so each gate's output contract is byte-identical to today's.
• The trust-boundary check is tested once at the seam, including the case it exists to refuse.
• Fixture staging for the shared walk is not duplicated across both gate suites.
• scripts/affected-tests.sh --run passes for the touched surfaces.

Out of scope:

• Changing what either gate reports, its finding text, or its exit codes.
• Widening or narrowing the trust boundary itself. This item relocates the check; the policy is unchanged.
• Other duplicated logic between the two gates outside the manifest walk.

---

Generated by Claude Code