一致性与使用方验证

本页是面向中文用户的说明。带标签版本中的英文规范、JSON Schema、测试夹具和 TCK 才是规范性依据。

AetherContracts 将四类证据分开，避免把结构接纳、上下文行为、语言接口与产品集成混为一谈。最新发布版本是 v0.1.0-alpha.3；当前 0.1.0-alpha.4 源码只是尚未发布的开发目标，不构成生产一致性声明。

证据层次

1. 规范：具有规范效力的英文语义和生命周期规则。
2. 结构定义：封闭的 JSON Schema Draft 2020-12 结构接纳规则。
3. 测试夹具与 TCK：有效、无效、迁移和上下文结果，以及稳定的公开失败类别。
4. 使用方证据：产品自己的传输、持久化、重启、认证与故障行为。

前三层属于 AetherContracts，第四层属于每个使用方。产品不能修改本地线协议文件，然后宣称公共契约已经改变。

运行语言中立 TCK

pnpm test:tck

黑盒运行器验证有界解析、规范整数行为、Thing Model 迁移、CloudLink 夹具结果、上下文重放和游标规则，以及清单一致性。默认检查完全离线。

运行器契约见 TCK v1 alpha，公共失败语义见基础规范。

语言绑定证据

每种绑定必须执行同一份公开测试夹具清单，并报告相同的契约字符串失败类别：

pnpm test:typescript
pnpm check:rust
pnpm check:c

完整仓库检查还会验证打包、CMake 安装、清理器行为、生成制品和发布哈希：

pnpm check

通过这些检查只表示已发布的 alpha 范围表现一致，不表示每种绑定都是完整的生产编解码器。

验证使用方制品全集

使用方锁会标识精确发布标签、解析后的提交、清单摘要、已导入制品集合和待处理集合。完整使用方必须导入全部必需制品，并且不能留下待处理项。

发布复合操作和离线验证器会拒绝：

• 与锁不一致的标签或操作提交；
• 布局不安全或不符合预期的发布包；
• 摘要错误的清单、制品或已导入字节；
• 不完整或包含额外内容的采用集合；
• 试图覆盖公共发布权威文件的本地文件。

在线验证会先认证 GitHub 发布身份，再执行相同的本地字节检查。对于已经导入的使用方目录，离线验证是默认方式，不会访问软件包仓库、消息代理或云账号。

产品证据保持独立

AetherEdge 与 AetherCloud 在各自仓库中补充真实消息代理、重启、PostgreSQL 与故障证据。这些结果可以满足某项发布门槛，但不会改变 AetherContracts 标签。同样，通过公开 TCK 也不能证明产品已经具备生产密钥生命周期、持久发件箱事务、运维部署或回滚路径。

在宣称实现一致，或改变旧传输默认值之前，请查看兼容性与发布门槛。