一次看起来像“新预设坏了”的失败
这次是在处理一套固件预设时，发现默认构建突然全部卡在第1道安全门。表面现象很容易把人带到错误方向：刚刚移植了一个新预设，构建又是在这之后失败的，于是第一反应往往是回头检查这个预设的内容，怀疑某个参数不合法，或者怀疑新文件破坏了原来的约束。
但失败有一个很不寻常的特征：不是新预设失败，而是任何默认构建都失败。也就是说，输入换不换，结果都一样。只要构建走到“当前内容是否仍然符合冻结基线”的检查，就会停下来。当所有输入都在同一道门失败时，优先怀疑门所依赖的基线，而不是逐个怀疑输入。
我先把问题缩小到基线指纹。它本来是为了确认当前登记表和已经验证过的处理阶段没有发生意外变化。指纹如果不匹配，构建应该停下，因为继续往下走可能把未经确认的结构写进产物。安全门本身没有错，真正需要查的是：它拿什么和什么比较，以及这两份数据是否还描述同一个系统。
登记表变了，冻结文件没有跟上
继续对照结构后，根因逐渐清楚了。冻结文件最初只记录了登记表里的5个槽，而当前登记表已经扩展到10个槽。新增的部分包括1个新的通用槽，以及4个人像相关槽。旧文件仍然代表过去某个时点的结构，当前登记表却代表已经扩展后的结构。
这里有一个容易被时间顺序掩盖的事实：这不一定意味着本轮新增内容改坏了系统，也可能只是登记表先发生了正常扩展，冻结基线却没有同步更新。冻结文件因此没有“错误地记录了旧事实”，它只是过期了。问题在于，安全门仍把它当成当前事实使用。
我没有因为人像相关槽在另一份说明里写着“未做”，就直接把它们从登记表删掉。登记表的职责是描述有哪些结构区域，是否完成渲染或校准是另一个维度。**“还没有完成某项工作”不等于“这个结构不应该登记”。**如果为了让检查通过而删回旧登记表，短期看像恢复了构建，长期却会让唯一的结构来源失真。
如果不处理这个差异，后果也不只是一次构建失败。后续任何新预设都会被同一条旧基线拦住；更危险的是，某个人可能为了赶进度绕过安全门，或者把登记表回退到旧版本。这样确实可能让流程继续，却把真正的结构漂移藏了起来，下一次再遇到变化时，系统会更难判断哪些内容经过验证。
完整字典比较把说明文字也当成了结构
问题还有第2层。冻结文件除了指纹结构，还保留了手工写入的状态说明和备注。这些字段对人很有用：它们可以说明基线处于什么状态、为什么冻结、什么时候复核。但原来的比较方式是整个字典直接相等比较。于是，说明字段也被当成了安全结构的一部分。
这种比较在文件很小、字段很少时看起来省事。只要生成结果和冻结文件一模一样，就认为安全门通过。但它把两种不同性质的信息混在了一起：槽集合、阶段摘要和有效性标记会影响安全判断；说明文字只是诊断和维护元数据。两者都放在一个文件里，并不意味着两者都应该参加相等比较。
最容易误判的是，为了省事把说明字段删掉，或者把安全门改成“只要大部分相等就通过”。前一种做法会丢掉维护语义，后一种做法则可能掩盖真正的结构漂移。我选择把基线拆成结构字段和说明元数据，是因为安全门要回答的是“当前结构是否与冻结结构一致”，而不是“文件是否逐字逐项相同”。
真正应该比较的，是3类会改变安全含义的字段：当前处理阶段的摘要、这个阶段是否处于有效状态，以及按登记表生成的槽结构。状态和说明可以继续保留，但说明不能偷偷改变判断结果。这样做不是降低标准，而是把标准放回正确的边界里。
正确修法不是跳过安全门
在这种故障面前，最快的错误捷径是直接跳过第1道安全门。另一个看似稳妥的捷径，是把登记表删回5个槽，让当前数据重新“适配”旧冻结文件。这两种做法都只是在修改失败的表现，没有回答当前结构到底是什么。
我判断应该按当前登记表重新生成10槽基线，并先把旧的5槽文件归档。理由有两个。第一，当前阶段本身已经经过验证，变化来自登记表扩展，而不是未经确认的处理逻辑。第二，旧文件仍然是重要证据，它能说明安全门为什么会失败，也能在之后作为负向测试输入。直接覆盖会让历史证据消失，今后很难区分“基线更新”与“基线被误改”。
重新生成时，生成器只负责写入真正参与比较的3类结构字段；状态说明和备注则沿用原来的语义，并补充冻结时间、槽数量和登记表来源等诊断信息。这样文件既能被程序可靠读取，也能让人看懂它为什么是当前基线。
**安全基线更新的关键不是让检查变宽松，而是让检查比较正确的对象。**这句话对很多配置系统都适用。配置、登记、快照、锁定清单里经常同时存在机器字段和人的备注；如果不先区分它们，任何一次说明文字调整都可能被误报成安全变化，任何一次结构变化也可能被备注噪声掩盖。
诊断要告诉我漂移发生在哪里
只报告“指纹不相等”还不够。它只能告诉我安全门拒绝了，却不能告诉我应该检查哪一层。于是这次还补了更具体的诊断：先报告槽集合是否漂移，再报告逐槽字段的差异。这样，如果登记表从5个槽扩展到10个槽，错误信息会明确指出当前有10个、冻结文件只有5个，而不是只留下一个无法行动的“不相等”。
诊断元数据的价值在故障现场尤其明显。构建失败时，执行者通常没有足够耐心重新阅读所有登记文件；他需要知道是阶段摘要变了、有效性变了，还是某些槽的结构字段变了。信息越接近实际决策，越不容易把安全问题误判成输入问题。
这也让我重新意识到，安全门不是一句布尔值。它至少有两层职责：决定是否放行，以及在不放行时帮助人找到原因。如果只有前一层，团队迟早会把“查不清楚”当成“先绕过去”。好的拒绝应该让修复路径比绕过路径更短。
正向通过，还要用旧基线反向失败
重冻结后，默认构建从第1道到第10道安全检查全部通过，说明当前10槽结构和新的冻结基线一致。但这还不能证明安全门没有被放宽。一个检查如果只验证“正确输入能通过”，仍然可能在错误输入上误放行。
所以我保留归档的旧5槽文件，专门把它作为负向测试输入。测试结果仍然在第1道安全门失败，并且报告了登记表槽集合漂移和逐槽差异。这一结果很重要：它证明修复不是简单删除比较、忽略槽集合，或者把任何不相等都当成可以继续。旧基线应该失败，当前基线应该通过，两种结果合在一起，才构成完整证据。
我把这次流程整理成一个可复用的方法。登记表发生扩展时，先确认变化是结构登记变化还是处理逻辑变化；再按当前登记表重新生成冻结基线；生成前自动归档旧文件；比较时只取真正影响安全的结构字段；最后同时做正向和负向验证。正向测试确认当前版本可用，负向测试确认旧版本和错误槽集仍然会被拦住。
一个流程成熟的标志，不是它能跑通一次，而是它能在下次少依赖临场记忆。把旧基线留下，把漂移位置说清，把错误输入也纳入测试，实际上是在给未来的执行者保留判断依据。
下次我会怎么做
下次遇到“所有构建突然失败”，我会先看失败是否与输入无关。如果无论哪个预设都卡在同一道门，就先检查安全门引用的冻结文件、登记表版本和比较字段，不急着逐个修改输入。
接着我会把基线内容分成两层：一层是会影响放行的结构字段，另一层是帮助人理解状态的说明元数据。前者必须严格比较，后者必须保留但不能意外参与比较。只要登记表扩展，就把同步重冻结视为结构变更的一部分，而不是等到构建失败后临时补救。
我也会把归档和负向测试写进习惯里。旧文件不是垃圾，错误输入也不是多余测试；它们分别回答“过去发生过什么”和“安全门是否真的还在工作”。如果新基线通过、旧基线失败、诊断能指出漂移位置，才算完成这次修复。
这件事让我重新意识到，安全系统最怕的不是一次明确的失败，而是为了恢复表面顺畅，悄悄删除了失败的依据。真正可靠的做法，是让当前结构得到确认，让历史证据得到保留，也让下一次的人能看懂为什么该停、应该改哪里。