@a9i5k4/dsh-auto-memory 3.0.1 → 3.1.0

package/docs/internal/PROCEDURAL-MEMORY-AND-APPROVAL-DESIGN-20260918.md

@@ -1,225 +0,0 @@
-# 作废标记语义修正 + Procedural Memory + 长期记忆审批（2026-09-18 设计稿）
-
-> **用户裁定**（本节其余内容均由此推出）：
-> ① 「**这个 reacted 不是过滤掉**……**并不是挡，我感觉是备注**」；
-> ② 「如果遇到这个，后面应该说明现在**更正的内容在哪个哈希值里面**，方便 AI 去搜索」；
-> ③ 「这个**长期记忆审批**的问题……用户都说看不懂……**太抽象了**，名字也不知道，流程是啥也不知道，没法审，**只能盲确认**」；
-> ④ 「这个教训和这个**攻关完成的项目**，和**多次重复的事件**，应该都可以上升为 **skill 式**的。这个长期记忆就是 **procedural memory**，你看能不能和那个做结合」。
-
----
-
-## 1. ★ I5 再修正：从「按状态分流」改为「一律返回、一律标记」
-
-### 1.1 我上一版的错误
-
-我上轮提的方案是「`superseded` 放行 + 标记，`retracted` **继续硬过滤**」。
-**用户否掉了，而且理由比我的更根本**：
-
-> 「如果你不记住这个教训的话，你还会再踩。所以**并不是挡，我感觉是备注**。」
-
-我的分法来自**检索视角**（过时的信息不该干扰当前判断）；用户的分法来自**学习视角**
-（**做错的事恰恰是最该被记住的**）。对记忆系统而言，后者才是目的——
-`retracted` 不是"垃圾数据"，它是**一条教训**：*「这条曾经被当成结论写下来，后来发现是错的」*。
-把它藏起来，等于**系统性遗忘自己的错误**，这正是用户说的"还会再踩"。
-
-### 1.2 修正后的语义（三态一律返回）
-
-| status | 语义 | 呈现 |
-|---|---|---|
-| `current` | 现行结论 | 原样（**逐字节向后兼容**） |
-| `superseded` | 被更新的结论取代 | `⚠已作废（已被 mem_<hash> 取代）` |
-| `retracted` | 判断有误 / 主动撤回 | `⚠已撤回（原因：<reason>；更正见 mem_<hash>）` |
-
-**关键变化**：`isRetrievablePre` 不再过滤任何 status（只对**未知值 fail-closed**，防未来新增枚举时静默放行）。
-
-### 1.3 「指向哈希值」= 让 AI 能自己去追（用户 ②）
-
-用户要求「说明更正的内容在哪个哈希值里面，方便 AI 去搜索」——
-这要求标记里带上**可检索的 id**，而不只是一句"已作废"。落地要点：
-
-- id 就是既有的 `mem_<32hex>` 锚点 id（**已有的东西，不新建 ID 体系**，守 S10.4）
-- 标记形态：`⚠已作废（已被 mem_xxxx 取代）` ⇒ AI 可直接拿这个 id 去 `memory_recall_pre` / `grep`
-- `retracted` 额外带 **reason**（为什么撤回）——这才是"教训"的正文，比 status 本身有价值
-
-> ⚠️ **安全纪律（已在 R4-A 探针锁定）**：id 只认 `/^mem_[0-9a-f]{32}$/` 形态，
-> 不合法一律丢弃 —— 防止把任意文本拼进检索呈现。
-
-### 1.4 对 I5 的最终影响
-
-原 I5：「非 `current` 的条目在**检索结果与注入内容两处**都被过滤」。
-**新语义**：**检索侧完全不过滤**（一律返回 + 标记）；**注入侧维持过滤**——
-理由是注入是**常驻目录**（B0 仅 800 token），拿常驻预算装过时条目会挤掉现行结论；
-检索是**按需**的，AI 主动问什么才给什么，装一条带警告的过时结论划算。
-
-⇒ 即 **I5 的"两处"要求被拆开**：检索侧从"过滤"改为"标注"，注入侧不变。
-
----
-
-## 2. ★ 仓库里已经有 procedural memory（用户的 ④ 不是新建，是接线）
-
-**这是本次最重要的发现**：用户说"看能不能和那个做结合"——**那些东西已经存在了**：
-
-| 已有资产 | 位置 | 作用 |
-|---|---|---|
-| `createProcedureStorePre` | `lib/procedure-store-pre.js` | 技能店：`observe/promote/activeProcedures/renderChecklist/touch/addEvidence` |
-| `createMemoryHubPre` | `lib/memory-hub-pre.js` | 三层编排器（episodic / **fact** / **procedure**） |
-| `isObservationOnlyPre` | `lib/procedure-observation-pre.js` | 观察型候选（不可晋升）标记 |
-| `act.skill` 段 | `lib/activation-inbox-pre.js` | **技能注入进投递面**（`renderSkillBlock` 渲染 checklist） |
-| 技能召回 | `lib/context-host-pre.js:524+` | query 匹配 active skill → 相似场景自动附上 |
-| 三层记忆面板 | `lib/client.js:2552+` | 「记忆中枢」页：晋升/激活/弃用/置顶 |
-| 证据制晋升闸门 | `index.js:522-531` | `minSessions=3` / `minSuccess=2` / `correctionCap=0.3` / 高风险需批准 |
-
-**⇒ 用户想要的「教训 / 攻关完成的项目 / 多次重复的事件 → skill 式」，机制上就是 `procedure` 层。**
-不需要新建系统，需要的是：**接通 + 让它好用 + 让它能被审**。
-
-> ⚠️ **agent 曾在此处判断错误（已更正）**：初稿写「`procedurePromotionEnabled=false` 与宣传不一致」，
-> 把它当成默认值 bug。**实际是有意关闭**（Hermes 遗留未修）——见 §2.1。
-
-
-### 2.1 出厂为什么是**关的**（用户裁定 2026-09-18，**纠正 agent 的误判**）
-
-`index.js:513  procedurePromotionEnabled: false`
-
-**agent 原判断（错）**：写成"宣传与实现不一致"，当成默认值 bug。
-**用户裁定**：
-
-> 「记忆晋升是因为**之前的记忆系统有这个问题**，它用的是 **Hermes 那套**。
-> 你可以从记忆里看到我要改，**所以才先关掉的，改完自然就能打开了**。」
-
-⇒ **这是有意的临时关闭，不是缺陷**。关闭理由是 Hermes 遗留问题（见已归档的 Hermes 调研笔记）。
-⇒ **待办不是"改默认值"，而是"把 Hermes 那套的问题改完"** —— 改完默认值自然打开。
-⇒ 本章 §4-1 的待拍板项**随之解除**（不再是选择，而是一个依赖关系）。
-
-### 2.2 三类来源到 procedure 的映射（用户的三个例子）
-
-| 用户说的 | 现有对应机制 | 缺口 / 裁定 |
-|---|---|---|
-| **「教训」**（踩过的坑） | `retracted` 条目 + `corrected` 证据 | **无自动通路** ⇒ ✅ **已裁定：教训进「候选」，不自动晋升，但可被检索**（见 §2.3） |
-| **「攻关完成的项目」** | `episode.success === true` → `observe()`（`memory-hub-pre.js:132-148`）| 只有 `intent + 1 步「观察任务：…」`，**步骤质量不足**（issue30 的 P3 就修过"步骤1: user"垃圾） |
-| **「多次重复的事件」** | `minSessions=3` + `minSuccess=2` 跨会话证据 | 机制**已有且合理** |
-
-⇒ **最大缺口在第 1 行**，且已被用户裁定（§2.3）。
-
-### 2.3 ★ 教训的晋升与检索（用户裁定 2026-09-18）
-
-> 用户原话：「**教训**肯定得进 C 啊，它**不自动晋升**，但是**可以形成候选**，
-> 模型也可以**通过搜索搜索到**。因为教训那边，我现在**自动注入的硬约束也是某种教训**，
-> 把它**上升到了约束层面**。」
-
-**裁定拆解**（agent 转写，若理解有偏差请纠正）：
-
-| 层 | 教训的形态 | 是否自动晋升 | 模型如何拿到 |
-|---|---|---|---|
-| **候选（Candidate）** | 从 `retracted` / `correction` 证据生成的**观察型** procedure candidate | ❌ **永不自动晋升** | **主动搜索**（`memory_recall` 可检索到） |
-| **skill** | 经证据闸门（`minSessions=3`/`minSuccess=2`）+ 人工审批后晋升 | 需人工 | **由官方流程注入**（见 §2.4） |
-| **约束 / 规则** | 用户当前**自动注入的硬约束**——「**也是某种教训**，把它上升到了约束层面」 | 用户显式写 | 每轮自动注入（rules layer） |
-
-**★ 这条裁定的关键洞察（本项最重要的一句）**：
-**教训的终极形态不是 skill，而是"约束"**。用户当前系统里自动注入的硬约束
-（记忆里的 `[规则 — 用户级硬性约束]` 层）**本质上就是教训升格后的产物**。
-⇒ 所以本设计不是"新建一个教训系统"，而是**把既有的三层打通**：
-`retracted 教训` →（候选，可检索）→（人工晋升）→ `skill` →（若足够普适）→ `约束/规则`。
-
-### 2.4 ★ skill 的注入路径（用户两次澄清后的**最终版**）
-
-**⚠️ agent 曾在上一稿下过头的结论（已更正）**：曾写「skill 注入归官方，插件不重复注入、
-`act.skill` 段可能应改为只提供检索入口」—— **这是错的**。
-
-**用户最终澄清（原话）**：
-
-> 「印象这个 **skill 是相对比较独立的系统**，它**顶多会塞这个语义换回（召回）的时候
-> 会换回这个 skill**。所以，**如果晋升成功，这个 skill 理论上应该是会被注入的**。」
-
-**⇒ 正确理解（两条并行、互不冲突）**：
-
-| | 官方 skills | **本插件的 procedure（skill）** |
-|---|---|---|
-| 归属 | DSH 官方技能系统 | **本插件，相对独立的系统** |
-| 注入方式 | 官方流程（"会把所有 skills 当作注入"） | **经本插件的语义召回命中后附着注入** |
-| 代码位置 | 官方 | `context-host-pre.js:524+`（query 匹配 active skill → `act.skill`）／<br>`activation-host-pre.js:300+`（Python 档 emit 帧）／`activation-inbox-pre.js` `renderSkillBlock` |
-| 结论 | 与插件无关 | **✅ 晋升成功后，skill 会被本插件正常注入** |
-
-**⇒ 对本设计的实际影响**：
-1. **`act.skill` 段保持不变**，不是"应废弃" —— 它是本插件 skill 注入的**实现本体**。
-   上一稿把它列为"待评估是否废弃"**作废**（BATTLE-PLAN §7 第 11 项随之撤销）。
-2. 「不用占插件资源」的语境是**官方 skills 那一套**，**不适用于**本插件的 procedure；
-   本插件 procedure 的注入走自己的语义召回，**该占的资源照占**（这是它的职责）。
-3. **晋升 = 真正生效**：晋升成功后 skill 进入 `activeProcedures()`，被相似 query 命中后注入。
-   ⇒ 这**加强了**审批责任感：审批界面「晋升后会怎样」那一栏要展示的正是
-   **`renderChecklist()` 的真实文本**（§3.2 第 2 条），因为**那就是将来会被注入的内容**。
-
-
----
-
-## 3. ★ 长期记忆审批：为什么"看不懂"（用户 ③）
-
-用户原话：「**名字也不知道，流程是啥也不知道，没法审，只能盲确认通过**」。
-
-### 3.1 现状（代码级）
-
-「记忆中枢」页（`client.js:2552+`）对每条 pipeline 条目只展示：
-`title` / `stage` / `riskLevel` / `evidence` + 三个按钮（晋升/激活/弃用/置顶）。
-
-**缺的恰恰是审查所需的三样**：
-
-| 审查需要知道 | 现状 | 后果 |
-|---|---|---|
-| **它是什么**（这条技能干什么） | 只有 `title`（≤40 字，还是从 `intent` 截断来的） | 名字看不出内容 |
-| **凭什么该晋升**（证据） | 只有 `evidence` 计数的裸数字 | 不知道是哪几次会话、发生了什么 |
-| **晋升后会怎样**（注入形态与代价） | 完全没展示 | 不知道点了会发生什么 |
-
-⇒ **这不是 UI 品味问题，是"审查所需信息结构性地不在界面上"** ⇒ 只能盲确认。
-
-### 3.2 设计方向（待细化，先记原则）
-
-1. **展示「凭什么」**：把 `evidence` 从计数展开为**可点开的证据链**——
-   哪几个 session、每次的 `kind`（success/correction）、对应的 episode 摘要。
-   *（数据已在 `addEvidence` 里存着，只是没展示。）*
-2. **展示「晋升后会注入什么」**：直接调 `renderChecklist(procedureId)` 把**将要注入的文本原样预览**。
-   *（函数已存在，`activation-inbox-pre.js` 就在用它渲染。）*
-3. **说人话**：`stage`/`riskLevel`/`observationOnly` 这些内部枚举要给**中文解释**，不能只显示代号。
-4. **能反悔**：晋升错了要能撤回（与 G3 的「撤销通道 U1」同源纪律）。
-
-> **与 G3 的关系**：G3 的 `restore`（撤销误标 superseded）与本项的「撤回误晋升」
-> 是**同一个交互模式**——**凡自动/半自动改变结论状态的操作，都必须有人工回退通道且留痕**。
-
----
-
-## 4. 待用户拍板 → ✅ **已全部拍板（2026-09-18）**
-
-| # | 事项 | 用户裁定 |
-|---|---|---|
-| 1 | `procedurePromotionEnabled` 出厂默认 | ✅ **不是默认值问题**——是**有意临时关闭**（Hermes 遗留）。⇒ **待办改为"把 Hermes 那套的问题改完"，改完自然打开**（详见 §2.1） |
-| 2 | 教训是否进 procedure | ✅ **「教训肯定得进 C 啊，它不自动晋升，但是可以形成候选，模型也可以通过搜索搜索到」** ⇒ **进候选 + 可检索 + 永不自动晋升**（详见 §2.3） |
-| 3 | 注入侧是否也返回 | ✅ **随 I5 修正一并解决**（见 §2.4 + BATTLE-PLAN §10）：**检索侧一律返回+标记**；<br>本插件 procedure（skill）**晋升成功后经语义召回正常注入**，`act.skill` 段**保持不变** |
-| 4 | 审批界面何时做 | ✅ 归口**前端重构**（与首次启动页一并） |
-
-**⇒ 4 项全部解除，本设计稿无阻塞项。**
-
----
-
-## 5. 归口与排期
-
-| 事项 | 归口 | 时机 |
-|---|---|---|
-| I5 再修正（一律返回 + 标记 + 指向哈希） | R4-A | ✅ 边界已全部拍板，可开工（改动仍冻结） |
-| 三条 issue #55–#58 修复 | 新增批次 | **前端重构之前**（用户裁定） |
-| **Hermes 遗留问题修复**（打开 procedurePromotion 的前提） | 待立项 | ⬜ **新识别出的依赖项** |
-| 教训 → 观察型候选（可检索、不自动晋升） | 待立项 | ⬜ 见 §2.3 |
-| ~~评估 `act.skill` 段在官方接管后的定位~~ | — | ❌ **已撤销**：skill 是**相对独立的系统**，晋升成功后**会被本插件正常注入** ⇒ `act.skill` 段是**实现本体，保持不变** |
-| **Hermes 遗留问题修复** | 待立项 | ⬜ **打开 procedurePromotion 的前提**（§2.1） |
-| 审批界面重构（看懂"凭什么"） | **前端重构** | 与首次启动页一并 |
-| 首次启动页重构 + 赞助商/中转站展示 | **前端重构** | 用户要求届时提醒 |
-
----
-
-## 6. 本次三项裁定暴露的一条通用判据（供后续沿用）
-
-> **agent 两次提出方案，两次被用户的"视角"推翻**：
-> ① I5：agent 用**检索视角**（过时信息别干扰）→ 用户用**学习视角**（做错的事最该记）；
-> ② procedurePromotion：agent 当**默认值 bug** → 实际是**有意的临时关闭**（依赖未修）。
->
-> ⇒ **可复用教训：看到"配置是关的/行为是旧的"，先查它是不是"因为已知缺陷而故意关的"，
-> 不要直接判定为疏漏。** 本仓已有先例（`memoryAnchorEnabled=false` 也是默认路径的关键开关），
-> 这类"关着的开关"往往承载着未修复的依赖，**误判为 bug 会导致方向性错误**。
-

package/docs/internal/PROGRESS-20260917.md

@@ -1,93 +0,0 @@
-# 周末作战 · 进度表（2026-09-17 收盘）
-
-> 权威顺序依据：`docs/internal/BATTLE-PLAN-20260917.md`（396 行）。
-> 回归口径：`node tools\run-smoke.mjs`（全量，非单套件）。
-> 本表每次阶段完工后回写。
-
-## 总进度条
-
-```
-L 层 ████████████████████ 100%   ✅ 已冻结（PASS 112 / FAIL 0）
-G4   ████████████████████ 100%   ✅ 已完成（=M3，已吸收）
-M9   ████████████████████ 100%   ✅ 已完成（容量默认 12000→24000 + 老配置迁移）
-M 层 ░░░░░░░░░░░░░░░░░░░░   0%   ⏭ 下一步（M1/M2）
-S 层 ░░░░░░░░░░░░░░░░░░░░   0%   ⏸ 待 L/M 冻结后开
-G2   ████████████████████ 100%   ✅ 已完成
-G3/G5/G6 ░░░░░░░░░░░░░░░░   0%   ⏸ 待办（见文末）
-```
-
----
-
-## 〇、M9 · 容量出厂默认 12000 → 24000（用户报障驱动）
-
-**用户原话**：「先把所有人的默认都改到 24000，好多人跟我抱怨写满了，写不进去了。」
-
-| # | 项 | 改动 |
-|---|---|---|
-| M9a | 出厂默认 | `DEFAULT_NOTE_CAPACITY_CHARS` / `DEFAULT_USER_CAPACITY_CHARS` 12000 → **24000** |
-| M9b | **老配置一次性迁移** | 新增 `upgradeCapacityDefaultsPre()`：配置里**仍是 12000**（= 没表达过偏好）才抬到 24000；用 `capacityDefaultsVersion` 守卫**只升一次**；用户自设值（8000/50000…）一律不动；异常 fail-soft |
-| M9c | 落盘 | `loadConfigSync`（注册期真正跑的那条）+ `loadConfig` 都接上；异步路径抬升后 `persistConfigPre()` 落盘（否则设置页读盘仍显示 12000） |
-| M9d | 文案同步 | 设置页 zh/en 各 2 处提示 + 两个输入框占位默认值 + 注入纪律行 + `memory_note_pre`/`memory_user_pre` 描述 |
-| M9e | 历史保全 | **2.4.0 changelog 里的 12000 原样保留**（那是发布记录，改它=伪造历史）——已写成断言 M9-10 锁死 |
-
-**为什么必须配迁移（关键）**：`saveConfig` 把**整个合并后的 config** 落盘（实测本机 95 个键全在盘上）⇒ 老用户只要在设置页存过**任何一项**，`noteCapacityChars: 12000` 就已被钉死在磁盘上。**只改常量对老用户完全无效**（配置值覆盖默认值）。这正是"好多人抱怨写满了"的机制。
-
-**验证**：`smoke-test-m9-capacity-default-pre.mjs` **10/10 绿**；变异演示 **6 处变异 → 4 条断言真红**，还原后 10/10 绿。
-
----
-
-## 一、本轮完工明细（逐条可回代码核对）
-
-| # | 项 | 状态 | 关键改动 | 证据 |
-|---|---|---|---|---|
-| L1 | 看板渲染解耦 | ✅ | `kanbanBoardData` 删掉 `handoffEnabled` 早退（渲染不归产物开关管） | 首 900 字符内无 `handoffEnabled`；`boardMode` 门保留 |
-| L2 | 面板 render 解耦 | ✅ | `handoffPanelData` 门改为 `boardMode!=='graph'` → `{enabled:false,reason:'legacy-mode'}` | `legacy-mode` 存在；无 `handoffEnabled` 早退 |
-| L3 | 接续预算重构 | ✅ | 新增 `assembleCarryPre({head,nav,bulk,budget})`：**nav 配额先扣、永不截断**，bulk 可截断 + 截断自述 | `export function assembleCarryPre(...)` 签名核对；`材料因预算被截断` 存在；`bulkParts.push` 存在 |
-| L3.5 | 附件路径进转写 | ✅ | `attachmentsOfContent` / `attachmentBlobPathsPre` / `renderAttachmentLinesPre` + `foldSessionLogEvents` 带 attachments | 12/12 断言绿 |
-| **L3.6** | **旧会话可检索化** | ✅ | 3 纯函数 `slimTranscriptPre` / `prevSessionSidAnchorPre` / `prevSessionL0Pre` + `listPrevSessionTranscripts` 接进 `searchHandoffCorpus` | **10/10 断言绿**；3 处变异**真红** |
-| L4 | 白板进检索 | ✅ | `recallMemoryPre` 的 `pushL0` 加 `handoff/PLAN.md` + 最新账本（词法臂 :5745 / 语义臂 :5953） | grep 命中两处 + `latestLedgerNamePre`（:8143） |
-| L5 | 锚点解耦 | ✅ | PLAN 锚点与账本锚点的 `boardMode==='graph'` 门移除 | `applyAnchorsPre(wsKey,'handoff/PLAN.md',...)` 处无 boardMode 门 |
-| L6 | 账本保护门注释 | ✅ | `checkMutationPre` 两条 `not-applicable` 分支 | `:2455 target-not-protected` / `:2456 ledger-append-only-no-before-side` |
-| L7 | 死导出存活标注 | ✅ | `wb-contract-pre.js` 两处标「对外契约保留」 | `:47` `WB_STATUSES_PRE_V1` / `:69` `describeWbReasonPre` |
-| **G4** | **白板纪律 + 写记忆时维护** | ✅ | GUIDANCE 三层分工 + 三条硬约束；`memory_log_pre` 描述加"顺手维护白板" | **7/7 断言绿**；关键词从全 False → 全 True |
-| G2 | 标本作废标记 | ✅ | `MEMORY.md` 两处 `> ⚠️ 已作废（2026-09-17 · G2 标记）` | 标记存在且指向 4 门结论 |
-
-**新增测试套件**：`smoke-test-l36-prev-session-pre.mjs`(10) + `smoke-test-g4-whiteboard-pre.mjs`(7)
-**全量回归**：`PASS 111 / FAIL 0 / TIMEOUT 0`（171.0s）
-
----
-
-## 二、用什么方式填补了什么空缺
-
-| 空缺（现象） | 根因（代码级） | 填法 | 为什么是这个填法 |
-|---|---|---|---|
-| 旧会话转写**检索不到**（用户"有些文件接不过去"） | `listHandoffLedgers` 的过滤正则只认 `handoff-<ts>`/`PLAN-<ts>`，**结构性排除** `prev-session-*` ⇒ `scope='handoff'` 永远是孤岛 | **新增独立 lister** `listPrevSessionTranscripts` 并接进 `searchHandoffCorpus` | **不放宽既有正则**——放宽会把旧会话混进账本/归档的血缘语义 |
-| 转写正文被工具噪声淹没（1854 工具事件 vs 530 assistant 消息） | 旧实现全量转写 | `slimTranscriptPre`：工具事件**转计数**，单条 2000 / 总长 60000 双上限 | 保留可追溯性（计数自述）同时让正文可见 |
-| 转写体每次重建 id 都变，破坏"index.json 完全可重建" | 无 | `prevSessionSidAnchorPre`：由 **sid 推导**（`sha256('prev-session\0'+sid)`）而非时间戳 | 同一会话恒等 ⇒ 可重建 |
-| 模型**不知道有白板这回事**，从不维护 | GUIDANCE 对 白板/PLAN/kind=plan/handoff **零覆盖**（实测七个关键词全 False） | GUIDANCE 加三层分工 + 三条硬约束；`memory_log_pre` 描述加"顺手维护白板" | 挂在**既有**每轮注入机制上，零新增通道 |
-| 白板与账本都写"下一步" ⇒ 漂移 | 无权威划分 | GUIDANCE 明确：账本=**动态状态的唯一权威** | 一处权威，另一处不再重复 |
-
----
-
-## 三、之后还待做什么
-
-### M 层（下一步，按 BATTLE-PLAN）
-- **M1** 契约行渲染
-- **M2** lint ①②④（只读纯函数）
-- ~~**M3** GUIDANCE 白板纪律~~ → **已被 G4 吸收，跳过**
-
-### S 层（M 冻结后开）
-- **S1** 容器结构
-- **S2** 视觉对齐 DeepSeek Flow
-- **侧边栏进度表**（用户长期要求，本表即其内容蓝本）
-
-### G 系列剩余
-- **G3/G5/G6**：`supersedes`/`status` 约定 + 读侧过滤；矛盾检测 lint（复用 M2，判据③④待用户裁定）；结论层 replace+archive 语义
-- 三层方案 A/B/C：**A**（条目带 `supersedes`/`status`，低成本）/ **B**（矛盾 lint）/ **C**（结论层 replace+archive，长期）
-
-### 待用户动作
-1. **自行重启宿主** —— `lib/index.js` 已改（L 层 + G4），不重启不生效。（agent 绝不碰 3080）
-2. ~~`noteCapacityChars` 建议 12000 → 24000~~ → **已完成（M9）**：出厂默认已改 24000，老配置（仍是 12000 的）会在重启后自动抬到 24000 并落盘，无需手动改设置。
-
-### 已知未做（有意，不在批准范围）
-- `boardMode` 原始字符串闸门尚有 13 处未改用 `isGraphModePre`（**L5 批准范围只含 2 处锚点写入**）

package/docs/internal/PROMPT-GAP-AUDIT-20260920.md

@@ -1,128 +0,0 @@
-# PROMPT-GAP-AUDIT — 代码能力 vs 模型 prompt 全量对账
-
-> 生成：2026-09-20 · 触发：用户「有什么是我代码应该让模型知道的内容，模型现在还不知道，就是注入里面还没讲」
-> 方法：全量扫描 `lib/*.js` 的 `export const` 枚举/契约常量 + 17 个 `defineTool` 的 description + `renderMemoryStatic` / `renderDynamic` 注入文本，逐条比对"代码有语义域 / prompt 有解释"。
-> 铁律：本表**只做对账，不判断该不该补**——补哪条由用户拍板。
-
-## 0. 一句话结论
-
-**共 17 条缺口，分四类。** 其中 6 条是**模型根本判断不了**（零入口），11 条是**有入口但语义域没讲全**。
-
----
-
-## A 类 · 模型零入口（判断不了，必须补代码才能补 prompt）
-
-| # | 能力 | 代码位置 | 现状 | 影响 |
-|---|---|---|---|---|
-| **A1** | **`retracted`（撤回）写入** | `note-status-pre.js:52` 支持三态 / `:69` 可渲染 retracted · `index.js:5866` 仅映射 `superseded` | **无通道**：`memory_note_pre` 只有 `supersedes` 参数，硬编码映射到 `superseded` | 用户 2026-09-18 裁定「retracted 不是垃圾，是教训」——**教训通路不可写** |
-| **A2** | **fact 过期机制** | `fact-store-pre.js:159 isExpired` · `:326 resolveConflict` · `:283 revokeBySource` · `:263 supersede` | 9 个能力齐全，**零 `defineTool`**（实测 `memory_fact*` = 0） | 用户问的「记忆是否过期」——模型既读不到也写不了 |
-| **A3** | **episodic（情节）写入** | `episodic-store-pre.js` · `EPISODE_OUTCOMES_PRE_V1 = ['unknown','success','failure','partial']` | 仅宿主自动（`index.js:7411` `hub.stores.episodic.append`） | 模型无法标记"这次是失败/部分成功" |
-| **A4** | **fact 语义域（5 个枚举）** | 见 §C-1 | 全部无 prompt | 模型不知道 fact 还有 epistemic_status / scope / trend 这些维度 |
-| **A5** | **看板 tag 命名约定** | `wb-sidecar-pre.js:594-597` `matchTags: ['type:goal' / 'type:state' / 'type:dead-end' / 'type:progress']` | prompt 未提任何 tag 名 | 模型写白板时**不知道要打 tag 才能进看板泳道**——只能靠 `matchTitle` 正则兜 |
-| **A6** | **看板泳道 = 5 条非 4 条** | `WB_KANBAN_LANES_PRE_V1`（`:593`）：goal / state / deadend / progress / **archive** | 注入里只说"四段式" | 用户说"看板方向 4 个"——实测**第 5 条「版本归档」靠 `matchKinds:['archive']`**，模型无从知晓 |
-
----
-
-## B 类 · 有入口但 prompt 没讲清
-
-| # | 缺什么 | 代码位置 | 现状 |
-|---|---|---|---|
-| **B1** | **白板/账本两套四段措辞不一致** | `index.js:5726`（催办块）用「当前目标/已完成/进行中/下一步第一步」· `:570`/`:3658` 用「任务状态/目标/已试方案与失败原因/进度与下一步」 | 同名四段、两套词，模型可能当同一件事 |
-| **B2** | **`boardMode=graph` 前提** | `index.js:10198` 条件注册 `memory_expand_pre` / `memory_trace_pre` | legacy 模式下工具**不存在**，prompt 无任何解释 |
-| **B3** | **procedure 晋升门限** | T4：`successCriteria` 缺失 ⇒ 结构上永不晋升 | 工具描述只提了 "high 需人工批准"，未说这条硬事实 |
-| **B4** | **R1 四条可读性判据** | `R1-READABILITY-FORENSICS-20260919.md`（开头空行=0 / 空行占比<15% / 同日重复 `## `=0 / 缺主语<5%） | 仅在文档，**未进任何 prompt** |
-| **B5** | **`memory_log_pre` 的 `date` 参数** | `index.js:9857` | 描述未说"可补写过去日期" |
-| **B6** | **`memory_note_pre` 的容量与整理行为** | `:9880` 提到 24000，但未说整理触发条件与归档位置 | 模型不知道写满后会发生什么 |
-| **B7** | **`memory_recall_pre` 的 `expand`/`format` 组合** | `:9976-9982` | 参数各自有描述，但**组合语义**（expand 时忽略 query）只在参数描述里夹带 |
-| **B8** | **`memory_maintain_pre` 的 days 语义** | `:10007` | 未说"阈值天数"与日志可见性关系 |
-| **B9** | **`memory_status_pre` / `memory_reflect_pre` 的适用时机** | `:10011` / `:10023` | 只写了功能，没写"什么时候该用" |
-| **B10** | **`memory_external_pre` 的 import 链接模式** | `:10028` | 未说"只记路径指针、不写内容"的防脏纪律 |
-| **B11** | **`memory_consolidate_pre` 与自动沉淀的关系** | `:10085` | prompt 里"自动沉淀"与"手动 consolidate"边界模糊 |
-
----
-
-## C 类 · 枚举值模型看不到（内部语义域）
-
-### C-1 fact 域（5 个）
-
-```
-FACT_EPISTEMIC_STATUSES_PRE_V1 = ['fact', 'observation', 'directive']
-FACT_SCOPES_PRE_V1             = ['User', 'Workspace']
-FACT_SOURCE_KINDS_PRE_V1       = ['explicit', 'inference']
-FACT_SOURCE_CLASSES_PRE_V1     = ['user-memory','workspace-notes','workspace-log','semantic-candidate','profile-candidate']
-FACT_TRENDS_PRE_V1             = ['new', 'strengthening', 'stable', 'weakening', 'stale']
-FACT_TTL_DEFAULT_PRE_V1        = 0   // 0 = 永不过期
-```
-
-### C-2 证据域（2 个）
-
-```
-ACCESS_KINDS_PRE_V1 = ['seen', 'read', 'cite', 'reuse', 'success', 'correction']
-ACK_REASONS_PRE_V1  = ['ok', 'disabled', 'busy', 'unsupported', 'oversize', 'stale']
-```
-
-### C-3 投递/激活域（2 个）
-
-```
-ACTIVATION_LEVELS_PRE_V1 = ['index', 'hint', 'excerpt', 'checklist', 'resource', 'full']
-DELIVERY_STATES_PRE_V1   = ['pending', 'claimed', 'delivered', 'expired', 'dropped']
-```
-
-### C-4 L0 层域（1 个）
-
-```
-L0_LAYERS = ['user', 'project', 'log', 'reflection', 'whiteboard']
-L0_LAYER_LABELS_PRE_V1 = { project:'结论层·项目笔记', user:'结论层·用户级记忆', whiteboard:'结论层·白板/账本', … }
-L0_RETRACTED_MARK_PRE_V1 = '⚠已撤回'
-```
-
-### C-5 降级域（1 个）
-
-```
-DEGRADE_KINDS_PRE_V1 = ['semantic-arm', 'evidence-arm', 'l0-sync']
-```
-
-### C-6 白板状态（1 个）
-
-```
-WB_STATUSES_PRE_V1 = ['current', 'superseded', 'retracted']   // 与笔记三态同名同值，但作用于白板条目
-```
-
----
-
-## D 类 · 三态/四段的家族对照（澄清用，非缺口）
-
-| 族 | 常量 | 取值 | 作用于 |
-|---|---|---|---|
-| 笔记条目生命周期 | `NOTE_STATUSES_PRE_V1` | current/superseded/retracted | `MEMORY.md` |
-| 白板条目生命周期 | `WB_STATUSES_PRE_V1` | current/superseded/retracted | 白板/账本条目 |
-| L0 检索标记 | `L0_STATUSES` | current/superseded/retracted | 检索输出标记 |
-| **账本四段**（截断权重） | `HANDOFF_LEDGER_SECTION_WEIGHTS_PRE_V1` | 任务状态.15 / 目标.20 / 已试方案与失败原因.35 / 进度与下一步.30 | 账本内部**截断排序** |
-| **看板五泳道**（渲染分组） | `WB_KANBAN_LANES_PRE_V1` | 目标 / 进行中 / 失败与弯路 / 进度与下一步 / **版本归档** | 面板**看板分列** |
-
-> **关键澄清（用户已指出）**：账本四段 ≠ 看板泳道 ≠ 记忆三态，**三者互不相交**。
-> 账本四段管"截断时先丢谁"；看板泳道管"面板上分几列"；三态管"条目是否作废"。
-
----
-
-## E 类 · 判定为「不需要进 prompt」
-
-| 项 | 理由 |
-|---|---|
-| `EPISODE_RETENTION_PRE_V1 / SEGMENT_CAP / MIN_SEGMENTS` | 宿主容量参数，模型无需知道 |
-| `UPSERT_OUTCOMES_PRE_V1` | fact store 内部返回值 |
-| `DEGRADE_CAP / QUOTA_THRESHOLDS / ARM_STATES` | 宿主降级配额 |
-| `EVIDENCE_PREFIX / OBSERVATION_PREFIX / ACTIVATION_ID_PREFIX` | id 前缀，内部格式 |
-| `BOARD_MODES_PRE_V1 = ['legacy','graph']` | 已由 B2 覆盖（说明"图模式才有那两个工具"即可） |
-| `INDEX_SYNC_PAGE_BUDGET` / `CONTEXT_BRIDGE_BUDGET` | 内部预算 |
-| 46 条路由 / `DEFAULT_CONFIG` 97 键 | 用户面配置，非模型面 |
-
----
-
-## F. 拍板建议（三条最小改动，已在前轮提出）
-
-1. **A1**：`memory_note_pre` 增 `retract: string[]`，与 `supersedes` 对称走 `applyNoteStatusPre`
-2. **B1**：统一白板/账本四段措辞，或在 prompt 显式声明二者区别
-3. **B2**：铭文补 boardMode 说明
-
-**若扩大范围**，A5（tag 命名约定）与 A6（第 5 条泳道）应一并补——否则模型写的白板**永远进不了看板的 tag 匹配**，只能靠 `matchTitle` 正则兜底。

package/docs/internal/R1-DEGRADE-AUDIT-20260918.md

@@ -1,163 +0,0 @@
-# R1 · 静默降级高危点普查报告
-
-> 2026-09-18 定稿 · 只读普查（未改任何代码）
-> 探针：`artifacts/_probe-silent-degrade.mjs`（全仓扫描）、`artifacts/_probe-r1-degrade.mjs`（逐点验证）
-> 上游：`BATTLE-PLAN-20260917.md` §3.6（R 系列执行顺序）
-
----
-
-## 0. 一句话结论
-
-**10 处高危中：1 处确诊真缺陷（evidence 读写不对称）、1 处假警报已撤销（miv）、其余 8 处为设计内容错。**
-
-**同时撤销 BATTLE-PLAN §3.5 的 M2.5c**（miv 疑点）——它是假警报，不得作为 M2.5a 的前置阻塞。
-
----
-
-## 1. ★ 确诊：evidence 读写**不对称**（真缺陷）
-
-### 证据链
-
-**写入侧**（`evidence-store-pre.js:109-130`）：
-
-```js
-async append(evidence, opts = {}) {
-  ...
-  mkdirSync(this.eventsDir, { recursive: true })   // :126 —— 懒建目录
-  appendFileSync(path.join(this.eventsDir, fname), line + '\n', 'utf8')
-}
-```
-- 目录**只在首次 append 成功时才创建**
-- 且 append 的调用**有条件**（`context-host-pre.js:164` 的 store 惰性创建 + 上游 feature gate）
-
-**读取侧**（`index.js:5889-5897`）：
-
-```js
-const agg = aggregateEvidenceEventsPre(scanEvidenceEventsPre({
-  listFiles: () => readdirSync(evDir).filter((x) => x.endsWith('.jsonl')),   // ← 无条件 readdirSync
-  ...
-}, {}))
-} catch (eImp) { try { diag('evidence-agg 降级为中性(impMap 空): ' + ...) } catch (_) {} }
-```
-- **无条件扫描**，目录不存在即抛 ENOENT ⇒ 静默降级
-
-### 本机实测（对照）
-
-```
-~/.dsh/memory/evidence-pre/events/
-  2026-09-17.jsonl  5953 行  mtime=09-17 23:58
-  2026-09-18.jsonl  1385 行  mtime=09-18 19:12   ← 仍在写
-  共 21 个文件
-```
-⇒ **本机写入侧健康**（开发机长期有会话活动）。
-
-### 用户侧（`C:\Users\Administrator\`）
-
-报 **功能异常**，日志：
-```
-[dsh-auto-memory] evidence-agg 降级为中性(impMap 空):
-ENOENT: no such file or directory, scandir 'C:\Users\Administrator\.dsh\memory\evidence\events'
-```
-- 路径**不是拼错**：`release.mjs:93` 有 `['memory/evidence-pre','memory/evidence']`（发布版重命名）
-- ⇒ 该用户**从未成功 append 过**（目录不存在）⇒ 每次 recall 必走 ENOENT
-
-### 缺陷本质
-
-| 侧 | 行为 | 后果 |
-|---|---|---|
-| 写 | **懒建 + 有条件** | 新装/未触发该 feature 的用户永远无目录 |
-| 读 | **无条件扫描** | 每次都 ENOENT ⇒ importance 恒中性（0.75） |
-
-**⇒ importance 加权这类用户**出厂即死**，且没有任何提示。**
-与 M8/M9 同族：**功能存在、代码在跑、输入永远为空**。
-
-### 修法（R3 范围，候选）
-
-| 方案 | 内容 |
-|---|---|
-| **E-1** | 读取侧先 `existsSync(evDir)`，不存在**静默返回空**（不报错）—— 消除噪音，但不解决"功能是死的" |
-| **E-2** | **写入侧改为确定性建目录**（注册期即建），读取侧条件不变 —— 让两侧对称 |
-| **E-3** | 两者都做 + 走 R3 留痕：**让"importance 恒中性"这件事可见**（面板/状态文件） |
-
-**倾向 E-1 + E-3**：E-1 消除每次 recall 的异常开销；E-3 让用户能看见"这条臂没在工作"。
-**E-2 需先查清 feature gate**（为何该用户没触发写入）——**尚未查证，不得当结论**。
-
----
-
-## 2. ✖ 撤销：miv 两公式疑点（假警报）
-
-### 原疑点
-```js
-index.js:5871            sha256([id, l0] 元组)
-context-host-pre.js:537  sha256(recs.map(r => r.memoryId).join(','))
-```
-原判断：两者应一致，否则 worker 三重过滤拒绝 → 静默回退纯词法。
-
-### 追查结果：**两条公式服务两个不同消费者，各自自洽**
-
-**① `index.js:5865` 注释的对照对象是 `index-sync`，不是 `context-host-pre:537`**：
-```
-// pyCorpus:与 context-host index-sync 同源的 corpus 快照(workspaceKey/scope/miv 须与已同步索引一致,...
-```
-
-**② `index-sync-pre.js:62` 只是【接收】miv，不自己计算**：
-```js
-const miv = String((input && input.memoryIndexVersion) || (snap ? snap.memoryIndexVersion : '') || '')
-if (!miv.startsWith('idx_pre_')) return { ok: false, reason: 'memoryIndexVersion' }
-```
-⇒ 它校验的是**前缀**，公式由调用方给定 ⇒ **不存在"两侧公式不一致"这一说**。
-
-**③ `context-host-pre.js:537` 是另一个域（技能/procedures）**：
-```
-:526  // 2026-08-28 P1⑥:优先 C2 稠密匹配(技能标题+步骤进嵌入索引,miv=技能集指纹,
-:527  // 集合不变则缓存命中);不可用回退词法 2-gram。
-:538  const rank = await engine._jsSemanticRank({ memoryIndexVersion: miv, records: recs }, ...)
-```
-⇒ 消费者是**直接调用**，miv 由本处生成、本处使用，**自洽**。
-
-### 结论
-**M2.5c 撤销。** 该疑点不成立；M2.5a 无此前置阻塞。
-（教训：注释里的「context-host」指**模块族**而非某一个文件；我最初把 `context-host-pre.js:537` 当成了注释所指的对照点——**推断当结论，已更正**。）
-
----
-
-## 3. 其余 8 处：判定为**设计内容错**
-
-| 位置 | 降级内容 | 判定 | 理由 |
-|---|---|---|---|
-| `index.js:5877` | 语义臂择优降级 | 🟡 **设计内，但需可见** | py→JS→词法三级择优是刻意设计（P13）；异常回退词法属预期 |
-| `index.js:5908` | temporal-parse 无时间臂 | 🟡 设计内 | 查询无时间表达时**本就该关**（`tr=null` 是正常路径，非异常） |
-| `index.js:8795` | l0-index sync 降级 | 🟡 设计内 | 同步失败不阻塞主流程 |
-| `index.js:3873` | buildPrevSessionPack → null | 🟡 设计内 | 接续材料失败不该阻断会话 |
-| `index.js:1941` | config migrate failed | 🟢 正常容错 | 迁移失败已有 `console.error` |
-| `index.js:9154` | agent lifecycle | 🟢 正常容错 | 生命周期钩子 |
-| `client.js:2825` | session rename 失败 | 🟢 正常容错 | UI 层 |
-
-**关键区分**：
-- **"正常路径"的降级**（如 `:5908` 无时间表达）**不是缺陷** —— 不该报错；
-- **"异常路径"的降级**（如 `:5897` ENOENT、`:5877` 引擎失败）**才是** —— 用户应当能知道。
-
-⇒ **R3 留痕层的判据应是**：区分「**预期内分支**」与「**预期外失败**」。
-只对后者留痕，否则会淹没在正常路径中。
-
----
-
-## 4. 对执行顺序的影响
-
-| 序 | 项 | 变化 |
-|---|---|---|
-| **R1** | 本报告 | ✅ **完成** |
-| **M2.5a** | L0 质量门 | ⚠️ **前置 M2.5c 已撤销 ⇒ 立即可开工，无阻塞** |
-| **M2.5c** | ~~miv 验证~~ | ❌ **撤销（假警报）** |
-| **R2** | 静默降级深查 | ✅ **本报告已覆盖 10 处高危；R2 可缩为"验证 E-2 的 feature gate"** |
-| **R3** | 降级留痕层 | 设计要点已明确（见 §3 判据） |
-
----
-
-## 5. 待办（未下结论的观察点）
-
-1. **为何该用户从未成功 append？**（feature gate / 配置 / 权限三者未分）
-   ⇒ 需 user 侧配置或再问用户；**本机无法复现**（本机写入健康）。
-2. **`evidence` 与 `evidence-pre` 两套目录在发布版是否都存活？**
-   ⇒ `release.mjs:169` 有 `['evidence-store-pre.js','evidence-store.js']`，
-   `lib/` 下**两者并存**（探针输出可见）—— 需确认哪一套是发布版实际加载的。