github / github/spec-kit

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

未关闭
#4,185 2 条评论 0 个 reaction 已指派 1 人 已被 @Shaurya2k06 认领 在 GitHub 查看
bug-assess severity-high
主要语言
Python
星标
137k
派生
12.3k
平均合并
2 天 12 小时
30 天内合并 PR
159

描述

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

贡献指南

打开贡献指南

评估

这个 Issue 还没有评估数据。

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。