fix(do-not-merge-gate): drop gh CLI dependency from label refetch

[kyle-sexton]

Summary

The do-not-merge-gate reusable's live label refetch ran gh api in a run step. The gate executes on whatever runner the caller selects, and a self-hosted image is not guaranteed to ship the gh CLI — observed on melodic-software/claude-code-plugins#330: exit 127 gh: command not found failed the required check with no blocking label present.

This ports the step to actions/github-script (same SHA-pinned v9.0.0 the pr-issue-linkage reusable already uses on the same runners). The merge_group PR-number parse, live-refetch semantics, and error messages are unchanged; the runtime is the action's bundled Node, removing the runner-image tooling dependency.

Other reusables still call gh (claude-review, link-check, queue-monitor-liveness, tool-version-drift-check); they are out of scope here — this fixes the one gate observed failing as a required consumer check.

No linked issue

Related

• Failure observed on docs(topics): ai-adoption-ladder contract set + WP1-WP3 plans claude-code-plugins#330 (do-not-merge / do-not-merge, exit 127)

Verification

• actionlint clean; zizmor no findings on the edited workflow
• Logic port is 1:1 (parse → live refetch → label test → identical error strings)

🤖 Generated with Claude Code

[claude]

Claude finished @kyle-sexton's task in 1m 31s —— View job

---

Review

• Gather context and read changed file
• Analyze diff for correctness, security, and CLAUDE.md compliance
• Post review findings

---

Summary: The port is correct and clean. No blockers. A few observations below.

Correctness — logic is 1:1

Concern	Old (bash)	New (JS)	Match?
merge_group PR parse	sed -nE 's#.*/pr-([0-9]+)-[0-9a-f]+$#\1#p'	/\/pr-(\d+)-[0-9a-f]+$/.exec(headRef)	✅
pull_request PR number	${{ github.event.pull_request.number }} via env	context.payload.pull_request?.number	✅
Live label refetch	gh api "repos/${REPO}/pulls/${n}"	github.rest.pulls.get({…})	✅
Label test	jq -e 'any(. == $label)'	Array.includes()	✅
Error strings	unchanged	unchanged	✅

context.payload.pull_request?.number is the correct accessor for both pull_request and pull_request_target — both events carry the full PR object in the payload.

Security

Script injection prevention is correct. Both inputs.label and github.event.merge_group.head_ref flow through env: at the step level and are read as process.env.* inside the script — never interpolated directly into the script: body. This is the recommended pattern for untrusted/user-supplied values. ✅

SHA pin on line 139: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9.0.0 — matches CLAUDE.md's requirement and the version already used in pr-issue-linkage. ✅

Token: github-script defaults to github.token, which is the same credential the old GH_TOKEN: ${{ github.token }} used. Scoped to the workflow-level pull-requests: read. ✅

pull_request_target on forks: The API call only needs pull-requests: read, and on fork PRs the token is already read-only. No privilege escalation risk. ✅

Minor upside worth noting

github-script uses Octokit with its built-in retry/throttle plugins, so the live refetch is slightly more resilient to transient 5xx/429 responses than the raw gh api call was. Not a required change — just a free improvement.

One nit (non-blocking)

Line 148: the ?? "" fallback on MERGE_GROUP_HEAD_REF is defensive but harmless — the env var is always a string when set via env: (GitHub renders the missing expression as an empty string before the runner sees it). Not a problem, just belt-and-suspenders.

---

Verdict: LGTM. The fix is minimal, targeted, and leaves all existing semantics intact. The only change is the runtime surface (bundled Node via github-script instead of the runner's gh binary), which is exactly the right move for a workflow that may land on arbitrary self-hosted images.