发布日执行指挥：在硬性前置条件满足后生成带责任人的小时级…

当你需要在发布当天把发布计划变成一系列不可逆动作，并逐项验证、监控、裁决与收尾时使用。

适用场景

解决思路

1. 验证硬性前置条件：读取当前冻结的 manifest，要求 (a) 存在 SHIP 裁决且其审计的 manifest_hash 与之匹配，(b) 存在权威发布日期与阶段；若缺失任一、裁决为 FIX/BLOCK、或哈希不匹配，则以 NEEDS_INPUT 停止。SHIP 仅证明通过门槛，不代表已获授权或动作已发生，并应用 Launch Action Control。
2. 汇总当天输入：收集渠道计划与责任人名单（用户提供），以及来自 launch-tier-planner 风险登记表的 kill criteria / 回滚阈值。每个观察窗阈值必须预先声明；若没有存档，必须在首次不可逆推送前明确并记录，绝不在发布当天临时编造阈值。
3. 生成带日期的小时级 runbook，列包括：action ID、时间块、确切动作/目标、manifest/payload 哈希、责任人、是否不可逆、观察窗、kill criterion、数据源、receipt 状态/引用。为发布/部署、解禁、商店上线、公告广播分别分配独立 action ID；合并行不能共用一个 receipt。渠道机制仍归 community-launch-runner 负责。
4. 逐项授权、执行并单独留证：在外部变更前，形成确切动作意图并获取针对该操作的授权；尝试后，采集提供方/URL 证据并记录 succeeded | partial | failed | unknown；runbook 行、dry run、SHIP 裁决或 proposal 都不算 receipt。随后运行固定观察窗，并依据预先声明的标准记录 CONTINUE 或 ROLLBACK。
5. 将事件分级为 P0-P3 并运行对应 playbook：P0 回滚是一个新的不可逆动作，需有自己的意图与 receipt；绝不把原始推送改写成仿佛未发生。P1 在时间块内修复或升级；P2 转交渠道负责人；P3 进入次日队列。每个事件、receipt 和裁决都要有带日期的日志行。
6. 在 T-0 热路径上提交 registry 状态行：在观察窗内，将带日期的提交/状态行（渠道上线、解禁、回滚已执行、观察到阶段变化）作为经授权的 operation: propose 请求，通过 registry-events.py 提交到 memory/events/launches.ndjson，遵循 state-model.md 中 T-0 按偏移排序的 proposal 解析条款。由 launch-registry 解析每个 proposal；本技能绝不执行 canonical 变更。
7. 执行晚间收尾与 lane join：对当前 manifest 要求的每个动作，匹配一个终态 receipt。缺失或 partial | unknown 的 receipt 会使该 lane 及整体 join 保持 OPEN，即使 URL 看似已上线或后续 dashboard 有流量。单独快照 D0 数字，排队未完成工作，并在不把 receipt 转为 registry 真相的前提下完成 proposals 批次。
8. 交接持续观察窗：将 D0 快照作为基线传给 launch-monitor，并把未完成的观察项与事件日志附在交接摘要中。

适用边界 · 注意事项

• 不适用于创建发布当天的内容或数据：渠道提交文案与平台规则处理应使用 community-launch-runner；媒体 pitch 与记者回复应使用 press-media-relations；遥测本身来自 launch-monitor 与自有分析，本技能只消费读数并裁决，绝不构建埋点。
• 不适用于计算 RAMP profile 结果或运行 RAMP 否决项——launch-readiness-auditor 已在上游完成。
• 绝不写入 canonical registry 文件——launch-registry 是唯一写入者；本技能只能通过经授权的 operation: propose 请求向 registry-events.py 提交 proposal 事件到 memory/events/launches.ndjson。