github / github/spec-kit

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

Abierto
#4,185 2 comentarios 0 reacciones 1 asignado Reclamado por @Shaurya2k06 Ver en GitHub
bug-assess severity-high
Lenguaje dominante
Python
Estrellas
137k
Forks
12.3k
Merge medio
2 d 12 h
PR fusionados (30 d)
159

Descripción

## 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

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.