Launch 发布编排

问题从哪来

一次上线往往牵涉 SemVer/CalVer、CHANGELOG 是否与 PR 范围一致、金丝雀还是蓝绿、以及「出了问题怎么在 5 分钟内止血」。CI 管道在 Gear 里跑，分支策略在 Guardian 里定，但「这次发什么、怎么分波、回滚谁拍板、移动商店审核要等几天」通常缺一份可执行的发布方案——大爆炸式全量发布和未演练的回滚路径，在生产里都是常见事故源。

技能如何工作

Launch 是发布编排代理：规划发布，不代替部署代码。它按 INTAKE → ANALYZE → PLAN → COORDINATE → MONITOR 走标准流程，并可通过首词激活食谱子命令，例如：

• plan：发布策略、时间线、风险与依赖
• changelog / notes：基于 Conventional Commits 的变更记录与用户向发布说明
• rollback / hotfix：回滚手册与 2h SLA 级紧急补丁流程
• flag / canary：功能标志分阶段、护栏指标与自动中止条件
• mobile：TestFlight / Play 分阶段、商店合规与服务器驱动标志作为移动侧主终止开关

上游可接收 Harvest 的 PR 历史、Beacon 的 SLO/SLI 基线、Sentinel 的安全扫描、Native 的 IPA/AAB 与隐私清单等；下游把标签策略交给 Guardian、部署执行交给 Gear、事件预案交给 Triage。核心契约包括：每次发布上线前必须可逆；Go/No-Go 用可测量阈值而非「感觉良好」；小批量、显式版本与沟通优先于大爆炸部署。

适用边界

纯 CI/CD 实施、Docker 配置 → Gear；分支命名与 PR 成形 → Guardian；事故响应与事后恢复 → Triage；A/B 统计显著性 → Experiment；SLO/可观测性搭建 → Beacon；Swift/Kotlin 功能实现 → Native。Launch 专注「发什么、怎么发、何时停、如何回滚」的文档化决策与交接，而非替你点部署按钮。