* chore(#2331): trigger PR-policy workflows on pull_request_target
Three PR-policy workflows (pr-title-validator, pr-target-validator,
require-issue-link) triggered on plain `pull_request`, so a fork PR's
GITHUB_TOKEN was downgraded to read-only regardless of the declared
`permissions:`. Each one comments on the PR and THEN emits its verdict, so the
createComment 403 killed the github-script step before core.setFailed ran: the
contributor saw an API stack trace instead of the instructions the comment
exists to deliver. Confirmed on PR #2084 (job 86573823878), whose title has
been non-compliant since 2026-07-08 while the explanatory comment 403'd on
every run.
Switches all three to pull_request_target (base-repo context, write-capable
token), matching the three siblings that already do this correctly
(pr-template-format, close-draft-prs, auto-close-unsolicited-prs). Safe: the
only checkouts are BASE-branch with persist-credentials: false, and every
PR-controlled input is read as data — no head code executes. Also wraps each
comment in try/catch so a comment failure can never again suppress the verdict.
Extends tests/workflow-maintainer-skip.test.cjs with the trigger lock already
applied to close-draft-prs.yml (:32-42) for this same defect class.
Closes#2331
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* fix(#2331): strip backticks before echoing untrusted text into bot comments
Found by the orthogonal security review of this change.
pr-title-validator and pr-target-validator echo attacker-controlled text (the PR
title; the fork's branch name) into an inline-code span in a comment posted by
github-actions[bot]. A single backtick closes the span early and the remainder
renders as live Markdown — GFM autolinks a bare URL — so a fork author could
make our own bot post an arbitrary clickable link into a PR thread, borrowing
the bot's credibility for phishing.
This interpolation is unchanged from next, but it was NOT previously reachable
from forks: the createComment call 403'd and the comment was never posted. The
trigger switch in the parent commit is what makes it reachable by untrusted
authors for the first time, using the write token it grants — so it is in scope
here and fixed here rather than deferred.
A PR title has no charset restriction, so that vector is fully exploitable. The
branch-name vector is weaker (check-ref-format forbids space, ':', '[' and '*',
so no bare URL, link or emphasis is expressible) but is the same class and is
stripped identically rather than left to the charset to police. Stripping the
backtick is complete: it is the only character that can break out of an
inline-code span. Only the rendered body needs this — core.warning/setFailed go
to the job log, where @actions/core already escapes workflow commands.
Also strengthens the try/catch test to assert core.setFailed sits AFTER the
catch block rather than merely existing, so moving the verdict inside the try
(the exact inversion #2331 fixes) fails the test.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* test(#2331): assert verdict ordering on code, not on comment prose
The first cut of the verdict-ordering guard failed against correct code. It used
indexOf('core.setFailed') on raw source, and these workflows name core.setFailed
in their own comments while explaining the bug — at lines 29/118/147, 16 and 6,
all BEFORE the catch block. So the assertion compared a comment to the call and
reported the inversion it was written to catch. gsd-test caught it: 4 unique
failures across linux-node22/24.
The code was right; the test was measuring the wrong text. Fixes:
- readWorkflowCode() strips whole-line YAML/JS comments so positional
assertions see only executable text.
- The ordering check is extracted to verdictSurvivesCommentFailure() and
exercised against BOTH a good and an inverted sample, so the guard is proven
non-vacuous rather than merely passing.
- A test pins the trap itself: raw source really does mention core.setFailed
before the catch, while the stripped view puts the real call after it.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* fix(#2331): drop the unnecessary permission widening; the trigger was the whole bug
Both orthogonal review passes flagged the permissions block, from opposite
directions — one said issues:write was dead surface on require-issue-link, the
other said it was the load-bearing scope the two validators lacked. Neither is
right, and the repo's own history settles it:
- pr-title-validator declares pull-requests:write ONLY, and its sticky comment
has posted 26 times.
- pr-target-validator declares pull-requests:write ONLY — posted 8 times.
- require-issue-link declares issues:write ONLY — posted on same-repo PRs
#106, #164, #232, #259.
So GitHub accepts EITHER scope for issues.createComment when the target is a
PR, and all three files already declared a sufficient one. The 403 was purely
the fork token downgrade. My added scopes fixed nothing and widened privilege
on precisely the workflows now running as pull_request_target — the context
where surplus scope matters most. Reverted: permissions are byte-identical to
next, and the diff is now trigger + try/catch + sanitizer only.
The permission test previously used an (issues|pull-requests) alternation, so
it passed on the pre-fix tree and would not have caught removal of the scope
that matters. It now asserts each file's SPECIFIC scope and, more usefully,
asserts the absence of the other — locking the least-privilege property against
a future 'add it to be safe' regression. It is a forward lock, not a #2331
fails-first test; the trigger assertion is the fails-first one.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* feat(#1928): remove sunset gemini cli runtime, redirect to antigravity
Google sunset Gemini CLI on 2026-06-18; Antigravity CLI is its official successor (already a first-class GSD runtime). Remove the gemini runtime from the enum (16->15), aliases, labels, config-home fragment, install path, converters (convertClaudeToGemini{Markdown,Toml,Agent}, convertSlashCommandsToGeminiMentions), capability descriptor, gemini-extension.json, RULESET.GEMINI.*, and the interactive menu (renumbered, no gap).
--gemini now prints an explicit deprecation notice citing the 2026-06-18 sunset and redirects to --antigravity (no silent alias, per the issue's Hyrum's-Law rejection). Antigravity is preserved throughout: its GEMINI.md contextFileName, .gemini/antigravity config home, the shared convertGeminiToolName/claudeToGeminiTools tool vocabulary, and the 'gemini' hookEvents dialect it declares. GEMINI.md retargeted as Antigravity's context file.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* chore(#1928): backfill changeset PR number (#1996)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* chore(#1928): drop Gemini CLI from issue templates (review nit)
Removes the sunset Gemini CLI runtime from the two GitHub issue-template
runtime lists that the removal PR missed, per @davesienkowski's review nit:
- feature_request.yml: 'Applicable runtimes' checkbox (a user could otherwise
request a feature for a runtime GSD no longer supports)
- bug_report.yml: 'Runtime' dropdown + the stale ~/.gemini/settings.json
retrieval-help line
Leaves the post-removal templates fully consistent with the Antigravity redirect.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add .claude-plugin/marketplace.json so Claude-plugin-compatible runtimes
(ZCODE et al.) discover gsd-core from a custom marketplace source. The
canonical version lives at plugins[0].version and tracks package.json via
the release version-sync.
Refactor scripts/sync-manifest-versions.cjs so VERSIONED_MANIFESTS entries
are {path, versionKey} dot-path descriptors (default 'version'); register
marketplace.json with versionKey 'plugins.0.version'. getByPath/setByPath
reject __proto__/constructor/prototype (prototype-pollution guard).
plugin.json / gemini-extension.json behavior is unchanged.
- tests/issue-1855-marketplace-manifest.test.cjs: schema + version-sync guard
- tests/issue-844-manifest-version-sync.test.cjs: updated for descriptor shape
- VERSIONING.md + auto-backmerge VERSION_STAMP_MANIFESTS: include marketplace.json
- docs/how-to/install-on-your-runtime.md: marketplace discovery how-to
auto-backmerge's needs_review safety net parked the PR whenever a code
file existed only on main. The version manifests (package.json,
package-lock.json, .claude-plugin/plugin.json, gemini-extension.json)
diverge every release by design (next runs a -dev version), so the net
misfired on every release — and that manual-review park is what let the
back-merge sit and go stale (e.g. #1379, which then conflicted with a
later #1777 purity-gate edit to fragments it had deleted).
Exclude the generated package-lock.json outright (it carries a version
per package entry, so a dep bump is indistinguishable from a release
stamp; it only mirrors package.json, still checked). For package.json /
plugin.json / gemini-extension.json, ignore a drop whose main-vs-base
diff touches only the top-level "version" field. A substantive
(non-version) straight-to-main change still parks, preserving the
safety net's real purpose.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
The required "Issue link required" check failed on automated back-merge
PRs (chore/backmerge-main-to-next-<sha>), which legitimately map to no
issue — a `Closes #N` would pollute the released CHANGELOG. When such a
PR parks for manual review (needs_review), the maintainer could only
merge via --admin.
Carve them out at the failing step's `if:` (step-level, so the required
check still reports SUCCESS rather than a branch-protection-blocking
"skipped"), keyed on the workflow-authored branch name AND same-repo
identity so a fork PR cannot forge the exemption.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
close-draft-prs.yml (on pull_request_target after #760) cannot close fork draft
PRs whose head branch name looks like a Git SHA — GitHub never dispatches
pull_request_target for such branches, and a pull_request run from a fork gets a
read-only token. So a draft PR on a SHA-named fork branch evades the auto-close.
Add close-draft-prs-sweep.yml: a schedule (every 6h) + workflow_dispatch sweep
running in base-repo context with pull-requests: write that paginates open PRs,
filters to non-OWNER/MEMBER/COLLABORATOR drafts, and closes + comments them with
the identical policy/message as the event-driven workflow. Re-fetches each
candidate before mutating (TOCTOU guard), closes before commenting so
enforcement is never gated on the explanatory comment, and core.setFailed on
partial failures. The per-PR workflow remains the fast path; this is the
safety net for the documented residual bypass.
Extends tests/workflow-maintainer-skip.test.cjs with structural guards locking
the triggers, write permission, maintainer carve-out, pagination, and message.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Bare `pull_request` hands fork PRs a read-only GITHUB_TOKEN, so the
close/comment API calls 403 and a first-time/external contributor's draft
PR survives — bypassing the auto-close for exactly the population the job
targets. Switch to `pull_request_target`, which runs in the base-repo
context with a write-capable token even for fork PRs. Safe because the job
never checks out or executes PR-supplied code; it only reads event metadata
and calls the GitHub API. The minimal `permissions: pull-requests: write`
block still constrains the token.
Add a regression guard in tests/workflow-maintainer-skip.test.cjs asserting
the workflow triggers on pull_request_target and not bare pull_request.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
