release-workflow

Skills Collection 发布工作流

使用不可变的源身份和已观察到的验证事实，运行所请求的发布阶段。本地候选版本、远程 CI、已安装的源代码、发布结果和最终证明是彼此独立的结果。

范围与授权

确定仓库、目标版本、请求的阶段和当前基线。审计现有标签时使用历史模式；新版本发布时使用当前模式。仅请求全新安装并不授权创建标签或发布。

在请求任何缺失的发布授权之前，先准备并审查本地候选版本。首次进行远程写入前，明确列出确切的候选版本、标签、软件包数量和操作。在该范围内重复使用已明确授予的授权；目标变更时必须重新征求决定。切勿推送、创建标签、发布、全局安装或更改 Host 配置，除非这些操作属于获授权的任务。

构件与文档状态

• Manifest 冻结准备时的范围、源身份和本地证据。
• 发布说明和公开快照页面描述此版本的内容，但不冻结“另一个版本当前处于稳定状态”或“此版本尚未发布”之类的声明。
• 回执在发布后首次于 main 上创建，并记录已观察到的事实。不要预填回执，也不要将其放入候选版本或标签中。

请阅读 DOCUMENT-STATE.md，了解当前稳定版本的权威来源、双语页面、快照和 Release 正文语义、观察输入以及历史兼容性。文件存在且链接文本匹配，并不能证明版本或发布状态正确。

执行所选阶段

PREPARED → CI_VERIFIED → TAGGED → INSTALL_VERIFIED → PUBLISHED → ATTESTED

请阅读 RELEASE-STAGES.md 了解阶段流程，并阅读 VERIFICATION.md 了解如何从实际发布的源代码安装。在每个相关的固定树和阶段上运行通用完整性检查。记录的 CI 必须对应确切的 commit，且已完成并成功。标签保护、带注释的对象及其 peel 身份，以及完整的安装清单仍是必需项。

使用语义感知渲染器准备 Release 正文，然后检查实际发布的正文和导航。只有已观察到的安装和发布证据才能支持成功声明。本地外部事实替代项必须显式使用 --simulate，并始终标记为 SIMULATED_PASS，绝不可标记为生产环境 PASS。

收尾

按照 CLOSEOUT.md 执行：每个阶段完成一次完整一致的修复，验证最终暂存的 Git 树及其干净导出，并要求获授权发布所需的候选版本和 final-main 的 CI 均精确匹配。候选版本和回执必须是不同的 commit。保留失败的尝试和不可变历史记录。

最终 main CI 的观察结果应留在其自身回执之外；不要创建自我引用的 commit 循环。报告候选版本和最终身份、实际检查、安装和发布结果以及尚未解决的关卡。仅有已发布的 Release 或成功推送，并不代表任务已完成。