用途：把已合并的变更从集成分支安全推进到生产，避免例行发布引发故障、配置被静默回滚或密钥被孤立。核心原则是：正确的 diff、正确的顺序、走项目自动化、生产由人工审批。
主要能力与流程：
- 发现流程：不硬编码，先读仓库，确认集成分支名、发布机制（Makefile 的 promote 目标或 .github/workflows/）、部署触发方式、仓库层级与顺序、配置模型（配置与镜像是否分离）。
- 漂移检查：不要信 GitHub 比较视图的三点 diff，它会把 squash-merge 或发布气泡提交误报为 diverged。用两点 diff 判断真实内容差异：git fetch --all；git diff <integration>..main；git diff <integration>..main --stat；并用 git rev-parse <integration>^{tree} main^{tree} 比较 tree SHA。若两点 diff 为空即内容相等，无需发布；若 main 有集成分支没有的热修复，先合并 main → integration。
- 跨层顺序：infra → platform → app，每层完全部署后再进行下一层。每个仓库内开 PR 或跑 promote 目标，需非作者审批，再走受门控的部署，绝不直接推 main。
- 走项目自动化：使用团队封装的包装器，不手工跑原始基础设施命令；配置先应用再部署；YAML 缩进敏感，应用后要回读探测实际生效值。
- 发布后对账：把 main 合并回集成分支，把发布气泡视为空操作，确认两点 diff 为空后推送。
限制与禁止事项：不得强制删除无恢复窗口的密钥、绕过软删除窗口、直接改云配置值而不走 IaC、从未合并分支应用基础设施变更、对解耦配置项目无审批门控地部署配置、销毁或缩容到零、非交互式强制覆盖 CI 密钥、授予提权自举权限后不回收、以 JSON 包装方式写入应用需要的原始密钥值。
适用场景：多仓库或多层服务的生产发布、需要人工审批门控的部署流程。资料未提供具体安装命令、收费或平台信息。