用途与实际影响
这项功能怎样使用
为什么需要它
把所有事实一起过期会制造重复劳动；反过来，只重新生成文件却不标旧结果，会让失效证据继续被引用。
举个实际例子
我可以说：“执行计划换成新版了，告诉我哪些结论还能用、哪些文件要重做。”仍能唯一找到原文的事实会接到新版；被删除或出现歧义的事实及相关旧文件会明确标为过期。
最后我会得到什么
得到新旧资料的差异、仍能沿用的结论、已失效的结论，以及哪些旧版交付物不能再当当前版使用。处理新增问题后另存新版本；目前影响范围能指出整次构建，尚不能精确到某一页或表格单元。
可以正式构建
新资料读得完整，旧结论引用的原话在新版中仍唯一可找到时，自动接到新位置；真正失去依据的结论及引用它的旧交付版本才标为过期。
需要确认
原话消失、出现多个相同位置或新旧说法冲突时，保留两版资料和待确认结论，只让负责人处理对应事实。
当前不可用
新版资料不能可靠读取或保存更新失败时，继续保留上一可靠版本，不假装已经完成换版。
从哪里开始
说某份需求或纪要换版了，请核对以前结论哪些受影响。
需要准备什么
- 哪份资料发生变化
- 新文件或已保存的新版本
从开始到拿到结果
- 1
先比较新旧资料
AI 核对选定来源的新旧内容，完全没变就保持现状。
- 2
只重看失去依据的结论
原话仍唯一可找的自动接续；消失或有歧义的标待审，并指出受影响的旧交付版本。
- 3
确认下一版的范围
交回仍有效、待审和已过期的部分；有歧义的原话由相关负责人重新确认后才进入新构建，旧目录保持可查。
技术实现与依据
这里保留实现、关键条件、精确入口、历史记录和验证结果。
精确 rebound、stale fact、stale build 与未关联事实隔离已实现；影响仍只到事实和整个 build，未到单文件/单块关键规则与设计选择
相同字节更新是 no-op，不制造 change set 或 stale。
原文在新版本中唯一存在时创建新 EvidenceSpan 并 source-rebound。
原文消失或出现多个匹配时事实 stale。
只把引用 changed facts 的 current（当前状态） build 标为 stale。
未关联事实保持 fresh，不要求重复确认。
当前 impact 只报告 facts 与 whole builds；没有文件、block、页面或工作表级影响。
下一版仍需处理新增冲突并通过同一 quality gate。
本模块用到的名词
- ChangeSet（变更集）
- 一次来源版本变化的结构化结果，分别记录重新绑定事实、过期事实和过期 build。
- rebound（重新绑定）
- 旧原文在新版本中仍唯一存在，证据换到新 SourceSnapshot，事实保持有效。
- stale build（过期构建）
- 引用发生变化事实的旧构建；文件仍保留，但不能再作为当前正式版本。
专业定义
来源更新不是全文重做：先比较每个证据原文，能唯一找到就接到新版本，找不到或不唯一才要求重新确认。
解决什么
解决一改全废、旧证据继续冒充当前、无关事实被误改和重新生成冒充影响分析的问题。
当前怎样实现
- update_source 先读取新字节、计算 hash（内容指纹），并创建 superseding SourceSnapshot。
- 每个旧 EvidenceSpan 的 quote 在新内容中做精确非重叠匹配。
- 唯一匹配创建新 locator（原件定位记录） 并替换 fact_evidence。
- 失效/重绑定都追加 review event 与新的 fact revision。
- changed fact IDs 反查 ArtifactBlock/Build，把引用变化的 current（当前状态） build 标 stale。
- ChangeSet 分表保存 impacted、rebound 和 build IDs。
执行流程
- 1
选择新来源版本
- 2
比对内容hash（内容指纹）
- 3
创建新snapshot
- 4
逐证据查唯一原文
- 5
自动rebound或标stale
- 6
更新fact revision
- 7
标记相关old build
- 8
查看impact并决定下一版
边界
- 只做精确原文匹配，不做语义相似重绑
- 多处匹配不猜
- 影响不精确到单Office文件
- 旧build不自动删除
- 来源更新不自动生成下一版
失败与恢复
- 新来源与旧版本字节相同
- 返回 no-op，不创建人工变化或过期记录。
- 旧原文在新版本出现多次
- 事实保持 stale，要求明确新证据，不按第一个匹配猜测。
- 更新事务中断
- SQLite 回滚，current（当前状态） snapshot、facts 和 builds 保持上一可靠状态。
真实入口
PRIVATE source · store.py update_source快照更新、精确匹配、rebound、stale和事务
PRIVATE source · acceptance.py两套合成来源变化与未关联事实回归
PRIVATE tests · core change tests真实失效、唯一重绑、无关事实隔离和旧build过期
如何验证
- 真实失效事实和旧 build 同时 stale。
- 唯一原文自动 rebound 且保持有效。
- 未关联事实不被误改。
- 显式重新确认可绑定当前来源版本。
- 事实/整 build 之外的影响粒度仍未实现。
与其他模块的关系
本模块决定旧结果是否还能用；最终时间价值、失败恢复和未闭合证据由下一模块统一说明。