Problem
The community-catalog agentic workflows only softly require a version-pinned download_url. Step 2d currently says the URL "should follow the pattern" — advisory language an autonomous run can rationalize around.
This surfaced in PR #4183 (update speckit-superpowers-bridge to v1.2.0), where the run switched the URL to a floating "latest" alias and validation passed it:
- .../releases/download/v1.1.0/speckit-superpowers-bridge-v1.1.0.zip (tag-pinned)
+ .../releases/latest/download/speckit-superpowers-bridge.zip (floating "latest")
…/releases/latest/download/… is neither of the two accepted tag-pinned patterns. It resolves to whatever the newest release happens to be, not to the <tag> (v1.2.0) recorded in the entry — so the catalog would keep serving the author's future releases under the pinned "version": "1.2.0" record. That's an integrity/reproducibility hole and breaks the convention (all existing catalog download_urls are tag-pinned; none use releases/latest).
The run passed validation because the checks only confirmed the URL returns HTTP 200 and that a v1.2.0 release exists — neither verifies the URL is pinned to the v1.2.0 tag.
Affected workflows
Same soft wording appears in all three community-catalog workflows:
.github/workflows/add-community-extension.md:110
.github/workflows/add-community-bundle.md:123
.github/workflows/add-community-preset.md:164
Proposed changes
- Change "should follow the pattern" → MUST for the tag-pinned
download_url requirement in all three workflows.
- Add an explicit rejection rule: a
download_url whose path contains releases/latest/ fails validation, even if it returns HTTP 200.
- Strengthen the release check to verify the URL's
<tag> segment matches the submitted v<version> (not just that a release exists and a URL 200s).
Accepted URL patterns (unchanged)
https://github.com/<owner>/<repo>/archive/refs/tags/v<version>.zip
https://github.com/<owner>/<repo>/releases/download/<tag>/<asset>.zip
Context
Problem
The community-catalog agentic workflows only softly require a version-pinned
download_url. Step 2d currently says the URL "should follow the pattern" — advisory language an autonomous run can rationalize around.This surfaced in PR #4183 (update
speckit-superpowers-bridgeto v1.2.0), where the run switched the URL to a floating "latest" alias and validation passed it:…/releases/latest/download/…is neither of the two accepted tag-pinned patterns. It resolves to whatever the newest release happens to be, not to the<tag>(v1.2.0) recorded in the entry — so the catalog would keep serving the author's future releases under the pinned"version": "1.2.0"record. That's an integrity/reproducibility hole and breaks the convention (all existing catalogdownload_urls are tag-pinned; none usereleases/latest).The run passed validation because the checks only confirmed the URL returns HTTP 200 and that a v1.2.0 release exists — neither verifies the URL is pinned to the
v1.2.0tag.Affected workflows
Same soft wording appears in all three community-catalog workflows:
.github/workflows/add-community-extension.md:110.github/workflows/add-community-bundle.md:123.github/workflows/add-community-preset.md:164Proposed changes
download_urlrequirement in all three workflows.download_urlwhose path containsreleases/latest/fails validation, even if it returns HTTP 200.<tag>segment matches the submittedv<version>(not just that a release exists and a URL 200s).Accepted URL patterns (unchanged)
https://github.com/<owner>/<repo>/archive/refs/tags/v<version>.ziphttps://github.com/<owner>/<repo>/releases/download/<tag>/<asset>.zipContext