用途
deployment-automation 是发布执行（release-execution）的锚点技能，适用于系统已经可构建、可打包或可运行测试之后的“安全发布执行”任务。它不负责让机器可运行，也不负责平台百科式讲解，而是围绕发布决策产出可执行的发布包（Release Packet）。
典型适用场景包括：预览或分支部署已存在，但没人明确它应在合并前证明什么；发布机制已能跑通，但暂存/生产晋升仍依赖口口相传的经验；核心决策是发布策略、发布门禁、验证深度或回滚准备；部署失败后需要遏制、回滚和安全恢复，而非大范围平台重构；在采用平台专属操作技能前，团队需要一个厂商中立的发布包；需要用预检、签核逻辑和明确停止条件加固现有部署路径。
不适用场景（应路由到相邻技能）：安装 Docker、kubectl、云 CLI、认证引导或让机器可运行 → system-environment-setup；仪表盘、告警、追踪或长期遥测架构 → monitoring-observability；Vercel 专属链接、域名、别名、环境变量或 claim URL → vercel-deploy；系统尚不能构建、打包或运行测试 → 先修复构建/环境问题；密钥轮换、IAM 策略、签名或合规架构 → 相关安全技能。
主要能力
该技能覆盖六种发布模式，每次运行只选择一种主模式：
- preview-release — 合并或晋升前的可共享验证发布。
- environment-promotion — 暂存 → 生产或多环境晋升，带有门禁与签核。
- container-paas-rollout — 托管应用/容器平台的发布规划。
- kubernetes-rollout — 滚动控制器行为、停止条件与回滚路径。
- rollback-response — 坏发布的遏制与恢复。
- release-hardening — 为现有流程补充缺失的预检、审批或验证。
发布策略选择覆盖：replace、rolling、blue-green、canary、progressive、feature-flag-assisted，并可结合 references/strategy-selection-and-stop-conditions.md 进行取舍。
输出始终为发布包，包含：模式、运行时/提供商、制品、环境、晋升模型、发布策略、前置条件（现有部署路径、所需认证/配置、已知阻塞/迁移）、步骤、验证（健康检查、冒烟检查、人工/自动签核、停止条件）、回滚/恢复（立即回滚路径、回滚不能撤销的内容）以及交接（相邻技能或提供商专属后续）。
使用方式
该技能按以下步骤执行：
Step 1：冻结发布画像。规范化请求，确定 release_profile：mode、runtime_shape（static-frontend、web-app、api-service、worker-job、multi-service、unknown）、artifact_shape（platform-build、image、build-output、package、unknown）、target_environment（preview、staging、production、mixed、unknown）、promotion_model（same-artifact-promotion、rebuild-per-env、direct-deploy、unknown）、rollout_strategy、stateful_risk、verification_depth。每次运行只选择一个主模式。
Step 2：收集最小真实证据集。不要凭空编造发布流程，至少确认：实际交付的制品是什么、当前范围是哪个环境、是同一制品跨环境晋升还是按环境重建、当前部署命令/提供商操作/控制器是什么、已存在哪些健康检查/冒烟检查/签核信号、真实回滚方法是什么、是否存在使回滚不对称的 schema/数据变更。任何未知项需明确说明，并默认采用最小安全解释。
Step 3：尽早执行边界路由。在生成发布包之前，若请求实际涉及环境搭建、监控可观测性、Vercel 专属机制或安全合规，应路由到对应技能。
Step 4：加载匹配的支持包，而非扩展前门。按模式使用 references/release-packet-templates.md 中对应的发布包模板；选择策略时参考 references/strategy-selection-and-stop-conditions.md；最终确定前使用 references/rollout-and-rollback-checklist.md 作为最低发布安全清单。
Step 5：应用发布执行规则：构建与发布分离；部署与流量暴露分离；应用回滚与数据回滚分离；选择匹配团队验证成熟度的最小发布策略；在可复现性重要时优先同一制品晋升；验证是强制项，健康检查加一条核心流程是最低可接受完成线；停止条件优先于乐观，明确什么应暂停晋升或触发回滚。
Step 6：产出发布包，而非 DevOps 讲座。按固定格式输出。
Step 7：优先加固而非增加包装层。若“部署很乱”，应分类发布模式、指明当前事实源、添加预检/验证/回滚结构，并将平台细节路由到正确相邻技能；不要发明新的通用部署包装层或把 CI 编写吸收进该技能。
使用前需阅读的支持文档：references/deployment-modes-and-boundaries.md、references/release-packet-templates.md、references/strategy-selection-and-stop-conditions.md、references/rollout-and-rollback-checklist.md、references/platform-routing-notes.md。
适用场景
- 每个 PR 都有预览 URL，但评审者仍批准了坏流程，需要明确合并前部署流程应要求什么。
- 自动部署到暂存，但生产晋升仍是手动 Slack 仪式，需要最安全的发布包。
- 最新发布在生产中超时且包含迁移，需要最安全的回滚计划。
- 发布策略、发布门禁、验证深度或回滚准备成为主要决策。
- 部署失败后需要遏制、回滚和安全恢复。
- 需要厂商中立的发布包，然后再使用平台专属操作技能。
- 需要用预检检查、签核逻辑和明确停止条件加固现有部署路径。
限制
该技能不负责安装 Docker、kubectl、云 CLI 或认证引导（应走 system-environment-setup）；不负责仪表盘、告警、追踪或长期遥测架构（应走 monitoring-observability）；不负责 Vercel 专属链接、域名、别名、环境变量或 claim URL（应走 vercel-deploy）；若系统尚不能构建、打包或运行测试，应先修复构建/环境问题；不负责密钥轮换、IAM 策略、签名或合规架构（应路由到相关安全技能）。该技能的输出是发布包与路由建议，不是平台百科，也不吸收 CI 编写。