自动关联目录：兼容协商：一个版本号不能描述整条资产管线

核心判断：预览解析、场景计划、UE Cook、Bundle、上传 Journal 和渲染后端可以独立升级；用一个“工具版本”全局判兼容，要么误杀可复用阶段，要么放过真正不兼容的组合。

一、业务冲突

渲染后端变化不应强迫重做已经完成的 Cook；Bundle 格式变化却必须阻止旧客户端直接加载。若所有阶段只比较一个版本号，小改动会导致整条流水线失效，而漏升总版本又会把不兼容产物推到更晚才失败。

二、实际实现

实际能力快照分别记录检查协议、场景事实 Schema、规范化版本、解析器指纹、计划 Schema、配置 Revision、工具链指纹、引擎版本、Bundle/Trailer/Manifest/Journal Schema、渲染后端和目标平台 Cook Key。兼容检查按 facts、plan、cook、upload、reconcile、renderer 分阶段选择所需键，并返回带 Stage 和 required/actual 的原因。

三、值得保留

这将“兼容”从一个布尔值变成可解释能力向量。未受影响阶段可以复用缓存，真正不匹配的阶段在执行前失败；能力原因还能直接关闭 Add Files 或 Submit，而不是等 UE 子进程报模糊错误。

四、结构性缺陷

阶段到兼容键的映射本身是一份关键依赖图，若在多端手写，新增字段可能只被一端纳入。部分 fingerprint 只能说明实现字节变化，不能解释语义兼容范围；过细版本又会导致无意义缓存失效。

五、目标设计

struct StageContract {
    StageId stage;
    Map<CapabilityKey, CompatibilityRule> requires;
    Hash semanticFingerprint;
};

Compatibility Negotiate(StageContract producer, StageContract consumer) {
    for (auto [key, rule] : consumer.requires)
        if (!rule.Accepts(producer[key])) return Mismatch(key, producer[key], rule);
    return Compatible;
}

每个 Stage 在一个规范清单中声明输入能力，构建时生成各语言检查器与文档。Fingerprint 只覆盖真实语义输入，渲染后端等下游变化不污染上游缓存键。

六、取舍与验证

能力向量更复杂，但能显著缩小重建范围。用 pairwise 版本矩阵验证：每次只改变一个能力，断言最早失败 Stage、可复用前缀和修复建议准确；同时用测试阻止新能力字段未归属任何 Stage。