当同一事实散落在多个工件或平台且需要建立/修复单一事实源时…

同一事实在多个文档、代码、配置或平台中重复、过期或矛盾时，用它定位所有出现位置、制定合并计划，获批后收敛到一个规范归属并让其余位置引用它。

适用场景

解决思路

1. 遵循核心原则：一个事实只有一个归属，其他需要它的地方引用该归属；引用不会漂移，副本会漂移。
2. 明确范围内的“事实”：指出被跟踪的具体事实、值、规格、决策、状态或定义，而不是整个文档。
3. 先做只读审计：在给定工件和平台中枚举该事实的每一次出现。
4. 用第二种方法重新枚举：换一个搜索词、同义词或工具再查一遍，确认它没有漏掉第一次扫描未发现的出现位置。
5. 对每个出现位置分类：完全副本、改写、部分、过期或矛盾。
6. 选择规范归属：选最权威、维护最频繁、最接近该事实实际变更处的位置；不要因为方便就提升弱副本；若不存在，则抽取新的规范归属。
7. 为每个非规范出现位置决定动作：去重（dedupe，删除冗余副本）、引用（reference，文档应链接到规范处，代码应 import/source/include 它，配置应使用共享读取）或调和（reconcile，内容不一致，需要人工裁决）。
8. 编辑前先报告审计：用表格列出出现位置（位置 · 类型 · 动作）、提议的规范归属及一行理由、必须合入的唯一细节、需要决策的矛盾，以及精确的变更计划。
9. 请求明确批准执行变更计划；若未获批准，则在只读报告后停止。
10. 使规范归属完整且最新：合入只存在于副本中的任何唯一细节；绝不要因合并而丢失信息。
11. 先在规范归属中调和矛盾；当正确值不明确时，在替换任何内容前先确认。
12. 把每个重复项替换为指向规范归属的活引用：文档用链接、“见 <规范归属>”、带链接的引用，或平台支持时用转译嵌入（transclude）；代码用对共享归属的 import/source/include；配置从唯一维护文件做共享读取。
13. 删除现已冗余的副本；若删除会使读者孤立，则保留一行指针而不是直接删除。
14. 若一次检查没有发现需要合并的散落副本，则不做任何变更。
15. 审计阶段保持只读：在用户批准变更计划前，不要编辑、移动或删除。
16. 空发现列表是有效结果：绝不要为了证明合并合理而编造漂移。
17. 把矛盾与普通重复分开；绝不要静默决定哪个冲突值是“真”。
18. 标记只存在于非规范副本中的细节；在能够切掉该副本前，必须先把它合入规范归属。
19. 没有明确确认时，不要跨信任/权限边界合并（如私有→公开、面向客户→内部）。
20. 以编辑安全方式变更：触碰每个替换目标前先断言其存在（报告 `MISS`，绝不静默无操作），使用 `PYTHONUTF8=1` 做 Unicode 安全编辑，按出现位置逐个处理，绝不批量清扫；结构性代码移动使用语言感知工具或脚本化 AST/解析器编辑，绝不用脚本化文本重写。
21. 做平台感知处理：尽可能使用转译嵌入（transclude），否则链接到读者可跟随的稳定锚点；当平台无法链接回来时，优先保留引用而不是硬删除。
22. 当同一项目事实被拆在只读审计工件和变更工件之间，且审计没有独立持久用途时，把这视为 SSOT 散落：提议把审计折叠进变更工件，然后仅在批准后执行。
23. 若只读检查器与变更后续已成为一个不可分割工作流，把检查器折叠进合并器并保留批准闸门；不要拆成两半，因为拆分反射会让更安全的前半段更容易被跳过。
24. 完成前验证：审计在变更前已报告且已获批准，除非本次运行保持只读。
25. 完成前验证：规范归属自身保存完整、当前的事实。
26. 完成前验证：每个原先的副本现在都引用它，且每个引用都能解析。
27. 完成前验证：没有唯一细节丢失，也没有任何内容被孤立。
28. 完成前验证：矛盾已调和为一个值，而不是留下重复。
29. 完成前验证：报告已合并了什么、规范归属在哪里、仅审计了什么，以及还有什么需要人工决策。

适用边界 · 注意事项

• 当单一事实源已经稳定、没有散落副本时，不要反复执行合并；它是一次性修复，不是持续维护。
• 当只发现矛盾但正确值不明确且无法确认时，不要静默选择或继续替换。
• 没有明确确认时，不要跨信任/权限边界（私有→公开、面向客户→内部）合并。