更新记忆

HaroCue 不把记忆当作可以被模型随意覆盖的字段。更新是用户明确发起的、带来源和版本的控制动作；它会留下关系，让你知道旧认识为什么不再进入当前 Cue。

选择正确的动作

动作	发生什么	适合什么时候用
纠正	写入新的 User Claim，并保留 Corrects 关系	原来的表述或事实不对
停止使用	记录带生效时间的 Transitions	以前成立，后来不再适用
局部例外	在明确工作区内建立规则	某个项目需要不同处理方式
重新表述	通过新 Claim 替代旧正文，不直接编辑历史	只是想换一种说法

判断方法 先看原始依据，再区分「以前就错了」和「后来发生变化」。两者需要不同的关系和生效时间。

纠正错误

处理步骤

1. 点开记忆节点，查看原始依据和当前状态。
2. 选择「纠正这条」，输入替代内容，或只撤回旧 Claim。
3. 系统在一次事务中写入新的 UserInput Evidence 和 User Claim。
4. 撤回旧 Claim，并建立 Corrects 关系。

结果

旧认识仍可在历史检查中看到，但不再作为当前有效记忆。新 Claim 要重新通过作用域、来源和时间资格检查。

停止使用

当世界没有错、只是从某个时间起不再适用时，选择「停止使用」。系统写入一条用户决定，并用 Transitions { effective_at } 记录生效时间。

这样可以保留变化前的历史，而不把「以前成立」改写成「从来不成立」。查询的 valid_at 到达生效时间后，新的状态才会影响 Cue。

建立局部例外

在另一个明确工作区中添加局部规则时，产品会检查基础 Claim 确实属于另一个工作区，但不会跨作用域建立一条可互相读取的关系。当前工作区的具体规则可以优先于用户授权的全局偏好。

为什么不能直接改文字

直接编辑旧 Claim	通过新 Claim 纠正
历史依据和变化原因容易丢失	保留 Corrects 关系和原始来源
旧的 Cue 快照难以判断是否过期	revision 变化会让旧快照重新验证
模型可以悄悄改变用户含义	用户动作明确写入 UserInput 和 User

模型整理可以补充实体关系，但不能代替用户作出真值裁决。

并发与版本

校验字段	保护什么	失败时怎么做
expected_revision	防止覆盖别人刚写入的变化	刷新后重新选择
scope_epoch	防止清空或切换工作区后的旧任务写回	丢弃旧动作
来源与保留期	防止引用已经不可读的原文	重新选择有依据的来源

内核先在副本中完整校验，再通过 CAS 提交。工作区切换、并发写入、来源过期或 Claim 已被遗忘时，操作会返回冲突或找不到；界面不能自动把旧动作重放到新状态。

记忆包和回顾草稿同样是快照。删除、纠正或新提交后，运行时会重新验证它们；旧包不能凭空撤回已经显示的文字，所以展示前的复核是必要的。

相关代码

用户界面的 apply_memory_correction 最终进入 ProductMemoryService::correct；核心动作定义在 crates/harocue-memory/src/model.rs 的 Operation，原子校验和关系写入在 crates/harocue-memory/src/mutation.rs。工作区作用域、局部例外和回顾快照在 crates/harocue-runtime/src/product_memory.rs，前端交互在 frontend/src/main.ts 与 frontend/src/knowledge-map.ts。

下一步

• 搜索记忆：确认新的 Claim 是否有资格进入结果。
• 删除记忆：不希望内容继续被使用时如何遗忘。
• 记忆评估：验证纠正是否真的改变了读取结果。