github / github/spec-kit

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

Đang mở
#4,185 2 bình luận 0 reaction 1 người được giao Được @Shaurya2k06 nhận Xem trên GitHub
bug-assess severity-high
Ngôn ngữ chính
Python
Star
137k
Fork
12.3k
Merge trung bình
2 ngày 12 giờ
Pull request đã merge (30 ngày)
159

Mô tả

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

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Đánh giá

Issue này chưa được đánh giá.

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.