版本发布

把发布作为一条可审计流水线：工作区、远端 Git、发布平台和最终用户安装结果必须分别验收。优先复用仓库已有脚本、工作流和版本约定。

权限门

只有用户明确要求“发布新版本”或明确授权提交、推送并发布时，才执行外部变更。该授权覆盖本次发布范围内的普通提交、非强制推送、创建新标签和仓库既有发布流程；以下动作仍需单独确认：强制推送、移动或删除远端标签、覆盖或撤回已发布制品、绕过质量门或安全控制。

用户只要求检查、规划或生成发布说明时，完成只读分析后停止。

1. 建立发布契约

先读取仓库指令和发布文档，再检查：

• 仓库根、当前分支、上游、远端、分支差异、已有标签和发布记录；
• 全部已跟踪与未跟踪变更，包含暂存区；
• 版本唯一来源、锁文件、变更日志、发布脚本和 CI 工作流；
• 制品名称、发布渠道、目标 registry 或应用商店，以及当前已发布版本。

优先采用仓库明确规定的版本。未指定时，按仓库政策或 SemVer 选择能表达本次变更的最小版本；破坏性变更或版本含义不明确时请用户决定。完成标准是目标版本、发布范围、原生发布入口和成功信号均已确定。

2. 固定发布集合

逐项区分发布相关变更与用户的其他工作。能安全分离时只暂存发布路径；同一文件中存在无法可靠拆分的其他改动时，暂停并说明冲突。保留工作区原状，不通过 stash、reset、clean 或 checkout 隐藏问题。

提交前检查完整 diff 和未跟踪文件，排除凭证、私钥、令牌、真实密码、临时产物和机器专属配置。每次暂存、提交和创建标签前重新读取状态；工作区若出现新的并发变更，重新分类后再继续。

同步修改所有受约束的版本文件和锁文件。遵循仓库提交规范，精确暂存并复核 cached diff；已有正确提交时不制造空提交。完成标准是提交内容只包含发布集合，提交信息能说明真实意图。

3. 通过质量门

从仓库脚本和 CI 配置确定检查项，通常包括类型检查、测试、lint、构建、打包预览、Skill 或资源同步检查、兼容矩阵和发布前钩子。先运行最小反馈回路，修复后再运行完整发布门。

修复失败时保持原有安全级别和测试强度；不得通过跳过测试、关闭签名、放宽权限或删除断言来换取通过。完成标准是所有仓库要求的发布前检查真实通过，且最终包清单包含预期运行文件。

4. 提交并推送

提交后以非强制方式推送当前发布分支，并比较本地提交与远端目标提交。推送被拒绝时先获取远端状态，只有在工作区可安全整合且不会改写他人历史时才进行合并或 rebase；冲突需要按仓库规则解决并重新跑受影响检查。

完成标准是远端分支准确包含发布提交，且本地没有遗漏的发布相关变更。

5. 触发发布

需要选择或诊断发布机制时读取 references/release-mechanisms.md。优先使用仓库已经存在的可信发布路径，例如版本标签触发的 CI、GitHub Release 或 registry 发布脚本。

创建标签前再次核对标签版本、manifest 版本和目标提交。推送标签或启动发布后持续跟踪到终态，读取失败步骤和原始日志。发布平台已经接受某个版本后，不重复发布同一版本。

完成标准是发布平台明确成功，且日志中的制品名称、版本、来源提交与目标一致。

6. 验证公开结果

发布流水线成功不等于用户已经可用。至少验证：

• 远端分支与标签都指向预期提交；
• registry 或发布页能够查询到目标版本，稳定标签指向正确版本；
• 使用隔离临时目录或空缓存从公开渠道全新安装；
• 运行版本命令和一项低风险核心 smoke test；
• 临时验证产物已清理。

registry 正在处理时等待并轮询权威元数据，不重新上传。完成标准是全新消费者能够获得并运行目标版本。

恢复循环

异常发生后先保留可复现的命令、退出码和已脱敏日志，再判断失败属于源码、测试、版本、Git、认证、发布工作流、registry 延迟还是制品运行。实施最小范围修复，重新运行最近的失败门，然后从受影响层向后复验。

同一错误连续三次没有新增证据，或继续处理需要交互式登录、账户权限、额外秘密、远端历史改写或扩大发布范围时，停止并向用户说明唯一阻塞项。外部系统短暂延迟不算失败，保持轮询直到成功或出现明确错误。

成功回复

每次成功发布后给出简洁的新版本发布说明，不把本地检查冒充远端或公开验收：

## <制品名> <版本>

更新内容
- <用户可感知的变化>

升级方法
```shell
<用户实际执行的升级命令>
```

发布结果
- 提交：<commit>
- 标签：<tag>
- 渠道：<registry 或发布页链接>
- 验证：<公开安装与 smoke test 结果>

没有对应项时省略，不用占位文字。发布失败时提供阻塞证据和恢复入口，不输出成功版发布说明。