@a9i5k4/dsh-auto-memory 2.2.6 → 2.3.0

package/docs/prompts/P6-ledger-weight.md

@@ -0,0 +1,27 @@
+> **投喂方式**：本段须与 `_COMMON.md` 一并投喂。
+
+## 【P6】账本权重化截断
+
+**目标**：`ledger.slice(0, 8000)` 是位置截断。实测账本**段内异质**——「已试方案与失败原因」段里三条全是**成功解法**；「进度与下一步」混了已完成项、真待办、元指令。按位置截可能把高价值段整体截掉。
+
+**涉及功能模块**：`lib/index.js`（解析 + 权重分配），解析部分建议抽成 `lib/handoff-anchor-pre.js` 纯函数。
+
+**验收标准**：
+1. 正确解析四段：`## 任务状态` / `## 目标` / `## 已试方案与失败原因` / `## 进度与下一步`
+2. 权重：失败原因 .35 ＞ 下一步 .30 ＞ 目标 .20 ＞ 任务状态 .15
+3. 预算不足时**从最低权重段开始截**
+4. 纯函数 + fixture 锁定解析与排序
+
+**需先检索的仓库路径与符号关键词**：
+- 路径：`lib/index.js`、`docs/M-CM7-HANDOFF-LAYERED-RETRIEVAL.md`
+- 关键词：`readLatestHandoff`、`## 任务状态`、`## 已试方案与失败原因`、`handoffLedgerChars`、`handoffPlanChars`、`writeHandoffLedger`
+- 必须先确认：① 四段标题的**确切字符串**（含空格/全半角）② 是否存在 `handoffLedgerChars` 等配置项（若有则复用，勿硬编码）
+
+**改动边界**：
+- ✅ 允许新增：`lib/handoff-anchor-pre.js`、`tests/smoke/smoke-test-handoff-anchor-pre.mjs`
+- ✅ 允许：`buildContinueCarry()` 中调用新解析函数替换 `slice(0,8000)`
+- ❌ 禁止：删除任何原文（只影响注入，不动文件）；把"成功解法"误标为"失败原因"
+
+**回滚**：`git checkout lib/index.js` + 删除新增文件。
+
+---

package/docs/prompts/P7-write-fix.md

@@ -0,0 +1,26 @@
+> **投喂方式**：本段须与 `_COMMON.md` 一并投喂。
+
+## 【P7】写入侧缺陷修复
+
+**目标**：两个独立小缺陷 ① 账本标题重复（最近 6 个中 3 个含两个 `# 交接账本` 标题行、时间戳不一致，解析会取到错的）② `PLAN.md` 退化成日志（并列堆积 2.2.5/2.2.6 状态与历史踩坑，无老化）。
+
+**涉及功能模块**：`memory_note_pre` 的 `kind=handoff` 分支；白板归档（复用既有 PLAN archive 机制）。
+
+**验收标准**：
+1. 追加写入前检测已存在标题则跳过（或解析取最后一个标题，二选一并断言）
+2. 白板区分「当前状态」与「历史」，历史移入 `handoff/archive/`
+3. 不丢失任何既有内容
+4. 五套基线不下降
+
+**需先检索的仓库路径与符号关键词**：
+- 路径：`lib/index.js`、`lib/memory-writer-pre.js`
+- 关键词：`writeHandoffLedger`、`writePlanSnapshot`、`kind`、`handoff`、`plan`、`archive`、`PLAN-`、`MemoryDocumentWriter`、`sanitizeForWrite`
+- 必须先确认：① 账本写入函数的真实名字与行号 ② 标题是在写入函数里拼的还是 LLM 生成的 ③ 既有 PLAN 归档函数
+
+**改动边界**：
+- ✅ 允许：`lib/index.js` 中账本/白板写入函数（最小 diff）
+- ❌ 禁止：删除用户已有账本/白板内容；改动注入预算；绕过 `sanitizeForWrite`（I3）
+
+**回滚**：`git checkout lib/index.js`；文件层面改动需说明是否可回滚（建议先备份 `~/.dsh/memory`）。
+
+---

package/docs/prompts/P8-rrf-wiring.md

@@ -0,0 +1,47 @@
+> **投喂方式**：本段须与 `_COMMON.md` 一并投喂。
+> 依赖：**P3（已完成，c917bbe）**。`rankFusionRRFPre` 已交付但零引用，本段负责接线。
+> 定位：**缺陷修复**（修复 P2 语义臂实效性），非新增能力 → 默认开启，保留 `legacy` 回退开关。
+
+## 【P8】RRF 接线进 recall（替换字典序排序）
+
+**背景（实读代码，2026-09-09 核实）**：
+- `lib/index.js:3301` `async recall(query, limit = 8, agent, scope = 'all', opts = null)`。
+- 现状 L0 分支排序为 **`.sort((a, b) => b.lex - a.lex || (b.sem || 0) - (a.sem || 0) || (a.id < b.id ? -1 : a.id > b.id ? 1 : 0))`** —— **字典序排序**：词法分主导，**语义分仅在词法分完全相等时才打破平局**。
+- 后果：P2 接入的 C2 语义臂（`_jsSemanticRank`）在排序中几乎不起作用，`recall()` 实质仍是纯词法。
+- P3 已交付 `lib/recall-fusion-pre.js`：`rankFusionRRFPre(pairs, opts)`、`FUSION_RRF_K_PRE_V1 = 60`、`FUSION_RRF_DIVISOR_PRE_V1 = 60`、`RECALL_FUSION_VERSION = 'rrf_fusion_pre_v1'` —— **经 grep 确认零引用**。
+
+**目标**：把 `rankFusionRRFPre` 接入 `recall()` 的 L0 命中排序，替换字典序排序，使词法臂与语义臂真正融合。
+
+**涉及功能模块**：`lib/index.js` 的 `recall()`（`3301` 起）L0 分支；消费 `lib/recall-fusion-pre.js`。
+
+**验收标准**：
+1. L0 命中的排序由 `rankFusionRRFPre` 产生，**词法与语义均为真实输入**（构造 lex 相同、sem 不同的用例，排序必须随 sem 变化——**这是本段的核心断言**）
+2. RRF 参数：`k = 60`（复用 `FUSION_RRF_K_PRE_V1`），**禁止 score-space 加权**
+3. **排序确定性**：相同输入两次结果全等（id 序列逐项相等）
+4. 提供 `legacy` 回退开关（配置或参数），可一键回到字典序排序；**默认值为 `rrf`**（缺陷修复）
+5. 语义臂不可用 → fail-soft 退回纯词法，不报错、不阻塞
+6. 既有基线不降：**p4 34**、l0-extract 18 / handoff 51 / continue-chain 58 / water-step 12 / autocont-host 29；新增断言覆盖第 1、3 条
+7. 回报中必须给出 **legacy vs rrf 的排序差异实测**（至少 3 条主题性查询，列出 top-5 id 序列 diff）
+
+**需先检索的仓库路径与符号关键词**：
+- 路径：`lib/index.js`、`lib/recall-fusion-pre.js`、`lib/semantic-js-pre.js`、`lib/shadow-retrieval-pre.js`
+- 关键词：`async recall(`、`l0Mode`、`_jsSemanticRank`、`rankFusionRRFPre`、`FUSION_RRF_K_PRE_V1`、`FUSION_RRF_DIVISOR_PRE_V1`、`b.lex - a.lex`、`l0Hits`、`l0Corpus`
+- **必须先确认**：① `recall()` 中 L0 分支的准确行号范围与 `l0Hits` 的构造过程 ② `lex` / `sem` 两个分数的量纲（是否可比；若不可比，RRF 的 rank 输入正是为此设计）③ `rankFusionRRFPre(pairs, opts)` 的 `pairs` 确切形状（**以源码为准，不得臆造**）④ `_jsSemanticRank` 的返回结构
+
+**改动边界**：
+- ✅ 允许修改：`lib/index.js` 中 `recall()` 的 **L0 命中排序部分**（最小 diff）
+- ✅ 允许新增：`tests/smoke/` 断言
+- ❌ **禁止修改**：`lib/recall-fusion-pre.js`（P3 已锁定）、`lib/l0-extract-pre.js`、`lib/semantic-js-pre.js`、`lib/shadow-retrieval-pre.js`
+- ❌ 禁止：改变 `recall()` 签名；改动 L0 抽取逻辑；改动注入（I1）；score-space 加权 RRF（Hindsight issue #3956：k=60 动态范围仅 5.9 倍，加权致 recall@20 从 0.97 崩到 0.40）
+- ❌ 禁止：整文件重写 `index.js`
+
+**集成位置正确性（回报必写）**：
+- 说明改在 `recall()` 内部何处、为何不影响非 L0 分支（旧行为）
+- 列出 `recall()` 的全部调用点行号
+- 开关落在哪个配置项（键名 + 默认值 + 行号）
+
+**回滚**：`git checkout lib/index.js`；或把开关切回 `legacy`（说明切换方式）。
+
+**停止条件**：若 `rankFusionRRFPre` 的 `pairs` 形状与 `recall()` 现有数据结构无法对应，**立即停止回报**，禁止自造适配层绕过。
+
+**自检清单**：按 `_COMMON.md` §5 执行（本段重点：`node --check lib/index.js` + p4 smoke ≥34 + 确定性断言）。

package/docs/prompts/P9-REVIEW-DECISION.md

@@ -0,0 +1,95 @@
+# P9 排查报告 · 规划侧评审与裁决（2026-09-09 20:53）
+
+> 依据：实读 `lib/context-host-pre.js`、`lib/context-bridge-pre.js`、`lib/index.js`、`lib/memory-importance-pre.js`，非采信报告。
+
+## 一、报告核实结果
+
+| 结论 | 核实 | 判定 |
+|---|---|---|
+| reuse 无生产者 | grep 全 `lib/`，`'reuse'` 仅出现在枚举/白名单/聚合处，无 create 函数 | ✅ 成立，根因 (a) 正确 |
+| correction 条件过严 | `createCorrectionEvidencesFromText` = 纠正词典 AND `createCiteEvidencesFromText`（文本须含完整 memoryId） | ✅ 成立，根因 (b) 正确 |
+| success 根因 | 见下 | ❌ **误判** |
+
+## 二、success 根因误判（重要修正）
+
+报告称 success 触发链 =「被 read/cite 的 memoryId ∩ 某 procedure 的 sourceMemoryIds，交集稀疏」。
+
+实读 `lib/index.js:4583-4595`：
+
+```js
+for (const e of cited) {
+  for (const p of allProcs) {
+    if (!(p.sourceMemoryIds || []).includes(e.memoryId)) continue
+    procs.addEvidence(p.procedureId, { kind: 'success', sessionRef: sr })  // ← 交集只 gate 这一行
+  }
+  const r = createSuccessEvidencePre({ ... memoryId: e.memoryId ... })      // ← 这行在交集判断之外
+  if (r.ok) successEvs.push(r.evidence)
+}
+```
+
+**`createSuccessEvidencePre` 在内层 procedure 循环之外**——它对 `cited` 里的**每一条**都建 success 事件，**不要求 procedure 交集**。因此：
+
+- 报告的核心根因「sourceMemoryIds 覆盖面极小」**不成立**——交集只影响 procedure 晋升，不影响 success 事件。
+- **真正根因**：① 整块包在 `memoryHubEnabled === true` 门内（`lib/index.js:4576`），该开关 **M8-3 今天才开**，此前这段代码从未执行；② `cited` 来自 `recentEvidenceForSuccess(5×60×1000)` = **近 5 分钟内**的 read/cite 事件（`context-host-pre.js:691`），而 read/cite 全量才 82/286，5 分钟窗口天然稀疏。
+
+**裁决：success 不改代码，降级为「观察」。** M8-3 已开门，先跑一周看真实产出；若一周后仍 ≈0，再单独加「放宽窗口/来源」小段。报告建议的「把匹配面扩到 cite 过的记忆」是**基于误判的方案，无需执行**。
+
+## 三、P9a 方案自身的漏洞（需重设计）
+
+报告方案：「用户段同时存在 cites 时，若命中纠正词典，把已建的 cite 证据就地升级为 correction」。
+
+但 `emitTextEvidence`（`context-host-pre.js:490-501`）里，`cites` 也是从 `seg.text`（**用户自己消息**）算的。既然用户消息几乎不含完整 memoryId，`cites` 在 user 段也≈0 → **「用户段同时存在 cites」这一前提本身就不会成立**，照做仍然零触发。
+
+**正确设计**：correction 的归因对象应是**最近被 cite 的记忆**（来自 assistant 段的 cite 事件），不是用户消息里新找的 id。即：user 段命中纠正词典 → 查 store 里**最近一条 cite/read**（复用 `recentEvidenceForSuccess` 已有的 store 读取思路）→ 对那**一条**记忆发 correction，且**保留 cite 不改写**。
+
+## 四、importance 公式的精确诊断（比报告更准）
+
+报告说「importance 由 seen 绝对主导」。实读 `lib/memory-importance-pre.js`，公式是：
+
+```
+pos = 0.5 × min(1, distinctSessions/3) + 0.5 × min(1, (success+reuse)/4)
+importance = clamp01(0.5 + 0.3 × pos − 0.5 × correctionRate)
+```
+
+**seen/read/cite 根本不直接进分子**——它们只进 `total`（稀释 correctionRate）和 `distinctSessions`（跨会话数）。真正的正向驱动是 **distinctSessions 和 success+reuse** 两项。
+
+当前 success+reuse=0 ⇒ `pos = 0.5 × diversity` ⇒ importance = 0.5 + 0.15 × min(1, sessions/3)，上限 0.65、中性 0.5、correction 拉低至 0.30——**与实测 [0.30, 0.65] 完全吻合**。
+
+**结论**：当前 importance 实质 = **跨会话重现度（distinctSessions）**，这是一个**还不错的信号**（不是纯曝光）；真正死掉的是公式里的「有用性半区」`success+reuse`。这修正了「曝光度」的说法，也重新定位了 P10：P10 不是"降 seen 权重"（seen 本就不直接加权），而是"待 success/reuse/correction 流动后，标定 `IMPORTANCE_WEIGHTS`（升版本）"。
+
+## 五、最终裁决与顺序
+
+| 段 | 裁决 | 说明 |
+|---|---|---|
+| **P9a** correction | ✅ **批准，重设计** | 归因到"最近被 cite 的记忆"（单条），保留 cite 另发 correction；见 `FIX-AGENT-P9a.md` |
+| **P9b** success | ⏸️ **降级为观察** | 不改代码；跑一周，产出观察清单（见下） |
+| **P9c** reuse | ⏳ **延后** | 确认无生产者；与 success 同属公式里的同一饱和项 `(success+reuse)/4`，可合为一个「有用性信号补全」段，等 P9a + success 观察后再定 |
+| **P10** 定标 | ⏸️ **顺序后移** | 需等 success/reuse/correction 有真实数据；届时改 `memory-importance-pre.js`（**解除 M8-2b 锁定，P10 是该模块合法 owner**）+ 标定 w |
+
+### success 观察清单（一周，无需代码，交用户/执行侧）
+
+- [ ] M8 启用后，`success` 事件是否开始产出（`~/.dsh/memory/evidence-pre/events/` 里 `"kind":"success"` 计数）
+- [ ] 若有：日均量级 vs read+cite（预期 1-5%）
+- [ ] 若仍 ≈0：确认是否因 `recentEvidenceForSuccess` 的 5 分钟窗口太窄（此时才需要放宽窗口/来源）
+
+## 七、追加：success 是**结构性断裂**（2026-09-09 23:10，规划侧自我修正）
+
+P9a 执行中发现并经我实证核实：
+
+- **磁盘事件实样**：顶层字段为 `['anchorId','event','evidenceId','kind','memoryId','namespace','policyVersion','recordedAt','schemaVersion','scope','source','storePolicyVersion','workspaceRef']` —— **无 `ts`、无 `createdAt`**，`ts` 在 `event.ts`（值 `1788932690285`）。
+- **缺陷代码**：`lib\context-host-pre.js` 的 `recentEvidenceForSuccess` 内 `const ets = e.ts || e.createdAt || 0` → 恒为 0 → `0 < cutoff` → **全部跳过 → 恒返回空数组**。
+- **唯一调用方**：`lib\index.js:4576` 的 M9 success 块 → `cited` 恒空 → **success 永远为 0**。
+- **对照**：P9a 新增的 `selectCorrectionAttributionPre`（同文件 68/77 行）已用正确口径 `Number(e.event && e.event.ts) || Number(e.ts) || Number(e.createdAt) || 0`——可见正确写法已在库内，只是老函数未同步。
+
+**结论修正（我的责任）**：本文 §二曾判定 success「主因是开关今天才开 + 5 分钟窗口稀疏」，并据此把 P9b 降级为"观察一周"。**该结论不完整**——即使开关打开，由于时间戳取值错误，`cited` 仍恒为空，success **永远**不会产出。观察一周只会得到 0。
+
+**success 零产出的完整三因**：
+1. `memoryHubEnabled` 门控（M8-3 今日已开，已消除）
+2. **`recentEvidenceForSuccess` 时间戳取值错误（结构性，阻断）** ← P9a 附带发现，已实证
+3. 5 分钟窗口 vs consolidation 周期（~30 分钟）不匹配（**稀疏性**，需在 2 修复后实测判断）
+
+**裁决：立即补 P9d 修复段**（1 行 + 断言），见 `FIX-AGENT-P9d.md`。**本段优先级高于一切观察类动作。** 窗口是否放宽，待 P9d 用真实数据给出 5/30 分钟命中量级后再定，**不在 P9d 内改**。
+
+## 六、给执行侧的一句提醒
+
+P9 报告整体质量高（实测复现、三选一框架、理想触发场景清单），**唯一需要纠正的是 success 的根因**——`createSuccessEvidencePre` 早已接好且不依赖 procedure 交集，它没产出的真正原因是"开关今天才开 + 5 分钟窗口稀疏"。后续修复段据此调整，不必做「扩匹配面」。

package/docs/prompts/P9-evidence-write-coverage.md

@@ -0,0 +1,113 @@
+> **给使用者的说明**：M8-2b 验收后的下一个瓶颈。同样**自包含**（硬约束内联 + 绝对路径），复制时从 `你是一名严谨的排查 Agent` 开始复制到文件末尾。
+
+---
+
+你是一名严谨的排查 Agent。工作目录：`D:\dsh-auto-memory`（Node.js 项目，BSD-3-Clause，v2.2.6，零运行时依赖）。
+
+# 任务：evidence 写入侧覆盖率排查（reuse / success 零产出，correction 近乎为零）
+
+## 0. 背景（已有实测数据，你必须先自行复现）
+
+evidence 事件落盘于 `C:\Users\JH Z\.dsh\memory\evidence-pre\events\*.jsonl`（按日）。对全量事件按 `kind` 统计的实测分布：
+
+| kind | 全量 | 近 7 天 |
+|---|---|---|
+| seen | 4930 | 4828 |
+| cite | 286 | 199 |
+| read | 82 | 33 |
+| correction | **2** | 1 |
+| **reuse** | **0** | **0** |
+| **success** | **0** | **0** |
+
+**问题**：`reuse` 与 `success` **从未落盘**，`correction` 全量仅 2 条。而 `lib\context-bridge-pre.js` 的六类枚举为 `['seen','read','cite','reuse','success','correction']`。
+
+**影响**：M8-2b 的 importance 目前实质由 `seen`（曝光次数）驱动 ≈ **曝光度**，不是有用性；负向下压（correction）几乎不存在。这决定了 M8-2「重要性排序」最终能兑现多少价值。
+
+**第一步请用脚本复现上述分布**（任选 python/node，读取 events 目录统计 `kind`），并把你的实测结果贴进回报。
+
+## 1. 必读文件（绝对路径）
+
+- `D:\dsh-auto-memory\lib\context-bridge-pre.js` —— 六类枚举（第 45 行 `ACCESS_KINDS_PRE_V1`）、各 create 函数
+- `D:\dsh-auto-memory\lib\index.js` —— 写入侧调用点（重点搜索 `createSuccessEvidencePre`、`createCorrectionEvidencesFromText`、`createCiteEvidencesFromText`、`createAccessEvidencePre`、`recordEvidence`、`:1301` 附近的 read coverage 观察、`:4539` 附近的 success evidence）
+- `D:\dsh-auto-memory\lib\procedure-store-pre.js` —— success/correction 是否只喂给 procedure 晋升而**未落 events**
+- `D:\dsh-auto-memory\lib\evidence-agg-pre.js` —— 消费侧（**禁止修改**）
+- 真实数据：`C:\Users\JH Z\.dsh\memory\evidence-pre\events\*.jsonl`
+
+## 2. 目标
+
+1. **定位根因**：`reuse` / `success` 零产出、`correction` 近乎为零的**确切原因**，三选一（须有证据）：
+   - (a) **调用点未接线** —— create 函数存在但生产路径从未调用；
+   - (b) **触发条件未满足** —— 有调用但前置条件（如"本轮 substantive 且记忆被 read/cite"）几乎不成立；
+   - (c) **落盘分流** —— 事件被写入别处（如只喂 procedure store）而未进 events 目录。
+2. **给出影响判断**：当前 importance 实际由哪些信号驱动，与设计的六类模型差多少。
+3. **视根因决定是否修复**：若是 (a) 明显未接线 → 提出最小修复方案；若是 (b)/(c) → **只报告，不改代码**，等待用户决策。
+
+## 3. 硬约束（违反即打回）
+
+1. **搜索优先**：每个符号先 grep 到定义处并记下真实行号；统计必须基于**真实文件**，不得沿用本 prompt 的数字而不复现。
+2. **默认不动代码**：本段定位为**排查**，除用户明确同意外**不得修改任何 `lib/` 文件**（修复方案写进回报）。
+3. 若确需改：最小 diff、零新依赖、不改既有 API 签名、不删既有断言。
+4. **不得修改 events 目录**（只读）。
+5. 不得修改 `lib\evidence-agg-pre.js`、`lib\memory-importance-pre.js`、`lib\recall-fusion-pre.js`（均已锁定）。
+
+## 4. 改动边界
+
+- ✅ 允许：新增临时统计脚本（**用完即删，不得留在仓库**）
+- ✅ 允许：在用户确认后做最小修复
+- ❌ 禁止修改：`lib\evidence-agg-pre.js`、`lib\memory-importance-pre.js`、`lib\recall-fusion-pre.js`、`lib\context-bridge-pre.js`、`lib\procedure-store-pre.js`、`lib\fact-store-pre.js`
+- ❌ 禁止：events 目录任何写操作
+
+## 5. 验收标准
+
+1. 回报含**你实测的 kind 分布**（全量 + 近 7 天），与背景表对照
+2. 对 `reuse`、`success`、`correction` 三者**分别**给出根因结论，各自标注 (a)/(b)/(c) 并附 `文件:行号` 证据
+3. 列出所有 **写入 events 的调用点行号**（完整清单）
+4. 给出"当前 importance 实际由哪些信号驱动"的判断
+5. **附加「每类事件的理想触发场景清单」**（执行侧建议，2026-09-09 采纳）：对六类 evidence 逐个给出——
+   - 应该在什么用户行为/系统事件下产生（例：`read` = 模型实际读取了该记忆原文；`cite` = 回复中引用了该记忆；`reuse` = 跨会话再次命中同一记忆；`success` = 该记忆参与后任务被判定成功；`correction` = 用户纠正了由该记忆产生的内容）
+   - **当前实际是否触发**（有数据 / 零产出）
+   - 修复后**预期分布**（粗略量级即可，如"success 应达 seen 的 1%~5%"）
+   此清单用于判断修复后的实际分布是否健康，是本段的核心交付物之一。
+6. 若提出修复方案：说明改哪个文件哪一行、预期新增哪些 kind 的事件、如何验证、回滚方式
+
+## 6. 停止条件
+
+- 找不到任何写入 events 的代码路径（说明落盘机制与理解不同）；
+- `ACCESS_KINDS_PRE_V1` 与实际落盘 kind 不一致且无法解释。
+
+回报格式：
+```
+停止原因：未能定位 <符号/路径>
+已尝试：<搜索词 1>、<搜索词 2>、<路径>
+需要：<澄清问题>
+```
+
+## 7. 完成后自检
+
+```bash
+cd /d/D/dsh-auto-memory || cd D:/dsh-auto-memory
+
+# 若做了修复才需要；仅排查则跳过编译检查
+node --check lib/index.js
+
+node tests/smoke/smoke-test-evidence-agg-pre.mjs        # 14
+node tests/smoke/smoke-test-memory-importance-pre.mjs   # 18
+node tests/smoke/smoke-test-p4-l0-response-pre.mjs      # 34
+node tests/smoke/smoke-test-p8-rrf-wiring-pre.mjs       # 14
+
+git status --short   # 仅排查时不得有任何 lib/ 改动
+git diff --stat
+```
+
+## 8. 回报必须包含
+
+1. 实测 kind 分布（全量 + 近 7 天）
+2. 三者的根因结论 + `文件:行号` 证据
+3. events 写入点完整清单
+4. importance 实际驱动信号判断
+5. 修复方案（若适用）+ 回滚方式
+6. 自检原始输出
+
+---
+
+> **投喂提示**：本段自包含，无需再附 `_COMMON.md`。背景依据见 `D:\dsh-auto-memory\docs\prompts\M8-2-ADJUDICATION.md` §6.3。

package/docs/prompts/README.md

@@ -0,0 +1,105 @@
+# prompts/ 投喂说明
+
+> **🎯 本轮收尾投喂顺序看 [`FEEDING-SEQUENCE.md`](FEEDING-SEQUENCE.md)** —— 3 段喂 AI + 1 步你重启验证发版。
+
+> **🚀 按轮次执行？先看 [`FEEDING-SCRIPT.md`](FEEDING-SCRIPT.md)** —— 每一轮投喂哪两个文件、Agent 要读哪些仓库文件、产出与验收，一张表说清。
+> **⚠️ 2026-09-09 收官后补做段：`P8` + `M8-2b`，裁决依据见 [`M8-2-ADJUDICATION.md`](M8-2-ADJUDICATION.md)**（M8-2 排序目标未达成，**不降级，拆两段补做**）。
+
+从 `docs/PROMPT-SET-STRICT.md` 拆分而来（脚本切片，内容未改），每个文件是一个**独立可投喂单元**。
+
+---
+
+## 一、投喂公式（唯一规则）
+
+```
+投喂给 Agent 的内容 = _COMMON.md  +  某一个任务段文件
+```
+
+- `_COMMON.md` **每次都必须带**，它是全局约束（搜索优先、六条禁止、停止回报、自检模板、项目事实速查）。单独投喂任务段 = 约束缺失 = 结果不可信。
+- 任务段文件二选一即可，**不要一次塞多段**（除明确说明可并行的批次，也要分多个 Agent 分别投喂）。
+
+**示例**：
+```
+请先阅读以下内容作为全局约束：
+<粘贴 _COMMON.md 全文>
+
+然后执行任务：
+<粘贴 P1-l0-index.md 全文>
+```
+
+---
+
+## 二、文件清单
+
+| 文件 | 内容 | 依赖 | 改哪些文件 | 风险 |
+|---|---|---|---|---|
+| **`_COMMON.md`** | **通用前置约束（必带）** | — | — | — |
+| `P1-l0-index.md` | L0 向量索引 + 增量更新 | 无（T1 已完成） | 新增 `lib/l0-index-pre.js` + smoke | 低（不接线） |
+| `P2-semantic-recall.md` | 语义臂接入 recall | P1 | `lib/index.js` 的 `recall()` | 中 |
+| `P3-fusion.md` | 融合层 rank-space + 绝对分数 | P2 | `lib/semantic-js-pre.js`（新增并存） | 中高 |
+| `P4-l0-response.md` | recall 返回 L0 + 按需展开 | P3 | `lib/index.js` 的 `recall()` | 中 |
+| `P5-handoff-anchor.md` | 接续锚点表注入 | 无 | `lib/index.js` 的 `buildContinueCarry()` | 中 |
+| `P6-ledger-weight.md` | 账本权重化截断 | P5 | 新增 `lib/handoff-anchor-pre.js` + `index.js` | 中 |
+| `P7-write-fix.md` | 写入侧缺陷修复（标题重复/白板老化） | 无 | `lib/index.js` 写入函数 | 低 |
+| `M8-R-research.md` | M8 调研任务书（只读） | 无 | **禁止改任何文件** | 无 |
+| `M8-R-REPORT.md` | **M8 调研报告（已执行，结论在此）** | — | — | — |
+| `M8-1-fact-metadata.md` | Fact 元数据补强（时间三价+认识论状态+趋势） | 无 | `lib/fact-store-pre.js`（增量） | 中 |
+| `M8-2-importance-wiring.md` | evidence → importance 接入检索排序 | 建议 P3 后 | 新增 `lib/memory-importance-pre.js` | 中 |
+| `M8-3-enable-verify.md` | M8 启用 + live 验证清单 | **需你先确认** | `lib/index.js` 默认值一行 | 高 |
+| `P8-rrf-wiring.md` | **RRF 接线进 recall**（替换字典序排序，激活 P2 语义臂） | P3 已交付 | `lib/index.js` 的 L0 排序分支 | 中 |
+| `M8-2b-evidence-pipeline.md` | evidence 聚合层 + importance 加权接入 | **P8** | 新增 `lib/evidence-agg-pre.js` | 中 |
+| `M8-2-ADJUDICATION.md` | **M8-2 目标裁决**（不降级，拆两段补做；含四条代码证据） | — | — | — |
+| `P9-REVIEW-DECISION.md` | **P9 评审裁决**（success 根因误判纠正 + P9a 重设计 + importance 公式精确诊断） | — | — | — |
+| **`FIX-AGENT-P8.md`** | **⭐ 复制即投喂：P8 RRF 接线（自包含，无需 `_COMMON.md`）** | P3 已交付 | `lib/index.js` L0 排序段 | 中 |
+| `FIX-AGENT-M8-2b.md` | 复制即投喂：evidence 管道 + importance 加权（自包含） | **P8 验收后** | 新增 `lib/evidence-agg-pre.js` | 中 |
+| `P9-evidence-write-coverage.md` | 排查 reuse/success 零产出、correction 近乎为零的根因（**默认只排查不改码**） | M8-2b 后 | 无（排查段） | 低 |
+| **`FIX-AGENT-P9.md`** | **⭐ 复制即投喂：evidence 写入覆盖排查（自包含；报告先交规划侧过目）** | M8-2b 后 | 无（只排查） | 低 |
+| **`FIX-AGENT-P9a.md`** | **⭐ 复制即投喂：correction 修复（重设计，单条归因）** | P9 裁决后 | `lib/context-host-pre.js` | 中 |
+| **`FIX-AGENT-P9d.md`** | **⭐ 复制即投喂：success 时间戳缺陷修复（success 链结构性断裂，优先于观察）** | 无 | `lib/context-host-pre.js` 一行 | 低 |
+| **`FIX-AGENT-P12-FULL-REGRESSION.md`** | **⭐ 一整段投喂：修 P12 + 重启 + 九套静态 + 七项 live + 发版 Go/No-Go 结论** | 无 | `lib/shadow-retrieval-pre.js` + m4 断言 | 中 |
+| **`FIX-AGENT-TEMPORAL-ARM.md`** | **⭐ 时间检索臂（第一优先新功能）：解析时间表达 + 软性第三臂，零行为变更** | **P12 之后** | 新增 `lib/temporal-parse-pre.js` + recall-fusion 兼容扩展 | 中 |
+| **`LIVE-VERIFY-ZCODE.md`** | **⭐ 给 Zcode 的独立 live 验收（可重启+控 UI+读后台日志，第三方视角，九项取证 + Go/No-Go）** | 第 1-3 段后 | **禁止改任何文件** | — |
+| **`ZCODE-DROPIN.md`** | **⭐⭐ 直接整段扔进 Zcode 的那一份（含 `--no-open`、九项取证、Go/No-Go）** | 第 1-3 段后 | **禁止改任何文件** | — |
+| `P10-importance-calibration.md` | importance 效应定标：`0.5+w×imp` 可配置 + 真实查询翻转率实测 | **P9 结论后** | `lib/index.js` dense 臂一行 + 配置项 | 低 |
+| `P11-silent-catch-observability.md` | fail-soft 空 catch 统一加 diag（**只加日志不改行为**，可与 P9 并行） | 无 | `lib/index.js` catch 行 | 低 |
+| **`FIX-AGENT-P11.md`** | **⭐ 复制即投喂：静默 catch 可观测（自包含，可与 P9 并行给另一 Agent）** | 无 | `lib/index.js` catch 行 | 低 |
+| `EXEC-ORDER.md` | 执行顺序与冲突提示 | — | — | — |
+
+---
+
+## 三、执行顺序
+
+```
+批次 1（可并行，互不干扰）
+  ├─ P1-l0-index.md        纯新增文件，不接线 → 删除即回滚
+  ├─ P5-handoff-anchor.md
+  ├─ P7-write-fix.md
+  └─ M8-R-research.md      只读，产出报告后等你确认
+
+批次 2 → P2-semantic-recall.md        （依赖 P1）
+批次 3 → P3-fusion.md                 （依赖 P2）
+批次 4 → P4-l0-response.md            （依赖 P3）
+批次 5 → P6-ledger-weight.md          （依赖 P5）
+批次 6 → M8-1-fact-metadata.md        （可与批次 1 并行）
+批次 7 → M8-2-importance-wiring.md     （建议 P3 之后）
+批次 8 → M8-3-enable-verify.md         （**需你先确认是否改默认**）
+```
+
+---
+
+## 四、三个最容易犯的错
+
+1. **只投喂任务段，忘带 `_COMMON.md`** —— 约束会全部丢失，Agent 可能整文件重写或臆造 API。
+2. **把多个任务段一次性塞给同一个 Agent** —— 尤其 P2/P3/P4 与 P5/P6 都要改 `lib/index.js`，同 Agent 连续改极易互相覆盖。**同批次并行时必须分多个 Agent，且串行验收、逐段 `git diff`**。
+3. **跳过 M8-R 直接要 M8 改造** —— M8-R 是只读调研，产出报告后**必须经你确认架构方向**，才能生成 M8-1…。它的停止条件很硬：查不到"参考 Hermes / 架构极不成熟"的文档出处就必须停下回报，不许猜。
+
+---
+
+## 五、验收（每段 Agent 回报后你必查）
+
+```bash
+cd D:\dsh-auto-memory
+git status --short          # 改动范围是否符合该段的"允许/禁止"清单
+git diff --stat             # 是否最小 diff（新增段应 <100 行，改动段应 <50 行）
+```
+外加该段自检清单里的五套 smoke 数字：**l0-extract 18 / handoff 51 / continue-chain 58 / water-step 12 / autocont-host 29**，任何一个下降即打回。