correction-pipeline

更正流程

**约定：**参见 conventions/brain-first.md — 根因链的第 1 步就是先执行 brain-first 查找链（精确词条用 search， 概念型问题用 query），然后再进行其他操作。

**约定：**参见 _brain-filing-rules.md — 更正时直接编辑页面；页面仍按主要主题归档。

触发条件

用户指出的任何事实错误。没有例外。不要说“我会记下来”。

（将请求路由至此是 harness 约定，并非机械保证；但一旦启用此技能，上述无例外要求就是必须遵守的准则。）

立即响应

1. **承认错误。**不要辩解，不要解释。只需说：“你说得对。我弄错了。”
2. 引用具体的错误说法，让用户知道你准确理解了哪里出错。
3. 陈述正确事实，以用户提供的内容为准。

根因分析（要执行这些步骤，而不只是记一笔）

按顺序执行以下步骤，并向用户报告发现。

步骤 1：搜索 brain

gbrain search "<relevant terms>" --limit 10

对于概念型或使用同义表达的说法，升级为 gbrain query "<question>"（LLM 扩展可找回 search 遗漏的表达）。要列出所有包含该说法的已索引页面，请使用关键词搜索（会分页显示每个匹配项）；只有尚未同步的编辑才在检出目录中使用 grep 搜索：

gbrain search '"<wrong claim terms>"' --match keyword
BRAIN_DIR=$(gbrain config get sync.repo_path)
grep -ri "<wrong claim terms>" "$BRAIN_DIR/people/" "$BRAIN_DIR/companies/" "$BRAIN_DIR/concepts/" 2>/dev/null

**问题：**错误事实是否存在于 brain 中？如果是 → brain 就是污染源。修复 brain 页面（步骤 6）。

步骤 2：搜索记忆文件

使用 grep 搜索 harness 始终加载的记忆文件（例如工作区的 MEMORY.md 及任何 memory/*.md 配套文件 — 具体位置取决于你的 harness）：

grep -ri "<wrong claim terms>" <memory files> 2>/dev/null

**问题：**错误事实是否存在于记忆中？如果是 → 记忆就是污染源。修复记忆文件。

步骤 3：检查 SOUL.md 和 USER.md

grep -i "<relevant terms>" <workspace>/SOUL.md <workspace>/USER.md 2>/dev/null

**问题：**是否存在可能导致错误推断的误导性段落？每个上下文窗口都会加载 SOUL.md 和 USER.md — 此处含糊或有歧义的语句会影响每个会话。

**重要：**在 gbrain 安装中，这些文件由引导问答库（state/interview.json）渲染生成。在此记录发现；修复必须在步骤 6 中通过问答库完成，绝不能直接编辑渲染后的文件。

步骤 4：检查事实表

gbrain recall <entity-slug>            # facts about the subject, newest first
gbrain recall --grep "<claim terms>"   # substring filter when the entity is unclear

是否存在置信度较高的错误事实？记下其事实 ID。

步骤 5：分类错误

分类	说明	修复位置
BRAIN_ERROR	brain 页面中存在错误事实	在 brain 仓库中编辑页面、提交并重新同步
MEMORY_ERROR	记忆文件中存在错误事实	修复记忆文件
SOUL_USER_ERROR	SOUL.md 或 USER.md 中存在误导性段落	修复问答库并重新渲染 — 绝不修改渲染后的文件
FACTS_TABLE_ERROR	gbrain 事实表中存在错误事实	recall → forget <fact-id> → remember 更正内容
HALLUCINATION	没有来源 — LLM 根据部分信号编造内容	指明污染向量（哪些部分信号导致了错误），写入一条防护事实
STALE_DATA	事实过去正确，但现在已不再正确	使用当前事实更新来源，并以新事实取代过时事实
CROSS_CONTAMINATION	将关于人物 A 的正确事实归到了人物 B 名下	修正来源中的归属 — 涉及双方实体

第 6 步：修复来源

• **BRAIN_ERROR：**在 brain 仓库中编辑页面文件。在更正的那一行添加 [Source: user correction, YYYY-MM-DD]。提交后运行 gbrain sync，让数据库反映修复结果。（如果只编辑数据库行而不修改 仓库文件，或反过来，二者就会不一致，直到下次同步时其中一个被覆盖。）
• **MEMORY_ERROR：**编辑记忆文件。添加一条带日期的更正说明。
• **SOUL_USER_ERROR：**绝不要直接编辑 SOUL.md / USER.md——它们是 渲染生成的文件，手动编辑会在下次渲染时悄无声息地丢失。请在共享的引导 答案库中修正底层答案，然后重新渲染：

  gbrain bootstrap interview --set KEY "corrected value"   # verbatim, user's words
  gbrain bootstrap interview --show                        # read back
  gbrain bootstrap interview --status                      # get the confirm hash
  gbrain bootstrap interview --confirm <hash>
  gbrain bootstrap render --only SOUL.md --force           # repeat per affected file
  

  完整的访谈规范（复述确认流程、逐字记录答案、备份行为）位于 skills/soul-audit/SKILL.md 中—— 只修复单个键之外的任何问题，都应按此流程处理。
• **FACTS_TABLE_ERROR：**将错误的行标记为过期，并附上来源信息写入更正内容：

  gbrain recall <entity-slug>                                  # find the fact id
  gbrain forget <fact-id>                                      # expire the wrong fact
  gbrain remember "<correct fact>" \
    --provenance "user correction, YYYY-MM-DD" --entity <entity-slug>
  

• **HALLUCINATION：**没有可修复的来源。找出引发虚构内容的部分线索，然后添加防护，避免它再次引发类似问题：

  gbrain remember "WRONG: <what was said>. RIGHT: <what is true>. Guard: <instruction to prevent recurrence>" \
    --provenance "user correction, YYYY-MM-DD (hallucination guard)" --entity <entity-slug>
  

• **STALE_DATA：**使用 BRAIN_ERROR 流程更新来源页面，写入当前的准确信息，并替换任何过时的事实行（使用 forget 删除旧记录，再用 remember 记录当前准确信息及新的来源信息）。
• **CROSS_CONTAMINATION：**在来源处修正归属，然后检查两个实体：人物 A 的页面和事实记录（事实现在是否位于正确位置？），以及人物 B 的页面和事实记录（错误归属的痕迹是否已全部清除？）。

第 7 步：检查传播情况

错误事实可能已传播到其他 brain 页面、综合输出或记忆文件中。

gbrain search '"<wrong claim terms>"' --match keyword
grep -ri "<wrong claim terms>" "$BRAIN_DIR" 2>/dev/null | grep -v ".git"   # edits not yet synced

修复所有实例，而不只是第一个找到的实例。修改仓库后重新同步。

第 8 步：向用户报告

简短报告：

**Error:** [what was wrong]
**Root cause:** [BRAIN_ERROR | HALLUCINATION | etc.]
**Source:** [specific file/line or fact id, or "no source — confabulated from X"]
**Fixed:** [what was changed, where]
**Propagation:** [other files fixed, or "no propagation found"]

严重程度级别

级别	描述	处理方式
S1 — 身份错误	关于用户的家庭、血统、历史或核心身份的错误事实	立即修复。这些错误会污染一切——每次综合、每个书籍镜像、每次对话。
S2 — 实体错误	brain 中关于某个人、公司或交易的错误事实	修复 brain 页面，并检查传播情况
S3 — 情境错误	对用户当前状态、感受或处境的错误推断	使用 remember 添加防护事实。通常属于幻觉。
S4 — 轻微事实错误	日期、数字或细节错误	修复来源，无需检查传播情况

需要留意的重复错误模式

模式	示例	防护措施
强行套用心理治疗叙事	“你一直在逃避与联合创始人的艰难对话”（没有证据）	在对用户的行为或状态作出判断前，先检查日历和行为数据
自动将姓名纠正为名人	一位名叫 alice-example Cho 的联系人被悄悄替换为一位姓名相似的名人	用户身边的人比世界名人优先——先在 people/ 中查找确认
混淆观点与事实	把观点表中的看法写入事实记录	观点 = 他人的看法。事实 = 用户的个人知识。
仅依据会话上下文作出枚举性断言	“你在两家公司工作过”——漏掉了只记录在 brain 中的那家公司	没有先搜索 brain，绝不要作出枚举性断言（如“你所有的 X”“每个 Y”“你 Z 的三次经历”）。会话上下文总是不完整的。
常驻加载文件中缺少数据	核心事实只存在于 brain 页面中，而不在 USER.md/MEMORY.md 中，导致每次会话都会重新推导出错误结论	当更正揭示常驻加载文件存在缺漏时，通过适当的入口补上缺失数据（渲染生成的文件使用答案库，记忆文件直接编辑），以便它出现在今后的每个上下文窗口中

补充：矛盾探测

此技能是响应式的——当用户指出错误时触发。随附的矛盾探测是同一套规范中的主动部分：它会在用户发现之前找出大脑内部的冲突。

gbrain eval suspected-contradictions   # run the probe
gbrain find-contradictions             # read the latest run's findings

如果更正揭示了一类冲突（例如两个页面对日期说法不一），请随后运行探测——大脑中其他地方可能也存在相同的污染模式。

约定

此技能保证：

• 每个事实错误都会追溯到根因，而不只是记录下来
• 在该类错误真正需要修复的地方修正来源（编辑页面 + 提交 + 重新同步；对事实行使用 forget/remember；对 SOUL/USER 使用答案库 + 重新渲染——绝不直接编辑渲染后的文件）
• 检查传播情况（全脑 grep + gbrain search）
• 向用户清楚说明错在哪里、原因是什么，以及修复了什么
• 路由与 frontmatter 中的规范触发条件一致
• 保持隐私约定：不使用真实姓名、特定分支的文件系统路径字面值或上游分支引用

输出格式

此技能的输出是第 8 步的根因报告，在对话中直接交付；同时应用所有源修复（提交并重新同步 brain-repo 编辑；使事实行过期或被取代；从答案库重新渲染身份文件）。

去重（明确边界）

• skills/maintain/SKILL.md — 主动维护大脑健康（过时页面、孤立项、引文、doctor）。此技能是响应式的：追溯用户具体更正所涉及的污染源。如果没人说“这不对”，那就归 maintain 管。
• 矛盾探测（gbrain eval suspected-contradictions / gbrain find-contradictions）——主动检测大脑内部的冲突。两者互为补充，并不重叠：探测会找出两个大脑来源之间的冲突；此技能则从用户提供的更正入手。
• skills/soul-audit/SKILL.md — 完整的身份重新访谈流程。此技能会在修复 SOUL_USER_ERROR 时委派给它；绝不重新实现访谈或渲染流程。
• skills/citation-fixer/SKILL.md — 引文格式合规性。更正陈述的真实性属于此技能；修复真实陈述的引文方式属于 citation-fixer。
• frontmatter-guard（主机端）——结构性页面验证（YAML 格式），而非陈述真实性验证。

失败时的处理

遇到任何 gbrain 错误 code、退出代码、[AGENT] 块或通知块时，请遵循Agent 操作员协议。此技能特有的情况：

• forget <fact-id> / remember 返回 fact_not_found 或 fact_already_expired：重新运行 recall 获取当前事实 ID；绝不要猜测 ID 来执行 forget。
• 页面修复返回 revision_conflict：重新读取页面，将更正应用到当前文本，并以新版本保存。
• write_pending（退出代码 10）：更正已被接受，但尚未提交；在告知用户已修复之前，先轮询 gbrain write-request <request_id>。

反模式

• “记下了，我会记住。” 不行。追溯来源。修复来源。
• 只修复记忆，却不检查大脑。 大脑是持久存储。记忆会被清空。
• 直接编辑 SOUL.md / USER.md。 它们由答案库渲染而来；手动编辑会在下次渲染时失效，错误也会再次出现。修复答案，然后重新渲染。
• 编辑 brain-repo 文件却不重新同步（或修改数据库行却不提交）。 两个存储会发生偏差，下次同步时错误又会复现。
• 只修复一个实例，却不检查传播情况。 错误事实会扩散。
• 归咎于幻觉，却不找出部分信号。 每次幻觉都有源头——找到它。
• 采取防御性回应。 承认错误之前，绝不要解释自己为什么会弄错。