github / github/spec-kit

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

Ouverte
#4,185 2 commentaires 0 réactions 1 personne assignée Réclamée par @Shaurya2k06 Voir sur GitHub
bug-assess severity-high
Langage dominant
Python
Étoiles
137k
Forks
12.3k
Merge moyen
2 j 12 h
PR mergées (30 j)
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

Guide de contribution

Ouvrir le guide de contribution

Évaluation

Cette issue n'a pas encore été évaluée.

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.