剩余发布工作与拟议推广¶

状态：实现与本地验证；未使用部署授权。

有序发布操作¶

1. 审查本地变更/PR 和 CI 结果。记录用于部署和回滚的不可变已合并提交和镜像。所有 director 必须在启用 correction 之前运行已审查的空闲 worker；在 correction 保持禁用期间，验证混合版本部署行为。
2. 发布 relay 镜像，并部署 director，同时禁用 correction cohort0 和 durable rehome。验证镜像、健康状态、预览路由、迁移 schema、池压力和清理。这需要已授权的部署工作流。
3. 使用现有 cell 工作流滚动支持 cell 镜像；验证 protocol3、正确的 incarnation 和遥测。按正常方式发布更新后的桌面端。手机协议保持不变；correction 不需要移动更新。
4. 使用物理手机验证打包的桌面端（前台、实际后台挂起、恢复、静默连接和目标失败），并验证现有客户端对新 cell 的行为。在 CI 中对 Linux/Windows 运行相同的传输门；验证实际由 SSH 拥有的终端能够在客户端断开连接和正常重连后存活。
5. 读取经过身份验证的聚合预览。按方向估算合格群体；使用匹配的未变更对照 cohort。在更改设置或启用之前，选择初始 cohort 并记录审批。
6. 通过现有 director 工作流输入配置已批准的 cohort，并在部署期间保持 durable 控制禁用。验证服务修订版本和带标签的回滚修订版本，然后通过现有 regional-rehome 控制工作流启用。
7. 发生回归时停止新的 claims，同时普通迁移清理和恢复继续。调查现有工作，而不是强制基于计时器的源关闭。

拟议数值验收标准（启用前必须批准）¶

这些是推广提案，不是生产基线或授权的测量。

• 第一阶段：1% 确定性主机 cohort；全局上限仍为8个开放迁移。观察至少24小时和30次已完成迁移。如果流量无法提供30次，则延长观察；不要将小样本视为成功。
• 立即停止：任何优化导致的已建立客户端关闭、在源权限不明确时重新开放准入、重复变更、授权绕过，或允许超过8个优化迁移（现有工作也会消耗上限）。
• 可靠性停止：与未变更 cohort 在匹配的15分钟窗口相比，分配/连接失败率上升>=1个百分点或2倍（要求每个比较组>=100次尝试）；对低计数失败逐一调查。现有生产事故限制始终优先。
• 性能验收：匹配的迁移后分配 cell 对照 RTT 每主机中位数改善>=25ms 且>=20%，至少80%可评估迁移主机满足；要求迁移前后两个独立样本。使用分配 epoch/cell 身份识别样本。将样本不足记录为不可评估。
• 客户端连接建立 p95 在考虑未变更 cohort 后，相对于其匹配基线不得回退>10%。建立不是应用命令延迟；在验证运行中单独记录物理手机交互计时。
• 扩展需要健康的注册/完成、稳定的预留使用、没有增长的卡住恢复积压，以及上述数值标准。持续连接的客户端可以无限期推迟优化。

证据边界¶

本地测试使用真实 socket 流量和独立主机执行，但使用合成时钟/身份验证。构建和 schema 夹具都不能证明分发、生产延迟、物理手机或签名桌面端升级。单独的 Docker SSH 测试验证 SSH 提供商恢复；它们不是物理手机到 SSH 切换的证据。检查表有意将这些发布门保持开放。