先别急着替换路径
这次遇到的问题，表面上像是一个模板文件找不到了。自动建稿流程原本依赖多个模板来源，有的源稿已经被移除，有的路径虽然还看得见，却只是指向冷归档的软链。流程在真正消费模板时，才发现这些来源已经不再满足使用规则。
第一反应很容易是把旧路径换成另一个“看起来存在”的路径，让建稿先跑起来。尤其当任务量已经排在队列里时，任何能让流程继续的办法都显得有吸引力。但我一开始越想赶紧恢复，越觉得这件事不能只按文件是否存在来判断。文件在目录里，不等于它还承担着可复用的模板职责；软链能解析，也不等于它代表了一个稳定来源。
模板不是一个临时能打开的文件，而是一项需要持续验收的构建依赖。
这件事让我重新意识到，自动化最危险的故障，不一定是立刻报错的故障。真正麻烦的是流程暂时不报错，却把不可靠的来源继续写入后续产物。那样得到的不是恢复，而是把问题向后推，直到某次批量建稿出现难以解释的差异。
文件还在，不代表来源可靠
模板失效通常不会只有一种形态。源稿被清理，是最直接的一种；冷归档软链仍然存在，则更容易造成误判。路径可以解析，读取动作也可能成功，可它已经不再是允许消费的来源。两者如果都被简单归为“找不到文件”，后续修复就会漏掉真正的边界。
我把问题拆成了3层。第1层是实体性：这个来源是否真的是当前存放的内容，而不是依赖另一处可能变化的指向。第2层是可验证性：模板能否被解析，关键结构是否完整。第3层是可消费性：它能否完成一次真实建稿，并通过最小的可开性预检。
这3层不能互相代替。实体来源不能自动证明内容完整，解析成功不能证明建稿结果可用，建稿完成也不能证明模板以后仍会稳定存在。如果只验证其中一层，自动化流程就会把一个局部通过误认为整体恢复。
如果不处理这个区别，后果会很具体：今天改好的默认值，明天可能又指向一个冷备路径；批量建稿表面上成功，打开后却缺少必要内容；更糟的是，注册表显示一切正常，排查者反而失去了判断问题发生在哪一层的线索。
先建立实体种子，再谈注册
后来找到的突破口不是复活某个旧路径，而是一个已经具备完整模板稿和指纹的实体种子仓。它的重要性不在于“有一份备份”，而在于它能作为长期稳定来源被独立检查。它不是从注册表里倒推出的路径，也不是临时拼出来的替代品。
我选择先把实体种子当作候选来源，是因为模板治理首先要回答“我到底在消费什么”。如果来源本身说不清，后面的指纹比较只是在给不确定性贴标签。相反，先固定实体内容，再为它建立可重复计算的指纹，注册表才有了可以核对的参照物。
这里的“实体”并不意味着永远不会变化，而是意味着变化有明确落点。它可以被读取、被解析、被复制，也能在下一次检查中重新计算指纹。这样一来，模板的身份不再由一个容易漂移的路径决定，而由内容和校验关系共同决定。
可靠的默认来源，必须先有可追溯的实体，再有可核验的注册记录。
这也是我没有直接把旧条目改成新路径的原因。直接替换虽然快，却会把“来源迁移”和“内容是否一致”混成一个动作。一旦后面发现新模板与原注册内容并不一致，就很难判断这是有意升级、误覆盖，还是一次未经审计的临时修补。
注册、实建和可开性要分开验
有了实体种子之后，新的模板不能一注册就立即成为消费方默认值。实际流程分成了几步：先登记来源，再做只读解析；解析通过后，进行一次真实建稿；建稿完成，再做可开性预检；全部通过，才切换消费方的默认值。
把这些动作拆开，听上去像增加了手续，但它们回答的是不同问题。注册回答“系统知道这个来源”；解析回答“内容结构能被理解”；实际建稿回答“它能参与完整流程”；可开性预检回答“生成的结果不是只有文件名成功”。少掉任何一步，都可能把局部成功误认为可以上线的依赖。
真实建稿尤其重要。只做读取测试，无法发现模板在渲染、字段填充或输出阶段的兼容问题。那次验证稿完成后又被归档，草稿首页没有留下残留，这说明验证本身也要有边界：既要证明流程真实跑通，又不能把测试内容混进正常工作区。
切换默认值的门槛不是“模板能读”，而是“模板能被真实消费并且产物可开”。
我更愿意把这看成一次小型发布，而不是改一个配置。发布前有来源和指纹，发布中有实建，发布后有结果预检和清理。这样做的价值，是把“我觉得可以了”变成一条别人也能复核的判断链。
指纹不一致时必须关门
最容易误判的地方，是冷备实体与注册指纹不一致。看到冷备内容仍然能打开，人很容易觉得只是注册表过期，于是直接用冷备覆盖登记值。这个捷径看起来符合恢复直觉，实际上会抹掉最重要的异常信号：内容已经变了，但变化原因还没有被解释。
我判断这里应该采用 fail-closed，是因为注册表承担的是信任边界，而不是缓存作用。指纹一致，说明当前实体仍与已登记内容相符，可以继续进入后续检查；指纹不一致，只能说明“这是一个不同的实体”，不能自动说明它就是正确的新版本。
因此，不一致条目不直接覆盖注册表，而是保留失败状态，等待单独判断。这个状态不是流程没做好，也不是为了让人难受而增加阻断。它是在告诉后续操作者：这里有一个需要解释的变化，当前系统不能替你把未知当成正确。
如果采用“只要有可用备份就覆盖”的策略，短期内确实可能少一个报错，长期却会造成更大的审计缺口。未来再出现差异时，没有人知道登记值何时被换过，也无法分辨是有意升级还是错误恢复。失败状态的价值，是保留尚未被证明的事实，而不是假装系统已经恢复。
失效条目也要留下来
处理失效模板时，另一个看似合理的做法是把坏条目删掉，让注册表只保留当前可用项。这样看起来更干净，实际上会失去一部分故障历史。一个来源为什么失效、何时失效、是否因为源稿被移除、是否因为软链指向冷归档，这些信息都可能影响下一次迁移。
所以，失效条目继续保留审计记录，每条记录说明路径的现状、失效根因和处置结果。这里的“保留”不是让它继续参与建稿，而是把它从可消费状态和审计状态区分开。消费方只读取通过校验的条目，审计者仍然能看到曾经发生过什么。
这件事表面上是在整理注册表，其实是在治理记忆。如果只留下成功项，系统会越来越像一个没有历史的黑箱；每次故障都要重新猜测。一个流程成熟的标志，不是它永远没有失败，而是失败发生后，下一次排查不必从零开始。
下次我会怎么做
下次再遇到模板文件失效，我会先暂停“换路径”的冲动，按下面的顺序判断：先确认来源是否为实体，再确认内容能否解析；随后做一次最小真实建稿和可开性预检；最后重新计算指纹，并决定它是可注册、可切换，还是必须保留为失败状态。
如果冷备实体与注册指纹一致，我会把它当作可继续验证的候选，而不是直接当成默认值。如果不一致，我会保留差异，记录现状和根因，不用覆盖动作掩盖未知。只有来源、内容、建稿结果和指纹都通过，才会让消费方改用新模板。
我还会把验证稿的清理纳入流程本身。测试完成后归档，草稿首页不残留，说明验证是一次有边界的检查，不是向工作区追加垃圾。这样，自动建稿的可靠性就不只体现在“今天能不能跑”，也体现在“下次出了问题，能不能知道为什么”。
真正值得复用的不是某个模板路径，而是一套在不确定时主动关门、在证据充分时才放行的习惯。
我更愿意把它看成一种工作纪律：把模板当构建依赖，把实体当来源，把指纹当证据，把失败状态当审计的一部分。临时兜底可以帮助流程度过一次故障，但只有经过校验的长期来源，才能让自动建稿继续可靠。