任务：转自动化的编译半边，先用合成合约和合成台架做通（编译设计 E1–E3）

转自动化的编译半边（docs/hub-r4-compile-design.md）原先定的是等所有者给出执行用的函数合约再开工。10-23 改为先用合成合约和合成台架做通 E1 到 E3：整条路（模型在 Circle 里按受限结构编译评审过的用例，Hub 在边界上核对）先做出来、验收过；所有者给出真合约以后，用 circle-hub doc put 换成真的那份，形状放不进去时改包的校验函数。为了不让“符合合约”被当成真的，合约文档自己声明是合成的，每条结论都写明“按合成合约核对”和“不证明在真实设备上跑得通”。这一步不接触任何设备，不写任何业务系统。

两部分分别指派，B 的答案不能看 A 的代码。

  • 规则：同前（不推送、不建 PR、不发布、不部署，不碰 7420、钥匙串、环境配置文件和任何真实系统；测试只用合成数据，地址都在 192.0.2.0/24 和 2001:db8::/32；git commit -s）。

A. case-compile 工作流包（分支 hub-case-compile，目录 circle-hub-case-compile）

  • 可以改的路径：新包 packs/workflow/case-compile/**。核心缺什么先回报，不要自己改核心。
  • 验证：npx tsc --noEmit；node --test --test-concurrency=3 "packs/**/*.test.ts"；包的发布校验（照别的包的 publish.test.ts）。
  1. 输入：一份评审过的用例文档（敏捷平台的脑图，条目和 case-review 一样按“带标签或带标记”取用例）；目标构建（命令目录 commands@1，命令和参数照 catalog@1 核对）；合约命名文档 doc:compile-contract；台架清单命名文档（test-bed 包的清单形状）。包里带一份合成合约和一份合成台架作样例。
  2. 合约的形状由这个包的校验函数定：对象（例如被测设备、客户端、服务器）和它们的方法，每个方法的参数个数和类型，禁用的（对象，方法）组合（例如重启类），以及 synthetic: true 这样的声明。合成合约只写够编译这类用例的最少几个方法，不抄任何旧系统的名字和值。
  3. 模型按受限结构填槽（模型 W05：桶、块、算子、预期来源是有限集），每个用例一份执行计划：步骤列表，每步是（对象，方法，参数）；字面地址写台架上的实体或分配到的地址；检查步骤的期望结果必须引用用例原文、缺陷修复说明或手册的逐字片段。
  4. Hub 在边界上重跑的核对（纯函数，照编译设计第 2 节）：
    • （对象，方法）在合约里、没被禁用，参数个数和类型对；
    • 字面地址：每个都要解析成台架上的设备接口地址或分配到的地址；监听地址必须是被测设备的接口地址，且同一网段上有触发设备；盲地址不能当监听或虚拟地址；后端地址必须是服务器设备的地址；台架之外的地址一律拒绝。台架事实的算法照 test-bed 包的 bed-facts；能不能跨包复用，核心缺什么，先回报；
    • 命令和参数在目标构建的命令目录里、取值在范围内；
    • 每个期望结果都有逐字来源；
    • 同一份用例反复编译结果相同：执行计划由确定性生成器从槽位出（先出 JSON 形式的执行计划，工作簿格式等所有者），另一个读取器回读核对。
  5. 结论都是事实或未知，从不写“可以运行”；合约是合成的时候，每条结论都带“按合成合约核对”；所有结论都带“不证明在真实设备上跑得通”。
  6. SKILL.md 写清模型怎么填、修正说明怎么读，给完整的提交样例（照 defect-to-case 的写法）。
  7. 合成测试先写：合约的正反例（方法不在合约里、被禁用、参数个数或类型错）；地址的正反例（台架外、盲地址当监听、后端不是服务器、监听网段上没有触发设备）；命令不存在、参数越界；期望结果没有来源；同一份用例编译两次结果逐字节相同。

B. 编译核对的独立答案（分支 hub-compile-gold，目录 circle-hub-compile-gold）

  • 可以改的路径：scripts/real/gold/compile-check.ts、scripts/real/accept/case-compile.ts 和它们的测试。不导入包或核心的函数，不看 A 的代码。
  • 验证：npx tsc --noEmit；node --test --test-concurrency=2 "scripts/real/**/*.test.ts"。
  1. compile-check.ts：输入是集成者导出的执行计划（run show --json 和提交）、合约文档、台架清单和这个构建的命令树原件。自己解析，逐步重算第 A.4 节的每一条核对，输出每一步的判定（通过、不通过和原因、未知）。
  2. case-compile.ts：真实客户端场景（照别的场景的写法）：模型开始一次 case-compile 运行、提交执行计划；场景核对 Hub 的判定和 compile-check.ts 算出的答案逐步相同，回答里有“按合成合约核对”和“不证明在真实设备上跑得通”。
  3. 合成测试：每类核对的正反例各一例；判定比对的正反例。

完成后在终端里回报：提交号、测试数量、没做完或拿不准的地方。真实客户端的验收（E3）由集成者用真实模型跑。