转自动化的编译半边：要什么、Hub 能核对什么、分几步
状态（2026-10-23 更新）：集成者按目标先在合成合约和合成台架上做了编译半边（case-compile，见进度 10-23 的记录）；下面写的三样真实输入仍要所有者提供，换成真的之前，结论都标“按合成合约核对”。下面是原来的需求和步骤。转自动化有两半：设备管理（设计，第一阶段已落地，不接触设备）和编译半边（把评审过的用例变成执行用的脚本，并在上机之前核对）。编译半边现在做不了的原因不是缺代码，而是缺三样所有者才有的东西。
1. 所有者要给的三样
- 执行用的函数合约。 脚本里每一步能调用哪些（对象，方法）组合，哪些组合被禁用（例如重启类），参数怎么写。Hub 不能从旧系统里抄这份合约（AGENTS.md：SyntheticReference 是只读的行为参考，不运行、不导入、不复制它的代码和配置值）。所有者自己把合约文件用
circle-hub doc put发布成命名文档（比如excel-contract），它就成了部署数据，不进 Git，Hub 的包只读它。需要的形状由包的校验函数定，所有者给的文件放不进去时，由所有者或我们一起改成能放进去的形状。 - 执行入口和工作簿的格式。 旧做法是把工作簿交给实验室网关，网关先按合约校验、再取台架租约、再派发；工作簿里要有网关认的两个标记（执行表的范围名和合约身份标记）。这些细节在旧网关里，不在本仓库，也不能从旧系统抄；要么所有者给一份格式说明（文字即可），要么指定一个新的、由 Hub 自己定义的执行格式。第二种做法就不依赖旧网关，但上机的执行器要重写（TypeScript），那是第三阶段（改动类操作），要所有者另行批准。
- 台架事实的来源。 设备管理包的清单文档（拓扑）。格式和校验在
packs/workflow/test-bed/functions/manifest.ts（设计见设备管理包设计第 5 节），所有者按那个形状导出一份即可；包里会带合成样例。
2. Hub 在上机之前能核对什么（静态层，全部是纯函数）
模型在 Circle 里按受限的结构填写（类别是有限集：桶、块、算子、预期来源，模型 W05），Hub 在边界上重跑核对，不让模型写不能核对的东西：
- 每一步的（对象，方法）在合约里、没被禁用、参数个数和类型对；
- 脚本里出现的地址：每个字面地址要解析成台架上的设备接口地址或分配到的地址（T04）；监听地址必须是某台被测设备的接口地址，且同一网段上有触发设备；盲地址（没有触发设备的网段上的地址）不能当监听或虚拟地址；后端地址必须是服务器设备的地址；台架之外的地址一律拒绝（旧系统叫“编造的不可达地址”）；
- 每个命令和参数在目标构建的命令树里存在、取值在范围内（已有的
catalog@1解释器）； - 每个期望结果有来源（用例原文、缺陷修复说明或手册的逐字引文），不能是模型自己写的；
- 同一份用例反复编译，结果相同（生成器是确定性的，工作簿由确定性生成器按槽位和引用出，另一个读取器回读核对，P05）。
这一层的结论都是事实或未知，不是“可以运行”：它证明脚本符合合约和台架事实，不证明在真实设备上跑得通。后一句要写进每份结果。
3. 分步
| 步 | 内容 | 需要 |
|---|---|---|
| E1 | 合约命名文档 + 校验函数 + 一个合成合约的样例；case-compile 工作流包（槽位、检查、样例）；确定性生成器出工作簿（先出 JSON 形式的执行计划，工作簿格式等所有者第 2 条） |
第 1 样 |
| E2 | 把台架事实接进去：字面地址解析、监听/触发配对、盲地址（bed-facts 已有函数） |
第 3 样 |
| E3 | 真实 Circle 客户端验收：合成合约和合成台架上，模型编译一份真实用例，Hub 的核对与独立算法一致 | E1、E2 |
| E4（第二阶段，需另行批准） | 台架上的只读观察：执行器取版本和接口地址，和声明比对 | 设备管理的第二阶段前提 |
| E5（第三阶段，需另行批准） | 上机：经执行器按租约派发，至多一次，丢回复即冻结 | 执行入口、命令类清单 |
4. 现在不做的原因
没有第 1 样，编译的“合约”只能是我们自己编的，核对出来的“符合合约”就没有意义，反而会被当成真的。所以先不写代码，等所有者给合约文件（或指定新格式）再开 E1。
10-23 改为：先用合成合约和合成台架做通 E1 到 E3（任务页 docs/hub-r4-tasks/case-compile.md），整条路先做出来、验收过；所有者给出真合约以后换成真的。为了不让“符合合约”被当成真的，合约文档自己声明是合成的，每条结论都写明“按合成合约核对”，所有结论都写明“不证明在真实设备上跑得通”。E4、E5 照旧要所有者另行批准。