从 alpha.3 迁移到 alpha.4 开发目标

本页是英文原文的简体中文说明。带标签版本中的英文规范、JSON Schema、测试夹具和 TCK 共同构成规范性依据；中文页面只用于任务路由和人工审查。

• 最新发布版本：v0.1.0-alpha.3。
• 开发目标：0.1.0-alpha.4。
• 生产就绪：否。
• 默认传输模式：旧传输。

0.1.0-alpha.4 是尚未发布的开发目标，不是发布版本。

目前还不存在不可变的 v0.1.0-alpha.4 发布标签。使用方不得把 alpha.4 当作已发布版本进行固定、下载或声明一致性。开发工作可以验证候选快照，但证据必须标明确切的源码提交或候选摘要，并且不得表述为发布一致性。

正在开发的契约变化

alpha.4 目标保留 alpha.3 的核心身份，同时增加必须显式协商的契约面：

• 与提供方无关的接入拓扑快照和类型化观测；
• 一个复用现有会话、位置、摘要、重放、数据丢失和持久确认语义的 CloudLink 接入扩展；
• 独立激活的受治理控制扩展，其首个封闭动作是 device.power.set.v1；
• 针对默认关闭认证提案的更严格挑战、心跳、重放、命名空间分区、到期和确认恢复规则。

alpha.3 使用方应当拒绝新的 alpha.4 接入消息种类。CloudLink 基础协议协商不会激活任何一个扩展。提供方凭据仍然留在边缘侧；提供方接受请求不等于物理完成；受治理控制扩展仍然默认关闭。

云端先行发布顺序

1. 让所有已经投入使用的产品继续固定到确切的 v0.1.0-alpha.3 使用方锁，并保持旧传输启用。
2. 先在 AetherCloud 中加入 alpha.4 候选消息的解码和拒绝测试，不要启用 AetherEdge 的新消息发布。
3. 运行语言无关 TCK，以及产品自己负责的持久化、重启、重复消息、过期代次、重命名、删除、超时和故障证据。
4. 向 AetherEdge 加入完全相同的候选制品全集，接入扩展和受治理控制扩展仍保持默认关闭。
5. 只有在云端接受确切扩展配置，并且重连或重放证据通过后，才启用只读接入。
6. 在云端报价密钥配置、轮换、吊销，边缘验证器归属，持久重放绑定，策略、确认、审计和端到端提供方错误证据齐备之前，继续关闭受治理控制。
7. 只有 v0.1.0-alpha.4 标签、发布清单和制品包摘要真正发布后，才能用不可变发布版本替换候选固定项。

仓库测试夹具通过并不能满足产品自己负责的消息代理、数据库、重启或物理设备证据。修改任何兼容性声明前，必须把这些结果绑定到确切的产品提交。

回滚

首先停用接入扩展和受治理控制扩展。停止发布新的扩展消息，保留旧传输路径，并排空或隔离扩展专用的待处理工作；存在未声明缺口时，不得推进持久确认位置。

不得把 alpha.4 扩展载荷重新解释为 alpha.3 核心消息，也不得重写不可变的 alpha.3 发布字节。如果产品必须回到已发布基线，应恢复确切的 v0.1.0-alpha.3 使用方锁，并离线验证完整的导入制品集合。

回滚不能授权删除尚未解决的缓冲位置、接受变化后的重放摘要、绕过到期检查，或者把提供方接受请求表述为物理完成。

发布前所需证据

• 真实存在的 v0.1.0-alpha.4 带注释标签和不可变发布包；
• 相互一致的英文规范、JSON Schema、测试夹具、TCK、语言绑定、清单和哈希证据；
• 绑定到确切产品提交的 AetherEdge 与 AetherCloud 使用方锁；
• 云端先行的解码和拒绝证据；
• 重连、重启、重复消息、冲突、数据丢失、重命名、删除、过期代次、提供方错误、超时和延迟状态证据；
• 能够保留旧行为以及边缘侧物理控制最终决定权的回滚证据。

修改状态前，请阅读兼容性与发布门槛和 一致性与使用方验证。机器可读的产品证据矩阵位于 AetherContracts 仓库的 compatibility/product-matrix.json。