github / github/spec-kit

Community catalog workflows: make tag-pinned download_url a MUST and reject `releases/latest/`

Open
#4,185 2 comments 0 reactions 1 assignee Claimed by @Shaurya2k06 View on GitHub
bug-assess severity-high
Dominant language
Python
Stars
137k
Forks
12.3k
Avg merge
2d 12h
Merged PRs (30d)
159

Description

## 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 `` (`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_url`s 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

1. Change "should follow the pattern" → **MUST** for the tag-pinned `download_url` requirement in all three workflows.
2. Add an explicit rejection rule: a `download_url` whose path contains `releases/latest/` **fails validation**, even if it returns HTTP 200.
3. Strengthen the release check to verify the URL's `` segment matches the submitted `v` (not just that *a* release exists and *a* URL 200s).

## Accepted URL patterns (unchanged)

- `https://github.com///archive/refs/tags/v.zip`
- `https://github.com///releases/download//.zip`

## Context

- PR #4183

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.