taozuqin/ST-Bionic-Memory-Ecology
1
0
Fork 0
mirror of https://github.com/Youzini-afk/ST-Bionic-Memory-Ecology.git synced 2026-05-15 22:30:38 +08:00
Code Issues Packages Projects Releases Wiki Activity

chore: stop tracking local claude plans

Browse Source
This commit is contained in:
Youzini-afk
2026-04-03 14:43:03 +08:00
parent 613e9f17fb
commit 715ae0ca05
3 changed files with 1 additions and 716 deletions
Download Patch File Download Diff File Expand all files Collapse all files

353
.claude/plans/hide-engine-decouple-and-timer-blockers-plan.md
View File

@@ -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` 双写。

363
.claude/plans/hide-hash-extraction-fix.md
View File

@@ -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` | 隐藏调度 |

1
.gitignore vendored
View File

@@ -1,4 +1,5 @@
node_modules/
.claude/
npm-debug.log*
yarn-debug.log*
yarn-error.log*