发布 Checklist

本 skill 用于版本发布前的系统化检查，确保发布内容、回滚方案和验证计划就绪。可独立使用。

发布候选检查与发布完成检查是两个不同的事实边界：候选阶段运行 check-release --version X.Y.Z --require-changelog --lineage-mode candidate，此时 tag 可以尚未创建；发布 commit、tag 和 push 完成后，运行 check-release --version X.Y.Z --require-changelog --lineage-mode released --release-commit <commit>，本地 tag 缺失、tag 指错 commit、remote tag 缺失或不一致均 fail-closed。不得以候选态 PASS 代替发布完成态 lineage 证据。

0.66.0 起还必须验证 declarative release manifest。FEAT/candidate commit 中保持 lifecycle_state: candidate；发布 commit 才可追加唯一 candidate_to_released event 并改为 released。该 commit 必须只有一个 parent，且 parent 是 Git 派生的 candidate commit。release-ledger 的 UNKNOWN 或 BLOCKED 不是通过。Historical backfill 只提供历史信任，不得据此回补 tag；历史 tag 变更必须有独立 DEC。

触发条件

• 版本发布前，需要确认发布就绪状态
• 功能已通过测试（G7 通过），准备进入发布流程
• 用户要求对当前版本做发布前检查

输入

执行步骤

第一步：发布范围确认

第二步：变更日志检查

第三步：回滚方案验证

参考 Amazon 可逆性分类：

• 可逆发布（灰度/回滚容易）：快速推进，回滚方案简化
• 不可逆发布（数据迁移/Schema 变更）：深度论证回滚方案，必须有验证记录

第三步补充：Ledger 与 Projection 验证

第四步：发布后验证计划

第五步：数据验证计划（A/B 测试与指标对比）

参考 字节跳动数据驱动——每次发布必须有可衡量的影响评估，不接受"看起来不错"。

无数据时的替代判定标准（功能无法 A/B 测试时）：

• 基础设施变更（CI 配置/监控/部署脚本）→ 用"部署后 CI 稳定运行 N 次"替代指标对比
• 安全修复 → 用"漏洞扫描清零"替代指标对比
• 内部工具/文档变更 → 用"目标用户（开发者/新成员）能否在 X 分钟内完成目标操作"替代
• 无可量化用户指标的小项目 → 用"核心功能冒烟测试通过 + 无新 bug 报告 48 小时"替代
• 替代标准底线：至少要有一个可验证的成功定义——"无数据"不是不做验证的借口

第六步：发布决策

输出

质量标准

• 发布范围明确，有版本号和变更清单
• 变更日志覆盖所有变更，破坏性变更已高亮
• 回滚方案有具体步骤且已验证
• 发布后验证清单存在且包含核心功能验证项
• 数据验证计划已定义（核心指标基线+成功标准+回滚触发条件；无数据时有替代标准）
• 发布决策有明确理由
• Declarative ledger 与 projection 检查通过；四态结果未被降级包装

独立使用说明

本 skill 可脱离完整生命周期独立使用。

如果项目已初始化 governance（.governance/ 存在）

1. 先执行目标锚定检查（读 plan-tracker → 确认成功标准 → 偏离检查）
2. 不需要先通过任何 Gate
3. 可用于任何版本发布前的检查（不限于正式发布阶段）
4. 热修复/紧急发布也可使用本 checklist，但可跳过非必要检查项并记录跳过原因
5. 如果后续接入完整工作流，本 skill 的产出自动成为 G9（发布就绪）的证据

如果项目未初始化 governance（.governance/ 不存在）

1. 跳过所有治理前置检查
2. 直接执行本 skill 的核心流程（发布前 checklist + 回滚方案验证 + 发布决策）
3. 执行完毕后提醒用户："当前项目未初始化 governance。如需自动证据记录、Gate 检查、风险跟踪，运行 /governance-init。"

子工作流映射