自动关联目录：派生索引：Manifest 不一致不一定是内容损坏

核心判断：内容事实、派生分类和物理存放位置必须分开。派生索引可以从权威内容重算；字节缺失、路径归属变化和摘要不符则是真正的数据损坏，不能用“重建索引”掩盖。

一、业务问题：规则升级会让旧索引过时

场景中的脚本节点决定脚本属于公共层还是某个关卡，Manifest 为快速校验保存一份所有权索引。随着分类规则演进，同一份场景内容可能推导出不同的所有权标签。此时 Manifest 与新规则不一致，不代表脚本字节损坏。

反过来，如果场景新增了一个脚本引用，但 Manifest 中没有对应文件和摘要，系统也不能凭引用“发明”文件内容。两类问题都表现为索引不一致，修复权限却完全不同。

二、实际实现：只修分类，不改变存储事实

现有恢复逻辑会重新合并每个关卡与公共片段，从场景计算期望脚本所有权，再与 Manifest 比较。只有条目数量和路径集合完全一致时，才允许更新 Owner/Level 分类。

它还保留一条重要限制：物理存储绑定不是分类结果。一个文件已经放在关卡私有目录时，不能只把 Manifest 标签改为共享，否则索引会指向不存在的位置。此类情况进入恢复流程，而不是自动重标。

这是一种很成熟的修复边界：重算可推导事实，但不伪造内容，也不静默移动字节。

三、推荐数据分层

Authoritative:
  scene graph, script bytes, stable references

Derived:
  ownership class, dependency index, object count, bounds

Placement:
  relative path, artifact slot, compression/target variant

Proof:
  digest, size, generation, toolchain fingerprint

恢复器必须声明自己能修改哪一层：

rebuildDerived(authoritative)       // 可自动执行
relocatePlacement(plan, journal)    // 显式迁移事务
replaceAuthoritative(from backup)   // 需要已验证恢复源
rebaselineProof(current bytes)      // 不能在普通打开时自动执行

尤其要避免“摘要不一致就重算摘要”。那会把外部篡改或半写文件正式承认为新基线，等于删除完整性保护。

四、验证结论

测试要区分分类规则变化、Manifest 少条目、脚本字节缺失、文件被移动、摘要变化、场景引用删除和大小写路径冲突。每种故障必须产生不同诊断和可用修复动作；自动修复后再次用同一验证器检查，结果必须收敛。

更一般的经验是：Manifest 既有索引又有证明时，不能把所有字段都当作同等权威。先标明字段来源，才能知道哪些不一致可重算，哪些必须停机恢复。