@a9i5k4/dsh-auto-memory 3.0.0 → 3.0.1

package/docs/internal/HANDOFF-TO-ZCODE-20260920.md

@@ -0,0 +1,309 @@
+# 交接：dsh-auto-memory 功能梳理 + 首页构建（2026-09-20 · 来自 DSH 线）
+
+---
+
+# 🚨 2026-09-20 更新 · 美术方向已换（**先读这段**）
+
+**用户裁定：「把原有的那个色调和风格丢掉，主要采用 DeepSeek 主页的形式。」**
+
+## 权威文档已更换
+
+| | 文档 | 状态 |
+|---|---|---|
+| ❌ **作废** | `docs/internal/ART-DIRECTION-WIREFRAME.md` | **不要再照它做配色** |
+| ✅ **现行** | **`docs/internal/ART-DIRECTION-DEEPSEEK-20260920.md`** | **照这份做** |
+
+**链接**（用户在文件面板可直接打开）：
+
+```
+D:\dsh-auto-memory\docs\internal\ART-DIRECTION-DEEPSEEK-20260920.md
+```
+
+## 如果你已经在做了 —— 自查三条，一样就继续，不一样就改
+
+| # | 自查项 | 若不符 → 改成 |
+|---|---|---|
+| **1** | **主色是品牌蓝 `#4d6bfe` 吗？** | 若是**信号橙 `#E9470C`** ⇒ **改** |
+| **2** | **用了玻璃 + 圆角吗？** | 若你**避开了** `backdrop-filter` 和圆角 ⇒ **改**（官网自己就在用：`blur(12px)`、卡片 24px） |
+| **3** | **背景与角色是分层帧率吗？** | 若是**整页统一帧率** ⇒ **改**（背景 60fps + **角色 24fps 线描抽象**） |
+
+## 三条核心规格（速记）
+
+1. **底色**：亮 `#f9f8f8` / 暗 **`#0a0a0a`**（**建议主推暗色**，贴「黑鲸」调性）
+2. **层级**：**半透明白叠加**（`surface-1..5`），不画实色分区线
+3. **★ 分层帧率**：**背景 60fps 丝滑** + **角色 24fps 抽象线描** —— 两层**不需要同步**，这是刻意的视觉对比
+
+## 角色层规格（**抽象优先**，用户明确要求）
+
+- 单色线描，1–1.5px；**极简甚至零着色**（只留发丝高光 + 瞳孔一点蓝）
+- **剪影可辨识 > 五官精细**；远景可只留四个特征：轮廓 + 呆毛 + 头鳍 + 鲸尾
+- 好处：**耐看 · 省体积 · 且绕开了「等精绘排期」这个最大卡点**
+
+## 角色版权约束（**必读**）
+
+鲸鱼娘源自「明月」（作者 **商山无行**），协议 **CC BY-NC-SA 4.0** ⇒ **须署名 · 禁商用 · 衍生同协议**。
+本项目为非商业开源插件，属可接受范畴；**将来若商业化必须重评**。
+
+**官网 CSS 本地副本**（可直接读）：`artifacts/_ds-css/`（三份，共 85 KB）
+
+**完整理由与逐项对照** → 见 `ART-DIRECTION-DEEPSEEK-20260920.md`（351 行，§0 专讲为什么要推翻旧版）
+
+---
+
+> **这是什么**：一份**自包含**的交接文档。读完它 + 它指向的三份权威文档，你就能接手工作，**不需要**访问 DSH 的记忆系统或聊天记录。
+> **谁写的**：在 DSH（DeepSeek Harness）线上做这个插件的 agent。
+> **给谁**：ZCode 线的 agent。
+> **为什么交接**：DSH 线转入维护期；本轮工作（功能梳理 + 架构梳理 + 首页）需要**构建链 + 浏览器迭代能力**，ZCode 的 computer use 更强。
+
+
+---
+
+## §0 一句话启动指令（用户可直接把下面这段粘给 ZCode）
+
+```
+项目在 D:\dsh-auto-memory。先读 docs/internal/HANDOFF-TO-ZCODE-20260920.md（全文），
+再读它 §2 列的三份权威文档。读完在会话里复述：①我在做什么 ②哪三个目录我可以写
+③哪两个目录绝对不能碰 ④三路任务分别的交付物是什么。复述完再开工，不要提前动手。
+```
+
+---
+
+## §1 你的工作边界（**先看这段，越界会造成真实损失**）
+
+### ✅ 你可以写的地方
+
+| 目录 | 用途 |
+|---|---|
+| `docs/` | 文档、功能清单、架构图、首页源码（含新建子目录） |
+| `新目录（自选）` | 首页工程（如 `landing/`、`site/`）—— **见 §4-C 的方案** |
+
+### ❌ 你**不能**碰的地方
+
+| 目录 | 为什么 |
+|---|---|
+| **`lib/`** | **这是活的宿主代码**。本地 profile 用 `link:` 挂载，`lib/` 一改，正在运行的 DSH 宿主**立刻受影响**。而且它与 DSH 线的开发同步进行 —— 两边同时改会撞车。 |
+| `tests/` | 与 `lib/` 绑定（146 个回归套件）。**不要动。** |
+| `tools/` | 发布工具链。**不要动。** |
+| `.dsh-memory/` | DSH 线的记忆数据。**只读，不要写。** |
+
+### ⚠️ 一条硬约束（重要）
+
+**插件（`lib/client.js`）不能加构建链。** 它是手写的 `__ModuleLoader__` bundle，只有一个文件、没有构建步骤、依赖只能是宿主 seed 表里的包。
+
+**但首页不受这条约束** —— 首页是**独立静态站点**，可以有构建链（Astro/Vite/Three.js 随便用）。详见 §4-C。
+
+---
+
+## §2 权威文档索引（**按顺序读，不要跳**）
+
+| # | 文档 | 讲什么 | 你必须从中得到什么 |
+|---|---|---|---|
+| **1** | **✅ `docs/internal/ART-DIRECTION-DEEPSEEK-20260920.md`**（351 行，2026-09-20） | **美术方向 v2 · DeepSeek 官网体系**：官网实测色板 / 圆角玻璃投影六档 / 按钮态 / **分层帧率** / **角色抽象化规格** / 鲸鱼娘版权链 | **首页就按这份做** —— 旧 `ART-DIRECTION-WIREFRAME.md` **已作废**（见文首横幅） |
+| **2** | `docs/internal/PRE-FRONTEND-CHECKLIST-20260919.md`（705 行） | **排期权威视图**：§4 含 R1–R7 前端要求、§8 真实进度执行序、**§10 = 前端之后一起做的三项遗留** | 理解「前端项目的边界与已定事项」 |
+| **3** | `docs/internal/DESIGN-OVERHAUL-PRE-RESEARCH.md`（285 行） | **大排期预研**：§2 现状硬数据（量化）、§4 三条线目标形态、§5 排期、**§8 六个拍板点** | **功能清单与架构梳理的起点** —— §2 已经有一批量化数据可直接引用 |
+
+**索引文档（按需查，不必通读）**：
+
+- `docs/internal/UI-INVENTORY-RAW.md` —— 设置项 8 组 / 85 键的原始清单
+- `docs/UI-REFACTOR-PRE-RESEARCH.md` —— 界面重构预研
+- `docs/internal/ISSUE10-FIX-EXECUTION-20260919.md` —— ⑩ 系列修复执行记录（下文的「变更」多出自此）
+- `README.md` / `docs/USER-GUIDE.zh-CN.md` —— 面向用户的现有说明（**已知覆盖不全**，见 §4-A）
+
+---
+
+## §3 你在 09-14 之后缺失的变更（**你的记忆缺口在这里**）
+
+你在 `~/.zcode/cli/memories/projects/dsh-auto-memory-4412cd98b2e33c51/memory/` 已有 31 份本项目记忆，**最新到 09-14**（含一份 `handoff-2026-09-11-from-dsh.md`）。
+**09-14 之后 DSH 线做的事，你的记忆里没有 —— 以下是全量清单：**
+
+### 3.1 上游 issue 全批闭环（GitHub 队列清零）
+
+- **13 条 issue** 全部带针对性证据回复并关闭；**6 个 PR** squash-merge 进 `main`（`821a35d7` → `8da0d606`）。
+- **仓库当前 open issue/PR 数 = 0。**
+- 关键结论：**上游 issue 的根因清单可能整体过时** —— 它们多基于 `main@d816497(v3.0.0)` 撰写，而开发线经多轮重构后，其中「17 个 smoke 红」「python import 失效」等描述**均不成立**。⇒ 处理上游 issue 前**必须先实跑核验**，不可照单全修。
+
+### 3.2 已交付的后端能力（**这些是首页可以宣传的素材**）
+
+| 代号 | 能力 | 用户能看到什么 |
+|---|---|---|
+| **T4** | procedure memory **模型直写通路** | 模型可以自己写技能/流程（新增工具 `memory_procedure_pre`，模型工具数 16→17） |
+| **R7** | 用户级硬性约束**可视编辑** | 用户能在面板里**自己增删改**「每轮必注入的硬约束」，有预览、删除二次确认 |
+| **R1–R6** | 审批界面**可读性** | 技能审批不再只有英文枚举：中文化阶段 + **「为什么还不能晋升」用人话说**（含具体数字）+ 可展开预览真实步骤 |
+| **#82** | 配置**原子写入 + 损坏隔离** | 保存中途崩溃不再无感重置全部配置；损坏文件被改名保留（`.corrupt-<ts>`） |
+| **#86-3** | `DSH_HOME` 统一 | 7 处实现收敛到 1 处，跨平台路径不再打架 |
+| **#84** | 诊断留痕 | 事件环丢弃有计数；unhandledRejection 有 `{count, firstAt, lastAt}` |
+| **T10** | 机械流程切片**默认关闭** | 解耦开关 `hubMechanicalProcedureFeedEnabled`（默认 false） |
+
+### 3.3 三条**可复用的工程纪律**（你写文档时也该遵守）
+
+1. **fail-soft 必须留痕** —— 不能静默降级。本项目所有 catch 分支都要有可观察信号。
+2. **变异测试必须真红** —— 把条件改成常量后，JS 三元**仍会渲染假分支**，字符串还在文件里 ⇒ 断言要**先定位分支再断言**，不能只查「字符串存在」。
+3. **「PR merge 成功 ≠ 修复落地」** —— PR 常改**陈旧副本**（`lib/*.js` 而非宿主真正 import 的 `lib/*-pre.js`），必须另行移植。
+
+---
+
+## §4 三路任务书（**并行执行**）
+
+> **用户明确要求：兵分三路并行。** 三路互不阻塞，可同时开工。
+
+### 4-A · 第一路：**功能全量调查 → 三层功能清单**
+
+**目标**：产出一份 `docs/internal/FEATURE-INVENTORY.md`，**同时满足用户视角与工程视角**。
+
+**交付物规格（三层结构，缺一不可）**：
+
+| 层 | 内容 | 粒度要求 |
+|---|---|---|
+| **L1 用户能力** | 「用户能用它做什么」 | 一句话一条，**面向宣传** |
+| **L2 承载面** | 每个能力**现在住在哪**（页签/插槽/设置分组） | 表格，**面向前端搬家** |
+| **L3 工程细节** | 全部实现细节 | **全量不删减** |
+
+**⚠️ L3 的硬要求（用户原话：「所有的工程细节信息都要保存着」）**：
+
+- 必须有：**17 个模型工具**（逐个列出签名与用途）、**49 条 HTTP 路由**、**85 个设置键**（8 组）、**6 处插槽注册**、数据文件清单、关键调用链
+- **不许摘要化、不许「等等」省略、不许只写代表性的**
+- **L3 的地位不是「附录」，是「存档」** —— 用户要自己决定哪些展示、哪些宣传、哪些留在后台
+
+**建议做法**：
+1. 先读 `docs/internal/DESIGN-OVERHAUL-PRE-RESEARCH.md` §2（已有量化数据可直接引用，别重做）
+2. 再读 `docs/internal/UI-INVENTORY-RAW.md`（85 键清单）
+3. `lib/` **只读**扫一遍，把工具/路由/插槽/设置项**机械枚举**出来（不要靠猜）
+4. 补 L1/L2 的映射关系
+
+**注意**：`lib/` 你**不能改，但可以读**。枚举时用 `grep`/`node` 脚本，不要手工抄。
+
+### 4-B · 第二路：**架构与技术栈调查**
+
+**目标**：产出 `docs/internal/ARCHITECTURE-FOR-ZCODE-20260920.md`，让后续任何 agent 能理解「这东西是怎么搭起来的」。
+
+**必须覆盖**：
+
+| 主题 | 要点 |
+|---|---|
+| **三层结构** | 宿主 `lib/index.js`（Node 侧，11460 行）／浏览器 `lib/client.js`（5701 行）／可选 Python 语义引擎 |
+| **插槽系统** | 宿主的 `ctx.slots` API：`inject` / `register` 语义、**61 个插槽清单**、`one handle one scope` 约束 |
+| **数据流** | 记忆文件 → 注入面 → 检出 → 检索；HTTP 路由的认证边界（**loopback-only，401 是预期**） |
+| **双线结构** | pre 开发线（`D:\dsh-auto-memory`）vs REL 发布线（`D:\dsh_debug\_publish_dsh-auto-memory`） |
+| **文件名约定** | 宿主真正 import 的是 `lib/*-pre.js`；同名的 `lib/*.js` 是**陈旧副本，不生效** |
+| **测试体系** | 146 个 smoke 套件、`node tools/run-smoke.mjs` 用法、**前端仅 3 个断言组件行为**（已知缺口） |
+
+**关键已知事实（别重新发现）**：插槽调查已在 DSH 线做过一轮，结论在 §6.3 与 `dsh-plugin-ecosystem-integration.md`（你自己的记忆里就有）。
+
+### 4-C · 第三路：**开始构建首页**（标准最高的一路）
+
+**目标**：**新首页从 0 做出来**，按 **`ART-DIRECTION-DEEPSEEK-20260920.md`** 的规格（**不是**旧线框稿版）。
+
+**用户的两条明确指令**：
+
+1. **旧 HTML 直接扔掉** —— `docs/landing/index.html`（1745 行 / 122 KB）**废弃**，从 0 重做。
+2. **~~「就按一周之前的那个规划来做」~~ → 已更新为「主要采用 DeepSeek 主页的形式」** —— 即按 **`ART-DIRECTION-DEEPSEEK-20260920.md`**，并结合三个开源素材库。
+
+**两个已拍板的前提**：
+
+| 项 | 决定 |
+|---|---|
+| **托管方式** | **GitHub Pages**（放弃 htmlpreview） |
+| **面板形态** | **保持液态玻璃不变** —— 线框稿风格**只用于首页**，不要试图改面板 |
+
+**用户对抄素材的态度（原话）**：
+
+> 「这个风险无所谓……你就大大方方让他抄就行了。**就是要这种优秀的美学风格和艺术风格，能多抄多少就抄多少。**」
+
+**迭代方式**：用户明确说 **「先让模型改到自己满意」**，且 **ZCode 的 computer use 很好** —— 可以**一步一步截图、一步一步滚、一步一步迭代**。请用起来。
+
+---
+
+## §5 三路共用的硬纪律
+
+### 5.1 用户级硬规则（**违反会造成真实损失**）
+
+| # | 规则 | 为什么 |
+|---|---|---|
+| **1** | **绝不停止/重启 DSH web 宿主（3080 端口）** | 一旦关闭，**用户的会话思维链会直接断开卡死**。宿主只能由用户手动重启。 |
+| **2** | **绝不无差别杀 node 进程** | DSH harness 与插件宿主**都跑在 node 上**。`Get-Process node \| Stop-Process` 会连带杀死正在运行的会话（2026-09-14 实际发生过一次）。 |
+| **3** | **不碰 `lib/`** | 见 §1。 |
+| **4** | **改 DSH 配置前必须先备份** | 避免块级结构丢失。 |
+
+### 5.2 本仓工程纪律
+
+| 纪律 | 说明 |
+|---|---|
+| **文件用 CRLF，无 BOM** | 本仓全部源文件是 CRLF。改动后校验：`LFonly` 必须为 0。 |
+| **大文件分块写入** | 一次性生成整个大文件会被拒绝。 |
+| **`edit` 用 `replace_all` 后必须核对命中数** | 替换范围**包含同一次编辑新加入的代码块** —— 若新块内文本与待替换文本相同，会一起替换（曾造成辅助函数自递归）。 |
+| **fail-soft 必须留痕** | 不得静默降级。 |
+| **别用固定字符窗口做断言** | 曾因 `SRC.slice(idx, idx+900)` 越界到相邻函数而误判。要**用花括号配对精确取函数体**。 |
+
+### 5.3 与 DSH 线的协作约定
+
+- **`lib/` 归 DSH 线，`docs/` 与首页归 ZCode 线。** 各改各的，不要交叉。
+- 若你发现**必须改 `lib/`** 才能完成的任务：**不要改**，写进文档的「待 DSH 线处理」清单。
+- 你把交付物写到仓库里，DSH 线**能读到** —— 两边通过**文件**同步，不通过聊天。
+
+---
+
+## §6 三个素材库（已取证）
+
+| 仓库 | 语言/栈 | ⭐ | License | 体积 | 备注 |
+|---|---|---|---|---|---|
+| **[JesseLee-CN/rhinelab-blog-theme](https://github.com/JesseLee-CN/rhinelab-blog-theme)** | Astro + Three.js + TS + Pagefind | 5 | **MIT** | 55.8 MB | **同作者配套**：自述「含 RhineLabUI 三维档案终端 `/lab/`（脱敏开源版）」 |
+| **[LBEILC/RhineLabUI](https://github.com/LBEILC/RhineLabUI)** | TypeScript + Three.js | **565** | **MIT** | 133.5 MB | 有线上 demo：<https://rhine-lab-ui.vercel.app> |
+| **[Ulchemist/arknights-motion-library](https://github.com/Ulchemist/arknights-motion-library)** | JavaScript | 2 | **NOASSERTION** | 25.9 MB | 见下方提醒 |
+
+### 6.1 用户对复用的态度（已授权）
+
+> 「这个风险无所谓，我现在这个东西，几个人就能用啊，而且我现在用的也是开源库，**你就大大方方让他抄就行了**。**就是要这种优秀的美学风格和艺术风格，能多抄多少就抄多少。**」
+
+⇒ **以美学风格复用为主**（配色/排版/动效/三维交互的**做法与观感**），这是最有价值的部分。
+
+### 6.2 事实性提醒（知情即可，不构成阻碍）
+
+- `arknights-motion-library` 的 License 显示为 **NOASSERTION** —— GitHub **未能识别出标准许可证**，意味着复用权利**不明确**，建议点进仓库确认作者实际声明。
+- 名字含 **Arknights（明日方舟）**：**代码许可 ≠ 美术资源许可**。游戏角色素材的版权归属游戏方，这类「动作库」通常复用其**动作数据格式/播放器实现**而非原画。
+
+### 6.3 一个关键技术结论（**决定复用可行性**）
+
+> **首页与插件是两套约束，互不影响。**
+
+| | 插件（`lib/client.js`） | **首页（独立站点）** |
+|---|---|---|
+| 运行环境 | 宿主 GUI 内，被 `__ModuleLoader__` 加载 | **独立网页，浏览器直接打开** |
+| 依赖 | ❌ 只能用宿主 seed 表提供的包 | **✅ 随便用** |
+| 构建步骤 | ❌ **没有**，手写单文件 | **✅ 可以有**（Astro / Vite / TS 随便） |
+| 产物 | 随 npm 包分发 | **GitHub Pages 托管构建产物（标准做法）** |
+
+⇒ **三个素材库都需要构建链（Astro / TypeScript），这完全不触碰插件约束。** 你可以放手用。
+
+### 6.4 「怎么 combine」的建议方向（**供参考，最终由你做决定**）
+
+| 从哪来 | 拿什么 |
+|---|---|
+| **ART-DIRECTION-DEEPSEEK-20260920.md** | **骨架与规格**：官网实测色板（品牌蓝 `#4d6bfe` / 暗底 `#0a0a0a`）、圆角玻璃投影六档、按钮态、**分层帧率（背景 60fps + 角色 24fps）**、**角色抽象化规格** |
+| **rhinelab-blog-theme** | **Astro 站点结构 + 三维终端页的做法**（它本身就是一个含 `/lab/` 的博客主题，与首页定位最接近） |
+| **RhineLabUI** | **三维档案界面的交互范式与视觉语言**（565 stars，最成熟） |
+| **arknights-motion-library** | **动效/序列帧播放的实现思路**（对应你要的 24fps 动效） |
+
+**✅ 原「美学冲突」已消失**：旧版 §2.4 禁玻璃/圆角/投影，与 RhineLab 系深色发光玻璃**冲突**；**改走 DeepSeek 官网体系后，两边调性一致**（都用玻璃 + 圆角 + 暗色高科技），可放心 combine。
+⇒ **这两套美学的调性不同**，combine 时需要一个明确取舍。**建议：以线框稿的「克制 + 工程图」为骨架，把 RhineLab 的动效与三维交互作为「局部亮点」引入**，而不是整体转向深色霓虹。
+
+---
+
+## §7 完成判据（自我验收）
+
+| 路 | 判据 |
+|---|---|
+| **4-A** | `FEATURE-INVENTORY.md` 三层齐全；**L3 覆盖 17 工具 / 49 路由 / 85 设置键 / 6 插槽，无「等等」省略** |
+| **4-B** | `ARCHITECTURE-FOR-ZCODE-*.md` 能让**没见过这个项目的 agent** 理解整体结构 |
+| **4-C** | 首页可本地打开并正常渲染；**有截图证据**；遵循 ART-DIRECTION 的色板与禁止项；**已考虑 GitHub Pages 部署方式** |
+
+---
+
+## §8 你现在就该做的三件事（按顺序）
+
+1. **通读本文档 + §2 的三份权威文档**（不要跳）
+2. **在会话里复述**：①我在做什么 ②能写哪三个目录 ③不能碰哪两个目录 ④三路交付物分别是什么 —— **复述完再动手**
+3. **三路并行开工**：先派调查（4-A / 4-B），同时自己起手首页（4-C）
+
+> **最后一句**：这份文档是**自包含**的。你不需要 DSH 的记忆系统。但如果你想知道「为什么当初这么决定」，`docs/internal/` 下有完整的决策记录（`PRE-FRONTEND-CHECKLIST-20260919.md` §8 有真实进度执行序）。
+
+

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

@@ -0,0 +1,120 @@
+# ③ 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

@@ -0,0 +1,74 @@
+# ③ 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 属用户拍板项。