《万法归一》的规则被拆进很多份 GDD 以后，单篇阅读反而不够了。确定性、数据、移动、战斗、敌人、生成、成长、技能、难度、事件、模式、UI、平台和音画反馈，每份文档单独读都能成立，危险的是它们对同一件事说了不同版本。
一开始我很容易把 18／18 文档都标成 Approved 当成完成。这个判断太早了。批准状态、依赖表和性能预算会随其他文档继续修改。单篇通过只能证明这一篇当时自洽，不能证明整套设计没有漂移。
我没有逐份再写摘要，而是先对齐权威来源。谁能改生命，谁能推进 RNG，谁能结算终局，谁只读状态。随后把依赖反向查一遍，再用五个跨系统场景走完整顺序，包括同 tick 死亡与奖励、融合替换、血祭最大生命、终局压力叠加，以及后台恢复。18 份 GDD 的交叉复审地图
这轮没有发现阻断性的玩法矛盾，找到的是三组文档漂移。早期依赖表仍把后来已经批准的 GDD 写成待复审；Auto Combat 还在询问 1／2ms P95，而注册表的预算已经改为 0.80／1.60ms；概念文档和 UI 文档里的里程碑、resolve by 与“下一份 GDD”标签没有跟上实际进度。原因很朴素，文档在不同时间更新，状态文字没有自动跟着权威注册表变化。
交叉复审记录了 18／18 份 MVP GDD、每份 8／8 个必需章节、5／5 个跨系统场景，以及 7 个实体、211 条公式、491 个常量的设计契约。归档时重新运行 ruby tests/design/design contracts test.rb ，结果仍然通过。这个结论只证明设计契约自洽，不证明实现、平衡、性能、真机或真人 Playtest。
现在我不再只问这份文档写完没有，还会问它引用的状态还是不是现在的状态。数字、所有权和里程碑各有一个权威来源，其他文档只引用；跨系统场景则负责找那些单篇阅读永远看不见的问题。