自动关联目录：跨语言合约：同一 Schema 必须拥有规范化身份

核心判断：桌面 UI、Python 服务和 UE 工具各有一份 Schema 文件并不等于共享合约；只有明确唯一来源、规范化身份、派生规则和跨实现向量，才能阻止格式相同但语义分叉。

一、业务冲突

导入队列跨 TypeScript、Python 与 UE 子进程传递草稿、计划、Issue 和结果。各端都需要本地类型与校验器，Schema 必然会被打进多个制品。若开发者分别编辑副本，直到真实任务经过全部进程时才会暴露字段缺失或枚举差异。

二、实际实现

构建工具从 SDK 中解析规范 Schema，校验 $id，将同一内容送入独立服务包，并把 Schema 摘要写入布局 Manifest。若桌面侧存在副本，会先按 JSON 语义规范化后比较；仅换行和缩进不改变身份，真实字段差异则中止打包。测试覆盖副本不同、Schema 缺失、ID 错误和独立构建不依赖桌面检出。

三、值得保留

合约身份不依赖 Git 路径或文本换行，分发包也能自证自己携带哪份 Schema。打包阶段 fail closed 避免了混合版本 SDK；这比“约定大家同步复制文件”可靠得多。

四、结构性缺陷

Schema 一致只能证明数据形状一致，不能证明手写 TypeScript interface、Python 投影和 UE 解析器实现了同一语义。某些约束若只存在代码而未进入 Schema，摘要也看不见。多个派生副本仍增加错误入口。

五、目标设计

Canonical IDL + semantic rules
  -> JSON Schema
  -> TypeScript types + validators
  -> Python models + validators
  -> UE generated constants/readers
  -> shared golden vectors and negative vectors

生成物标注源合约摘要，不允许手改。除字段 Schema 外，规范还需定义 canonicalization、整数范围、未知字段策略、状态转换和错误码目录；每种语言运行同一批正反例并比较规范化输出。

六、取舍与验证

代码生成会增加构建工具和升级成本，复杂 UE 类型也未必适合全自动生成；可以先生成常量、枚举与校验表，保留手写领域对象。验收标准不是文件相等，而是三端对同一向量给出相同接受、拒绝和规范化结果。