自动关联目录：工具分发：复制可执行目录不等于生成可验证 SDK

核心判断：UE Cook 工具能在开发机运行，不代表它可以独立分发；一个 SDK 必须声明最小文件闭包、插件与配置白名单、协议版本和每个文件摘要，并拒绝额外内容。

一、业务冲突

独立资产处理工具依赖 Engine 配置、Shader、少量引擎资产、业务插件、Schema 和许可证。直接复制编辑器目录虽然省事，却会带入开发脚本、测试、无关插件和机器偶然存在的文件；漏文件则只在另一台机器启动或 Cook 时失败。

二、实际实现

实际工具包使用两层 Manifest：运行文件清单声明所需目录、精确文件和插件描述；SDK 清单声明引擎/协议/格式版本、插件与配置白名单、工具链指纹以及每个 SDK 文件的 SHA-256。打包只复制声明内容，拒绝未列出的顶层目录、链接、缺失文件和摘要篡改，测试还放入 do-not-ship 文件证明它不会随目录被带走。

三、值得保留

这把“开发目录快照”提升成可验证制品。插件只允许一个窄业务入口，配置和骨架基线都有显式身份；服务端契约 Schema 也随包记录摘要。部署脚本还能把资产工具与普通客户端/DS 分发边界分开。

四、结构性缺陷

运行文件清单和 SDK 清单有部分重叠，维护者仍可能在一个清单加文件却漏另一个。目录级允许规则过宽时，新文件会被意外纳入；固定 Engine 资源列表又容易随引擎升级失效。仅校验文件摘要也不能证明可执行文件在干净机器上能启动。

五、目标设计

struct ToolBundleManifest {
    BundleId id;
    ToolchainContract contract;
    Array<FileEntry> files;       // logical path, size, hash, role
    Array<RuntimeProbe> probes;
};

Bundle BuildToolBundle(BuildReceipt receipt, AllowPolicy policy) {
    auto closure = ResolveRuntimeDependencies(receipt);
    Require(policy.AcceptsExactly(closure));
    return SealAndVerify(closure, contract, probes);
}

从 UBT Receipt 和动态依赖扫描生成候选闭包，再由白名单审核，而不是手工复制整目录。最终包在隔离目录执行启动、能力查询和最小 Cook Probe，成功结果写回 Manifest。

六、取舍与验证

严格闭包会让引擎升级首先失败在打包门禁，而不是用户机器，这是合理成本。验证包括缺文件、增文件、符号链接、摘要篡改、协议不匹配、无共享 DDC 和全新用户目录，确保 SDK 的可运行性来自自身而非开发环境。