在添加数据、配置、状态、常量、枚举字符串…

任何事实只应存在一处，其他部分都从该处读取；适用于新增或合并可能重复的数据/配置/状态/常量/缓存，或两处来源已不一致时。

适用场景

解决思路

1. 添加数据前，先找谁已经拥有它；扩展该所有者，不要创建竞争来源。
2. 优先派生而非存储：如果平台或现有来源能在读取时回答，就在那里读取，不要把答案复制到第二处导致陈旧。
3. 顺手吸收发现的重复：当改动硬编码了文件已知内容或反之时，把两者合并，不要留下第三个变体。
4. 让缺失条目显式失败：单一来源只有在缺失被视为错误、绝不是静默默认值时才具有权威性。
5. 标记产物是生成还是手改，并且绝不编辑生成输出；每个产物都要声明自己是哪类。
6. 词汇要类型化，不要字符串化：代码分支依赖的标识符、种类、状态和名称应使用常量、枚举、密封类型或注册表项；重复出现的自由字符串就是两处事实来源，只差一个拼写错误。
7. 两个来源冲突时，明确指出矛盾；完整修复要确定哪个值生效，合并为一个来源并删除失败者；绝不静默跟随任一个，否则会把分歧洗成你碰巧先读到的答案；在声明关键路径上，实时分歧要直接发消息给所有者，而不只是建跟踪项，因为未读工单不会暴露任何东西。
8. 不要复制阈值、URL 或映射作为“临时”副本；临时副本的寿命与上方的 TODO 相同。
9. 不要创建 `thing-v2` 放在 `thing` 旁边，而应就地编辑。
10. 不要用代码中的默认值遮蔽配置文件的值；否则有人改配置却无效果。
11. 不要在两个服务里放两个枚举来拼写相同状态；一旦一方新增状态，边界会变成静默过滤器。
12. 缓存和读模型只有在自动派生且陈旧有界可观察时，才是合法的派生副本；禁止人工保持同步的副本。
13. 测试 fixture 可以有意冻结现实副本，并用 fixture 标签表明这一点。
14. 文档遵循同一规则：索引只路由、绝不决策；若安装了 technical-writer 插件，其 `technical-writing` 技能负责这一侧。

适用边界 · 注意事项

• 缓存和读模型若其派生是自动的、陈旧有界且可观察，则不适用“消除副本”，它们是合法的派生副本。
• 测试 fixture 可以有意冻结现实副本，并用 fixture 标签表明，不适用“必须从单一来源实时读取”。
• 文档索引只负责路由、绝不负责决策；不应让索引成为决策来源。