chore: stop tracking local claude plans

2026-05-15 22:30:38 +08:00 · 2026-04-03 14:43:03 +08:00
parent 613e9f17fb
commit 715ae0ca05
3 changed files with 1 additions and 716 deletions
--- a/.claude/plans/hide-engine-decouple-and-timer-blockers-plan.md
+++ b/.claude/plans/hide-engine-decouple-and-timer-blockers-plan.md
@@ -1,353 +0,0 @@
-# ST-BME：旧楼层隐藏解耦 + Timer Blocker 修复计划
-
-## 这份计划是给谁看的
-
-给接手这件事的另一个 AI / 开发者快速建立上下文用。  
-目标是让对方**不用再向用户追问背景**，直接理解：
-
-1. 用户真正想解决的痛点是什么
-2. 目前代码已经修到哪一步了
-3. 当前还卡着哪些 blocker
-4. 下一步该按什么顺序、以多保守的方式去改
-
---
-
-## 用户的真实痛点
-
-用户要的不是单纯“修一个 bug”，而是下面这套行为最终成立：
-
-1. **主 AI 节省 token**
-   旧楼层自动隐藏，主 AI 不再看到太老的消息
-2. **BME 仍能正常提取**
-   即使旧楼层被隐藏，BME 也还能按固定上下文窗口读取所需消息，不会因为隐藏而读不到
-3. **不要再因为隐藏状态变化误触发历史恢复**
-4. **不要让 `is_system` 成为隐藏系统与提取系统之间的耦合桥梁**
-
-用户想要的理想设计可以概括成一句话：
-
-> 旧楼层隐藏只负责 `/hide` / `/unhide`，BME 提取自己按固定窗口读消息，两套逻辑解耦。
-
---
-
-## 当前已经确认的事实
-
-### 1. 当前隐藏逻辑不是纯 `/hide`
-
-当前仓库里的旧楼层隐藏是**双轨**：
-
-1. 调宿主 `/hide N-M` / `/unhide N-M`
-2. 同时本地改 `message.is_system`
-3. 同时同步 DOM 上的 `is_system` attribute
-
-证据：
-
- [hide-engine.js](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\hide-engine.js)
-  - `markManagedSystemRange`
-  - `restoreManagedSystemFlags`
-  - `syncSystemAttribute`
-  - `runHideApply`
-
-### 2. 当前 BME 提取链路确实会按 `is_system` 跳过消息
-
-这点非常关键，说明“只删隐藏引擎里的 `is_system` 双写”还不够。
-
-证据：
-
- [chat-history.js](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\chat-history.js)
-  - `isAssistantChatMessage(message) => !message.is_user && !message.is_system`
-  - `buildExtractionMessages(...)` 中 `if (msg.is_system) continue`
-  - playableSeq / assistant floor 映射里也会跳过 `is_system`
- [index.js](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\index.js)
-  - 例如 `pendingMessages = ...filter((msg) => !msg.is_system)`
-
-结论：
-
-> 当前 BME 的“可提取消息集合”仍然受 `is_system` 影响。
-
-### 3. 历史 hash 误恢复问题已经基本修过一轮
-
-已经做过的修复：
-
-1. `buildMessageHash` 已不再把 `isSystem` 计入 hash
-2. 已加入 `processedMessageHashVersion` 迁移逻辑
-3. 之前“隐藏状态变化 -> hash 脏 -> 误触发历史恢复”的链路，实测已明显缓解
-
-证据：
-
- [runtime-state.js](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\runtime-state.js)
- [index.js](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\index.js)
-
-结论：
-
-> 现在“是否能做纯 `/hide` 设计”的主要阻碍，已经不再是 hash，而是提取链路仍依赖 `is_system`。
-
-### 4. 当前还有独立的事件层 blocker，导致测试结果会被污染
-
-已发现两类 `Illegal invocation`：
-
-1. `MESSAGE_RECEIVED` 路径里的 `queueMicrotask` 借壳调用问题
-2. `CHAT_CHANGED` 路径里的 `clearTimeout` 借壳调用问题
-
-用户最新测试显示：
-
- 新聊天刚切换时就在 `onChatChangedController` 崩掉
- 面板出现“等待图谱加载”
- 这种状态下继续测自动提取 / 隐藏逻辑，结论不干净
-
-证据：
-
- [event-binding.js](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\event-binding.js)
-  - `onChatChangedController`
-  - `scheduleSendIntentHookRetryController`
-  - `onMessageReceivedController`
-
---
-
-## 用户当前最关心的两个问题
-
-### 问题 A：最终能不能做成“只 `/hide`，不碰 `is_system`”？
-
-答案：
-
-**可以朝这个方向改，但不能只改 hide-engine。**
-
-如果只删：
-
- `markManagedSystemRange`
- `restoreManagedSystemFlags`
-
-而不改提取链路，那么当前 BME 仍然可能因为：
-
-1. 宿主 `/hide` 自己修改了 `is_system`
-2. 或者 BME 当前仍按 `is_system` 过滤消息
-
-而导致：
-
- 提取读不到被隐藏楼层
- assistant turn 识别错位
- 上下文窗口与可见消息集合混在一起
-
-### 问题 B：现在能不能继续测聊天行为？
-
-答案：
-
-**不建议。**
-
-因为 `onChatChangedController` 当前还有 `Illegal invocation`，会污染新聊天初始化流程。  
-在这个 blocker 修掉之前，继续测：
-
- 自动提取是否触发
- 图谱加载是否正常
- 隐藏与提取是否协同
-
-得到的结果都不可靠。
-
---
-
-## 对另一个 AI 的核心提醒
-
-### 不要误判为“只要去掉 hide-engine 的 `is_system` 双写就结束了”
-
-真正需要拆开的，是两件事：
-
-1. **主 AI 的上下文可见性**
-   由 `/hide` / `/unhide` 控制
-2. **BME 提取的上下文读取**
-   应由 `extractContextTurns` 等窗口逻辑控制
-
-当前代码里，这两件事都还部分依赖 `is_system`，所以必须一起梳理。
-
-### 不要误判为“继续沿用 `runtime.clearTimeout(...)` 直接调用没问题”
-
-当前已经出现实证：
-
- `queueMicrotask` 直接借 runtime 调用会触发 `Illegal invocation`
- `clearTimeout` 直接借 runtime 调用也会触发 `Illegal invocation`
-
-说明这些原生 API 不适合直接裸调 runtime 透传引用。
-
---
-
-## 推荐方案总览
-
-建议按两个阶段推进，而不是混成一个大改：
-
-### 阶段 1：先清理事件层 blocker，恢复干净测试环境
-
-#### 目标
-
-修掉新聊天 / 收消息路径里的 `Illegal invocation`，确保后续功能测试有效。
-
-#### 推荐修法
-
-不要粗暴把所有 `runtime.setTimeout/clearTimeout` 改成 `globalThis.*`。  
-更稳的做法是：
-
-1. 在 [event-binding.js](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\event-binding.js) 中引入一个本地 timer wrapper
-2. 模式与 [hide-engine.js](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\hide-engine.js) 的 `getTimerApi()` 保持一致
-3. 继续优先使用 runtime 提供的 timer
-4. 但通过 `Reflect.apply(..., globalThis, args)` 安全调用
-
-#### 理由
-
-这样可以同时保留：
-
-1. runtime 注入 timer 的可测试性 / 可替换性
-2. 避免 `Illegal invocation`
-3. 与仓库现有模式一致，降低风格分裂
-
-#### 阶段 1 需要修改的点
-
- [event-binding.js](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\event-binding.js)
-  - 新增本地 `getTimerApi(runtime)` 或等价 helper
-  - `scheduleSendIntentHookRetryController`
-  - `onChatChangedController`
-  - 如有其他 runtime timer 裸调，也一起替换
-
-#### 阶段 1 验收标准
-
-1. 新开聊天不再报 `onChatChangedController ... Illegal invocation`
-2. 收到 assistant 消息时不再报 `onMessageReceivedController ... Illegal invocation`
-3. 新聊天可以正常进入图谱加载 / 自动提取链路
-
---
-
-### 阶段 2：推进“纯 `/hide` + 提取解耦”
-
-#### 目标
-
-最终实现：
-
-1. 隐藏系统只负责主 AI 可见性
-2. BME 提取系统只负责按窗口读取上下文
-3. `is_system` 不再是两者之间的耦合信号
-
-#### 先做的确认
-
-需要先确认宿主 ST 的 `/hide` / `/unhide` 真实语义：
-
-1. `/hide` 是否会改消息对象的 `is_system`
-2. `/unhide` 是否会恢复
-3. 变化是 UI 层面的，还是底层 chat 数据层面的
-
-这个确认很重要，因为它决定：
-
- 纯 `/hide` 后 BME 是否仍会在当前实现下跳过被隐藏消息
-
-#### 改造顺序
-
-##### 步骤 2-1：清点所有“提取链路按 `is_system` 过滤消息”的位置
-
-重点：
-
- [chat-history.js](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\chat-history.js)
-  - `isAssistantChatMessage`
-  - `getAssistantTurns`
-  - `buildExtractionMessages`
-  - playableSeq / assistantSeq 映射
- [index.js](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\index.js)
-  - 所有影响 extraction 的 `!msg.is_system` 过滤
-
-##### 步骤 2-2：把 extraction 上下文改成按窗口/索引读取
-
-原则：
-
-1. extraction 读取“聊天真实楼层窗口”
-2. 上下文范围由 `extractContextTurns` 控制
-3. 不再把“是否 hidden/system”当成提取可见性的主判据
-
-##### 步骤 2-3：重新定义 assistant turn 识别
-
-当前 assistant turn 识别依赖：
-
- `!message.is_user && !message.is_system`
-
-这会把被隐藏的 assistant 楼层排除掉。  
-需要把“真正系统消息”和“被隐藏的普通历史楼层”区分开来。
-
-##### 步骤 2-4：在确认 extraction 已解耦后，再收敛 hide-engine
-
-届时才安全移除：
-
- `markManagedSystemRange`
- `restoreManagedSystemFlags`
- `syncSystemAttribute`
- `__st_bme_hide_managed` 相关逻辑
-
-让 hide-engine 回归为：
-
-1. 计算范围
-2. 调 `/hide`
-3. 调 `/unhide`
-4. 不再改本地 `is_system`
-
-#### 阶段 2 验收标准
-
-1. 主 AI 仍然只看到最近 N 条消息
-2. BME 在隐藏开启时仍能提取到所需上下文
-3. 手动提取后继续聊天，不再误报历史变化
-4. assistant turn 识别不因 hidden/system 混淆而错位
-
---
-
-## 为什么不建议“现在直接删掉 `is_system` 双写试试看”
-
-因为这会同时引入两个不确定性：
-
-1. 宿主 `/hide` 是否自己也会改 `is_system`，尚未确认
-2. BME 当前 extraction 仍依赖 `is_system` 过滤消息，已确认
-
-如果现在直接删双写，出现问题时将很难判断到底是：
-
-1. 宿主 `/hide` 的语义问题
-2. extraction 过滤逻辑没拆干净
-3. assistant turn 识别仍依赖 `is_system`
-
-因此更稳的方式是：
-
-1. 先恢复干净测试环境
-2. 再把 extraction 与 `is_system` 的耦合逐层拆掉
-3. 最后再收敛 hide-engine
-
---
-
-## 这份计划背后的核心逻辑
-
-### 逻辑 1：主 AI 的“可见性”与 BME 的“可提取性”是两套规则
-
-如果继续让二者共享 `is_system` 这一信号，就会不断出现：
-
- 为了主 AI 节流而牺牲 BME 提取
- 或为了 BME 提取而破坏主 AI 隐藏
-
-### 逻辑 2：当前最大的技术债不是 hash，而是耦合
-
-hash 误恢复这部分已经修过一轮。  
-真正要彻底收尾，必须把：
-
- hide-engine
- extraction
- assistant turn 识别
-
-从“共同依赖 `is_system`”改成“职责分离”。
-
-### 逻辑 3：当前测试 blocker 必须先清掉
-
-在 `CHAT_CHANGED` 和 `MESSAGE_RECEIVED` 都可能因原生 API 借壳调用而报 `Illegal invocation` 的情况下，继续测试高层行为没有意义。
-
---
-
-## 当前建议的执行顺序
-
-1. 修 `event-binding.js` 中 timer / microtask 的安全调用问题
-2. 验证新聊天初始化、图谱加载、自动提取链路恢复正常
-3. 确认宿主 `/hide` / `/unhide` 的真实数据层语义
-4. 梳理 extraction 对 `is_system` 的依赖
-5. 改成按窗口读取提取上下文
-6. 最后移除 hide-engine 的本地 `is_system` 双写
-
---
-
-## 给另一个 AI 的一句话摘要
-
-> 用户的目标不是单纯修 bug，而是把“主 AI 隐藏旧楼层”和“BME 读取提取上下文”彻底解耦：隐藏系统最终应只做 `/hide`/`/unhide`，BME 提取应按固定窗口读真实楼层；当前 blocker 是 `event-binding.js` 中 runtime 透传的原生 timer/microtask API 直接调用导致 `Illegal invocation`，需先用与 `hide-engine.js` 一致的安全 wrapper 修复测试环境，再推进 extraction 去 `is_system` 依赖，最后才能安全移除 hide-engine 的本地 `is_system` 双写。  
--- a/.claude/plans/hide-hash-extraction-fix.md
+++ b/.claude/plans/hide-hash-extraction-fix.md
@@ -1,363 +0,0 @@
-# ST-BME: 隐藏旧楼层 × 自动提取 × 历史恢复 问题修复计划（收紧版）
-
-## 目标
-
-把当前现象拆成两类问题分别处理，避免把“已证实的根因”和“待确认的假设”混在一起：
-
-1. **已证实问题**：隐藏旧楼层会改动 `is_system`，而历史完整性哈希把 `is_system` 算进去，导致误判历史被改动，进而触发错误恢复，甚至形成恢复循环。
-2. **待确认问题**：新聊天里自动提取不启动，当前最可疑的是图谱持久化就绪时序，但还没有足够证据证明它与上面的哈希误判属于同一条因果链。
-
---
-
-## 当前观察到的症状
-
-### 症状 A：新聊天中自动提取似乎不启动
-
- 新开聊天，聊了多层后，“历史状态”仍显示“干净，已处理到楼层 -1”
- 手动点击“手动提取”后，`lastProcessedAssistantFloor` 才推进
-
-### 症状 B：手动提取成功后，再聊一层会误触发历史恢复
-
- 提示类似：
-
-> ⚠ 楼层 4 内容或 swipe 已变化
-> 检测到楼层历史变化，将从楼层 4 之后自动恢复图谱
-
-### 症状 C：触发恢复后界面表现为“提取卡住”
-
- 面板显示“ST-BME 提取 - AI 生成中...”
- Console 没有明显新的推进日志
- 更可能是恢复与后续自动提取反复触发，表现为“看起来挂住”
-
---
-
-## 已确认的代码事实
-
-### 1. 自动提取入口确实存在
-
- [`event-binding.js`](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\event-binding.js) 的 `onMessageReceivedController`
- 收到 assistant 消息后，会排一个 microtask 调用 `runExtraction()`
-
-### 2. 自动提取确实会被图谱未就绪挡住
-
- [`extraction-controller.js`](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\extraction-controller.js) 的 `runExtractionController`
- Guard 3：
-
-```js
-if (!runtime.ensureGraphMutationReady("自动提取", { notify: false })) {
-  runtime.deferAutoExtraction?.("graph-not-ready");
-  return;
-}
-```
-
- [`index.js`](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\index.js) 的 `deferAutoExtraction` / `maybeResumePendingAutoExtraction` 也确实存在持续重试逻辑
-
-### 3. 隐藏旧楼层会直接改 `message.is_system`
-
- [`hide-engine.js`](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\hide-engine.js) 的 `markManagedSystemRange`
- 会把消息对象直接写成 `message.is_system = true`
- 同时写入 `message.extra.__st_bme_hide_managed = true`
- [`restoreManagedSystemFlags`] 会把这些消息重新改回 `is_system = false`
-
-### 4. 历史完整性哈希当前包含 `isSystem`
-
- [`runtime-state.js`](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\runtime-state.js) 的 `buildMessageHash`
-
-```js
-const payload = JSON.stringify({
-  isUser: Boolean(message?.is_user),
-  isSystem: managedHideMarker ? false : Boolean(message?.is_system),
-  text: String(message?.mes || ""),
-  swipeId,
-});
-```
-
-### 5. 历史恢复就是基于这个哈希差异触发的
-
- [`runtime-state.js`](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\runtime-state.js) 的 `detectHistoryMutation`
- [`index.js`](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\index.js) 的 `inspectHistoryMutation` / `recoverHistoryIfNeeded`
-
-因此，**“隐藏逻辑改了 `is_system`，而历史哈希又把 `is_system` 当成内容真相的一部分”这一矛盾是已坐实的。**
-
---
-
-## 根因划分
-
-### 根因 1（已确认）：`is_system` 被错误纳入历史完整性判断
-
-这是症状 B、C 的主根因。
-
-#### 问题链条
-
-1. 某次提取完成后，系统对已处理楼层拍快照
-2. 快照中的哈希包含 `isSystem`
-3. 旧楼层隐藏逻辑随后执行，会改动部分消息的 `is_system`
-4. 后续完整性检查重新计算哈希时，发现同一楼层 hash 不一致
-5. `detectHistoryMutation` 误以为消息内容或 swipe 发生变化
-6. 触发 `recoverHistoryIfNeeded`
-7. 若恢复后又再次遇到同类误判，就可能出现“恢复 -> 再检查 -> 再恢复”的循环
-
-#### 关键结论
-
- `is_system` 在这里更像一种**展示/隐藏副作用**
- 它不应作为“消息历史真实性”的核心判据
- 否则隐藏功能会污染历史恢复机制
-
-### 根因 2（待确认）：自动提取在新聊天中的启动/恢复时序不稳
-
-这是症状 A 的最可疑原因，但**目前还不能写死为已确认根因**。
-
-#### 当前证据
-
- 自动提取入口存在
- Guard 3 会在 DB 未就绪时阻断
- 阻断后会走 `deferAutoExtraction`
- resume 逻辑理论上会持续重试，不是一次失败就永久放弃
-
-#### 当前仍不确定的点
-
- 新聊天里究竟是否一直卡在 `ensureGraphMutationReady`
- 还是 `MESSAGE_RECEIVED` 实际没有按预期命中 assistant 消息
- 还是 defer/resume 被别的状态反复打断
- 还是 load state 在某些聊天中长期停在非 ready 状态
-
-所以，症状 A 目前应视为一个**独立待诊断问题**，而不是直接并入“隐藏哈希误判”这条链。
-
---
-
-## 修复方案
-
-### 修复 A（核心，直接做）：从 `buildMessageHash` 中移除 `isSystem`
-
-**目标文件**：[`runtime-state.js`](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\runtime-state.js)
-
-#### 当前实现
-
-```js
-export function buildMessageHash(message) {
-  const managedHideMarker = Boolean(
-    message?.extra &&
-      typeof message.extra === "object" &&
-      message.extra.__st_bme_hide_managed === true,
-  );
-  const swipeId = Number.isFinite(message?.swipe_id) ? message.swipe_id : null;
-  const payload = JSON.stringify({
-    isUser: Boolean(message?.is_user),
-    isSystem: managedHideMarker ? false : Boolean(message?.is_system),
-    text: String(message?.mes || ""),
-    swipeId,
-  });
-  return String(stableHashString(payload));
-}
-```
-
-#### 建议修改
-
-```js
-export function buildMessageHash(message) {
-  const swipeId = Number.isFinite(message?.swipe_id) ? message.swipe_id : null;
-  const payload = JSON.stringify({
-    isUser: Boolean(message?.is_user),
-    text: String(message?.mes || ""),
-    swipeId,
-  });
-  return String(stableHashString(payload));
-}
-```
-
-#### 理由
-
- `is_system` 的变化不等于消息内容被编辑
- `text + swipeId + isUser` 已经足够覆盖绝大多数真正影响提取语义的变化
- 这能直接切断“隐藏副作用 -> hash 变化 -> 误恢复”的链路
-
-#### 风险
-
- 如果用户真的手动把一条消息从普通消息改成系统消息，这个变化将不再被历史恢复逻辑视为“内容变更”
- 但这种操作相对罕见，而且比起当前误恢复问题，这个代价是可以接受的
-
-### 修复 A-1（必须配套）：加入快照哈希版本迁移
-
-**这不是可选备注，而应作为正式方案的一部分。**
-
-如果只改 `buildMessageHash` 而不做迁移：
-
- 旧快照是“含 `isSystem`”算法算出的
- 新代码会用“不含 `isSystem`”算法重新计算
- 第一次完整性检查几乎必然把所有已处理楼层判成 dirty
- 这会触发一次高代价恢复/重建
-
-#### 推荐做法
-
-给历史快照引入一个明确的 hash schema version，例如：
-
- `historyState.processedMessageHashVersion = 2`
-
-加载图状态时：
-
-1. 若版本缺失或旧于当前版本
-2. 不走“历史被篡改”的判断
-3. 直接清空旧 `processedMessageHashes`
-4. 基于当前聊天内容重新拍一份新快照
-5. 更新版本号
-
-#### 目标
-
- 避免升级后第一次运行就误触发一次全量恢复
- 把这次变化当成“哈希算法升级”，而不是“聊天历史损坏”
-
-### 修复 B（设计收敛，次优先）：减少或移除 BME 对 `is_system` 的双写
-
-**目标文件**：[`hide-engine.js`](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\hide-engine.js)
-
-当前隐藏引擎已经调用宿主的 `/hide` 和 `/unhide`，但仍然自己改：
-
- `message.is_system`
- DOM 上的 `is_system` attribute
- `__st_bme_hide_managed`
-
-这说明现在是“宿主隐藏 + BME 本地 system 标记”双轨并存，副作用偏大。
-
-#### 建议
-
-先确认宿主 `/hide` 的真实语义：
-
-1. `/hide` 是否已经足以让主 AI 和 UI 正常隐藏旧消息
-2. `/hide` 是否会自行管理 `is_system`
-3. BME 是否还有任何逻辑依赖 `message.is_system` 来跳过消息
-
-#### 若确认不再需要本地双写
-
-则逐步去掉：
-
- `markManagedSystemRange`
- `restoreManagedSystemFlags`
- `syncSystemAttribute`
- `__st_bme_hide_managed` 相关用途
-
-#### 注意
-
-这一步是“降低副作用、收敛设计”的改进，不是修复症状 B/C 的前提。  
-**真正阻断误恢复的是修复 A。**
-
-### 修复 C（诊断，尽快做）：给自动提取 guard 和 resume 点加日志
-
-**目标文件**：
-
- [`extraction-controller.js`](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\extraction-controller.js)
- [`index.js`](C:\Users\brian\OneDrive\Desktop\ST-Bionic-Memory-Ecology-past\index.js)
-
-#### 建议打点位置
-
-1. `runExtractionController` 每个 return 前
-2. `ensureGraphMutationReady` 返回 false 的分支
-3. `deferAutoExtraction`
-4. `maybeResumePendingAutoExtraction`
-5. `onMessageReceivedController` 命中 assistant 消息时
-
-#### 目标不是长期保留大量日志
-
-而是回答这几个问题：
-
- 新聊天时是否真的进入了 `runExtraction`
- 是否总卡在 `graph-not-ready`
- defer 是否持续排队
- resume 是否真的被触发
- resume 后是否又被 `extracting` / `history-recovering` / `graph-not-ready` 打回
-
-只有拿到这些证据，才能决定症状 A 下一步是：
-
- 调整 load-ready 时机
- 在 chat loaded / chat changed 后主动 resume 一次
- 还是修正 assistant message 识别逻辑
-
---
-
-## 不建议在文档里写死的说法
-
-以下表述建议从“结论”降级为“待验证假设”：
-
-### 1. “三个症状是同一条因果链”
-
-建议改为：
-
- 症状 B/C 已有统一根因
- 症状 A 暂时独立排查
-
-### 2. “自动提取比隐藏重算更早执行，因此会读到隐藏中间态”
-
-从当前代码时序看，这个说法不够稳。
-
- 自动提取：`MESSAGE_RECEIVED` microtask
- 隐藏重算：`GENERATION_ENDED` 后 180ms 调度
-
-更稳妥的写法是：
-
- 隐藏逻辑会改动消息对象的 `is_system`
- 历史哈希又把 `is_system` 算进去了
- 因此在后续任一完整性检查时都可能误判 dirty
-
-不必把主要解释建立在“正好撞上中间态”之上。
-
---
-
-## 实施顺序
-
-1. **先做修复 A**
-   从历史哈希中移除 `isSystem`
-2. **立刻配套修复 A-1**
-   加入快照哈希版本迁移，避免升级后误触发全量恢复
-3. **并行做修复 C**
-   加最小必要日志，单独定位症状 A
-4. **最后评估修复 B**
-   收敛隐藏引擎，减少 `is_system` 相关副作用
-
---
-
-## 验收标准
-
-### 针对症状 B/C
-
-1. 手动提取成功后，再聊一层
-2. 不再出现“楼层 X 内容或 swipe 已变化”的误恢复提示
-3. `recoverHistoryIfNeeded` 不会因为纯隐藏操作反复触发
-4. 面板不会再卡在“AI 生成中...”但无实际推进
-
-### 针对升级迁移
-
-1. 更新到新版本后
-2. 不因 hash 算法变化直接触发一次全量恢复
-3. `processedMessageHashes` 能平滑迁移到新版本
-
-### 针对症状 A
-
-1. 新聊天中收到 assistant 消息后能看到明确日志链路
-2. 能判断问题究竟发生在：
-   - 事件未命中
-   - graph-not-ready
-   - defer/resume 丢失
-   - history-recovering 打断
-   - 其他 guard
-
---
-
-## 关键文件索引
-
-| 文件 | 关键函数 | 用途 |
-|------|----------|------|
-| `runtime-state.js` | `buildMessageHash` | 历史完整性哈希计算 |
-| `runtime-state.js` | `snapshotProcessedMessageHashes` | 拍快照 |
-| `runtime-state.js` | `detectHistoryMutation` | hash 对比与 dirty 判断 |
-| `hide-engine.js` | `markManagedSystemRange` | 本地写 `is_system` |
-| `hide-engine.js` | `restoreManagedSystemFlags` | 撤销本地写 `is_system` |
-| `hide-engine.js` | `syncSystemAttribute` | 同步 DOM `is_system` attribute |
-| `hide-engine.js` | `runHideApply` | 隐藏主流程 |
-| `extraction-controller.js` | `runExtractionController` | 自动提取主流程 |
-| `event-binding.js` | `onMessageReceivedController` | 自动提取事件入口 |
-| `index.js` | `ensureGraphMutationReady` | 图谱写入前置就绪判断 |
-| `index.js` | `deferAutoExtraction` | 自动提取延迟重试 |
-| `index.js` | `maybeResumePendingAutoExtraction` | 自动提取恢复 |
-| `index.js` | `updateProcessedHistorySnapshot` | 更新处理后快照 |
-| `index.js` | `inspectHistoryMutation` | 历史检查入口 |
-| `index.js` | `recoverHistoryIfNeeded` | 历史恢复主流程 |
-| `index.js` | `scheduleMessageHideApply` | 隐藏调度 |
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,5 @@
 node_modules/
+.claude/
 npm-debug.log*
 yarn-debug.log*
 yarn-error.log*