用途与实际影响
这项功能怎样使用
为什么需要它
最新表达可能只是补充或临时安排，历史表达也可能仍支持长期理解；同时，旧任务拿着旧卡回写会把后来的更正覆盖。存储时间线和认知取舍必须分开。
举个实际例子
我说“这次为了赶时间先这样，平时还是按原来的”。AI 把它记为有语境的临时取舍，不改成永久偏好；另一个旧任务稍后回写时发现现行版本变了，会先重读再合并。
最后我会得到什么
得到保留原时间、来源和变化类别的表达，以及共同更新的摘要、详述与证据；重试、无变化和冲突有不同结果，历史原话仍可回查。
可以用于当前帮助
新的本人表达与现行版本核对后保存并读回；同一次重复提交不制造两份新认识，没有语义变化也如实说明。
需要分辨
同一请求出现不同内容，或旧任务想覆盖后来更正时先停下、重读现行说法，再判断怎样合并。
当前不可用
写入或显示用文件刷新失败时先查记录是否已保存，不凭一次报错盲重写。
从哪里开始
直接说明一个新想法、更正或“这次例外，平时仍按旧习惯”。
需要准备什么
- 这次新的本人原话或更正
- 它针对哪项现行理解（若不明显）
从开始到拿到结果
- 1
系统核对并处理
分清永久变化和一次性取舍，核对现行版本后合并；并发旧任务发现冲突须重读。
- 2
交付与接续
交回真正保存并读回的表达；失败或无变化分别说明，旧原话仍可追溯。
技术实现与依据
这里保留实现、关键条件、精确入口、历史记录和验证结果。
schema（数据结构） 6 已实现四类表达变化、证据角色与投递版本检查；聚合 72 条 current（当前状态）、67 条 historical，不公开具体原话关键规则与设计选择
current（当前状态）/historical/withdrawn 是存储状态，不是事实真伪或证据权重。
supplement 默认保留未撤回旧内容；temporary 使用真实适用范围，不凭空给偏好设过期日。
correction/withdrawal 必须用 related-statement-id 指向同键旧表达；未来生效的更正按时间生效。
同键当前明示必须被考虑和引用，但可作反例或语境；不再一律阻断有依据的模型认识。
历史原话可支持明确限定过去的认识；已纠正错误不再支持现行事实，仍可解释认识变化。
程序让卡片 stale 只要求复核，不能代替模型判断旧认识已经被推翻。
本模块用到的名词
- Idempotent（幂等）
- 相同投递已经处理，不插入第二份，也不再次让卡失效；后来再次真实表达属于另一个事件。
- Current conflict（现行版本冲突）
- 读取后已经出现新的版本，必须先理解新内容再决定如何合并。
- Statement transition（表达变化）
- 补充、临时、更正与撤回是不同语义，由 AI 按本人原话判断。
专业定义
我可以补充一件旧事、临时改变选择或明确撤回旧话；系统保留这些差别，不用一条新记录把旧认识全部推翻。
解决什么
解决补充被当作撤回、临时选择变永久、历史原话失去语境、投递重复和旧版本静默覆盖。
当前怎样实现
- preference_statements 保存 transition_kind、related_statement_id、原生生效时间、来源与投递身份；按同键时间线维护 current（当前状态） 与历史。
- writeback_deliveries 以 delivery_id 固定 operation、caller_project、origin_ref、payload SHA-256 与已返回结果；同一重试复用结果，不再次插入或令旧卡失效。
- expected-current-id 对 record 使用 statement_id、对 snapshot 使用 snapshot_id；尚无该键须在真实读取后声明 none/null，不混用编号。
- snapshot_evidence 与 snapshot_statement_evidence 保存 supports/contradicts/context；改编号或角色须显式提交经复核 detail。
- snapshot-batch 一次绑定各卡 expected_current_ids，保持同一投递的稳定身份；旧数组输入保留兼容。
- 用户原话进入 record，模型理解进入 snapshot；程序不把助手总结改成用户明示，也不为凑一种证据类型造假记录。
执行流程
- 1
读取相关当前表达或卡
- 2
按原话区分四种变化
- 3
保留原时间与出处
- 4
固定投递身份和现行版本
- 5
验证引用及证据角色
- 6
提交相关表达/认知
- 7
更新同源视图并回读
- 8
用当前问题检查是否正确使用
边界
- 不从订单或助手文本自动写成本人明示。
- 不同 key 的真实语义仍由 AI 判断，不靠键名机械合并。
- 不删除原件或历史成果，不把同一事实跨平台复述算成独立证据。
- 没有独立 history/undo 浏览命令不等于没有原话关系、撤回语义或版本保留。
失败与恢复
- 相同 delivery-id 使用不同载荷
- 返回 delivery_conflict，找回原请求，不换一个新编号掩盖冲突。
- expected-current-id 与当前不同
- 返回 current_conflict，重读最新表达或卡，AI 判断合并或重建。
- 证据或角色改变却没有复核详述
- 拒绝沿用旧解释；补齐本次准确的摘要、详述和证据后再提交。
- 数据库提交后视图刷新失败
- 先查现存记录与投递结果，再恢复同源视图，不能盲目再次 record。
真实入口
DOMAIN_CONTRACT.md四种变化、证据取舍、可靠投递和并发冲突
daily_preferences.py / schema.sql表达、认知、角色和writeback_deliveries实现
tests/test_writeback.py / test_personal_background.py幂等、冲突、历史语境和认知更新回归
如何验证
- 当前合成回归包含投递重试、不同载荷冲突、旧版本拒绝、明确撤回/更正、历史明示和证据角色。
- 2026-09-07 基线有 185 项 Python 与 14 个子测试通过；本批没有向个人数据库 record、snapshot 或 ingest。
与其他模块的关系
它保证认识可以可靠演化；是否认同一种解释仍取决于真实语境与证据，程序状态不会替本人做决定。