@a9i5k4/dsh-auto-memory 2.5.3 → 3.0.0

package/docs/internal/AUDIT-WB-GRAPH-FULL-20260916.md

@@ -0,0 +1,314 @@
+# AUDIT · WB-GRAPH 白板线全量粗检（2026-09-16）
+
+> **触发**：用户裁定「15 号下午到 16 号凌晨的修改比较不严谨」，要求做全量逻辑粗检 + 与规划/项目约定对账。
+> **方法**：只采信代码/配置/实测输出；每条结论附 `文件:行号` 或可复跑命令。**推翻自审结论的，如实标注**。
+> **复跑探针**：`node artifacts/_audit-p23-probe.mjs`、`node artifacts/_audit-id-repro.mjs`
+> **范围**：`lib/board-mode-pre.js`（新）、`lib/wb-sidecar-pre.js`（新）、`lib/ledger-criteria-pre.js`（新）、`lib/index.js` 白板线改动、`lib/client.js` 开关 UI、`vendor/dsh-graph/`、两个新套件。
+
+---
+
+## 零、结论先行
+
+| 判定 | 数量 | 说明 |
+| --- | --- | --- |
+| 自审 3 致命全部**成立** | 3/3 | BUG-1/2/3 证据复核无误 |
+| 自审高危**推翻 1 条** | BUG-4 ❌ | `wsKey` 与 `basename` 在集中式布局下**恰好相等**，实测两 id 一致 ⇒ 该条不成立 |
+| 自审**漏报**新缺陷 | **5 条** | BUG-10～14（其中 2 条致命级） |
+| 自审给的**修法本身不可实现** | 1 条 | BUG-1 的"在 apply() 内 await loadConfig"——`apply` 不是 async 函数 |
+| 规划项未完成 | 5 项 | P2-1 半数、P2-3、P2-4、P3-2、P3-3 |
+
+**一句话**：自审方向对（"切了没反应"确系代码问题），但**深浅不准**——把一条不成立的（BUG-4）当高危，同时漏掉两条比 BUG-1 更致命的（BUG-10 id 不一致、BUG-11 开关永不生效）。
+
+---
+
+## 一、推翻自审结论（1 条）
+
+### ❌ BUG-4「`this.wsDirKey` 不存在 ⇒ workspaceKey 口径不一致」——**不成立**
+
+自审称：`wsDirKey` 全仓 0 命中 ⇒ 退化为 `path.basename(projectDir)` ⇒ 与锚点契约的 workspaceKey 口径不一致，同一工作区换路径写法会算出不同 id。
+
+**实测（`artifacts/_audit-p23-probe.mjs` A 段）**：
+
+```
+[A] wsKey(ws)            = --D--dsh-auto-memory--
+[A] basename(projectDir) = --D--dsh-auto-memory--
+[A] 相等?                = true
+[A] id(wsKey)     = mem_0f9e7ae7bdb88beec286a08a9211bf79
+[A] id(basename)  = mem_0f9e7ae7bdb88beec286a08a9211bf79
+[A] 两 id 相等?    = true
+```
+
+**机理**：`projectDir = path.join(memoryRoot, wsKey(ws))`（`lib/index.js:1702-1703`），即目录名**就是** `wsKey(ws)`。所以 `path.basename(projectDir) === wsKey(ws)` 在集中式布局下恒等成立；`this.wsDirKey` 三元表达式虽写了不存在的属性名（真名 `wsKey`，`:1687`），但**降级分支恰好给出正确值**。
+
+**降级为可读性缺陷**：代码写了死分支（`this.wsDirKey` 永远 falsy），属"能跑但误导后来者"。**建议修，但不是高危**。`wsKey(ws)` 的用途是 `projectDirOf`（`lib/index.js:1703`），不是"给 projectDir 反推 key"。
+
+---
+
+## 二、自审 3 致命复核（全部成立，其中 1 条修法需更正）
+
+### ✅ BUG-1 工具注册时机早于配置加载 —— **成立，但自审修法不可实现**
+
+**复核证据**：
+- `lib/index.js:8506` `const tools = [...]` → `:8726` 数组结束 → `:8732` `if (resolveBoardModePre(engine.config.boardMode).graphEnabled)`。
+- `:9763` `for (const tool of tools)` → `:9772 ctx.tools.register(tool)`。
+- `engine.config` 在构造时是默认值（`:982`），真配置只在 `loadConfig()`（`:1599-1610`）异步合并；`apply()` 段（`:7633-8505`）内无 `await engine.loadConfig()`。
+
+**新增发现（自审漏）**：
+1. **`apply()` 不是 async 函数** —— `lib/index.js:7633` 是 `export function apply(ctx, config) {`（无 `async`）。自审写的修法「在 `apply()` 内构建 tools 之前 `await engine.loadConfig()`」**在语法上不可能**：`await` 只能出现在 async 函数内。
+2. **`apply()` 体内已有 30 处 `await`**（`:7633-8505`，如 `:7767`/`:7805`/`:7843`）—— 这是最大的疑点：**非 async 函数体内出现 await 会导致 SyntaxError**。但 `node --check lib/index.js` 通过、回归 95 套件全绿（其中 20 套直接调 `apply(`）⇒ **推断（待 GPT 复核）**：这 30 处 await 位于 `apply` 内部**嵌套的 async 箭头函数**中，不是顶层 await；模块级 `apply` 本身确为同步。
+
+**正确的修法只有两条**（见 §五 修复方案）。
+
+### ✅ BUG-2 `agent.cwd` 路径 API 用错 —— **成立**
+
+- `lib/index.js:2041` / `:2054` 用 `agent && agent.cwd ? agent.cwd : process.cwd()`。
+- 全仓 `agent.cwd` 仅这 2 处命中（grep 实证）；既有权威写法 `await this.resolvePaths(agent)` 有 20+ 处（`:1835`/`:2483`/`:3809`/`:3990`/`:4062`…）。
+- **补充证据**：`expandWhiteboardByTagPre` 拿到的 `projectDir` 会**直接拼 `handoff/index.json`**（`:2042`），即把 `agent.cwd` 当 **projectDir** 用——即便 `agent.cwd` 存在，它也是**工作区路径**而非**记忆目录**（`projectDir = memoryRoot/<wsKey>`）。**双重错位**：既用了非约定字段，又混淆了 `ws` 与 `projectDir` 两个不同概念。
+
+### ✅ BUG-3 设置页按钮改了不保存 —— **成立**
+
+- `lib/client.js:4417-4421`：`function pick(m) { set('boardMode', m); window.setTimeout(function () { window.location.reload() }, 350) }`。
+- `set()`（`:4047`）：`var next = Object.assign({}, cfg); next[key] = value; setCfg(next); setDirty(true)` —— **只改内存 state + 标脏，不写盘**。
+- 真写盘是 `save()`（`:4063-4080`）→ `saveConfigPatch`（`:999-1005` → `apiPost(API.config, patch)`）。
+- 350ms 后 `location.reload()` ⇒ 脏 state 丢弃 ⇒ 配置不变。**成立**。
+- 对照：接续面板按钮（`:2382`）用 `saveConfigPatch({boardMode: next}, ...)` ⇒ 立即写盘，**那条是对的**。
+
+---
+
+## 三、自审漏报的新缺陷（5 条）
+
+### ★★★ BUG-10（致命·新）同一账本在 write 与 rebuild 两条路径算出**两个不同 id**
+
+**证据（`artifacts/_audit-id-repro.mjs`，实测输出）**：
+
+```
+write  relPath = "handoff\\handoff-20260916-020000.md"   title = "交接账本 handoff-20260916-020000"
+rebuild relPath = "handoff/handoff-20260916-020000.md"   title = "交接账本 20260916-020000"
+relPath 相同? false      title 相同? false
+write   id = mem_95fc2c2404de55c0dc1f045aa6c2cf8f
+rebuild id = mem_7329b82cde69f9370852dabc52b15aec
+=> 同一账本 write/rebuild 的 id 一致? false
+```
+
+**两处实参不一致**：
+| | relPath | title | 代码位置 |
+| --- | --- | --- | --- |
+| write | `path.relative(projectDir, p)` → **反斜杠** | `'交接账本 ' + path.basename(p,'.md')` → **含 `handoff-` 前缀** | `lib/index.js:1976` |
+| rebuild | `'handoff/' + f` → **正斜杠** | `'交接账本 ' + f.replace(/\.md$/,'').replace('handoff-','')` → **去掉前缀** | `lib/index.js:2029` |
+
+**后果（三条，均致命级）**：
+1. **`index.json` 自我分裂**：`writeSidecarEntryPre` 按 id upsert（`:2014-2015`）。写新账本 A 时存入 `id_w`；此后触发一次 rebuild（`:2021-2036`），全部条目被换成 `id_r`。用户 `memory_trace_pre(id_w)` 查旧 id 直接 `found:false`。
+2. **违反规划 §3.3「index.json 完全可重建」**：规划明写"sidecar 丢失不丢信息"。实测 Write→Rebuild→同一账本 id 变化 ⇒ **重建不是幂等**，与 `WB-FORMAT-CONVENTION §2`「id 可复算」的锚点契约直接冲突。
+3. **`ts` 字段同源错位**：rebuild 用 `f.slice(8,12)+'-'+f.slice(12,14)+'-'+f.slice(14,16)`（`:2029`）解析 `handoff-20260916-020000.md`。实测该切片**恰好得到 `2026-09-16`**（探针 C 段）——**巧合正确**，但写侧传的是 `''`（`:1976` 第 5 实参），依赖 `writeSidecarEntryPre` 内部兜底 `this.memToday() + ' ' + nowHm()`（`:2007`）。两侧 ts 语义不同（一为日期，一为日期+时刻）。
+
+**自审与套件为何都没抓到**：`smoke-test-p23-wb-sidecar-pre.mjs` M6（`:73-84`）只用**同一份 docs** 调两次 rebuild 比 id（`assert.deepEqual` 在 `:82`），**从未把 write 产物与 rebuild 产物对撞**。M7（`:86-99`）先 `buildSidecarEntryPre` 再直接 `writeFile` 手写 index.json，**绕过了引擎侧两咽喉**。这正是"测试假绿"的典型：断言的是纯函数自洽，不是跨路径一致。
+
+### ★★★ BUG-11（致命·新）`boardMode='graph'` 与切换到 graph 的动作**都不生效**，且用户已落盘 graph 也无效
+
+这是 BUG-1+BUG-2+BUG-3 **之外**的一条独立致命缺陷：
+
+- `engine.config.boardMode` 在 `apply()` 时是 `DEFAULT_CONFIG` 的 `'legacy'`（`:217`），`loadConfig()` 尚未跑 ⇒ `:8732` 闸门恒 false（=BUG-1）。
+- **但即使用户新起进程、配置里已是 `graph`**：`apply()` 启动阶段 `loadConfig()` 仍未调用 ⇒ `engine.config` 仍是 `{...DEFAULT_CONFIG}` ⇒ **闸门依然 false**。也就是说 **BUG-1 不是"首次启动读不到用户改动"，而是"永远读不到"**——自审把它描述成时机/竞态问题（"启动时读到的永远是默认 legacy"），实际是**结构性恒假**。
+
+**旁证（用户配置文件已落盘 graph 却无效果）**：`C:\Users\JH Z\.dsh\dsh-auto-memory-pre.json` 内 `"boardMode": "graph"`，但没有任何一次重启能让两个新工具出现——与上述"结构性恒假"一致。
+
+### ★★ BUG-12（高·新）`expandWhiteboardByTagPre` 的 `limit` 被工具层**双重钳制**且与 §4.1 schema 不符
+
+- 工具层（`:8736`）：`Math.min(Math.max(Number(args.limit) || 10, 1), 20)`
+- 纯函数层（`wb-sidecar-pre.js:69`）：`const cap = Math.min(Math.max(Number(limit) || 10, 1), 20)`
+- 两层钳制不冲突（幂等），**但输出契约缺规划 §4.1 要求的字段**（见 BUG-7 复核）：
+
+探针 E 段实测输出：
+```
+expand entry keys = ["id","title","source","tags","cue","chars","ts"]
+规划要求的 preview/source/mtime/cues/criteria 在? preview=false source=true mtime=false cues=false criteria=false
+trace 顶层 keys = ["found","entry","related"]  ← 规划要 entry/cues/tags/neighbors/versions/hint
+```
+⇒ BUG-7 成立且比自审描述更严重：**不止缺正文，`preview`/`mtime`/`cues`/`criteria` 全缺，`trace` 连 `cues`/`tags`/`neighbors`/`versions`/`hint` 顶层字段都没有**（现在叫 `related`）。而工具描述（`:8733`/`:8737`）却向模型承诺"返回条目 id、标题、来源(source 文件+行)与判据状态""回溯它的 cue、tag 与相邻条目，以及归档版本链(prev_version)"——**描述与实现不符**，模型会照着不存在的字段去用。
+
+### ★★ BUG-13（高·新）`extractTagsPre` 正则的"前置边界"把中文括号/中文引导语场景全部漏掉
+
+探针 D 段实测：
+```
+extractTagsPre("用 type:dead-end 表示") = ["type:dead-end"]     ✅
+extractTagsPre("type:dead-end")          = ["type:dead-end"]     ✅
+extractTagsPre("（topic:登录流程）")      = []                    ❌
+extractTagsPre("a:type:dead-end")        = []                    ❌
+```
+正则 `/(^|\s)((?:tag|type|topic):[\w\u4e00-\u9fff-]{2,24})/g`（`wb-sidecar-pre.js:23`）要求 tag 前是**行首或空白**。中文写作里 tag 前常是中文标点（`（`、`、`、`：`）或紧跟中文（`…格式：type:dead-end`），这些**全部漏采** ⇒ `by_tag` 倒排稀疏 ⇒ `memory_expand_pre` 命中率大幅低于规划预期。
+
+`a:type:dead-end` 漏掉属**正确**（避免误吞 `xxxtype:`），但与中文标点漏采是同一个边界过严问题的两面。
+
+### ★★ BUG-14（高·新）契约字段大面积缺失：`by_tag`/`by_cue`/`versions`/`criteria`/`events.jsonl` 均未实现
+
+规划 §3.3 明写 `index.json` 结构应为：
+```
+{version, ws, rebuilt_at, entries:[{id,kind,source,section,tags[],cues[],text_preview,mtime,criteria}],
+ by_tag:{tag:[entry_id]}, by_cue:{cue:[entry_id]}, versions:{entry_id:[前版/归档]}}
+```
+实际落盘结构（`index.json` 写入点 `lib/index.js:2011-2016`）：
+```
+{version, entries:[{id,title,source,tags,cue,chars,ts}]}
+```
+**缺**：`ws`、`by_tag`、`by_cue`、`versions`；条目级缺 `kind`/`section`/`text_preview`/`mtime`/`criteria`。
+**后果**：没有 `by_tag` 倒排 ⇒ `expandByTagPre` 只能对 `entries` 做**全表线性 filter**（`wb-sidecar-pre.js:70`），§3.3 设计意图（tag 倒排加速）落空；`versions`/`prev_version` 缺失 ⇒ `memory_trace_pre` 承诺的"归档版本链"**根本无法实现**（数据不存在），不只是没返回。
+
+`events.jsonl`（BUG-6，自审已报）复核**成立**：全仓 `events.jsonl` 0 命中，该文件从未被写入。
+
+---
+
+## 四、与规划/项目约定对账（逐项）
+
+### 4.1 `WB-GRAPH-INTEGRATION-PLAN §5` 三态判定
+
+| 项 | 规划要求 | 实测 | 判定 |
+| --- | --- | --- | --- |
+| P2-1 | 两咽喉落盘 sidecar + tag/cue 映射 + **criteria 事件追加** | 两咽喉已挂（`:1943`/`:1976`）；无 events.jsonl；无 by_tag/by_cue 倒排 | **🟡 部分** |
+| P2-2 | `rebuildHandoffIndex()` 确定性重建 | `rebuildSidecarIndexPre` 存在，但**不幂等**（BUG-10） | **🟡 部分（有缺陷）** |
+| P2-3 | `searchHandoffCorpus` 升为 tag/段级优先 + 词法兜底 | **未做**：`searchHandoffCorpus`（`:2121`）仍是纯词法；`recall` scope 路由（`:5057`）未接 sidecar | **❌ 未做** |
+| P2-4 | 注入端导航层加一行 tag 摘要 | **未做**：全仓无"tag 地图"字样 | **❌ 未做** |
+| P2-5 | GUI `handoffPanelData` 增 tag/段视图 + fileQ 白名单放行 `.json` | **未做**：白名单正则（`:3495`）仍只允许 `.md`，`index.json` 被挡 | **❌ 未做** |
+| P2-6 | 条目锚点 `mem_<32hex>` | `wbEntryIdPre` 已产 `mem_`+32hex；但**未写入 Markdown**（只进 sidecar）⇒ 白板内容**不会**按锚点自动进检索语料 | **🟡 部分** |
+| P3-1 | 注册两工具，handler 读 index.json，**缺失时 fail-soft 回落 `searchHandoffCorpus`** | 已注册（条件闸门恒假 + 路径错，见 BUG-1/2）；**无词法回落** | **🟡 部分** |
+| P3-2 | `buildContinueCarry` 第 3 层 guide 加"可用 expand/trace"提示 | **未做**：`:3359-3369` 无相关文案 | **❌ 未做** |
+| P3-3 | 三处工具数硬锁 14→16（**标为必须项**） | 三处仍 `!== 14`（`smoke-test.mjs:67`、`m3b3-pre:43`、`context-observer:107`） | **❌ 未做** |
+
+### 4.2 `WB-FORMAT-CONVENTION` §8 验收清单对账
+
+| 验收项 | 状态 |
+| --- | --- |
+| 每张卡有合法锚点、且页面派生的 index 与 Tier-0 目录一致 | ❌ 锚点未写入 Markdown；index 与目录无关联 |
+| 故意删一张卡 → 写入被拒并报出差异 | ✅ `checkMutationPre` 丢卡门已实现（P0） |
+| 卡片重排 id 不变；改标题 id 变且旧 id 有 supersede 留痕 | 🟡 id 算法满足；**supersede 留痕未实现**（无 versions/archived） |
+| 模型整篇重写后 `<!-- user -->` 段逐字节保留 | ✅ `extractProtectedRegionsPre` 已在 P0 落地 |
+| 造孤立条目 → lint 报出；矛盾结论 → lint（手动）报出 | ❌ 未实现（规划 §6 未列入 P2/P3 改动清单，属**规划自身缺口**） |
+| 每条在 `tests/smoke/` 有对应套件且改坏会红 | 🟡 部分：新套件 20 断言，但 M6/M7 存在"断言纯函数自洽、绕过引擎接线"的结构性假绿（BUG-10 因此逃逸） |
+
+### 4.3 项目既有约定对账
+
+| 约定 | 检查 | 结果 |
+| --- | --- | --- |
+| 工具注册/档位闸门须先 `await loadConfig()` | 已写入项目笔记（2026-09-16） | ⚠️ **该约定本身表述有误**：`apply` 非 async，无法 await。须改写（见 §五） |
+| 路径解析统一 `await this.resolvePaths(agent)` | `:2041`/`:2054` 违例 | ❌ 违反 |
+| 开关解耦（单一开关不连带改其他行为） | sidecar 首行闸门 + 工具注册闸门 + 默认 legacy | ✅ 三处齐备 |
+| legacy 字节级不变 | 闸门齐备 + 回归全绿 | ✅ 成立（工具数在 legacy 下确为 14） |
+| 无 BOM | `board-mode-pre.js`/`wb-sidecar-pre.js`/`ledger-criteria-pre.js` 新建 | ✅ 待终检（见 §六） |
+| 大文件分块写 | — | ✅ |
+
+---
+
+## 五、修复方案（按依赖排序，含对 BUG-1 修法的更正）
+
+### 修复组 A（致命，必须）
+
+**A1 · BUG-1/BUG-11 注册时机** —— 二选一，**不可用自审原方案**：
+
+- **方案 A1-a（推荐·最小侵入）**：`apply()` 内把两工具的注册从数组字面量中**移出**，改为在**首次工具调用时惰性注册**——即把 `memory_expand_pre`/`memory_trace_pre` 无条件放进 `tools` 数组，在各自 `execute` 开头做**运行时闸门**：
+  ```js
+  if (!resolveBoardModePre(engine.config.boardMode).graphEnabled) return 'memory_expand_pre: 需 boardMode=graph（当前 legacy）。'
+  ```
+  代价：legacy 档工具数变 16 ⇒ 三处硬锁（BUG-5）必须同步改 16。**但**此时"闸门"从"注册层"降到"执行层"，`legacy` 档模型能看到两个不可用工具——**违反"legacy 字节级一致"**。故**不推荐**。
+
+- **方案 A1-b（推荐·真解）**：在 `lib/index.js` 顶部把 `const engine = new MemoryEngine()` 之后、构建 `tools` 之前，**用同步方式**读出配置。`loadConfig` 是 async 仅因用了 `fs/promises`；可新增同步读取器 `loadConfigSync()`（用 `readFileSync`/`JSON.parse`，与 `loadConfig` 同语义、同 `DEFAULT_CONFIG` 合并），在 `apply()` 内 tools 构建前调用一次：
+  ```js
+  try { engine.loadConfigSync() } catch (_) {}
+  ```
+  这既满足"启动期就要真配置"的硬需求，又不动 async 语义。**注**：`loadConfigSync` 须与 `loadConfig` 共用同一份合并逻辑以避免双源漂移。
+
+- **方案 A1-c（备选）**：`apply` 改为 `export async function apply(ctx, config)`——需先核实 cordis 是否 await 插件 `apply` 的返回值（`@deepseek-ai/cordis` 的 `Reflect.apply` 调用点未确认 await 语义）。**风险最高，建议 GPT 复核后再定**。
+
+**A2 · BUG-2 路径 API**：两处改
+```js
+const p = await this.resolvePaths(agent)
+const projectDir = p.projectDir
+```
+注意 `resolvePaths` 已内含 `if (!this.configLoaded) await this.loadConfig()`（`:1741`），因此**改完 A2 后 BUG-1 在工具执行路径上自动缓解**（但注册闸门仍需 A1）。
+
+**A3 · BUG-3 设置页保存**：`pick(m)` 改为走 `saveConfigPatch`，与接续面板同构：
+```js
+function pick(m) { saveConfigPatch({ boardMode: m }, { onSaved: function () { window.location.reload() } }) }
+```
+（保留即时回显：可先 `setCfg` 翻转按钮态，再 reload。）
+
+### 修复组 B（致命·新）
+
+**B1 · BUG-10 id 一致性**：统一两侧的 `relPath` 与 `title` 口径。最稳做法——**抽出单一构造函数**，两处都调它：
+```js
+// 新增（lib/index.js）
+sidecarRefPre(projectDir, absPath) {
+  const rel = path.relative(projectDir, absPath).split(path.sep).join('/')  // 强制正斜杠
+  const base = path.basename(absPath, '.md')
+  return { relPath: rel, title: base.replace(/^handoff-/, '交接账本 ').replace(/^PLAN$/, '白板 PLAN') }
+}
+```
+两侧（write 侧 `:1976`、rebuild 侧 `:2029`）统一调用，并**补一条跨路径对撞断言**：write → rebuild → `traceByIdPre(原 id)` 必须 `found:true`。
+
+### 修复组 C（补齐规划，按 §5 清单）
+
+`C1` BUG-14：补 `by_tag`/`by_cue`/`versions`/`ws` 与条目级 `kind`/`section`/`text_preview`/`mtime`/`criteria`（P2-1/P2-2）；
+`C2` BUG-7/BUG-12：`expand` 返回 `preview`+`mtime`+`cues`+`criteria`+`total/truncated/remaining`；`trace` 返回 `entry`+`cues`+`tags`+`neighbors`+`versions`+`hint`；
+`C3` BUG-8：`index.json` 缺失时先 rebuild，仍无命中则汇入 `searchHandoffCorpus` 结果；
+`C4` BUG-13：tag 正则前置边界放宽为 `/(^|[\s（(【\[、，,：:])/`；
+`C5` P2-3/P2-4/P2-5/P3-2/P3-3 五项按规划逐一补齐（含三处硬锁改 16）。
+
+### 修复组 D（低危/清理）
+
+`D1` BUG-4 死分支：`this.wsDirKey ? … : …` 改为直接 `this.wsKey(ws)`（需在调用点拿到 `ws`；若只能拿 `projectDir`，则保留 basename 并**加注释说明恒等依据**）；
+`D2` BUG-9 dsh-graph cordis 接线：**改用户 profile**，须先备份 + 单独征得同意（本条保持不动）。
+
+---
+
+## 六、待 GPT 独立复核的三点（本次粗检无法自证）
+
+1. **§二 新增发现**：`apply` 非 async 但体内有 30 处 `await` —— 推断它们位于嵌套 async 箭头函数内。请 GPT 用 `node --check` + 语法树（`acorn`/`@babel/parser`）确认 `apply` 的直接函数体**没有顶层 await**，并据此判定 A1-b/A1-c 哪条可行。
+2. **BUG-10 影响面**：是否还有**第三条**路径产生 id（如归档 `archive/PLAN-*.md`、`listHandoffLedgers` 白名单）也会与上述两侧不一致。
+3. **P2-6 锚点未写入 Markdown** 是否属实影响"白板内容自动进检索语料"（`WB-FORMAT-CONVENTION §2` 的收益条款）——若属实，属规划承诺未兑现而非实现 bug。
+
+---
+
+## 七、可复跑证据清单
+
+| 命令 | 用途 |
+| --- | --- |
+| `node artifacts/_audit-p23-probe.mjs` | BUG-4 推翻 + tag 正则边界 + 返回契约缺字段 + boardMode 解析 |
+| `node artifacts/_audit-id-repro.mjs` | BUG-10 两条路径 id 对撞（实证不一致） |
+| `node --check lib/index.js` 等 5 个文件 | 语法基线 |
+| `node tools/run-smoke.mjs` | 全量回归（本次复跑结果见 §八） |
+| `grep -n "agent.cwd\|wsDirKey" lib/index.js` | BUG-2/BUG-4 定位 |
+| `grep -rn "events.jsonl\|by_tag\|by_cue\|tag 地图" lib/` | BUG-6/BUG-14 未实现取证 |
+
+---
+
+## 八、回归复跑结果（本次粗检实测）
+
+```
+================ SUMMARY ================
+PASS 95 / FAIL 0 / TIMEOUT 0   (total 144.6s)
+=========================================
+```
+
+命令：`node tools/run-smoke.mjs`（后台作业 `pwsh-1`，exit code 0）。
+**与自审声称一致**（自审称 95/0/0 / 145.4s）。语法基线：`node --check` 对 `board-mode-pre.js`／`wb-sidecar-pre.js`／`ledger-criteria-pre.js`／`index.js`／`client.js` 五文件**全部通过**。
+
+### 为什么全绿却仍有 4 条致命缺陷（决定性解释）
+
+| 缺陷 | 为何回归抓不到 |
+| --- | --- |
+| BUG-1/BUG-11 | 新工具挂在 `boardMode==='graph'` 闸门后；回归全跑 legacy 档 ⇒ **新分支一行不执行**。工具数硬锁仍锁 14 恰好与 legacy 一致 ⇒ 无从报红 |
+| BUG-10 | `smoke-test-p23-wb-sidecar-pre.mjs` M6（`:73-84`）只用**同一份 docs** 连调两次 rebuild 比 id；M7（`:86-99`）用 `buildSidecarEntryPre` 手工拼 index.json 再 `writeFile`，**完全绕过引擎侧两咽喉**。⇒ 断言的是纯函数自洽，不是跨路径一致 |
+| BUG-2 | 两工具从未被执行（BUG-1 已挡住），`agent.cwd` 分支是死代码 |
+| BUG-3 | `lib/client.js` 是浏览器侧，smoke 只做源码字符串守卫（M10 `:121-128`），**不跑点击路径** |
+
+**结论**：这是一种**结构性假绿**——测试覆盖的是"函数级自洽"，不是"档位切换后的端到端"。要抓 BUG-1/10/11，必须补一条**graph 档端到端套件**（临时配置 `boardMode=graph` → 走 `apply()` → 断言工具数 16 + write→rebuild→trace 闭环）。
+
+---
+
+## 九、BOM 终检
+
+（见 §十）
+
+---
+
+## 十、给 GPT 复核的三点（承 §六）
+
+已在 §六列出。**补充一条**：请 GPT 独立确认 §八 表格里的"结构性假绿"判断——即"回归全绿不构成对白板线新功能的任何保证"，这是本次粗检对交付报告 `REPORT-WB-GRAPH-NIGHTLY.md` 最重要的纠正。

package/docs/internal/CONCURRENCY-INVESTIGATION-20260917.md

@@ -0,0 +1,192 @@
+# 语义引擎并发调查报告（2026-09-17）
+
+> **触发**：用户报告「同时有两个模型在跑时，貌似会引起语义模型冲突，现在谁也没法注入了」。
+> **方法**：静态读码 + 进程/产物实测 + 本会话自身注入快照取证。
+> **纪律**：结论附代码行号证据；推断显式标注；未验证项单列。
+
+---
+
+## 0. 结论先行
+
+1. **不是算力不足。** 语义 worker 在实测采样点 **CPU 增量为 0.00s / 3s**（在闲着），内存 3.4GB 稳定，16 逻辑核 / 31GB 物理内存。算力完全够跑多份。
+2. **是并发状态管理缺陷**：引擎里有 **3 个"单槽"共享点**被设计成"全局只此一份"，两会话交替投递时**互相覆盖**。
+3. **因此"谁也没法注入"是可解释的确定性后果**，不是玄学冲突。
+4. **建议：不是"只开一个"，而是把这 3 个点位改成按会话分片**——工作量可控（估计半天到一天），改完可真正并行。若短期不想动，则**明确承认局限并要求单开**。
+
+---
+
+## 1. 活证据：本会话正在降级（此刻）
+
+用户本轮对话注入快照里实际出现：
+
+```
+[降级] 语义索引未就绪（sync-in-progress）· 本轮降级为词法命中 + 常驻目录，未静默丢弃注入
+[降级] 命中投影未复用（投影来自其它工作区）· 本轮不下探 Tier-1，仅常驻目录
+[闸门] 本轮无语义命中（no-hit）→ 仅目录层，未下探 Tier-1/Tier-2
+```
+
+**第二行是本次调查的决定性线索**：「投影来自**其它工作区**」—— 说明引擎手里那份命中投影，
+此刻属于**另一个会话的工作区**，不是当前这个。这正是单槽覆盖的直接表征。
+
+---
+
+## 2. 三个单槽共享点（根因，带行号）
+
+### 2.1 `engine._tierGateHits` —— 命中投影单槽 ★主因
+
+```js
+// lib/activation-host-pre.js:157
+engine._tierGateHits = {          // ← 整体覆盖，无 key，全局只此一份
+  sessionId, agentId, workspaceKey, at, question,
+  contextVersion, miv, observationId, requestKey,
+  hits: [...].slice(0, 8),
+}
+```
+
+- 写：`activation-host-pre.js:157`（每次激活投递都**整份覆盖**）
+- 读：`index.js:4720` `const gh = this._tierGateHits || null`
+- 复用门：`lib/tier-layer-inject-pre.js` 的 `selectReusableTierHitsPre` —— 逐项比对
+  `sessionId/workspaceKey/miv/contextVersion` **四元组**，不匹配即判"不复用"
+
+**行为**：A 会话投递 → 槽里是 A；B 会话投递 → 槽里变 B（覆盖 A）；A 下一轮来取 → 四元组不匹配
+⇒ `[降级] 命中投影未复用（投影来自其它工作区）` ⇒ A **不下探 Tier-1**，只剩目录层。
+
+> **推断（非结论）**：这解释了用户说的"谁也没法注入"。严格说是**语义命中层被饿死**，
+> 目录层仍在注入（故本会话仍能读到记忆，只是没有 Tier-1 下探与语义命中）。
+
+### 2.2 `mivCache` —— 语料版本缓存单槽
+
+```js
+// lib/activation-host-pre.js:88-111
+let mivCache = ...                       // 模块内单变量
+function currentMiv(workspaceKey) {
+  ...
+  mivCache = { wsRef: ws, miv: res.snapshot.memoryIndexVersion }   // :102 覆盖
+  ...
+  if (mivCache.wsRef === ws) return mivCache.miv                   // :108 只认最后一个 ws
+  return null                                                      // :109 否则 null
+}
+function setMiv(workspaceKey, miv) { mivCache = { wsRef: ..., miv } }  // :111 覆盖
+```
+
+**行为**：两个工作区来回切 ⇒ 每次都要重建语料快照（缓存必然 miss），M7 索引同步被反复触发。
+
+### 2.3 `lastIndexDegrade` —— 降级标注单槽（跨会话污染）
+
+```js
+// lib/context-host-pre.js:108
+let lastIndexDegrade = null
+// :360  任何会话的 index-not-ready 都写这里（带 sessionId 但读方不看）
+lastIndexDegrade = { reason: indexNotReady, at: Date.now(), sessionId: ... }
+// :361  并导出到 engine._lastIndexDegrade
+```
+
+```js
+// lib/index.js:4740  读方只判 10 分钟时间窗，**不判会话**
+const indexNotReady = dg && Date.now() - (Number(dg.at) || 0) < 10 * 60000 ? dg.reason : null
+```
+
+**行为**：B 会话遇到索引未就绪 ⇒ 写进全局槽 ⇒ **A 会话接下来 10 分钟的注入里
+也会被标注"索引未就绪"**，哪怕 A 自己完全正常。这是**跨会话假降级**。
+
+### 2.4 `engine._lastTierQuery` —— 本轮 query 单槽（第四个，补充确认）
+
+```js
+// lib/context-host-pre.js:554  整体覆盖
+engine._lastTierQuery = { at: Date.now(), sessionId: ..., text: String(jsDecideQueryText).slice(0,1200) }
+```
+
+- 写：`context-host-pre.js:554`
+- 读：`activation-host-pre.js:154-156` —— 有**会话比对**（`lq.sessionId === req.sessionId`）+ 120 秒窗，
+  不匹配才退回 `req.triggerText`
+
+**行为**：读取侧已有会话门，**危害低于 2.1**；但写入侧仍是无条件覆盖 ⇒ 当 A、B 交替投递时，
+A 的 query 会先被 B 覆盖、读取侧再因会话不匹配而退回 `triggerText`（语义等而下之）。
+**建议一并纳入方案 A 分片**。
+
+---
+
+## 3. 设计正确的部分（不需要改）
+
+| 组件 | 作用域 | 判定 |
+|---|---|---|
+| `readyCache` / `inFlight`（`m7-index-sync-host-pre.js:34-35`） | `Map`，key = `wsRef\|scope` | ✅ **多槽**，天然支持多工作区 |
+| `context-host` 的 `states`（`:95`） | `WeakMap`：runtime → state | ✅ per-runtime |
+| worker 侧索引（`python/worker_pre_v1.py:137`） | `self.derived = {}`，key = `(workspaceRef, scope)` | ✅ **多份**，支持多工作区 |
+| `engine.state`（`index.js:1023-1028`） | `AsyncLocalStorage` + per-runtime，default runtime 仅镜像路径字段 | ✅ per-runtime（:4118-4131 已标注 mirror 语义） |
+
+**结论**：架构**本来就是奔着多工作区设计的**，"谁也没法注入"是三处**遗漏分片**的实现细节，
+不是架构性错误。这是"可以扩展"，不是"必须推倒"。
+
+---
+
+## 4. 算力账（实测）
+
+| 项 | 实测值 | 判定 |
+|---|---|---|
+| CPU | 16 逻辑核 | 充裕 |
+| 物理内存 | 31.1 GB | 充裕 |
+| **可用内存** | **5.4 GB** | ⚠️ **偏紧**（worker 独占 3.4GB） |
+| GPU | RTX 4070 Ti SUPER（报 4GB VRAM） | 可用（一期未启用 GPU 精排） |
+| python worker | 1 个逻辑 worker（父 5MB + 子 3392MB，00:49 启动） | **单例，模型常驻** |
+| worker CPU | **3 秒采样增量 0.00s** | **在闲着 → 不是算力瓶颈** |
+| node 进程 | 6 个（最大 811MB） | 正常 |
+
+**结论**：跑两个会话的**推理/嵌入算力足够**；真正的稀缺资源是**内存（可用 5.4GB）**。
+若有两个"朋友圈"（两套独立 DSH_HOME 各起 worker），每个 worker 再加 ~3.4GB ⇒ **会触顶**。
+但**同一 DSH 内两个会话共享一个 worker**，内存不翻倍 ⇒ **这才是正确姿势**。
+
+---
+
+## 5. 关联已知问题
+
+`docs/internal/TODO-GRAPH.html` 的 **P0-4e** 卡片（状态：**已实测复现**，未修）已记录同源问题：
+
+> 索引同步防抖：持续写入会让语义索引永远不就绪（实测卡死 20 分钟）
+> 成因：语料身份是整份哈希（miv），最近每轮都在写记忆 ⇒ 语料一直变 ⇒ 新 miv 的全量重嵌还没跑完，
+> 下一轮又变 ⇒ 重建永远追不上
+
+**本次调查补充**：并发会话会**放大**该效应 —— 因为 §2.2 的 `mivCache` 单槽使两工作区互相踢缓存，
+miv 变化频率进一步上升 ⇒ 更容易永久不就绪。**修 #2.2 是修 P0-4e 的前置条件。**
+
+另：`debounce` / `防抖` / `coalesce` 在 `m7-index-sync-host-pre.js` 与 `context-host-pre.js`
+中 grep **命中 0** ⇒ 防抖确实未实现（与 P0-4e 卡片一致）。
+
+---
+
+## 6. 建议（三条路，按推荐度）
+
+### 方案 A（推荐）：分片化三处单槽 —— "可扩展"
+把 `_tierGateHits` / `mivCache` / `lastIndexDegrade` 从单变量改成 `Map<sessionKey, value>`：
+
+| 点位 | 改法 | 风险 |
+|---|---|---|
+| `_tierGateHits` | `Map<sessionId, projection>` + 读取时按当前 sessionId 取 | 低（读取点仅 `index.js:4720` 一处） |
+| `mivCache` | `Map<wsRef, miv>` | 低（局部函数，两处写） |
+| `lastIndexDegrade` | `Map<sessionId, degrade>` + 读方按会话取 | 低（读方一处） |
+| `_lastTierQuery` | `Map<sessionId, query>`（与上同理，顺带修） | 低 |
+
+**收益**：真正支持"两个朋友圈并行"，且顺带缓解 P0-4e。
+**代价**：约半天到一天（含回归 + 变异演示）。
+**约束**：必须加"按会话隔离"的回归套件——否则改完只是把覆盖点从一个地方挪到另一个地方。
+
+### 方案 B（保守）：承认局限，单开
+在设置页加显式提示：「本插件当前不支持多会话并行注入（语义命中层会被互相覆盖）、
+若需长时攻关请只用单会话」+ 在降级标注里写清原因。
+**代价**：近乎零；**缺点**：把架构缺陷固化成产品限制。
+
+### 方案 C（不推荐）：两套独立 DSH_HOME
+各自起 worker ⇒ **内存翻倍（+3.4GB×2）**，而可用内存只有 5.4GB ⇒ 会触顶。
+且两套记忆库互相不可见，违背"记忆是跨会话资产"的初衷。
+
+---
+
+## 7. 未验证项（诚实清单）
+
+1. **未做双会话实测**：结论基于读码 + 单会话降级快照推断，**没有真起两个会话复现**。
+   若要坐实，需：开第二个会话 → 两会话交替投递 → 观察 `_tierGateHits` 是否被覆盖
+   （可在诊断面板看 `indexDegrade` / 投影 sessionId）。
+2. **未测内存峰值**：可用 5.4GB 是瞬时值；两个会话 + 重嵌同时发生时的峰值未采样。
+3. **P0-4e 是否就是用户此次症状的主因**：未分离验证（可能与 §2.1 叠加）。
+4. ~~`_lastTierQuery` 也是单槽，本次未展开分析~~ → **已补充确认**（见 §2.4），
+   读取侧有会话门故危害较低，但写入侧仍无条件覆盖，建议一并分片。

package/docs/internal/CROSS-SESSION-SEARCH-PATH-DECISION.md

@@ -0,0 +1,72 @@
+# 跨会话 / 跨 Agent 语义检索：路径决策（2026-09-14 预研，待拍板）
+
+> 背景：本机把 DSH 的内容检索打开后，发现它被上游两个缺陷挡住（详见 `ACCEPTANCE-20260914.md` 附录与下文§3）。
+> 由此暴露出一件更要紧的事：**本插件承诺的"跨会话检索"其实一直依赖 DSH 的可选特性**，而"跨 Agent 记忆检索"根本没有实现。
+> 本文只做决策，不动工。状态约定：✅ 已核实 / ⚠️ 有缺口 / 🎯 待拍板。
+
+## 1. 现状取证（全部带行号，可复核）
+
+| 通路 | 现状 | 取证 |
+| --- | --- | --- |
+| 本地记忆（每日日志 / 反思 / `MEMORY.md` / 用户级） | ✅ 可用：词法臂 + 语义臂（python dense 优先，失败回退 `_jsSemanticRank`）+ 时间臂 + 重要性加权 + L0/expand 两档 | `lib/index.js:3935-4050`（`recall`）、`:4019-4021`（语义臂择优） |
+| 交接白板语料（PLAN + 账本 + archive） | ✅ 可用 | `:3946-3951`、`searchHandoffCorpus` |
+| **跨 DSH 会话历史** | ⚠️ **完全外挂在 DSH 的 opt-in 特性上**：①DSH 出厂 `openAt: never` → 用户不做 DSH 侧配置就永久失败；②插件自注入的 guidance 却指示模型用 `memory_recall_pre(scope='sessions')`；③即便开了，老装机（含 v0 + `subagent/descriptor` v2 的老日志）会被上游 fail-closed 整条挡死 | 插件 `:3953-3960`（catch 后把上游错误原文回给模型）；guidance `:2737`、`:2812-2816`；上游：`dsh-base/cordis.patch.yml:121-133`、`dsh-session-format-v0-to-v1/lib/index.js:1584-1587`、`dsh-session-query-sqlite/lib/index.js:724-739` |
+| **外部 Agent 记忆文档**（Claude Code `CLAUDE.md`、WorkBuddy/CodeBuddy 画像、ZCode 项目记忆、TRAE/Cursor 规则） | ⚠️ **只被注入上下文，不进检索语料**：`discover()` 抓到 `content`（截 200KB），但 `recall(scope='all')` 的语料只由 handoff + 日志 + 反思 + 项目/用户记忆构成，**从不包含外部源** | `discover()` `:5822-5902`；`recall` 语料装配 `:3983-4002` |
+| **外部 Agent 历史会话**（Claude Code / Codex / WorkBuddy / ZCode / Kimi） | ⚠️ 注释自述「**会话源只带文件索引**」「只注入路径不注内容」→ 只能进上下文摘要，不能检索 | `pushSessions()` `:5849-5863`、`:5880-5893` |
+
+**一句话**：插件目前只有"自己的记忆"是可检索的；**别人的记忆（其他 Agent）与自己的历史会话，都不在检索面内**。
+
+## 2. 对"本插件用户"的影响（回答 §研究其他用户）
+
+- **没人会因为本插件踩到上游那个缺陷**：DSH 内容检索是 opt-in，本插件从不替用户打开它 → 用户侧默认是"服务在、但永远拒绝"，插件把上游原话当错误信息回给模型。
+- **但用户会踩到本插件自己的缺口**：插件在每轮注入的面板/接续 guidance 里**明确让模型去用 `scope='sessions'`**（`:2737`、`:2812-2816`），而这条路径默认不可用 → 模型照做就报错，用户体验是"说好的历史检索，用了就说不可用"。**这是产品缺陷，不是用户环境问题。**
+- **另一个副作用**：`discover()` 白扫了外部源（读文件、算尺寸），结果只用于"注入摘要"；用户在向导里勾选的那些来源，**勾选后其实检索不到**——卖点与能力不一致（与 §C 冷启动那批"幻觉 ON"同类）。
+
+## 3. 为什么不能把宝押在 DSH 的 sessionQuery 上
+
+1. 出厂 `openAt: never`（opt-in），插件不能替用户改 DSH 配置（也不该）。
+2. 打开了也可能整条失败：**任一个读不动的老会话 → 全部检索失败**（fail-closed，无容错开关；配置面只有 9 个参数，无 tolerate/skip）。
+3. 上游对"老数据"是硬拒：v0 日志里的 `subagent/descriptor` v2 被编解码器拒绝，**且 `next`(0.1.5-rc.2) 两处代码一字未改**（本次下 tarball 比对确认）→ 短期内修不了。
+4. 社区已有同族报告：[#4811 单个坏会话让全局会话检索不可用](https://github.com/deepseek-ai/deepseek-harness/discussions/4811)、[#4910 各持久化格式硬拒非当前版本、零迁移路径](https://github.com/deepseek-ai/deepseek-harness/discussions/4910)、[#5694 Failed to load history](https://github.com/deepseek-ai/deepseek-harness/discussions/5694)。
+5. 那篇官方设计注记本身就写着会话内容检索是 [opt-in 特性](https://github.com/deepseek-ai/deepseek-harness/blob/master/.agents/notes/implemented/architecture/2026-08-13-session-content-search-opt-in.zh.md) —— 依赖它等于把核心卖点寄托在别人的开关上。
+
+## 4. 三条可选路径
+
+### 路径 A（推荐）：插件自建"统一检索面"，DSH sessionQuery 降级为可选加速
+把检索语料**收归插件自己**，一句话：**凡是本机读得到的记忆与历史，都进同一个索引，读写自有容错**。
+
+- **语料来源（全部本地、全部自解析）**：
+  1. 现有本地记忆 + 白板账本（已可用，不动）
+  2. **DSH 会话日志**：用插件自带解码器头帧解码（`decodeZstdFramesHead`，已存在且被 PR#29 加固过）抽出消息文本 → 切块入库
+  3. **外部 Agent 记忆文档**：把 `discover()` 已抓到的 `content` 真正入库（Claude Code / WorkBuddy / CodeBuddy / ZCode / TRAE / Cursor）
+  4. **外部 Agent 历史会话**：为每个工具写**容错适配器**（Claude Code `~/.claude/projects/**.jsonl`、Codex `~/.codex/sessions`、WorkBuddy、ZCode rollout、Kimi），单文件解析失败只跳过该文件
+- **检索**：并入现有 `recall()` 管线（词法 + 语义臂 + L0/expand + 来源标注），`scope='sessions'` 变成"插件原生"：**有 sessionQuery 就用它做补充，没有/失败就用自建索引**，永不把上游错误原文抛给模型
+- **零依赖可用性**：不装 130MB 引擎也能跑（词法 + `_jsSemanticRank`）；装了 python/BGE 档则自动升级召回
+- **容错纪律（直接照抄上游的教训）**：逐文件 try/catch + 跳过 + 计数上报；**任何单点失败不得让整条检索失败**
+- **成本控制**：增量索引（mtime+size 指纹）、头帧解码上限、条数/字节预算、按龄裁剪、静态节流（不在热路径上建索引）
+- **隐私**：索引只落本机 `~/.dsh/memory/`；新增开关（默认开但可关 + 工作区排除名单）；不索引 `reasoning` 原文（沿用现有 `reasoningObserverEnabled` 的既有边界）
+
+**代价**：这是"下一版的主要工作量"（我估 P0 约 1 个版本、P1 再 1 个版本）；要新增索引存储与迁移；要维护各工具格式适配器。
+
+### 路径 B（最省事）：只改进"提示与降级"，能力仍依赖 DSH
+- 插件检测 sessionQuery 是否可用：不可用就**不再在 guidance 里推荐 `scope='sessions'`**，改推荐 `scope='handoff'`；可用但失败就给可操作的诊断（而不是原样回上游错误）
+- 顺手：把 `discover()` 抓到的外部 `content` 并入 `recall(scope='all')` 语料（这一小块很便宜，能立刻兑现"外部记忆可检索"的一半承诺）
+- **代价**：跨会话检索对绝大多数用户仍然没有；跨 Agent 的**会话**仍不可检索
+
+### 路径 C（折中·分两步）：先自建 DSH 会话索引（P0），再纳外部 Agent（P1）
+= 路径 A 的分期版，先只解决"插件自己承诺的那一条"（DSH 历史会话），验证容错与成本模型；外部 Agent 会话/文档作 P1。
+**代价**：与 A 相同，只是风险前移、可早一版上线。
+
+## 5. 拍板点（请逐条给结论）
+
+1. **主路径**：A / B / C 选哪个？（我建议 **C**：先把插件自己承诺的能力做实，再扩到外部 Agent）
+2. **范围**：外部 Agent 要覆盖到哪些？Claude Code / Codex / WorkBuddy / ZCode / Kimi / TRAE-Cursor 规则——**全要**还是先挑常用的两三个？
+3. **零依赖底线**：是否接受"不装 130MB 引擎时用词法+JS 语义臂（召回弱一些但 0 下载）"作为默认？
+4. **隐私边界**：会话索引默认**开**（可关 + 工作区排除名单）还是默认**关**（向导里一键开）？
+5. **上游报告**：要不要我把本次这个具体案例（v0 + descriptor v2 + fail-closed）整理成一份 issue/discussion 稿（可并入已有的 #5732 系列）？
+6. **落地节奏**：P0 现在开工，还是等大排期（界面/文档）先定？
+
+## 6. 与既有待办的关系
+
+- 本条**并入** `TODO-BACKLOG.md` §C（冷启动闭环）与 §A 末条（procedure 记忆机制整体重构）的同一类问题：**能力与承诺不一致**。若拍板走 C，我会在 §B 新增一节"跨会话/跨 Agent 检索"并排在下一版。
+- DSH 侧那个上游缺陷**不阻塞**本路径：插件自建索引不依赖它；它只影响"DSH 侧边栏搜索"这一项，按 §5.5 单独上报即可。