@a9i5k4/dsh-auto-memory 3.0.1 → 3.1.0

package/docs/internal/HERMES-DATA-VERIFICATION-20260919.md

@@ -1,120 +0,0 @@
-# ③ Hermes 遗留 · **真机数据核查**（2026-09-19 第二轮）
-
-> 触发：上轮结论基于**源码审计**；本轮直读**真机落盘数据**，得到一条源码看不到的结论。
-> 方法：`artifacts/_probe-intent-clean.mjs`（对真实污染串执行）+ 直读 `~/.dsh/memory/hub-pre/procedures.json`。
-
----
-
-## 1. ★ 首先纠正一条被误传的事实
-
-**ZCode 审计「全机 7 个工作区均无 `procedures.json`」= 定位错了目录。**
-
-真机实测：
-
-| 路径 | 大小 | 最后写入 |
-|---|---|---|
-| `~/.dsh/memory/hub/procedures.json` | 126 B | 2026-09-01 10:34 |
-| **`~/.dsh/memory/hub-pre/procedures.json`** | **8295 B** | **2026-09-19 02:25** |
-
-`procedures.json` **在共享 hub 目录**（`~/.dsh/memory/hub-pre/`），**不在各工作区的 `.dsh-memory/` 下** —— 所以在「哪个工作区」里找永远找不到。
-⇒ **「全机无 procedures.json」这条事实不成立**，据此推出的「固化从未发生过」也随之作废。
-
----
-
-## 2. ★★ 真机数据揭示的真问题：**观察行被污染成注入文本**
-
-本机 10 条 procedure 的实测分布：
-
-| # | stage | title（截断） | 判定 |
-|---|---|---|---|
-| 1 | deprecated | `Current runtime context. This snap` | ★污染 |
-| 2 | **active** | `DSH 发射档位确认流程` | ✅ 正常（**唯一真实富候选**） |
-| 3 | deprecated | （乱码）`����������ȷ������(��֤)` | 编码损坏 |
-| 4 | observed | `{"path":"D:\\personal_issue\\.dsh-` | ★污染 |
-| 5 | observed | `Current DSH file policy: danger-fu` | ★污染 |
-| 6 | observed | `Current runtime context. This snap` | ★污染 |
-| 7 | observed | `让我自己去试吧。现在是什么情况？` | 用户原话 |
-| 8 | observed | `开始实施` | 用户原话 |
-| 9 | observed | `开始实施,实施完给我准确的报告保证我能看懂` | 用户原话 |
-| 10 | observed | `Approval prompts are disabled in t` | ★污染 |
-
-**7 条 `observed` 中 4 条 title 是运行时信封**（`Current DSH file policy:` / `Current runtime context.` / `Approval prompts are disabled in this session:` / `{"path":...`）。
-
-### 2.1 清洗器有效性：**部分有效，有漏网**
-
-`stripRuntimeIntentPre`（`intent-clean-safe-pre.js`，部署于 **2026-09-17 00:10**）对这 4 条真实信封的实测：
-
-| 信封 | 清洗器是否剥离 |
-|---|---|
-| `Current DSH file policy: …` | ✅ 剥离（`:17` 有专门规则） |
-| `Current runtime context. …` | ✅ 剥离（`:17` 同一条规则） |
-| **`Approval prompts are disabled in this session: …`** | ❌ **漏网**（无对应规则） |
-| **`{"path":"D:\\…`** | ❌ **漏网**（JSON 形态，无规则） |
-
-⇒ **`stripRuntimeIntentPre` 的全量断言 7/10**，两处真漏。
-
-### 2.2 ⚠️ 关于「污染是否仍在发生」= **证据不足，仅列推断**
-
-**我曾据时间线下此结论，但自查后撤回。** 现有硬证据：
-
-| 事实 | 值 | 性质 |
-|---|---|---|
-| 清洗器文件 mtime | 2026-09-17 00:10 | 硬证据 |
-| 接线点 `memory-hub-pre.js` mtime | 2026-09-17 00:12 | 硬证据 |
-| 漏网条目 #10 创建时间 | 2026-09-17 15:40（本地） | 硬证据 |
-| **当时宿主加载的是哪版代码** | **无法确定** | ❌ **缺口** |
-
-⇒ **关键缺口**：扫描**当前** node 进程，宿主启动于 **2026-09-18 23:52**（晚于清洗器 1.9 天）。
-但 #10 产生于 09-17 15:40，**那时运行的宿主进程早已不存在**，无从判断它是否已加载清洗器。
-**mtime ≠ 加载时间** —— 若那时宿主启动于清洗器部署之前且一直未重启，跑的仍是旧代码。
-
-⇒ 因此「污染仍在发生」**只能作为推断列出**，不能作为结论：
-
-> **推断（未证实）**：清洗器覆盖不全 ⇒ 同类信封仍会穿过。
-> **不依赖时间线的充分证据**：清洗器是**纯函数**，其对 4 种真实信封的失效已**直接实测**（§2.1）——
-> 只要是这种形态的输入，无论何时都会漏。**这比时间线推断更强**，也是本项建议的依据。
-
-**另有一条弱反向证据**：当前宿主（09-18 23:52 起）运行期间，`procedures.json` 于 09-19 02:25 被写过，
-但**未新增**任何 observed 条目（10 条中 `createdAt` 最新的仍是 #10）⇒ 至少**当前进程未再产出污染**。
-（但这也可能只是因为期间没有成功 episode 触发 crossFeed，**不构成清洗器有效的证明**。）
-
-**根因（代码级，确定）**：`memory-hub-pre.js:137` 的清洗只作用于 `ep.intent`：
-
-```js
-const procedureIntent = stripRuntimeIntentPre(ep.intent).trim()
-if (ep.success && … && procedureIntent && procedureIntent !== '(未提取)' && ep.actions && ep.actions.length) {
-  const cand = { title: procedureIntent.slice(0, 40), … }
-```
-
-清洗器是「**逐行 + 行首白名单**」的（`intent-clean-safe-pre.js:17` 只匹配行首
-`Current runtime context.` / `Current DSH file policy:`）。
-`Approval prompts are disabled…` 与 `{"path":…` **不在白名单** ⇒ 原样穿过。
-
-> ⚠️ 这正是该文件头注释自己预警的风险：「**注入形态会演进（新增标签/换行拼法）⇒ 漏判**」。
-
----
-
-## 3. 与 ③ 原结论的关系（**修订，不是推翻**）
-
-| 上轮结论 | 本轮修订 |
-|---|---|
-| issue #30 三处已修 ✅ | **维持**（源码 + 探针 25/25 确认） |
-| ③ 降级为「待观测」 | **维持**，但观测项换成了**有真机证据的真问题** |
-| H-1「上游是否真产富候选」 | **已可回答**：真机有 1 条 `active` 富候选（`DSH 发射档位确认流程`，`evidence.sessions=11`、`read=4`、`cite=14`）⇒ **上游确实产过富候选，只是仅 1 条** |
-| （新增）**H-3** | **清洗器覆盖不全 ⇒ 污染持续进入 procedure 层**（本条**有真机证据 + 时间线**，是本轮唯一**可动手**的发现） |
-
----
-
-## 4. ⚠️ 处置建议：**仍然不自行实施**，但优先级应当提高
-
-**不建议本轮动手的理由（维持上轮裁定）**：用户 2026-09-13 明确「任何 procedure 记忆引擎改动必须等用户拍板整体方案，别顺手修」。
-
-**但应把 H-3 提到用户面前**，因为：
-
-1. 它有**真机证据**（不是推测）：4/7 污染 + 时间线证明仍在发生；
-2. 它**不是一个「要不要开开关」的决策**，而是一个**明确的功能缺陷**（清洗器漏规则）；
-3. **成本极低**：`intent-clean-safe-pre.js:17` 的白名单加两个模式即可（纯函数，零副作用）；
-4. **风险可控**：加规则只会**多剥**，而剥错的代价是「少一条观察行」—— 观察行本就**不可晋升、不注入**（④ 已实测），故代价近乎为零。
-
-> **注**：`procedures.json` 里已有的 7 条脏数据**不会自动消失**（清洗器只作用于新写入）。
-> 是否需要清理存量、以及 `deprecated`/乱码条（#1/#3）如何处理，属**同一决策链**，一并请用户定。

package/docs/internal/HERMES-LEGACY-STATUS-20260919.md

@@ -1,74 +0,0 @@
-# ③ Hermes 遗留修复 · 现状核查结论（2026-09-19）
-
-> **本文档的结论会改变排期判断**，故单独立档。
-> 触发：按 `PRE-FRONTEND-CHECKLIST-20260919.md` 执行序推进 ③ 时的实施前核查。
-> 方法：直读 `lib/procedure-*.js` 真实代码 + `artifacts/_probe-procedure-promotion.mjs`（**25/25**，执行真实 store，不 mock）。
-
----
-
-## 1. 一句话结论
-
-**③「Hermes 遗留修复」所指的 issue #30 三处缺陷，在本仓 pre 线已经全部修复，且晋升链路端到端可达。**
-⇒ **③ 不应再作为「待修的 bug」排期**；它的真实形态是**「验证 + 决定是否打开开关」**。
-
----
-
-## 2. 证据链
-
-### 2.1 三处修复均已落地（代码 + 行为双证）
-
-| # | issue #30 的原始缺陷（ZCode 2026-09-13 审计） | 本仓现状 | 证据 |
-|---|---|---|---|
-| 1 | **按 `title` 去重** ⇒ 同名富候选被合并进观察行，`steps`/`successCriteria` **整体丢失** ⇒ promote 永久卡死 | ✅ **已修**：改按**指纹**匹配（指纹含 steps/preconditions/checks/successCriteria/rollback/isObservationOnly） | `procedure-observation-pre.js:21-30`；注释原文「**A title is not an identity**」 |
-| 2 | **观察行与富候选互相污染** | ✅ **已修**：`observe()` 先归一化历史行再指纹匹配；入参数组深拷（防调用方改脏） | `procedure-store-pre.js:153-174` |
-| 3 | **失败原因码不可区分**（都报 `no-success-criteria` ⇒ 误导"补判据就能晋升"） | ✅ **已修**：观察行**短路**返回 `observation-only` | `procedure-store-pre.js:270-273` |
-
-**行为级验证**（探针 Q1，8/8）：同名观察行与富候选**各自独立成行**（`procedureId` 不同）、富候选 `successCriteria` **未丢失**（长度 2）、原因码为 `observation-only` 而非 `no-success-criteria`。
-
-### 2.2 ★ 澄清一处易误判的代码
-
-`memory-hub-pre.js:145` 的 `sourceMemoryIds: []` **不是** issue #30 的旧 bug，而是**修复的一部分**：
-
-- 它出现在 `crossFeed()`（episode 自动喂）里，**配套** `observationOnly: true`（`:143`）。
-- 该通路产出的**本就只能是「观察行」**——episode 只提供"观察到一件事"的线索，不足以构成可晋升技能。
-- 硬编码空数组是**刻意的**：观察行**结构上**不该有 memoryId 证据（不得凭空造 provenance）。
-
-> ⚠️ **判据（可复用）**：看到「硬编码空数组」先别判 bug —— 先查它是否**与一个显式的语义标记配套**（此处 `observationOnly`）。
-> 与「看到配置是关的，先查是不是有意关闭」是同一条纪律的变体。
-
-### 2.3 富候选有真实通路（探针 Q3b，7/7 端到端）
-
-两条通路职责分离：
-
-| 通路 | 来源 | 产出 | 能否晋升 |
-|---|---|---|---|
-| ① `crossFeed()` | episode 成功 | **观察行**（`observationOnly:true`，`sourceMemoryIds:[]`） | ❌ 结构上不可（设计如此） |
-| ② `ingestJudgement()` → `procedureCandidateFromRow()` | judgement 行 | **富候选**（`sourceMemoryIds` 非空、`successCriteria` 透传） | ✅ **可** |
-
-**端到端实证**：构造合法 judgement 行 → `procedureCandidateFromRow` 产出候选（`sourceMemoryIds` 非空、带 `successCriteria`、**无** `observationOnly`）→ `observe()` 入账 → `promote({distinctSessions:3, successCount:2})` ⇒ **`decision:'promote'`，`stage:'validated'`**。
-
----
-
-## 3. 那么「真待办」是什么
-
-ZCode 审计另有一条**未在本仓验证过**的事实：**全机 7 个工作区均无 `procedures.json`，"固化成 skill 再注入"从未真正发生过。**
-
-结合本次核查，真实待办**不是**「修引擎」，而是下面两件（**均需用户裁定或观测**）：
-
-| 项 | 问题 | 性质 |
-|---|---|---|
-| **H-1** | **上游是否真的产出富候选？** 通路②可达 ≠ 有东西走它。需确认 judgement 行的真实产出率（本机 0 个 `procedures.json` 提示**可能为 0**） | **观测项**，非代码缺陷 |
-| **H-2** | **`procedurePromotionEnabled` 打开后会发生什么？** 引擎已就绪，但开关一开即改变所有用户行为 | **需用户拍板** |
-
-> **与用户原话的关系**：用户说「所以才先关掉的，**改完自然就能打开了**」——本次核查表明**引擎侧已经改完**。
-> ⇒ 因此「能否打开」的判据应从**代码就绪**转为**观测 H-1**：若上游长期产不出富候选，打开开关也只是让观察行持续堆积（无收益但无害）；反之则有真实收益。
-
----
-
-## 4. agent 的建议（不自行决定）
-
-1. **③ 从「待修」降级为「待观测」**：先加一个**只读探针**统计本机/目标用户的 judgement 行产出率与 `procedure_candidate` 命中数（零风险，属 R 系列观测面）。
-2. **开关保持 `false` 不动**，直到 H-1 有数据（与 ⑤ R4-C 的「等观察结果」同一处置逻辑）。
-3. **不在本轮改任何 `procedure-*.js`** —— 用户 2026-09-13 明确「**任何 procedure 记忆引擎改动必须等用户拍板整体方案，别顺手修**」，且「两个小改点已并入统一重构，**不单独做（动了也是白改）**」。
-
-> 上述 3 条是**建议**，不是结论；H-2 属用户拍板项。

package/docs/internal/ISSUE-55-58-VERIFICATION-20260918.md

@@ -1,175 +0,0 @@
-# 外部 issue #55–#58 核验报告（2026-09-18）
-
-> **核验人**：执行 Agent　**核验方式**：逐条对照 pre 线源码，**只采信代码证据，不采信 issue 自述**
-> **基线声明**：issue 自述基线 **v2.5.2 @ a972ebf**（本机确认该提交存在，`git describe` = `v2.5.2-14-ga972ebf`）
-> **报告对象**：`Minervaowl7` 于 2026-09-18 21:05–21:08 提交的 4 个 issue，来源标注「bug-hunter 自动审计（scan-only）」
-
----
-
-## 0. 一句话结论
-
-**4 条全部为真，且全部存在于 pre 线。** 无一误报，无一因 3.0 重建而失效。
-前 3 条（#55/#56/#57）是**同一族缺陷**：fail-soft 的 catch 吞掉了一个**本不该发生**的错误
-（未定义标识符 / 缓存登记时机错 / 缺 schema 校验），把"代码写错了"伪装成"环境问题"。
-第 4 条（#58）是**纯卫生问题**（慢性泄漏），性质不同。
-
-**但有一个关键前提必须说明**：这 4 条的**触发条件都较窄**，作者的 Low 定级是合理的（见 §3）。
-
----
-
-## 1. 逐条核验
-
-### #55 · `storage-manage-pre.js` `readSidecarPrev` 引用未定义标识符　✅ **确认为真**
-
-| 项 | 证据 |
-|---|---|
-| 声明 | `readSidecarPrev` 引用不在其作用域的 `docStore` |
-| 实测 | `:117 function readSidecarPrev(file) {` → `:118 try {` → `:119  if (!docStore \|\| ...) return null` |
-| 作用域 | `docStore` **只在** `:135 repair()` 与 `:169 deleteMemory()` 内 `const docStore = docStoreOf()` 定义 |
-| 工厂层 | `:31 const docStoreOf = ...`（只有函数，没有变量） |
-| 后果 | ESM 下必抛 `ReferenceError`，被 `:127 catch (_) { return null }` 吞掉 ⇒ **此函数结构上不可能返回非 null** |
-| 调用点 | `:148 docStore.rebuildSidecar(file, readSidecarPrev(file) \|\| undefined)` ⇒ 恒传 `undefined` |
-
-**作者额外发现的一个后果，我独立复核成立**：`rebuildSidecar` 拿不到 prev ⇒ 每次重建都产生新 epoch。
-而 evidence 的 fresh/stale 判定按 `recordDigest + sourceVersion` 匹配（`evidence-store-pre.js:237`）
-⇒ **「修复」功能反而把原本 fresh 的证据全部翻成 stale**。这是比"继承失效"更严重的实际影响。
-
-> 作者的置信 96/100、定级 **Medium** 是全部四条里最高的，合理。
-
----
-
-### #56 · `evidence-store-pre.js` 幂等缓存在落盘前登记　✅ **确认为真**
-
-| 项 | 证据 |
-|---|---|
-| 声明 | `_appended.add(id)` 在写盘**之前**执行 |
-| 实测 | `:112 if (id && this._appended.has(id)) { ...duplicate-evidence... }` → `:119 if (id) this._appended.add(id)` → `:120 this._chain = this._chain.then(() => this._writeLine(...))` |
-| 失败路径 | `:134 this.stats.writeFailed++` / `:135 this.stats.lastWriteError = ...` —— **无任何 `delete(id)`** |
-| 唯一清理 | `:187 this._appended.clear()`（在 `dispose()` 内） |
-| 后果 | 一次瞬时写失败 ⇒ 同 id 进程内重试**恒被拒**，证据静默丢失；除 `stats.writeFailed` 外无信号 |
-
-**修复建议复核**：作者说「`BoundedIdSet` 需补 `delete()`」——**我未验证该内部类是否有 delete**，
-这条属下修实现细节，落地时须先确认（可能是已有等价操作）。
-
----
-
-### #57 · `episodic-store-pre.js` `restore` 不校验 `current` 形状　✅ **确认为真**
-
-| 项 | 证据 |
-|---|---|
-| 声明 | `restore()` 对 `current` 零校验 |
-| 实测 | `:292 current = data.current \|\| null` —— **孤零零一行，无任何形状检查** |
-| 崩点 | `:202 if (current.segments.length < cfg.minSegments)` —— `current` 若为 `{}` ⇒ `TypeError` |
-| 对比 | `episodes` 走 `:222 validateEpisodePre(ep)`，`current` 完全没有对应校验 |
-| 后果 | `current` 损坏（手改/半损坏但可解析）⇒ restore "成功" ⇒ 之后每次 consolidate 都 TypeError ⇒ **巩固链路静默停摆直到重启** |
-
-**这条最符合本仓已记录的病害模式**：`restore` 声称成功（`{ ok: true, restored: N }`），
-但恢复出来的状态**结构上不可用** —— 与 M8/M9「结构性恒假」同族：**成功信号与真实可用性脱钩**。
-
----
-
-### #58 · `activation-host-pre.js` 清理为零调用 + 键格式错配　✅ **确认为真（两处均成立）**
-
-**根因 1 — 清理函数零调用方**：
-- 全仓 grep `activationHost.disposeRuntime|disposeSession|disposeAll` 只命中 **1 处**：
-  `index.js:10869 disposeAll('plugin disposed')`（仅插件整体卸载）
-- `index.js:1083` 的 runtime 释放路径只有 `this._shadowHost.disposeRuntime(runtime)`，
-  **没有** `this._activationHost.disposeRuntime(...)`
-- ⇒ 每会话遗留一条 `runtimeState`/`stepsByRuntime`/`pathsByKey`/inbox 记录，进程存活期内不释放
-
-**根因 2 — 键格式错配**：
-```
-:352  const key = sessionId + '|ws:' + workspaceKey      ← 写入键（stepFor）
-:510  stepsByRuntime.delete(String(runtimeKey))          ← 删除键（disposeRuntime）
-```
-两个键格式不同 ⇒ **即使接线，删除也是空操作**。作者这句话是准的。
-
-**定级**：单条很小、需长时间运行 + 频繁开关会话才显现 ⇒ Low 合理。
-
----
-
-## 2. 与 pre 线的关系（重要）
-
-| 问题 | 结论 |
-|---|---|
-| 这些文件在 pre 线存在吗？ | ✅ 四个都在（`*-pre.js` 变体，2752–28524 B） |
-| 3.0 重建修掉了它们吗？ | ❌ **没有**。四条缺陷在 pre 线**逐行可复现** |
-| pre 线是否已有修复？ | ❌ 未见任何对应补丁 |
-| issue 里的行号能直接用吗？ | ⚠️ **不能**。issue 行号是 2.5.2 的；pre 线行号已漂移（如 #55 的 `:117-128` 在 pre 线是 `:117-119`，`docStoreOf` 在 `:31` 而非 `:31` 附近需重定位） |
-
-**⇒ 这四条是「已发布版本存量缺陷 + pre 线同样存在」，需要在 pre 线修，随下个版本发出。**
-
----
-
-## 3. 严重性再评估（我的判断，供决策）
-
-作者的定级是 Low/Medium。**我同意 Low 的技术定级，但要补一条**：
-
-**#55 应升级为 Medium-High。** 理由不是"泄漏"，而是**功能反向**：
-设置页的「修复」按钮**不但没修，还把证据新鲜度全污染了**。这是一个**用户主动点击才会触发的、结果与按钮语义相反**的行为 ——
-比"缓慢泄漏"更值得优先。作者给 Medium，我认为偏保守（他大概只估了"epoch 继承失效"，
-没把"fresh→stale 反向污染"算进去；但这一条**作者自己在正文里写了**，所以是定级偏保守，不是漏判）。
-
-**四条的共同特征（本仓值得记的判据）**：
-
-> 这四条**没有一条**会被现有 smoke 抓到，也**没有一条**会在正常使用中报错。
-> 三条是 fail-soft 的 catch **吞掉了本该炸的错误**（未定义标识符 / 时机错 / 缺校验），
-> 一条是"删除键写错 ⇒ 删除静默失败"。
-> ⇒ **fail-soft 是本仓的铁律，但它的代价在这里集中兑现了**：
-> catch 把"代码 bug"降级成"无明显症状"，只有专门的静态审计才能捞出来。
-> 这正好印证用户的原话：「用 GPT 找到 bug」——这类 bug 靠跑是跑不出来的。
-
----
-
-## 4. 修复建议（按性价比排序）
-
-| 序 | issue | 修法 | 风险 | 建议时机 |
-|---|---|---|---|---|
-| 1 | **#55** | `readSidecarPrev` 内加 `const docStore = docStoreOf()`（与 `repair`/`deleteMemory` 一致）；补一条 smoke：repair 后 epoch/version 应继承 | 极低（一行 + 断言） | **立即** |
-| 2 | **#56** | 写入成功后才 `add(id)`（在 `.then((written) => ...)` 内判 `written === true`）；或失败时 `delete(id)` | 低（需确认 `BoundedIdSet` 能否 delete） | **立即** |
-| 3 | **#57** | `restore` 对 `current` 补形状校验（`sessionRef` 字符串 / `startedAt` 有限 / 三个数组），不合格置 `null`（**丢弃优于卡死**） | 低 | **立即** |
-| 4 | **#58** | ① `dispose(agent)` 补 `_activationHost.disposeRuntime(runtime.key)`；② `disposeRuntime` 改按 `stepFor` 实际键格式删除（或建条目时记下 key） | 中（键格式统一要**同时**核对所有读写点，否则二次错配） | 紧随 |
-
-**共同纪律**：四条都**必须先写"能失败"的套件**（当前 4 条全都零测试覆盖），
-且 #58 修完要**用变异演示确认键格式真的对齐**（正是"改了一处、另一处还是旧键"的典型）。
-
----
-
-## 5. 与今晚在做的 I5/R4-A 是否同一问题？——**不是，完全无关**
-
-用户问「这个和刚才改的东西是否针对的是同一个问题」——**明确不相干**：
-
-| | issue #55–#58 | 今晚在做的 R4-A / I5 |
-|---|---|---|
-| 对象 | `storage-manage` / `evidence-store` / `episodic-store` / `activation-host` | `l0-extract-pre` 的 `status` 谓词 |
-| 层面 | **存储与生命周期**（谁在何时清理、何时登记、何时校验） | **检索呈现**（作废条目该过滤还是该标记） |
-| 用户可见性 | 设置页「修复」按钮失效、证据静默丢失、巩固停摆 | 检索结果里能不能看到"这条已过时" |
-| 关系 | **无任何代码交叠** | — |
-
-**唯一的间接联系**：四条 issue 所在的模块（evidence-store / episodic-store / activation-host）
-正是 R1「静默降级普查」点过名的高危区，而 #55/#56/#57 三条**又是 fail-soft 吞错**同一族。
-⇒ **可以确认：R1 普查的方向是对的，但覆盖面不全** —— 它按"降级点"枚举，
-而这次是**按"标识符作用域/缓存时机"**这类静态缺陷找出来的，是另一个证据面。
-建议把「静态审计」列为 R 系列的补充分支（见 §6）。
-
----
-
-## 6. 建议（供用户决策，不自行执行）
-
-1. **立即修 #55/#56/#57**：三条都是低风险、一行到几行的修，且**用户可感知**（尤其 #55 的修复按钮反向污染）。
-2. **#58 紧随其后**，但键格式统一要**一并核对全部键读写点**再动手。
-3. **建议把「静态审计分支」正式写进作战计划**：本仓已有 R1（降级普查）与本次（外部审计），
-   但**缺少常态化的静态检查**（未定义标识符、键格式一致性、缓存登记时机）。
-   这次 4 条里有 3 条属于"跑不出来、只能看代码看出来"的类型，值得一条独立防线。
-4. **本次 issue 的作者质量值得肯定**：4/4 全真、行号级证据、给出建议修法、并**如实标注了 Low（没有夸大）**。
-   这是外部贡献里质量很高的一批。
-
----
-
-## 附：核验方法与可复核性
-
-- 提交存在性：`git describe --tags a972ebf` → `v2.5.2-14-ga972ebf`
-- 文件存在性：4 个 `lib/*-pre.js` 全部存在（含字节数）
-- 逐条 grep + 上下文窗口读取（`Select-String -Context`），对照 issue 声明的行号与代码形态
-- **未执行**：未跑复现脚本（#56/#57 需构造瞬时写失败/损坏 JSON，#58 需长时间运行观测）；
-  本次为**静态核验**，结论基于代码结构，不基于运行时观测 —— 如需运行时证据，应另写探针。