@a9i5k4/dsh-auto-memory 3.0.1 → 3.1.0

package/docs/internal/ISSUE10-FIX-EXECUTION-20260919.md

@@ -1,389 +0,0 @@
-# ⑩-a/⑩-b 修复执行记录（T0 → T1 → T2）
-
-> 执行日期：2026-09-19 · 执行人：主代理 · 依据：`ISSUE10B-FORENSICS-20260919.md` §8/§9
-> 状态：**T0/T1/T2 全部完工**，全量回归 **PASS 133 / FAIL 0 / TIMEOUT 0**（139.6s）
-> ⚠️ **待用户动作：重启宿主**（`lib/` 下三个文件已改未提交，pre 线以 `link:` 挂载 ⇒ 需要重启才生效）
-
----
-
-## 0. 一句话结论
-
-⑩-a（面板看不懂）与 ⑩-b（记忆文件侧的雷）**同源**：`memory-hub-pre.js` 的 **fact 通路从来没有过清洗器**。
-⑨ 只修了 procedure 那条路（`:152`），fact 那条路（`crossFeed` 的 fact 分支 + `factCandidateFromRow`）
-**整套漏掉** ⇒ 脏数据既进 `facts.json`（面板乱码），又经 `hubFlushTick` 写回 `MEMORY.md`（污染注入面与语义语料）。
-
-**本轮把这条链路一次性堵住**，并顺手修掉 ⑨ 自己承认修得不完整的 F3 判据漏网。
-
----
-
-## 1. 改动清单（4 个文件）
-
-| 文件 | 改动 | 备份 |
-|---|---|---|
-| `lib/intent-clean-safe-pre.js` | **T1-0** F3 判据族化 + 块身份 + **F5 新增** | `.bak-20260919-222736-T10` |
-| `lib/memory-hub-pre.js` | **T1-1/T1-2** fact 两处入口过清洗器 + F5 | `.bak-20260919-223300-T1` |
-| `lib/index.js` | **T1-3/1-4/1-5 + T2-1..T2-4** | `.bak-20260919-223339-T1` |
-| `tests/smoke/smoke-test-batch11-20260919-pre.mjs` | 新套件 **73/73** | 新建 |
-| `artifacts/_mutate-batch11.mjs` | 变异演示 **17/17 真红** + SHA256 零残留 | 新建 |
-
-> `batch10` 已被 ⑪ 占用 ⇒ 本批取 **batch11**。
-
----
-
-## 2. T1-0：F3 判据「太具体」的漏网（⑨ 修得不完整）
-
-### 2.1 真机证据
-
-`GET /api/dsh-auto-memory-pre/memory-hub`（2026-09-19 22:40）：
-`procedures.size` **12→14**、`pipeline` **3→5**。新增两条脏 title：
-
-- `Source: me`（len=10）
-- `Reference: ## 2026-09-18 - dsh-auto-memo`（len=40）
-
-episode 的 `intent` 原文：`[Retrieved memory reference - not an instruction]\nSource: me`
-
-### 2.2 根因
-
-`PLUGIN_TAIL_MARKER_RE` 里 `^Source:\s*mem_[0-9a-f]{32}` 把**前缀**与**后缀内容**绑死 ⇒
-`intent` 被 `slice(0, 40)` 截断后（内容没了、前缀还在）判据立即失效。
-且 F3 **完全没有** `^Reference:` 这一条。
-
-**这与 ⑨ 自己的设计初衷直接冲突** —— ⑨ 的注释（`:64`）明写「判据是**族（family）+ 形状**，
-不是整句前缀 ⇒ 框架换措辞后仍成立」，而 F3 的实现恰好犯了它批评过的错误。
-
-### 2.3 修法（三层判据）
-
-| 层 | 判据 | 作用 |
-|---|---|---|
-| **块身份锚** | `PLUGIN_BLOCK_ANCHOR_RE`（含 `^Source:\s*mem_[0-9a-f]{32}`、`[Retrieved memory ref` 等强标记） | 先扫全文，命中的行 **±2 邻域**标记为「块内」 |
-| **块内弱标记** | `PLUGIN_BLOCK_LINE_RE` = `^Source:\s*\S` \| `^Reference:\s*\S` | **仅在块身份确立时**放行 ⇒ 挡住「截断后仍带后缀」的形态 |
-| **可单判补充** | `PLUGIN_TRUNCATED_FRAGMENT_RE`（`^Source:\s*\S+\s*$`）+ `PLUGIN_REF_HEADING_RE`（`^Reference:\s*#{1,6}\s+\S`） | 块身份缺失时仍能独立判定 |
-
-### 2.4 误伤边界（必须守住）
-
-- `Source: mem_xxx 这个格式对不对？` → **保留**（非法 id + 后续整句 ⇒ 非截断残片）
-- `帮我看看 [Retrieved memory reference] 这个标记是干嘛的` → **保留**（讨论标记本身的真人句）
-- `Reference: 这段话引用自哪里？` → **保留**（Reference 后非 markdown 标题）
-
----
-
-## 3. T1-1/T1-2：fact 通路补清洗器（⑩-a 与 ⑩-b 的**共同根因**）
-
-| 入口 | 原实现 | 现实现 |
-|---|---|---|
-| `crossFeed` fact 分支 | `String(ep.intent).slice(0,30)` **未清洗** | 取 raw → F5 判定 → `stripRuntimeIntentPre` → 空值回退 `'episode'` |
-| `factCandidateFromRow` | `String(row.subject)` **未清洗** | 三字段同样处理；object 命中 F5 则置 `null` |
-
-**真机三条脏 fact 的实际字段值**（本套件 [6] 组逐字使用）：
-
-| factId | 脏形态 |
-|---|---|
-| `fact_pre_ac4920327df6601f25200d66e52df71f` | subject 含 **22 个 U+FFFD** |
-| `fact_pre_a9380f5bca22011e33547a45542c61a3` | object 内嵌 `Current DSH file policy: …` |
-| `fact_pre_dda6cc1f36176f5ea000c6f681ea6818` | object 内嵌 `Approval prompts are disabled …` |
-
----
-
-## 4. ★ F5：行内残留（**新套件自己抓出来的缺口**）
-
-### 4.1 发现过程
-
-新套件首轮跑出 **1 条真 FAIL**：[6] 组 `真机 fact[1]` 未通过。追查发现：
-
-```
-object = "现在是什么情况？ Current DSH file policy: danger-full-access. The DS"
-         └─真人话─┘ └──────────── 运行时信封 ────────────┘
-```
-
-### 4.2 为什么清洗器处理不了它
-
-`stripRuntimeIntentPre` 是**按行判断**的 —— 删掉这样的整行会**连带丢掉真人话**，
-所以它必须保留 ⇒ **「清洗后是否变化」这条判据对行内混合天然无效**。
-
-### 4.3 修法：新增 F5 判据（不做清洗，只做判定）
-
-`RUNTIME_RESIDUE_RE` 匹配**行内任意位置**的运行时标记短语：
-`Current DSH file policy` | `Current runtime context` | `Approval prompts are disabled in this session` |
-`[Retrieved memory ref` | `Verify against the current user request` | `If a reference hints at what you need` |
-`Reason: fv2 lane=` | `Score: N.N (rank N/N)`
-
-`looksRuntimeResiduePre(text)` → 布尔。**命中即判脏并丢弃该字段**（不做「清洗后照写」——
-这符合本仓纪律：fail-soft 必须留痕，静默改写等于悄悄改数据并丢失诊断事实）。
-
-**接入三处**：`crossFeed` fact 分支 · `factCandidateFromRow` · `hubFlushTick` 的 `dirty` 判定。
-
-> **F5 与 F1/F2 的区别**：F1/F2 判「**整行是**信封」，F5 判「**行内夹带**信封」。
-
----
-
-## 5. T1-3/T1-4/T1-5：hubFlushTick 内容卫生门
-
-⑩-b 取证结论：该通路 **6 道过滤全是「结构性」**（`state.flushed` / `count<8` / `subj` 非空 …），
-**没有一道内容卫生** ⇒ 脏 fact 实测已写入正文并归档
-（`archive/notes-archived.md:493` 的 `## DSH ������（M8 固化）`）。
-
-| 项 | 原实现 | 现实现 |
-|---|---|---|
-| **T1-3** 卫生门 | 无 | `cSubj/cObj/cPred` 过清洗器 **+ F5 三项** ⇒ `dirty` 则 `mark flushed` + `diag` + `_degradePre.record('hub-flush',…)` + `continue` |
-| **T1-4** 换行归一化 | 无 | `subj1/pred1/obj1 = ….replace(/\s*[\r\n]+\s*/g, ' ').trim()`，且**拼接确实用归一化变量** |
-| **T1-5** 失败留痕 | `catch (_) {}` **全吞** | `catch (eFlush)` + `diag('hub flush FAIL: …')` + `_degradePre.record('hub-flush','append-failed:…')` |
-
-> **为什么脏 fact 处理成 skip 而不是「清洗后照写」**：本仓纪律是 fail-soft 必须留痕、
-> 不得静默改写。清洗后照写等于悄悄改数据，并丢失「曾出现脏 fact」这一诊断事实。
-
----
-
-## 6. T2：四项结构加固
-
-| 项 | 问题 | 修法 |
-|---|---|---|
-| **T2-1** | 「已在正文」分支只 `flushed=true` **从不 `count++`**，且完全静默 | 补 `diag('hub flush skip(already-in-body): …')`；**保留「不写正文不计额度」的语义**（这是正确行为，问题只在于原先完全静默） |
-| **T2-2** | disposer 只 clear 两个 interval，**漏 `hubBootTimer`** | 补 `clearTimeout(hubBootTimer)` ⇒ dispose 后不再有回调 |
-| **T2-3** | `flush-state.json` 裸 `writeFileSync`，无锁无 tmp+rename | 改 **tmp + `renameSync`** 原子替换 |
-| **T2-4** | `setInterval(() => { void hubFlushTick() })` **无重入保护** | 加 `hubFlushInFlight` 标志 + `try/finally` 复位；定时器改走 `hubFlushTickGuarded` |
-
-> **T2-3 的真实危害**：写坏后 `hubFlushLoad` 静默吞异常 ⇒ `flushed` 回退到旧值
-> ⇒ **已写过的 fact 会被再写一遍**（正文出现两个同名 `（M8 固化）` 段落）。
-
----
-
-## 7. ★ 变异演示：从「假绿 8 条」到「17/17 全真红」
-
-**这是本轮最有价值的方法论发现。**
-
-### 7.1 首轮结果：**8 条假绿**
-
-| 假绿项 | 根因 | 处置 |
-|---|---|---|
-| T1-0c/0d 块身份 | **断言太弱**：原用例的每行都被其他判据命中 ⇒ 该路径实际未被覆盖 | **造真正需要块身份的用例**：`Source: mem_<截断> / Wo`（F3 与残片判据都不匹配） |
-| T1-1 crossFeed | **漏测**：原套件只测了 T1-2 | 补源码级断言（完整表达式） |
-| T1-4/T1-5/T2-3/T2-4 | **断言的是字面量存在，不是完整表达式** | 全部改为断言完整表达式 |
-| T2-3 锚点不唯一 | 全仓 `renameSync` **有两处** ⇒ 锚点命中邻近代码 | **限定在 `hubFlushSave` 函数体内**断言 |
-| F5a | 锚点串与实际代码不符 | 读实际代码取准锚点 |
-
-### 7.2 过程中发现的两个次生问题
-
-1. **`looksRuntimeResiduePre` 漏写 `export`** ⇒ `SyntaxError: does not provide an export named …`。
-   教训：新增导出必须跑一次真实 import 验证，`node --check` **查不出**这个。
-2. **T1-5 的首个变异体是无效变异**：写成 `catch (eFlush) { if (true) {} else {` ——
-   `if (true)` 之后仍执行原分支，**语义没变** ⇒ 假绿是**变异体写错**，不是断言太弱。
-   处置：改用 `lineContains/lineTo` **整行替换**（新增能力），把留痕真正删掉。
-
-### 7.3 最终结果
-
-```
-真红 17 / 假绿或锚点丢失 0  （共 17）
-SHA256 还原校验：clean / hub / idx 三文件**逐字节一致**（零残留）
-```
-
----
-
-## 8. 验收证据
-
-| 项 | 结果 |
-|---|---|
-| `node --check` 三文件 | OK |
-| 行尾 | 全部 **CRLF**（`index.js` 11115/11115 · `memory-hub-pre.js` 349/349 · `intent-clean-safe-pre.js` 230/230） |
-| 新套件 `smoke-test-batch11` | **PASS 73 / FAIL 0** |
-| 既有契约守卫 `batch9`（⑨） | **33/33** |
-| 既有契约守卫 `batch10`（⑪） | **57/57** |
-| 既有契约守卫 `r5-envelope-structural` | **36/36** |
-| 变异演示 | **17/17 真红** + SHA256 零残留 |
-| **全量回归** | **PASS 133 / FAIL 0 / TIMEOUT 0（139.6s）** |
-
-> 基线为 132；+1 = 本批新增的 `batch11`。
-
----
-
-## 9. 本轮没有做的事（明确边界）
-
-1. **没有碰 `MEMORY.md` 任何字节** —— 存量 3 条脏 fact 按用户拍板走**路 C（靠卫生门堵住，不改数据）**。
-2. **没有直接改 `hub-pre/*.json`** —— ⑨ 的教训：宿主内存持有副本，`dispose()` 会无条件回写 ⇒ 改盘会被回滚。
-3. **没有动 T3** —— 用户已拍板「T3 系统性收口单独立项，前端之前做」。
-   本轮只在**三个已知入口**设防（fact 两处 + hubFlushTick）；T3 要解决的是
-   「把 `sanitizeForWrite` 下沉到写原语 ⇒ 20 条写入路径自动受保护」，那是另一个战场。
-4. **没有重启宿主**（用户硬性规则）。
-
----
-
-## 10. 遗留与本轮新增的待办
-
-| 项 | 说明 |
-|---|---|
-| **待用户重启宿主** | `lib/` 三文件已改未生效 |
-| **T3 立项** | 20 条写入路径 × 3 个消费方，无联合门禁 |
-| **前端可读性** | 用户追加：「procedure memory / skill 的内容、**晋升的原因**都要在前端更好地表示」⇒ 已登记进 `PRE-FRONTEND-CHECKLIST-20260919.md` §4（R2 需 host 侧改动：`overview()` 目前只投影 `procedureId/title/stage/riskLevel/evidence/pinned/observationOnly`） |
-
----
-
-## 11. T3 执行记录（2026-09-19 · 第 2 批）
-
-### 11.1 ★ T3-1 原方案被实测推翻（两处数据破坏风险）
-
-⑩-b 报告的 T3-1 写的是「把 `sanitizeForWrite` 下沉到 `appendText`/`writeFull` ⇒ 20 条通路全受保护」。**取证发现不能照做**：
-
-| 风险 | 证据 |
-|---|---|
-| **① 体量截断** | `sanitizeForWrite` 超 `maxEntryChars`（默认 **8000**）时**不拒绝而是 `slice(0,8000)` 静默截断**（`:8327-8329`）。而 `writeFull` 承担「原文保底归档」（`:7723`，注释即写「绝不丢信息」）与「归档日志原文内联」（`:7733`）；实测真实日志 **77805 / 52394 / 43224** 字符 ⇒ 下沉后这些会被砍到 8000。 |
-| **② `RAW_JSON_MARK` 大面积误伤** | 该正则含**裸词 `updatedAt`**。实测扫描 **541 个真实记忆文件：124 个命中**（多数是正常提到 `updatedAt` 的正文）。它是**入口级**判据（针对「AI 调写入工具时传外部画像 raw JSON」），不适合审「整篇文档 / 任意追加」。 |
-
-### 11.2 T3-1 实际落地（用户拍板：**新开一个，不拆既有函数**）
-
-**新增 `hygieneGateForPrimitive(text)`**（`index.js`，独立于 `sanitizeForWrite`）：
-- **只做卫生**：`mojibake` / `stutter` / `base64` / `duplicate-lines` —— **无体量上限、不截断、不改写正文**（返回体只有 `{ok, reason?}`，无 `clean`/`truncated`）。
-- **刻意不含 `RAW_JSON_MARK`**（理由见 11.1②）。
-- **只挂 `appendText` 一处**，**不挂 `writeFull`**（它写整篇文档，命中面过大；且 `:7723` 是保底归档，绝不能因误伤而失败）。
-- **fail-soft**：内部异常一律视为放行 —— 新守卫绝不成为新失败源。
-- **拒绝时抛出** `memoryWriteError('hygiene', {reason})`，与写入原语既有契约一致（调用方已有 try/catch 兜底）。
-
-**`sanitizeForWrite` 一个字节未改**，现有 6 个入口继续用它（`WRITE_GATE_REASON` 的 `raw-json` 文案也保留）。
-
-### 11.3 ★ 顺带修复一个既有数据丢失 bug（必须修，否则新门会引爆它）
-
-`maintain()` 第 4 步的删除循环**遍历的是 `oldLogs` 而不是 `archived`**：
-
-```
-[归档] catch (e) { console.error(...) }      ← 失败只记日志，archived 里没有它
-[删除] for (const log of oldLogs) rm(...)    ← ★ 归档失败的也照样删
-```
-
-上方注释虽写「原文已在 archive/ 保底」，但那两段代码并不保证这件事。**加了卫生门之后，脏日志会让归档失败并被删 ⇒ 永久丢失。**
-**修法**：删除以 `archived` 为准（`if (archived.indexOf(log.name) === -1) { kept.push(...); continue }`）。
-
-### 11.4 验收证据（T3-1）
-
-| 项 | 结果 |
-|---|---|
-| `node --check` | OK · 全 CRLF |
-| **真实 `import` 验证** | OK（`node --check` 查不出 export 缺失） |
-| **探针 `artifacts/_probe-t3.mjs`** | **13/13 全绿**（含 3 条反向保证：大文本放行 · `sanitizeForWrite` 仍截断 · 仍拦 raw-json） |
-| **误伤扫描 `artifacts/_scan-t3-falsepos.mjs`** | 541 文件：判据收窄前「整文件被拒 **129**」→ 收窄后 **5**（1 mojibake + 4 stutter，**均为真脏**） |
-
-### 11.5 ★ T3-2 判定为「不做」（原报告判断有误）
-
-⑩-b 报告称 `m4-corpus-pre.js` 的 `dropped[]` 需「补 degrade 台账，让静默丢弃可见」。**取证推翻了「静默」**：
-
-| 消费者 | 位置 | 实际行为 |
-|---|---|---|
-| **审计持久化** | `shadow-host-pre.js:346-351` | 映射进 `appendAuditDurable(ev)`（`stage/reason/memoryId/sourceRef` + counts） |
-| **自动自愈** | `storage-manage-pre.js:82-95` | 按 `reason` 分类为 `stale`/`unrepairable`/`ok`，`REPAIRABLE_REASONS_PRE_V1` 命中即 rebuild sidecar |
-
-⇒ `dropped[]` **已被两处真实消费**，不是静默丢弃。且这两处**都没走 degrade 台账**，因为 `dropped` 属**常规观测**而非预期外失败 —— 补 `degrade.record` 会**违反** R4 批确立的纪律（「常规观测走并列通道，绝不 record，否则『有没有降级』永远非空」）。
-
-**结论：T3-2 不是遗漏，是设计。不做。**
-
-### 11.6 探针两次「假失败」的教训（可复用）
-
-初版探针两条 FAIL，**都是夹具写错，不是代码错**：
-
-1. `'abc'.repeat(12)`（无分隔符连写）**不该**命中 `hasStutter` —— 其词规则是 `(\w{2,})(?:[^\w]+\1){3,}`，**要求重复之间有分隔符**（覆盖 `"Run. Run. Run. Run."`）。
-2. `'x'.repeat(200)` 想测「大文本不被截断」，却**先命中 `BASE64_LINE`**（`^[A-Za-z0-9+/]{200,}={0,2}$`）⇒ 在长度检查**之前**就返回 `base64`。换含空格/中文的长文本才走对路径。
-
-**通用教训**：写判据探针时，**夹具必须避开其他判据的命中面**，否则测的不是你想测的分支（这是「假红」的常见来源，与 `⑩` 批的「假绿」互为镜像）。
-
-### 11.7 ★ T3-3 撞用户硬规则 · 已停手待拍板
-
-**目标**：`overview()` 暴露 flush 状态 + `reasonCodes` 投影（前端 R2「让人读懂晋升原因」的前置依赖）。
-
-**取证发现的雷**：`procedure-store-pre.js` 的 `promote()` **不是纯函数，有真实副作用**：
-
-| 行 | 副作用 |
-|---|---|
-| `:295` / `:297` | `stats.approvalAsked++` |
-| `:303` | **`p.stage = 'validated'`**（改状态） |
-| `:305` | `stats.validated++` |
-| `:306` | **`void persist()`**（写盘） |
-
-⇒ 若在 `overview()` 里对每条 procedure 跑 `promote()` 来取 `reasonCodes`，**「打开记忆中枢面板」这个只读动作会让所有够格的技能真的晋升并写盘**。
-
-**正解**：另写一个**纯只读的判定投影**（复算门限 → 返回 `reasonCodes`，不改状态、不写盘、不动 stats），供 `overview()` 调用。
-
-**为什么停手**：这要动 `lib/procedure-store-pre.js` —— 命中用户硬规则
-> 「涉及 procedure 记忆引擎（含清洗器）的改动，不得自行实施，必须等用户就整体方案拍板」。
-
-**★ 新增可复用纪律**：给只读投影（面板/概览）复用会改状态的判定函数 = **点一下面板就等于执行一次晋升**。复用任何判定函数前，必须先查它有没有副作用（改状态 / 写盘 / 改统计）。
-
-### 11.8 ★ 本条日志的端到端实证（`RAW_JSON_MARK` 误伤，非纸面推断）
-
-写 `11.1②` 这条记忆时，**日志写入被入口闸门以 `raw-json` 拒绝了一次** —— 原因仅仅是正文里**提到了那个字段名**（`u`…`A`，即 `updatedAt`）。
-
-⇒ `11.1②` 那个「541 文件 / 124 命中」的静态扫描结论，由此获得了**端到端**验证：该判据确实会把「正常提及该词」的内容误判为外部画像 raw JSON。**这也是 `hygieneGateForPrimitive` 刻意不含它的直接理由。**
-
-
----
-
-## §12 T4 完工 —— procedure memory 的**模型直写通路**（2026-09-19 用户拍板）
-
-### 12.1 用户原话与根因
-
-用户：「原来之前一直都没做模型生成的过程吗？这太恐怖了。赶紧把这个模型生成的过程做了。另外，这个 semantic 和 episodic memory 的部分是不是也没有接入模型啊？」
-
-**取证结论（三条线全部无模型入口，附代码证据）**：
-- `defineTool` 全仓仅 16 个，**零** `memory_fact*` / `memory_episode*` / `memory_procedure*`。
-- procedural 线唯一来源 = `memory-hub-pre.js:142-189` `crossFeed()`，把每个"成功 episode"机械切成候选；
-  而 episode 的 `actions` 恒为 `['user','user','user']`（`episodes.json` 实测行）⇒
-  产出 14 条里 **13 条 evidence 全 0 / successCriteria 全 0 / steps 是 "步骤1: user" 占位符**。
-- **清洗器无法解决**：`['user','user','user']` 里本就不含流程信息 —— 这是**结构性天花板**，不是清洗不足。
-- episodic：`index.js:7382` `hub.stores.episodic.append({...})` 在自动沉淀路径内，**100% 宿主自动**，无工具。
-- fact：仅 `upsert(cand)`(`fact-store-pre.js:169`) + `ingestJudgementRows`(`:456`)，模型无直接路径。
-
-### 12.2 改动（两文件）
-
-**`lib/procedure-store-pre.js`** —— `promote(procedureId, extraEvidence, opts)` 新增第三参：
-- `opts.authorizedBy === 'model'` ⇒ **跳过两条统计证据门**（`minSessionDiversity` / `minSuccessCount`）。
-- **为什么必须跳**：这两条门是给机械生成的观察行用的防污染护栏（靠"反复出现"累积证据）；
-  而模型主动写出的真技能（带 steps + successCriteria）**天生零历史证据**，不放行则永远卡 `diversity-below-3`。
-- **授权仍不能突破的结构门**（护栏保留）：`deprecated` 短路 / `isObservationOnlyPre` 短路 /
-  `no-success-criteria` / `correction-rate` / `has-correction`。
-- **留痕**：晋升成功写 `p.authorizedBy`，`reasonCodes` 追加 `model-authorized`（可审计、前端可展示）。
-- **向后兼容**：`opts` 缺省 `{}` ⇒ `authorizedBy` 为空串 ⇒ **未授权时行为逐字节不变**（T4-1 锁定）。
-
-**`lib/index.js`** —— 两处：
-1. 新增 `defineTool('memory_procedure_pre', ...)`（**工具数 16→17**）：
-   - `action: 'write' | 'activate'`；`write` → `observe()` 进审批列表；
-     `activate` → `observe` → `promote(授权=model)` → `activate` → **自动导出 SKILL.md**。
-   - `steps`/`successCriteria`/… 用**字符串分行**接收（`defineTool` 不支持 array schema）；
-     行首 `1. `/`- `/`* ` 自动剥离（模型输出格式不稳定的兜底）。
-   - 无 `successCriteria` 时**显式警告**（该条目结构上无法晋升）。
-2. `renderMemoryStatic()` 内新增注入语：技能库直写引导（用户原话「如果有值得介入 procedure memory 的东西，
-   那就接入写进审批列表」），含判据「下次我遇到类似场景，会不会想照做」。
-
-### 12.3 四处工具数硬锁联动（16→17 / legacy 14→15）
-
-加工具**必然**打破数量断言，逐处更新并注明原因：
-`tests/smoke/smoke-test.mjs:67` · `smoke-test-m3b3-pre.mjs:43` · `smoke-test-context-observer.mjs:107` ·
-`smoke-test-graph-mode-pre.mjs`（A1 graph 17 / **D1 legacy 15** / D2 非法档 15）·
-`smoke-test-p23-wb-sidecar-pre.mjs:127-138`（M9 正则 `!== 16` → `!== 17`）。
-★ 另在 `index.js` 工具定义处补「工具数 16→17」联动注释（M9 会检查该注释在场）。
-★ D1 新增反向断言：`memory_procedure_pre` **不受 boardMode 闸门管** ⇒ legacy 档也必须在场。
-
-### 12.4 验收（全部实跑，非纸面）
-
-| 项目 | 结果 |
-|---|---|
-| `node tests/smoke/smoke-test-t4-procedure-model-write-pre.mjs` | **36/36 通过** |
-| 变异①`if (!authorizedBy)` → `if (true)` | **27 通过 / 9 失败**（真红：授权失效被抓） |
-| 变异②删除 `observationOnly` 短路 | **34 通过 / 2 失败**（真红：授权越结构门被抓） |
-| 变异后恢复 | SHA256 `F140D7E5AE681EDE14F382D416B930C6A4E1D5389BDCE0B8B9AA36E9122C589` **逐字节一致，零残留** |
-| 全量回归 | **PASS 134 / FAIL 0 / TIMEOUT 0（138.1s）**（基线 133 → 134，+T4 套件） |
-
-### 12.5 三条踩坑（新增，可复用）
-
-1. **`addEvidence(pid, ev)` 的签名是 `ev.kind`**，不是 `{correction:1}` / `{success:true}` ——
-   传错**静默返回 `bad-evidence` 且不生效**（不是抛错）⇒ 夹具造出的"有纠正记录"根本不存在 ⇒ **假红**。
-   本套件**连续踩了三次同一坑**（correction / sessions / success 三处）。教训：造证据类夹具必须**加自检断言**
-   （`ae.ok === true` / `evidence.sessions >= 3`），否则测试在测空气。
-2. **加工具会连带打破多处"数量硬锁"** —— 本次共 5 个文件 6 处（含一处正则 `!==\s*16`）。
-   纪律：新增/删除工具后必须全仓 grep 工具数断言，逐处更新并**写明原因**，不能只改数字。
-3. **`memory_procedure_pre` 必须无条件注册** —— 它不属白板 P3 闸门；若误放进 `graphEnabled` 分支内，
-   legacy 档就没有模型写入口（本项目 BUG-15 正是"defineTool 写在数组外"的同型缺陷）。
-   D1 已加反向断言守住这一点。
-
-### 12.6 边界与未做
-
-- **未禁用** `crossFeed()` 的机械 procedure 分支 —— 那会改 `memory-hub-pre.js`，
-  触及用户「procedure 引擎改动须先拍板」硬规则，**待用户裁定**。
-- `T3-3`（`overview()` 补投影 / 只读 `evaluatePromotion`）仍待用户 A/B/C 选择。
-- 观察线信封残留（`memory-hub-pre.js:152` 只用 `stripRuntimeIntentPre`，缺 F5 同款 `looksRuntimeResiduePre`）
-  未修，属同一批 procedure 引擎议题。
-- **⚠️ 待用户重启宿主**：`lib/index.js` + `lib/procedure-store-pre.js` 已改未生效。

package/docs/internal/ISSUE10-PLAN-20260919.md

@@ -1,254 +0,0 @@
-# ⑩-a / ⑩-b 规划（2026-09-19）
-
-> **本文件是上下文压缩后的唯一恢复入口**——读完它即可恢复 ⑩ 的全部上下文，无需回溯对话。
-> **术语校正**：用户口述「石壁」＝**⑩-b**（「十B」的语音转写）。
-> **⑩-b 的定义**＝**记忆文件（`MEMORY.md`）侧的隐患**，含两件事：(i) 尚未引爆的 **M8 回写雷**；(ii) 排版与语义的耦合。
-
----
-
-## 0. 一句话定位（先看这张表）
-
-| | **⑩-a** | **⑩-b** |
-|---|---|---|
-| **是什么** | **前端「记忆中枢」面板里看不懂** | **记忆文件侧的隐患**（回写雷 + 排版/语义耦合） |
-| **用户本意** | ✅ **这就是 ⑩ 的原意**（2026-09-19 用户以面板截图澄清） | 后续深挖出来的 |
-| **涉及语义引擎吗** | **不涉及**（已代码核实） | **涉及** |
-| **涉及 `MEMORY.md` 吗** | **不涉及** | **涉及** |
-| **今天的状态** | **待修**（用户指示先做） | **取证中**（两个只读子代理并行） |
-
-**⑩ 的文档链**：
-- 取证数据 → `R1-READABILITY-FORENSICS-20260919.md`
-- 人话版 + 四选修法 → `ISSUE9-PURGE-AND-R1-PLAIN-20260919.md`
-- **本文件 = 拆分为 ⑩-a / ⑩-b 后的执行规划**
-
----
-
-## 1. ⑩-a · 前端面板可读性（**本项要做**）
-
-### 1.1 现象（用户截图，2026-09-19）
-前端「记忆中枢」→ 事实（Semantic）区，条目显示为乱码与噪声，**人看不懂**。
-
-### 1.2 根因 = **数据脏，不是渲染差**（已实测）
-
-喂该面板的是 `~/.dsh/memory/hub-pre/facts.json`。探针实测 **4 条中 3 条是坏的**：
-
-| # | factId | 坏在哪 |
-|---|---|---|
-| 0 | `fact_pre_ac4920327df6601f25200d66e52df71f` | **22 个 U+FFFD**：`DSH ������ \| has three modes \| shadow …` |
-| 1 | `fact_pre_a9380f5bca22011e33547a45542c61a3` | object 内嵌运行时信封：`Current DSH file policy: danger-full-access…` |
-| 3 | `fact_pre_dda6cc1f36176f5ea000c6f681ea6818` | object 内嵌运行时信封：`Approval prompts are disabled in this session…` |
-
-### 1.3 为什么脏 = **⑨ 只修了一半**（关键发现）
-
-`lib/memory-hub-pre.js` 的 `crossFeed()` **两条通路不对称**：
-
-```
-走 procedure（约 :152）→ stripRuntimeIntentPre(ep.intent)        ✅ ⑨ 已修
-走 fact     （约 :166）→ subject: ep.intent.slice(0, 30)          ❌ 完全没清洗
-                        object:  ep.unresolved[0].slice(0, 60)    ❌ 直接切片
-```
-
-同理 `factCandidateFromRow()`（约 `:249-265`）**也不调**清洗器，只做 `String(row.subject || sourceIds[0])`。
-⇒ **⑨ 修了「技能」那条路，「事实」这条路整套漏掉** —— 这是 `facts.json` 变脏的直接成因。
-
-### 1.4 修复方案
-
-| 步 | 动作 | 位置 |
-|---|---|---|
-| **a-1** | **清存量脏数据**（3 条） | `~/.dsh/memory/hub-pre/facts.json` |
-| **a-2** | `crossFeed()` 的 **fact 分支**补清洗：`subject`/`object` 先过 `stripRuntimeIntentPre` | `lib/memory-hub-pre.js` 约 `:166-174` |
-| **a-3** | `factCandidateFromRow()` 补清洗（`subject`/`predicate`/`object`） | 同文件约 `:249-265` |
-| **a-4** | 新增 smoke 套件 + 变异演示 + 全量回归 | `tests/smoke/` · `artifacts/` |
-
-**清洗器的选择**：复用 ⑨ 修好的 `stripRuntimeIntentPre()`（`lib/intent-clean-safe-pre.js`）。
-它同时覆盖两类脏数据——**F3**（召回块/信封尾部标记）与 **F4**（`looksEncodingCorruptedPre`，U+FFFD ≥3）
-⇒ 一条调用即可同时解决「信封污染」与「乱码」两种症状。
-
-**⚠️ 清存量数据的坑（⑨ 已踩过，务必复用）**：
-宿主**内存里持有副本**，`dispose()` 会**整份写回盘** ⇒ **直接编辑 json 会被回滚**。
-⑨ 的解法是走宿主自己的 loopback 通路（`POST /api/dsh-auto-memory-pre/memory-hub`）。
-
-### 1.4b ★ a-1 调研结论（2026-09-19 20:45 已查，**未动手**）
-
-**事实一：fact store 没有「按 id 删除」的方法。**
-`fact-store-pre.js:409-410` 导出的全集 = `upsert · supersede · get · query · conflictsList · pendingConflicts · resolveConflict · evidenceFor · revokeBySource · snapshot · restore · clear · dispose`
-—— **没有 `remove` / `delete` / `revokeById`。**
-
-**事实二：唯一的撤销通路是 `revokeBySource(sourceId)`（`:283-300`），且它按 provenance 反查**：
-
-```js
-if (!Array.isArray(f.provenance) || !f.provenance.includes(sid)) continue
-f.revoked = true; f.revokedAt = now; f.revokeReason = 'source-deleted'
-```
-
-⇒ **只读不删**（注释明写「保留 provenance 与 revokedAt，只读不删（可审计、可追溯）」）。
-
-**事实三：三条脏数据的 provenance 分别是** `mem_af41b679…`（记忆 id）、`epi_pre_66d51268…` / `epi_pre_010a543e…`（episode id）
-⇒ 用 `revokeBySource` 清它们，**前提是先删掉那两个来源** —— 代价远大于清三条 fact。
-
-**⇒ a-1 的三条候选路线（待用户拍板，勿自行选）**：
-
-| | 做法 | 代价 | 评价 |
-|---|---|---|---|
-| **路 A** | 走 `storage-manage` 的 `delete`（`index.js:10476-10487`，级联 `factStore.revokeBySource`） | **要连带删掉那条记忆 / episode** | ❌ 副作用太大 |
-| **路 B** | 新增 `revokeById(factId)`（按 id 直接撤销） | 动源码（新增方法 + 套件），但最小精准，**仍符合既有语义**（只读不删 + 留痕） | ⭕ 可选 |
-| **路 C** | **不改数据，改行为**：让 `hubFlushTick` 的过滤条件**主动跳过脏 fact**（`subject`/`object` 命中清洗器判据即 skip） | **零数据改动**，脏条目留在盘上但**永远写不出去** | ✅ **倾向** |
-
-**★ 更根本的判断**：⑩-a 的根因是「**fact 通路没清洗**」⇒ **先修 a-2/a-3，新脏数据即断源**。
-**存量 3 条怎么处置，是独立的小决策**，不影响主线；且与 ⑨ 的取舍同源（**⑨ 时用户选的是「弃用不删」**）。
-
-### 1.5 验收标准（可自动化）
-1. `facts.json` 中 U+FFFD 计数 = 0
-2. `facts.json` 中命中 `/Current DSH file policy|Approval prompts are disabled|Current runtime context|Retrieved memory ref/i` 的条数 = 0
-3. 新套件断言：`crossFeed` 走 fact 时脏 intent **不落库**
-4. 变异演示真红（把新加的清洗调用去掉 ⇒ 断言必须变红）
-5. 全量回归 **0 失败**
-
-### 1.6 风险与回退
-- **风险：低**。不改注入路径、不改语义语料、不碰 `MEMORY.md`。
-- **回退**：清洗器调用是**纯函数前置**，去掉即恢复原行为；数据侧有备份。
-
-### 1.7 顺带记录（不在本次范围）
-清洗后仍会看到 `XX | 有未决事项 | YY` 这类由 episode 自动派生的事实——**内容质量本身偏低**（它是「有未决事项」的机械模板，不是真的知识）。
-**这是 ⑩-a 之后的独立话题**（可称 ⑩-a-2 「fact 质量」），需另立规划，不在本轮。
-
----
-
-## 2. ⑩-b · 记忆文件侧的隐患（**本项只取证，不修**）
-
-### 2.1 为什么「涉及语义」——三条管线的耦合（已代码核实）
-
-`MEMORY.md` **不是纯文本**，它同时喂三条管线：
-
-| # | 消费方 | 依据 |
-|---|---|---|
-| ① | **注入上下文**（整篇文本） | `lib/index.js:5498-5499` |
-| ② | **L0 摘要抽取**（按 `<!-- memory:mem_<32hex> -->` 切条） | `lib/l0-extract-pre.js:34` |
-| ③ | **语义语料**（锚点划字节区间 → `recordDigest`） | `lib/memory-anchor-pre.js:168/248`；复核在 `lib/m4-corpus-pre.js:107` |
-
-**两条硬约束**：
-- 文件级先比 `fileDigest`，不等则**跳过整个文件**（`m4-corpus-pre.js:96`，连逐条比对都不做）；
-- `sourceVersion` 随 `fileDigest` 变化 **+1**（`memory-anchor-pre.js:267`）⇒ 该文件**向量全部失效需重编码**。
-
-**`memoryId` 是随机的**（`memory-anchor-pre.js:40` `newMemoryId()`）⇒ **就地改文件会换一批新 id**，
-已积累的 `seen/read/cite` 证据、`supersededBy` 指针、白板锚点**全部对不上号**。
-
-**正路**：sidecar 是**可重建的派生数据**（`note-status-pre.js:16` 明示）⇒ 改正文须配套走
-`storage-manage-pre.js` 的 `repair` 重建 sidecar（**只重建 sidecar，不动正文**）。代价＝向量重编码 + id 漂移。
-**真正安全**：**追加式写入**（既有 `memory-writer` 事务路径），不改已有条目的字节布局。
-**绝不可做**：改/删文件里的锚点标记——它是**切条唯一依据**，去掉后整篇退化为一个 legacy 块，`memoryId` 全丢。
-
-### 2.2 ★★★ 尚未引爆的雷：**判断已被推翻 —— 它已经引爆过**（2026-09-19 子代理 A 取证 + 主代理独立复核）
-
-> **⚠️ 本节原先写的是「实测尚未引爆」。该结论错误，已作废。**
-> 错误根源：把「两份 `MEMORY.md` 里 `（M8 固化）` 计数为 0」当成了「没写过」的证据。
-> **真相：写过了、而且是成功写入；后来被容量整理（compaction）移出正文、落进归档。**
-
-**★ 铁证（主代理独立复核，非仅采信子代理）**：
-
-| 证据 | 内容 |
-|---|---|
-| `archive/notes-archived.md:493-495` | `## DSH ������（M8 固化）` / `- has three modes：shadow ֻ��¼ …` / `- 来源：记忆中枢治理固化（confidence=0.92）` |
-| 同文件 `:519-521` / `:684-686` / `:3168-3170` | 另 3 段（`让我自己去试吧…` / `是这样的，我后台在改语义模型…` / `Approval prompts are disabled…`），**均带 `（M8 固化）`** |
-| `MEMORY.md.bak-20260917-G2` | 正文里**曾有** `## Approval prompts are disabled（M8 固化）` ⇒ 证明**当时确实在正文** |
-| 格式唯一性 | `（confidence=` 这一写法全仓只出现在 `lib/index.js:8981` ⇒ 这些段落**只能由本通路产生** |
-| 锚点存在 | 每段都带 `<!-- memory:mem_<32hex> -->` ⇒ 走的是 `appendText` **正经事务**，不是事后手工拼 |
-
-**⇒ 结论：`count: 0` 不是「没写」的证据。**
-`index.js:8962` `if (hubFlushState.date !== today) { …count = 0 }` —— `count` 按**记忆日**清零，
-当前 `date:2026-09-19 / count:0` 只表示「**今天还没写**」。
-
-**危险本质（现已确认，不再是假设）**：**facts 侧是脏的（见 §1.2），而这条通路会把脏数据写进 `MEMORY.md`** ——
-**从「面板难看」升级为「污染注入 + 污染语义语料」，且已实际发生。**
-归档里那段 `## DSH ������（M8 固化）` 就是活证据。
-
-### 2.3 ★ 子代理 A 的其余关键发现（含行号，可复核）
-
-| # | 发现 | 依据 |
-|---|---|---|
-| 1 | **两条 tick 的开关门控是彻底的**（关掉不写），**但定时器无条件创建**、开关关掉后仍每 30min 空转；**`hubBootTimer` 未纳入 disposer** | `index.js:8918/8958`（门控）· `8992-8993`（无条件创建）· `8999`（只 clear 两个 interval） |
-| 2 | **6 道过滤全是「结构性」，没有一道是「内容卫生」** —— 不查脏数据、不查长度、不查换行、不查信封 | `index.js:8970-8974` |
-| 3 | **`confidence: null` 直接放行**（`typeof null === 'object'` 判假）⇒ facts.json 里 3 条 null **全部放行** | `index.js:8972` |
-| 4 | **`ttl: 0` = 永不过期** ⇒ 4 条全放行 | `index.js:8971` + `fact-store-pre.js:60` |
-| 5 | **换行未归一化** ⇒ 一条 fact 可**伪造 `## ` 标题**，并被 `compactLegacyLayer` 的分段正则当成独立段落搬运 | `index.js:8981` · `4796` `if (m = ln.match(/^##\s+(.+)$/))` |
-| 6 | **失败静默**：`catch (_) {}` 吞异常（`:8987`），而 `hubFlushSave()`（`:8989`）**在 try 外无条件执行** ⇒ 失败也照写 flush-state | `index.js:8987` / `8989` |
-| 7 | **`flushed` 与 `count` 不自洽**：`cur.includes(subj)` 分支只置标记、不 `count++`；且该标记**永久生效**；且判定用**子串**（短主语易误命中） | `index.js:8980` vs `8984-8985`；`8962` 只清 count 不清 flushed |
-| 8 | **`flushed` 永不清理** ⇒ 实际语义是「**生命周期总量 8 条**」而非「每日 8 条」；**归档后永不重写**（单向） | 全仓无 `flushed = {}` / `delete` |
-| 9 | **无重入保护**（`void hubFlushTick()` 无 in-flight 标志）；文件不撕裂靠 docStore `_queue` 串行，但 **flush-state.json 是裸 `writeFileSync`，无锁无 tmp+rename** | `index.js:8993` · `8895` · `memory-writer-pre.js:345-352/506` |
-| 10 | **`hubFlushSave` 写失败被静默吞** ⇒ 重启后 `flushed` 回退 ⇒ **已写过的 fact 会被再写一遍**（正文出现两个同名 `（M8 固化）` 段落） | `index.js:8895` `catch (_) {}` |
-| 11 | **可观察性缺失**：成功有 `diag`（`:8986`），**失败零留痕**（无 diag、无 degrade 台账，对照 `:5853` note-status 路径**有** `_degradePre.record`）；`overview()` **不含 flush 字段** ⇒ 面板看不到「写了但没成功」 | `index.js:8986/8987` · `memory-hub-pre.js:192-220` |
-
-### 2.4 待查清单（子代理 B 仍在运行）
-
-**子代理 B —— `MEMORY.md` 全部写入者普查**（`88b6427e-5393-42b7-bed3-ee46c41e8ce6`）：完整清单 → 是否走事务 → `memoryId` 命运 → sidecar 与 digest → 风险面 → 现有防线。
-
----
-
-### 2.5 ★★★ ⑩-b 完整取证报告（2026-09-19 已完工）
-
-> **`docs/internal/ISSUE10B-FORENSICS-20260919.md`** ← **⑩-b 的唯一权威文档，压缩后读它**
-
-**两份只读子代理普查 + 主代理逐条复核的合并成果**，含：
-
-| 节 | 内容 |
-|---|---|
-| §0 | 一句话结论：**20 条写入通路 × 3 条消费管线，中间没有任何联合把关** |
-| §1 | 三条消费管线（注入 / L0 / 语料）+ 语料的两级静默丢弃 |
-| §2 | **20 条写入者全景表** + 清洗门只接 5 处 + **全自动无人值守的只有 3 条** |
-| §3 | 三个致命结构问题：`stripAnchorLines` 承诺不成立 · `reuse` 是死代码 · `sanitizeReservedSyntax` 去功能化 |
-| §4 | M8 回写通路：**已引爆的物证** + 六道过滤 + 五个失败模式 |
-| §5 | **主代理对子代理的三处纠正**（含「默认裸写」对用户本机不成立） |
-| §6 | 风险排序 + **「自我放大回路」** |
-| **§8** | **★ 修复方案 T0/T1/T2/T3 四层 + 执行顺序 + 验收标准 + 风险回退** |
-
-**★ 最重要的一条新增认知（§6）**：
-```
-记忆文件字节 → m4-corpus-pre.js:118 取 text → index.js:8943 作 fact.subject
-                                    ↓
-                         hubFlushTick:8982 写回 MEMORY.md
-                                    ↓
-                         （若脏）再次成为语料来源 → 再固化 → 再写回
-```
-⇒ **脏数据不只是「落盘」，它会自己繁殖。**
-
-**★ 关键洞察（§8.1）**：**⑩-a 的修法就是 ⑩-b 的主要止血手段** ——
-`crossFeed` 的 fact 分支未清洗，既是 §1.2（面板乱码）的成因，也是 M8 回写脏数据的源头。
-**给 fact 通路补清洗器，同时解决 ⑩-a 与 ⑩-b 的脏源。**
-
-**★ 诚实评估紧急度（§8.0）**：急性事故已发生完毕（4 条已写入并归档），**没有持续流血**；
-但 `count` 每日清零、`flushed` 永不清零 ⇒ **每个记忆日仍有最多 8 次脏写入机会**，且脏源持续产生。
-⇒ **中高优先，应在进入前端前修完**（与用户既定节奏一致）。
-
-### 2.4 取证完成后的流程（用户指定）
-1. 把「它是什么、怎么干、会造成什么隐患」讲清楚 → **用户看**
-2. 用户与 agent 一起定修法 → **修复方案再落一次盘**
-3. 用户压缩上下文 → **agent 一次修完**
-
----
-
-## 3. 执行序（用户 2026-09-19 指定）
-
-```
-[1] 本规划落盘                                    ← 本文件
-[2] ⑩-a 修复（面板清晰可懂）                      ← 先做
-[3] ⑩-b 全量取证（子代理，只读）                  ← 已并行启动
-[4] 向用户讲清 ⑩-b 的隐患 → 用户拍板修法 → 修法落盘
-[5] 用户压缩上下文 → agent 修完 ⑩-b
-[6] 走到前端方向
-[7] 前端做完 → GLM 全量审核 + 白皮书
-```
-
-**注意**：⑩-a 与 ⑩-b **不互相阻塞**：⑩-a 不碰 `MEMORY.md`、不碰语义语料。
-但 ⑩-a 的清洗器修复**会降低 ⑩-b 的风险**（脏 fact 不再新增）。
-
----
-
-## 4. 与最终方向的关系（用户 2026-09-19 补充）
-
-⑩-b 不是孤例，而是**一类系统性风险的一次样本**：本插件的「记忆」不是普通文件，
-而是**注入面 + 检索面 + 语义面共用的同一份字节**。任何一处写入都要同时满足三套约束，
-而**历史实现是分批长出来的**——于是「一处漏清洗」「一处绕过事务」这类雷会零散地留着。
-
-⇒ 这正是**前端做完后必须做「GLM 全量审核 + 白皮书」**的原因：
-**逐条修只能清掉已知的雷，全量审核才能把「还有多少雷、都分布在哪一类通路」讲清楚**，
-白皮书则是把这套「三面共用一份字节」的约束**显式成文**，让后续任何写入者都不再靠口口相传。