发布就绪验证

解决什么问题

发布单上写着“测试已过”，但没人能立刻回答：这次上线覆盖了哪些用户可见变化、依赖和迁移是否会影响旧数据、日志与告警能不能在出事时告诉你。团队往往在评审会上临时拼信息，blocker 和“可以接受的残余风险”混在一起，最后要么带着未知风险上线，要么为了小问题无限推迟。

这个技能把发布前的核查收敛成一次结构化检查，便于工程师在合并、审批或上线窗口前快速对齐事实。

核心能力与关键步骤

1. 明确范围与用户可见变化
先确认本次发布包含哪些变更，尤其是面向用户的行为变化、配置项、功能开关和默认值调整。范围不清时，后续的风险判断没有基准。

2. 审查交付证据

• 测试覆盖与最近一次完整验证结果
• 数据库迁移、回滚脚本和兼容性说明
• 配置、环境变量、依赖版本与升级路径
• 向后兼容策略：API、数据格式、旧客户端行为

3. 检查可观测性
确认日志字段足够定位问题，核心指标有基线，告警阈值能触发，仪表盘能展示关键成功信号。缺观测能力的发布，等于上线后才开始排障。

4. 准备回滚与缓解措施
列出可执行的回滚步骤、降级方案或开关策略，并确认这些手段在压力场景下真的可用。

5. 分离阻断项与残余风险
把必须修复的问题单独列出，允许已知且接受的风险单独记录，避免两者混淆。

输出格式

技能会返回：Ready（yes / no / conditional）、Blockers、Risks、Verification，分别说明是否可发布、必须修复项、已知残余风险，以及哪些已验证、哪些仍未验证。

适用边界

• 它替代不了领域判断：业务风险、合规要求、灰度策略仍需发布负责人决定。
• 结论取决于输入材料的完整性；如果缺少迁移脚本或监控信息，输出会反映为未验证项。
• 它适合发布门禁、上线前 checklist 和发布评审记录，不负责执行迁移或自动回滚。