发版靠清单，不靠感觉

发版由一组互相独立的动作组成，漏掉一步不会报错。防止“看起来发完了”其实少了一块

一句话规则

发布产物逐项打勾验证，清单固化进 skill

发生了什么

一次客户端发版：安装包传了，云端也部署了，唯独漏传了 CDN 主源。客户端的自动更新走的是 CDN，于是用户一直卡在旧版本，升不上来。

发版不是一个动作，而是一组互相独立的动作：每个平台的安装包、CDN、云端部署、公告。哪一步漏掉都不会报错，只会安静地少一块。

看得见的部分成功了，release 页面有了，部署是绿的，就会给人“发完了”的错觉。而自动更新这条路径，开发者自己几乎从来不走，我们都是直接装新包。

凭感觉发版，漏掉的总是最不显眼的那一步。agent 也一样，它只做它知道的步骤，做完就报告“已发布”。

把清单写下来，每一项都带验证方法：

## 发版清单 vX.Y.Z
- [ ] 每个平台的安装包都已上传，下载链接返回 200
- [ ] CDN 主源已更新，更新清单里的版本号是 X.Y.Z
- [ ] 云端服务已部署，健康检查返回新版本号
- [ ] 公告已发
- [ ] 找一台装着旧版本的机器，走通一次自动更新

验证尽量是命令：curl -sI <下载地址> 看状态码，curl -s <更新清单地址> 看版本号。

把清单固化进 skill，放在 .claude/skills/release/SKILL.md，正文写步骤和每一项的验证命令。发版有副作用，设成只能手动 /release 触发：

---
name: release
description: 按发版清单逐项发布并验证。任何一项没有验证通过，不得报告“已发布”
disable-model-invocation: true
---

最后一项永远站在用户这边验证：不是“我上传了”，而是“装着旧版本的用户真的升上来了”。

gstack 的 /ship、/land-and-deploy 能覆盖合并、版本号、部署这些通用步骤，但你的产品特有的去处（比如 CDN 主源），只有你自己的清单知道。