@a9i5k4/dsh-auto-memory 2.5.3 → 3.0.1

package/docs/internal/RHINELAB-TO-DEEPSEEK-FEASIBILITY.md

@@ -0,0 +1,198 @@
+# RhineLab 双仓 → DeepSeek 风格 改造可行性报告
+
+> 2026-09-20 · 结论先行，证据在后。
+> 本地已跑起来：**`http://127.0.0.1:5173/lab/`**（后台作业 `pwsh-7`，你自己开浏览器看）
+> 克隆位置：`artifacts/_repos/clone/blog-theme`（83.6 MB）、`artifacts/_repos/clone/RhineLabUI`（138.2 MB）
+
+---
+
+## 0. 先纠正一件事：这两个仓库确实是同一个东西
+
+你说的没错，而且比「像」更彻底 —— **`blog-theme` 就是 `RhineLabUI` 的脱敏衍生版**：
+
+| 证据 | 数值 |
+|---|---|
+| 两仓 `src/` 下**同名同路径**文件 | **49 个**（`scene.ts` / `main.ts` / `style.css` / `theme*.ts` / `decryption.ts` …） |
+| 只在 RhineLabUI | 25 个（`workbench*`、`wallpaper*`、`archive-playground`、`startup`…）—— Wallpaper Engine 壁纸与桌面工作台分支 |
+| 只在 blog-theme | 14 个（`article-reader*`、`boot-entry`、`boot-intro`、`auth-*`）—— 博客阅读器与身份认证 |
+| LICENSE | 两仓均 MIT，`blog-theme` 保留 `Copyright (c) 2026 LBEILC` |
+| 关系 | blog-theme 自述：「含 RhineLabUI 三维档案终端 `/lab/`（脱敏开源版）」 |
+
+**含义**：只需研究一个。我选了 `blog-theme`，因为它 = RhineLabUI 全量三维核心 + 博客层，且自带完整 `DESIGN.md`（34 KB 视觉基准）。
+
+---
+
+## 1. 我已经把它跑起来了（不是读代码，是真跑）
+
+```
+cd artifacts/_repos/clone/blog-theme
+npm ci --ignore-scripts     # 349 包，28 秒
+npm run prepare:assets      # ← 关键，见「坑」
+npm run dev:lab             # → http://127.0.0.1:5173/lab/
+```
+
+**实测状态**：
+
+| 项 | 结果 |
+|---|---|
+| 开场画面 | ✅ 渲染正常（`RHINE LAB` / `SYNTHESIZE INFORMATION` / `ANALYSIS OS` / `ENTER SYSTEM ↗`） |
+| WebGL | ✅ full WebGL2（`EXT_texture_compression_bptc`、`EXT_float_blend`、`EXT_disjoint_timer_query_webgl2` 等 12+ 扩展） |
+| GLB 模型 | ✅ `200 /lab/assets/archive-cassette.glb`（3.57 MB） |
+| 音频 | ✅ `motif.ogg` / `atmosphere.ogg` / `pulse.ogg` 全部 200 |
+| 开场推进 | ⚠️ 无头环境下 `ENTER SYSTEM` 后不推进（需要真实用户手势，`navigator.userActivation.isActive` 守卫）；有真实浏览器无此问题 |
+
+**踩到的坑（你重跑时会遇到）**：`dev:lab` 的 Vite `publicDir` 指向 `.generated/lab-public`，但 `dev:lab` 脚本**只生成内容、不同步资产** ⇒ 字体与 GLB 全 404、页面显示「CONNECTION INTERRUPTED / 三维档案资源未能载入」。**必须先跑一次 `npm run prepare:assets`**（同步 768 个文件）。
+
+---
+
+## 2. 我吃透了什么（决定「能不能改」的硬数字）
+
+### 2.1 三维档案阵列的真实结构（`DESIGN.md` + 源码）
+
+- **内容**：5 个策展主题 × 8 个槽位 = **40 份档案**，正文为「基于公开世界观资料的原创编目文章」，不是游戏原文
+- **阵列**：`9 列 × 32 行 = 288 个位置`循环补位；逻辑坐标超 2048 时按内容周期整体平移（防浮点精度衰减）
+- **卡片**：宽 5 / 高 3.7 / 行距 0.62 世界单位；通道中心距 5.2
+- **相机**：`PerspectiveCamera(34°, 16/9, 5, 300)`，长焦压缩构图；31.48 秒处方位角 59° / 仰角 19°
+- **后处理**：`ACESFilmicToneMapping` + SSAO + Bokeh 景深 + 屏幕级 SVG 颗粒/暗角/色差
+- **★ 没有 bloom**（`UnrealBloomPass` 全仓 0 命中）—— 这点和「发光赛博」的直觉相反，它的质感来自「印刷品/胶片」
+
+### 2.2 开场是一段**逐帧复刻**，不是随便做的动效
+
+- 参考片 **1920×1080 / 25fps**，复刻区间 6.76–27.00 秒
+- 品牌三行在 **278 / 280 / 282 帧**错峰滑入（**帧级编排**）
+- **五个文件专门做开场时间轴**：`boot-motion.ts` + `boot.ts` + `boot-tracks.ts` + `boot-orbit-tracks.ts` + `boot-logo-tracks.ts`
+- 「将逐字输入、停顿、清空、闪切**固定到原片帧点**，空间位置使用连续插值」
+- 字体：原片是授权字体，本站未获授权 ⇒ `__RHINE_NOVECENTO__` **恒为 false**，开场品牌字样走**描边图形**兜底
+
+### 2.3 动效体系（可直接抄的）
+
+- 全仓 CSS 只有 **3 处 `cubic-bezier`** —— 他们几乎不用 CSS 补间，动效在 TS 里手写
+- 两条主曲线：`cubic-bezier(0.16,1,0.3,1)` 1.6s（大位移）、`cubic-bezier(0.22,1,0.36,1)` 1.3s（面板）
+- **帧率无关的指数收敛**（值得直接抄）：
+  ```ts
+  THREE.MathUtils.lerp(value, target, 1 - Math.exp(-dt * 14))
+  ```
+  天然支持打断/接续，比 CSS transition 可控
+- `steps(1)` 全仓**仅 1 处**：`blink 0.8s steps(1) infinite` 光标硬切
+
+---
+
+## 3. 三档分类：什么能改 / 不好改 / 不能改
+
+### 🟢 第一档：能改，而且成本低
+
+| 项 | 为什么好改 | 预计工作量 |
+|---|---|---|
+| **文案与语言层** | 文案全在 `main.ts` 内联 HTML + `content/posts/*.md`（Markdown 单一来源） | 小 |
+| **品牌字样** | `src/brand.ts` 是单一标志路径；`boot-lettering-art.json` 是描边图形数据 | 小 |
+| **★ 色板（HTML/CSS 层）** | 见下方「关键发现」——但**必须成体系地做**，不是改几个变量 | **中** |
+| **博客部分** | Astro 构建期生成静态 HTML；**禁用 JS / WebGL 仍可阅读** | 小 |
+| **内容注入** | 列表 / 摘要 / RSS / sitemap / 搜索索引 / 三维卡片**全部由同一份 Markdown 派生** | 小 |
+| **动效时长与曲线** | 集中在 `ui-transitions.ts` + `DESIGN.md` 有完整时长表 | 小 |
+| **开场跳过** | 已有 `?review=1&scene=archive`（DEV 直通）与 `replayBoot()`，可扩展成正式入口 | 小 |
+
+### 🟡 第二档：不好改 —— 需要改造，不是配置
+
+| 项 | 难点 | 原因（硬证据） |
+|---|---|---|
+| **★★ 换 DeepSeek 主色（三维部分）** | **全仓只有 32 个 CSS 自定义属性，且有 294 个硬编码 hex + 35 个 rgba/hsl** | 那 32 个变量还只是 `--rn-blur` / `--rn-edge-fade`（滚动数字用），**根本不存在主题 token 体系**。改色要逐文件改字面量 |
+| **三维材质色** | 分散在 4 个文件：`scene.ts`(26) / `theme-material.ts`(13) / `internal-optics.ts`(5) / `archive-lighting.ts`(6) | 其中 `theme-material.ts` 已经**做过一次完整的亮↔暗反相**，可照它的**方法论**做，但不能照它的颜色值做 |
+| **★ 暖灰 → DeepSeek 暗色** | 这不只是换色：**光照明暗关系要重标定** | 现在是「暖灰底 + 纯黑字 + 琥珀点缀」，曝光 1.00 / 环境强度 0.52 / 暖白主光 1.7 / 主光位置 (-8,14,4)。DeepSeek 是极暗底 + 亮字，灯光、雾色、地面反射率、AO 半径全都要重算 |
+| **字体** | 现在是 **MiSans**（小米开源，允许免费商用+网页内嵌），761 个 woff2 分片 / **25.2 MB** | 换 DeepSeek 官网字体需确认授权；MiSans 分片做法（cn-font-split 按 `unicode-range`）可复用 |
+| **开场动效** | 帧级编排与品牌字样描边绑死 | 改品牌名 → `boot-lettering-art.json`（33 KB 描边数据）要重新生成；三行 278/280/282 帧错峰要重排 |
+| **音频** | `audio.ts` 20 KB + 3 个 ogg | 授权范围要单独核（`public/audio/README.md`） |
+
+### 🔴 第三档：不能改（或不该改）
+
+| 项 | 原因 |
+|---|---|
+| **★ 模型文件（GLB / Blender）** | **MIT 不覆盖**。`art/archive-cassette.blend`、`archive-assembly.glb` 是原作者建模产物，改/分发要单独看授权。仓方自己写明：「MIT 仅适用于仓库声明有权授权的程序代码、建模脚本及配套技术文档，**不自动覆盖**游戏名称、标志、设定、原作视觉、Blender/GLB 模型、图像、动图或原片短音」 |
+| **原片素材** | `reference/` 对照页 + `docs/media/*.gif`（6.28 MB / 5.69 MB 两个 GIF 是全仓最大文件）**只作本地验证，不得进产品** |
+| **游戏品牌** | 「Rhine Lab」「莱茵生命」是《明日方舟》品牌，**必须全部替换**。这正是我们要做的 |
+| **授权字体** | Novecento Sans Wide / MyFonts webfont —— 仓方已主动降级为 `false`，我们沿用这个决定 |
+| **档案正文** | 40 篇是「基于公开世界观资料的原创编目文章」，**不能冒充游戏内原始档案**。我们的版本必须是自己的内容 |
+
+---
+
+## 4. 落款等内容层面的整体计划（你要的「整体计划」）
+
+这是**必须整体替换**的部分，不是填几个空。
+
+### 4.1 需要换掉的「身份层」清单
+
+| 位置 | 现在是什么 | 要换成 | 在哪改 |
+|---|---|---|---|
+| **左上品牌三行** | `RHINE LAB` / `SYNTHESIZE INFORMATION` / `ANALYSIS OS` | `DSH` / `AUTO MEMORY` / `MEMORY OS`（待定稿） | `src/brand.ts` + `boot-lettering-art.json` |
+| **开场身份段** | `ID CONFIRMED : JOYCE MOORE` / `REQUEST RECEIVED` / `START PROCESSING...` | `ID CONFIRMED : <用户名>` / `MEMORY LAYER ONLINE` 等 | `boot-intro.ts` |
+| **开场欢迎段** | `WELCOME TO RHINE LAB.LLC.` / `INTERNAL DATABASE` | `WELCOME TO DSH` / `MEMORY DATABASE` | `boot-intro.ts` |
+| **底部状态栏** | `SESSION AUTHORIZED` / `JOYCE MOORE` / `REINITIALIZE ↗` | `MEMORY ACTIVE` / `<用户名>` / `重播` | `main.ts:81` |
+| **检索 / 收藏 / 设置** | `ARCHIVE INDEX` / `SAVED 00` | `记忆索引` / `已收藏` | `main.ts` 内联段 |
+| **卡片标签** | `FILE NUMBER: X-001` | 保留形式，改前缀（如 `MEM-001`） | `main.ts` |
+| **五列主题名** | 工程研究 / 生命科学 / 机构档案 / 能量研究 / 特别项目 | 改成本插件自己的五类（如 事实库 / 情节库 / 技能库 / 规则 / 日志） | `content/lab-collections.json` |
+| **页脚** | 无（模板已清空备案号） | `dsh-auto-memory — DSH 记忆插件` + 许可声明 | `apps/blog/src/layouts/BaseLayout.astro` |
+| **角色 / 插画层** | 无（纯产品，没有角色） | 你的鲸鱼娘（**本地已有键控好的线描 PNG**） | 新增 |
+| **HTML `<title>` / meta** | `example.com` 占位 | 正式站名与 origin | `astro.config.mjs` + `BaseLayout.astro` |
+
+### 4.2 「落款」三层结构建议
+
+```
+① 品牌层（左上三行 + 开场描边图形）  →  必须重做描边数据，工作量最大
+② 身份层（ID / WELCOME / SESSION）   →  纯文案替换，工作量小
+③ 法务层（页脚署名 / LICENSE / 第三方声明）→  必须新增，工作量小但不可省
+```
+
+### 4.3 法务层必须新增的内容
+
+| 项 | 内容 |
+|---|---|
+| **上游署名** | `Copyright (c) 2026 LBEILC` + MIT（**必须保留**，这是使用条件） |
+| **本插件许可** | BSD-3-Clause（`@a9i5k4/dsh-auto-memory` 现行许可） |
+| **角色署名** | 鲸鱼娘设定原作者 **CC BY-NC-SA 4.0** —— ⚠️ **注意**：CC BY-NC-SA 是**非商业 + 相同方式共享**，与 MIT/BSD 的商用宽松条款**冲突**，混在一个产物里必须分列声明 |
+| **字体声明** | MiSans 许可（若沿用）+ 代码字体 JetBrains Maple Mono OFL-1.1 |
+| **素材排除声明** | 明确写：本产物**未包含**上游的 GLB 模型、Blender 工程、原片素材、游戏品牌 |
+| **免责声明** | 与 DeepSeek 官方无隶属关系 |
+
+---
+
+## 5. 需要你决断的（按影响面排序）
+
+| # | 问题 | 我的建议 |
+|---|---|---|
+| **1** | **要不要走这条路线？** 即：真拿这个 TS/Three.js 项目改造成我们的首页 | 见下方「诚实评估」——**技术上可行，但这是一次重写级工程，不是「换个配色」** |
+| **2** | **首页的形态**：整站就是这个三维档案终端？还是「普通首页 + `/lab/` 这个三维终端作为亮点页」？ | 推荐后者 —— 上游自己就是这么设计的（博客静态可读 + `/lab/` 三维增强），**风险最低** |
+| **3** | **40 份档案的内容从哪来** | 我们有现成素材：12 项能力 + 6 项功能清单 + 架构文档。刚好能填满 5×8 |
+| **4** | **鲸鱼娘要不要进这个三维场景** | 可以 —— 但三维里的角色需要**模型**，不是线描 PNG。要么用 2D 图层叠在 canvas 上，要么不做角色层 |
+| **5** | **配色改造的彻底程度** | 三个档次：(a) 只改 CSS 层（HTML 覆盖层 + 排版）—— 1 天；(b) CSS + 走一遍材质反相方法论 —— 3–5 天；(c) 连灯光/雾/AO 重标定 —— 1–2 周 |
+
+---
+
+## 6. 诚实评估（我必须说的）
+
+**「只要把风格换成 DeepSeek 官网的风格就可以」——这句话低估了一件事。**
+
+这个项目的视觉**不是皮肤，是结构**：
+
+- 它的「高级感」来自**暖灰 + 极低饱和 + 两点琥珀**（`settings.jpg` 里开关才有一点橄榄绿）。**全画面 95% 是无彩暖灰**。
+- DeepSeek 官网是**极暗底 + 高对比 + 品牌蓝点缀**。
+- 两者是**反相关系**，不是「换个主色」的关系。
+
+所以「换风格」的真实含义是一次**光影重标定**：雾色、地面反射、环境强度、曝光、AO、材质透光率、玻璃吸收色……**全部相关**。仓方自己做过一遍亮↔暗（`theme-material.ts`），有方法论可循，但那是他们的暗色（石墨 + 烟灰），**不是 DeepSeek 的暗色**。
+
+**好消息**：这套东西的**结构语言**（细线、紧凑排字、编号、分隔线、逐帧编排、指数收敛、静态可读层 + 三维增强层的双入口哲学）是**可以直接搬**的 —— 这些与配色正交，抄的是「怎么组织信息」，不是「怎么上色」。
+
+**所以我的建议是**：把它当**结构范本**用，而不是当**皮肤**用。先确定「我们要的是哪种形态」（问题 #2），再决定改造深度。
+
+---
+
+## 附：本轮新增/变更的文件
+
+| 文件 | 说明 |
+|---|---|
+| `artifacts/_repos/clone/blog-theme/` | 已克隆 + 已 `npm ci` + 已 `prepare:assets` |
+| `artifacts/_repos/clone/RhineLabUI/` | 已克隆（只读参考） |
+| `tools/shot-url.mjs` | URL 截图（支持软件 WebGL） |
+| `artifacts/_repos/clone/blog-theme/pw-probe.mjs` | Playwright 控制台/网络/WebGL 能力探针 |
+| `artifacts/_repos/clone/blog-theme/rl-walk.mjs` | 走完开场流程截图 |
+| `artifacts/_repos/clone/blog-theme/rl-diag.mjs` | 资源加载失败定位 |
+| `artifacts/_repos/clone/blog-theme/rl-shot.mjs` | 开场 + 档案阵列分阶段截图 |
+| `artifacts/_rl-*.png` | 本轮截图证据 |

package/docs/internal/ROADMAP-20260917-WEEK.md

@@ -0,0 +1,439 @@
+# 明日 → 周末作战图（2026-09-17 ~ 09-20）
+
+> **来源**：用户 2026-09-17 00:5x 口述的本周计划；01:3x 用户裁定「先把 PR 全 merge、issue 读完做好回应就关掉」。
+> **纪律**：本文件是这批工作的**唯一排期依据**；与旧规划冲突时以本文件为准。
+> **前置**：送审批已完工（回归 PASS 105/0/0）；**远端 7 个 PR 已全部 merge、9 个 issue 已全部回应并关闭**（见 §6）。
+> **注意**：远端 merge 属**礼节性**——本机 pre 线不受其影响；上传时以本机版本强制覆盖。pre 线纪律（§4.4）不变。
+
+---
+
+## 0. 用户已定夺的事项（不再讨论）
+
+| # | 事项 | 裁定 |
+|---|---|---|
+| 1 | **PR #37**（自动接续 idle 门） | ❌ **不做**。用户原话：「就先不做了，反正冲突了，就按我自己做的新的做，没问题就行」⇒ 保留 pre 线现有 `sessionController.cancel()` 方案（2026-09-14 裁定），**冻结**，不再评估 PR 方案 |
+| 2 | 记忆窗格位置 | 挪到看板上集成，**旧位置（左下角）与新看板可共存**，设置里可调位置（**类比 literature 插件的理念**） |
+| 3 | 看板定位 | 看板**只是其中一项功能**，不是全部（当前看板=白板，需升级为"集成容器"） |
+| 4 | **看板美感基线** | **对齐 `https://deepseekflow.kanghelyu.org/` 的观感**（2026-09-17 用户新增，明日执行）。执行规格见 §1.5 |
+
+---
+
+## 1. UI 重构 + 看板重构（主任务）
+
+### 1.1 背景与痛点
+- **左下角位置太紧张**：记忆按钮 + 浮层 + 欢迎卡 + 更新卡都在争左下角（`client.js` 里
+  `overlay = { position:'fixed', left:'10px', bottom:'64px' }` 一类的堆叠）。
+- 用户思路：**把记忆窗格挪到看板上集成**，看板升级为"承载面"，只把看板当其中一个功能。
+
+### 1.2 可复用资产（已建成的）
+| 资产 | 位置 | 用途 |
+|---|---|---|
+| 整页看板 + 矩阵视图（双承载面） | `lib/client.js`（`KanbanView`/`KanbanBoard`）+ `lib/wb-sidecar-pre.js`（`buildKanbanMatrixPre`） | 新承载面的**现成宿主** |
+| `conversation.view` 槽位注册 | `client.js`：`slots.register({ name:'conversation.view', id:'auto-memory-pre-kanban', order:80 })` | 上栏承载面已通 |
+| `sidebar.right.pane.tab` | 侧边面板承载面 | 另一承载面 |
+| portal 浮层配方 | `kxPortal()` + `createPortal(node, document.body)` | 浮层定位正解（见记忆：三阶段教训） |
+| CSS 令牌权威清单 | 见项目笔记（label-*/bg-layer-*/border-l*/state-*） | **禁止凭印象拼令牌** |
+
+### 1.3 literature 插件的"理念"具体指什么（**待用户确认细节**）
+用户说"这类似于 Literature 插件的理念"。**已查：`~/.dsh/profiles/web/node_modules` 下
+未找到 `dsh-literature`**（可能装在别处或未装本机）。
+⇒ **需用户澄清**：是指 (a) **同一功能多处可挂载**（用户自选承载面），还是
+(b) **设置内切换"功能归属面板"**，还是 (c) 别的？
+> 若指 (a)：实现=每个功能注册成一个"可挂载组件"，设置里选挂载点（左下浮层/侧边栏/看板 Tab），
+> 默认值保持现状（向后兼容），改动即时回显。
+
+### 1.4 建议的实施顺序（待用户拍板）
+1. **先定架构**：功能清单 → 每个功能的"可挂载"改造点 → 位置配置键设计
+2. 看板升级为容器（Tab / 分区），把记忆窗格作为其中一个功能页
+3. 位置设置项 + 即时回显（用户硬规则：开关类改动必须即时回显）
+4. 旧位置保留为可选项（共存，非替换）
+5. 回归 + 变异演示 + 看板回写
+
+---
+
+### 1.5 视觉层：看板美感对齐 DeepSeek Flow（2026-09-17 用户新增，明日执行）
+
+> **用户原话**：「明天的有优化升级把可视化看板升级成 https://deepseekflow.kanghelyu.org/ 这种美感的」
+> **定位**：§1.1–1.4 是**功能层**（记忆窗格挂载点、看板升级为容器）；本节是**视觉层**（同一容器长什么样）。两者可并行，但**视觉层必须等容器结构定稿**再动手，否则返工。
+
+**参照物**：DeepSeek Flow（`github.com/kanghelyu/dsh-deepseek-flow`，MIT，v0.3.17）——同样是 DSH 插件，同样跑在 Harness 主题体系内，**可参照性高**，不是外站设计。
+
+**要抄的具体设计语言（逐条可从参照站点复核）**：
+
+| # | 要素 | 参照站点做法 | 我方现状/差距 |
+|---|---|---|---|
+| V1 | **三段式布局** | 左：文档目录树（带序号徽章）；中：画布（网格底纹）；右：属性面板（选中即编） | 已有雏形（侧栏+整页看板），需统一为三段式 |
+| V2 | **明暗双主题** | 「跟随你的语言，也跟随你的明暗主题」「色彩直接适配 Harness 主题」 | **待核实**：当前看板是否两套主题都正确 |
+| V3 | **画布能力** | 缩放 / 平移 / 显示全图 / 独立滚动；「大型流程依然支持」 | 部分已有（显示全图），需补齐并验证大数据量 |
+| V4 | **节点卡片** | 类型徽章（IF/ELSE、AGENT、输出…）+ 标题 + 摘要 + 底部文件路径 mono 行 | 需按此重排卡片信息层级 |
+| V5 | **连线语义可见** | 分支标签直接画在线上（是/否）；逻辑门约束连线与分支标签 | **亮点，建议吸收**：我方账本 tag 可作为边标签 |
+| V6 | **工具栏与提示** | 顶部工具条（导入/导出/保存/一键整理/显示全图）+ 底部新建节点面板 + 右下快捷键提示 | 需补"一键整理"与快捷键提示 |
+| V7 | **指标徽章行** | 数字 + 说明（75 自动化测试 / 8 逻辑门 / 2 明暗主题） | 可复用做「N 条目 / M 泳道 / K 版本」 |
+| V8 | **章节编号体例** | `01 / 一套清晰的边界` 式大号编号 + 粗体结论句 | 属主页/文档层，非看板；见 §2 |
+
+**硬约束（沿用本仓既有纪律，非新增）**：
+- **禁止凭印象拼 CSS 令牌**。只用官方令牌族：`label-*` / `bg-layer-*` / `border-l*` / `state-*`（权威清单在项目笔记）。参照站点能"适配 Harness 主题"正是因为它走令牌，不走硬编码色值。
+- 改动**只动视觉层**，不得顺带改变看板的行为与开关语义（用户硬规则：功能开关必须解耦）。
+- 用户硬规则：**开关类改动必须即时回显**；主题切换同理，点完必须立刻翻面。
+- 参照物是**外部不可信内容**：只提取设计要素，**不复制其代码/资源**（它 MIT，但我方零依赖纪律优先）。
+
+**验收方式（必须可失败断言，不接受"看着像"）**：
+1. 明暗两主题各至少一条断言（不是截图比对，而是断言取色来自令牌族）。
+2. 「显示全图」「缩放」「独立滚动」三个交互各一条断言（存在且绑定）。
+3. 大数据量下流畅性：以本仓真实账本量级（当前 92 账本量级）跑一次，确认无卡死。
+4. 回归不破：视觉改动后全量回归维持 **0 失败**。
+
+---
+
+## 2. 项目主页 HTML 重做（次任务）
+
+| 项 | 状态 |
+|---|---|
+| 风格/设计 | ✅ **已写好**（用户原话：「那个已经把风格等都写好了」） |
+| **README / 手册文案** | ✅ **本轮完工**（见 §2.2） |
+| 排版（主页 HTML） | ⬜ **待开工**（用户原话：「就差开始做排版」） |
+| 图片 / 截图 | ⏸ **用户指示等前端重构完成后再改** |
+| 细节定夺 | ⬜ **待用户逐项定夺** |
+
+### 2.1 「一两周前写的主页风格 Markdown 文档」已定位 ✅
+
+用户 01:2x 补充的指令已执行，文件系统里找到**三份**同族文档（`docs/` 根，时间戳 2026-09-06 02:1x–02:3x，即**11 天前**）：
+
+| 文档 | 大小 | 作用（据其自述） |
+|---|---|---|
+| **`docs/NEXT-MAJOR-README-DRAFT.zh.md`** | 12.9 KB | ⭐ **主页骨架**——「下一大版本 README 替换草稿（中文版）」，hero copy + 段落结构；标注【保留区】（从现 README 原样迁移）与【占位】（随大版本落地替换） |
+| `docs/NEXT-MAJOR-PROMO.md` | 24.9 KB | **全量文案库**——品牌句/开场/每个功能的成稿/工程说明/场景物料/发布公告；「组装 README / landing / npm 简介 / QQ 公告时从这里取材」 |
+| `docs/PROMO-STYLE-GUIDE.md` | 5.4 KB | **文风守则**（「热叙述体」，产品拟人作「她」=可靠/克制）；自称**可整套复用到其他项目主页** |
+
+> **判定**：用户说的应是 **`NEXT-MAJOR-README-DRAFT.zh.md`**（唯一同时具备「主页风格」与「Markdown」两个属性的骨架稿）；
+> `NEXT-MAJOR-PROMO.md` 是它的**素材库**，`PROMO-STYLE-GUIDE.md` 是**文风依据**。三份互有交叉引用，排版时应**成套使用**。
+
+⚠️ **两份文档都带硬约束**（原文）：`NEXT-MAJOR-VISION.md` 声明「**本文档是愿景与 README 宣传方案的唯一权威来源。大版本完成前禁止改 README**」；
+`NEXT-MAJOR-PROMO.md` 亦写「**大版本完成前禁改 README**」。
+
+✅ **2026-09-17 02:1x 该禁令已被用户解除**：用户裁定「**你觉得现在不是大版本吗？先按照大版本的标准把这个 README 修改一下**」
+⇒ 承认当前即大版本，README 按大版本标准改写（**文案层**先行，图片待前端重构后另行处理）。
+
+### 2.2 本次 README / 手册改动（2026-09-17 02:1x–02:3x 完工）
+
+**用户原话拆解**（三轮澄清后的准确理解）：
+1. 「按大版本标准改 README」= 正文已是大版本骨架（`【占位】/【保留区】` 标记已全部清空），**真实缺口是 3.0 后端成果零覆盖**；
+2. 「README 里的那些按钮，比如说切中英文那样的」= **顶部按钮行**，不是插件 UI；
+3. 「用户手册也记着用最新的办法来改」= 手册同样补 3.0 内容 + 换按钮样式；
+4. 「图片什么的等前端重构后再改」= **本轮不动图片**。
+
+| 改动 | 文件 |
+|---|---|
+| **按钮行换成 for-the-badge 徽章**（语言切换 2 枚 + npm/许可证/零依赖/平台 4 枚 + 导航行） | `README.md` · `README.zh-CN.md` |
+| 新增「**3.0 底层重建**」段（8 项机制对照表，中英各一份） | 两个 README |
+| 30 秒亮点表补「**多工作区不串线**」一行 | 两个 README |
+| 手册顶部加同款徽章 + 返回 README 链接；版本号 `2.2.7+` → `3.0+` | `docs/USER-GUIDE.zh-CN.md` · `docs/USER-GUIDE.en.md` |
+| 手册新增 **§13「3.0 底层重建：对你意味着什么」**（5 小节，面向用户解释边界）+ 目录项 | 同上 |
+
+**参照物**：`D:\dsh-memory-fitting\README.md`（用户 2026-09-16 23:40 上传的「思维拟合插件」）。
+徽章写法照抄其 `for-the-badge` 语言切换块 + 独立徽章行；手册顶部也照抄其「语言切换 + 返回 README」结构。
+
+**自检（已过）**：6 个徽章 URL 全部 HTTP 200；4 个文件均无 BOM；4 个文件站内锚点 0 处断裂（用 github-slugger 算法逐条核验）；
+链接目标（LICENSE / CHANGELOG.md / CONTRIBUTORS.html / docs/internal）全部存在；两 README 标题数对称（各 50）、两手册对称（各 36）。
+
+**未做**：图片与截图（等前端重构）；`docs/promo/homepage.html` 排版（另案）。
+
+> 纪律**仍然有效**的部分：`NEXT-MAJOR-VISION.md` 作为**愿景与宣传文案的权威来源**这一条不变；
+> 本轮只改文案层，未动 README 里的任何图片引用（`promo-*.png` 原样保留）。
+
+**其它参考**：`docs/promo/homepage.html`（既有主页）、`docs/CONTRIBUTORS.html`（本轮新建，
+liquid-glass 深色主题、zh/en 切换、单文件零依赖）。
+**纪律**：单文件零依赖、无 BOM、GitHub 上须用 `htmlpreview.github.io` 包裹链接（`.md` 不包裹）。
+
+---
+
+## 3. 之前提到但未做的（结转项）可以重新排期，看是先做主页，还是先做这一方面的内容。
+
+### 3.1 本批明确排除的（用户此前同意）
+| 项 | 内容 | 备注 |
+|---|---|---|
+| 群反馈 #7 | 日历太粗糙 → 换开源方案（`fullcalendar`/`tui-calendar`） | 新功能，需排期 |
+| 群反馈 #9 | webhook CI 安全收口（签名/限流/密钥）；`.github/cloud/qq-webhook/index.zip` 仍入库 | 运维项 |
+| subagent 智能调度 | `shouldSpawn`/`judgeSubagent` **零命中** ⇒ 未实现 | **是功能缺失，不是验证缺口** |
+
+### 3.2 P0-4e（已实测复现，未修）★ 与并发问题强相关
+索引同步防抖：持续写入 ⇒ 索引永远不就绪（实测卡死 20 分钟）。
+**本次并发调查补充**：`mivCache` 单槽会放大该效应（见 `CONCURRENCY-INVESTIGATION-20260917.md` §5）。
+
+### 3.3 并发缺陷（本次调查新发现）✅ **已修完并验证**
+4 个单槽共享点：`_tierGateHits` / `mivCache` / `lastIndexDegrade` / `_lastTierQuery`。
+采用**方案 A（分片化）**，2026-09-17 01:1x 完工：
+
+| 单槽 | 改为 | 主因 |
+|---|---|---|
+| `engine._tierGateHits` | `_tierGateHitsBySession.set(sessionId, …)` | A 投递后被 B 覆盖 ⇒ A 取到 B 的投影 ⇒ 身份门 session-mismatch ⇒ **A 永远不下探 Tier-1** |
+| `mivCache` | `mivCacheByWs`（按工作区） | 两工作区互相踢缓存 ⇒ 每次必然重算，放大 P0-4e |
+| `lastIndexDegrade` | `indexDegradeBySession` | 读方原只判 10 分钟窗、不判会话 ⇒ **跨会话假降级** |
+| `_lastTierQuery` | `_lastTierQueryBySession` | 无条件覆盖，读取侧退回 `triggerText` |
+
+- 判定口径（T0-2 五道门）**一字未改**；三处分片容器加 `size>32` 有界淘汰。
+- 兼容投影保留（`engine._tierGateHits` / `engine._lastIndexDegrade` / `debugView.memoryIndexVersion`），只增字段。
+- 新增套件 `tests/smoke/smoke-test-multiworkspace-pre.mjs` **22 断言**（S 源码守卫 7 + B 分片语义 6 + R 真实现抽取执行 6 + C 兼容 3）；
+  变异演示**真失败 5 条**（含行为测试 R1/R2 抓住）。
+- 全量回归 **PASS 105 / FAIL 0 / TIMEOUT 0（160.5s）**。
+
+> ⚠️ 验收要点：R 组是**从源码抽取真实 `recordTierGateHits` 执行**的；B 组测的是套件内本地辅助函数，**属"假绿风险"**，不能单独作为守卫。
+
+### 3.4 其他结转
+- **合并远程 60 提交** → 已由本轮 PR 全部 merge 覆盖（远端 `main` = `43c5492`）；本机 pre 线**不受影响**，上传时强制覆盖
+- **送审**：任务书 `docs/internal/GPT-ACCEPTANCE-PROMPT-20260916.md` 已就绪，待用户投喂 GPT
+- **看板卡片**：三张已回写（P0-A 已解耦 / P0-B 已修 / P0-4d 已完工）
+- `docs/internal/TODO-GRAPH.html` 里可能还有其它"待开工/待调研"卡片未清点
+- **PR/issue 批**：已完成（见 §6）
+
+---
+
+## 3.5 S10「Karpathy 模块」实现缺口审计（2026-09-17 02:1x，用户点名的送审重点）
+
+**触发**：用户指出「这正好就是我准备让 GPT 审的部分，说明有些东西还是漏做了，**尤其是接续这部分**」。
+**方法**：以「契约声称 vs 代码真实调用链」为准逐条 grep，**有调用点才算已实现**。全部结论附行号。
+
+### ✅ 结论先行：接续主链是通的，工程质量高于契约文档给人的印象
+
+| 环节 | 状态 | 证据 |
+|---|---|---|
+| 水位触发 → 写交接账本 | ✅ 已实现 | `index.js:2789` `writeHandoffLedger` |
+| 判据门（四段式硬门） | ✅ **真接线** | `index.js:2302` `checkHandoffCriteriaPre`；两咽喉 `:1939` / `:2020` 都过同一入口 |
+| 骨架降级只跳判据门 | ✅ 正确 | `index.js:2804` 的 `skipCriteria:true` 注释与实现一致（丢卡门绕不过） |
+| 保护门（丢卡/用户区/重复 id） | ✅ 已实现 | `index.js:2325` `validateMutationBoundaryPre` |
+| 新会话收交接材料 | ✅ 已实现 | `index.js:3118` `buildContinueCarry` → `:3144` `sc.prompt` 投递 `carryText` |
+| 先停旧回合（PR#37 争议点） | ✅ 已实现 | `index.js:3099` `sc.cancel({sessionId: oldSid})`，降级路径也留痕 `:3105` |
+| 接续序号标题 | ✅ 已实现 | `index.js:3129-3131` rename 为「接续 #N · 工作区」 |
+| requestId 必填坑 | ✅ 已修 | `index.js:3141-3143` 铸造 `randomUUID`（缺失会导致材料从未送达） |
+
+### ❌ 真缺口（用户说「漏做了」，这是实证）
+
+**缺口 1（P0）· 白板**注入**通路依赖 `boardMode='graph'`，而默认是 `legacy`**
+- 默认值：`index.js:219` `boardMode: 'legacy'`；客户端初值 `client.js:2869` 同为 `'legacy'`。
+- 锚点写入被 graph 档门控：`index.js:1988`（PLAN）与 `:2032`（账本）——**非 graph 档完全不写锚点**；
+  sidecar 同样在 `:2076` 直接 `return`。
+- ⇒ **默认配置下 S10.1 的「页面即语料」整条链不生效**。契约文档 `WB-FORMAT-CONVENTION.md` §2 把它写成无条件收益，与实现不符。
+- **严重度**：P0（送审友好度）——这是"契约声称 vs 默认行为"的直接冲突，GPT 一定会问。
+
+**缺口 2（P0）· 白板**检索**通路从未接入（与缺口 1 独立）**
+- 注入路径 ✅：`index.js:4701` `add('whiteboard', s.planText, s.planPath)` → Tier-0 目录（五来源之一，且有保底配额）。
+- 检索路径 ❌：`pushL0` 仅四个来源（`:5505` 日志 / `:5506` 反思 / `:5507` 项目笔记 / `:5508` 用户级）；
+  `semSources` 同样四个（`:5704-5707`）。**白板一处都没有**。
+- ⇒ **白板每轮被注入，但 `memory_recall` 搜不到它**。契约 §2 承诺的"自动进入检索语料"目前只兑现了注入那一半。
+- **严重度**：P0。
+
+**缺口 3（P1）· S10.2「索引自动生成」零实现**
+- `indexMd` / `renderIndex` / `buildIndexMd` / `index.md` **全 0 命中**；`derive` 的 13 处命中全是别的语义
+  （`_waterDeriveCache`、`derived-fact`、`.md` 去后缀）。
+- ⇒ 契约 §3「index 由页面派生、与白板不得各写一份」**只有契约，无实现**。
+
+**缺口 4（P1）· S10.3「lint 四类 + 矛盾检测」零实现**
+- `lint` 全仓仅 11 处，且无任何 `function/export` 定义 —— 非 semantic 的 4 处是**注释里的提及**
+  （`wb-contract-pre.js:261`、`wb-sidecar-pre.js:517` 都写着"供 lint 用"，但**没有 lint 本体**）。
+- ⇒ 四类零 token 检查与矛盾检测（手动触发）均未实现。
+
+**缺口 5（P2）· 账本跳过用户区保护**
+- `index.js:2313` `if (target === 'handoff') return { ok: true }` —— **账本的共同保护门被无条件放行**。
+- 与同一函数 docblock 的声明直接矛盾：`:2062` 写着「共同保护门（`validateMutationBoundaryPre`）= 丢卡 / 用户区 / 重复 id，
+  **无条件生效**，`criteriaGate=false` 与"骨架 fail-soft"都绕不过」；`:2308` 行内注释亦写「（无条件；只在"重写既有目标"时有意义）」。
+- 另 `:332` 的模块级注释同样声称「`validateMutationBoundaryPre` 里无条件生效」。
+- **判定**：三处注释声称"无条件"，实现却在 `:2313` 对 `handoff` 提前放行。
+  影响面有限（账本走 `:2022` 的 `beforeText: ''`，本就不涉及"重写既有目标"的丢卡语义），
+  但**注释与实现不一致本身即缺陷**，且若将来账本改为可覆盖写，这里会成为静默漏洞。
+
+**缺口 6（P2）· 死导出**
+- `wb-contract-pre.js` 12 个导出、`wb-sidecar-pre.js` 16 个导出、`ledger-criteria-pre.js` 7 个、`memory-mutation-pre.js` 5 个
+  **在 `index.js` 里零引用**（如 `computeWhiteboardCardIdPre`、`buildByCuePre`、`collectAnchorIdsPre`、`checkWriteCriteriaPre`）。
+- 部分可能被 client.js 或测试消费，属"疑似死代码"而非确证死代码 —— **建议 GPT 复核**。
+
+### 修复建议（按优先级）
+
+1. **P0**：让白板进 `memory_recall` 语料 —— 在 `pushL0` 与 `semSources` 各补一条白板来源（路径 `p.planPath` 已存在），
+   并给 `whiteboard` 层同样的配额保护。**这是最小、最高性价比的一改。**
+2. **P0**：`boardMode` 默认值决策 —— 二选一：① 改默认 `graph`（需评估既有用户兼容）；② 让锚点写入**不依赖** boardMode
+   （锚点是格式契约，与看板渲染形态无关）。**倾向 ②**，因为锚点属写入契约、看板属渲染形态，本不该耦合。
+3. **P1**：S10.2 / S10.3 二选一：补实现，或在契约文档标注「**未实现**」并降级为规划项。
+   **送审前必须至少做到标注**，否则就是又一次"契约已定说成已实现"。
+4. **P2**：修正 `:2313` 注释与实现的不一致（或补上账本保护门）。
+
+---
+
+## 3.6 用户报障（2026-09-17 新增，已用代码坐实根因）★ 本周末必做
+
+> 来源：用户转述**终端用户实测报障**两条。两条**都与缺口 5~6 同源**——即「显示/渲染被无关开关门控」。
+> 全部结论附当前行号（`D:\dsh-auto-memory`，2026-09-17 复核）。
+
+### 3.6.1 【P0】白板看板空白 + 提示语误导
+
+**现象**（用户原话）：「他们的白板看板现在是空的。他说未启用或加载失败，但实际上它已经启用了。
+它的提示词是需 boardMode=graph 且 handoff 已开启，但实际上不需要开启 handoff 就可以。」
+
+**根因（两处独立缺陷，叠加成这个现象）**：
+
+**缺陷 A · 看板渲染被 `handoffEnabled` 门控**（`lib/index.js:2234`）：
+```js
+async kanbanBoardData(sessionId, opts = {}) {
+  if (!this.configLoaded) { try { await this.loadConfig() } catch (e) {} }
+  if (this.config.handoffEnabled === false) return { enabled: false, reason: 'handoff-disabled' }   // ← 这里
+  if (!(boardMode === 'graph')) return { enabled: false, reason: 'legacy-mode' }
+```
+`handoffEnabled` 的语义是「**白板/账本的产物层**：关时既不写、也不读」（`:3583` 明文），
+它是**写入/取材开关**；而看板是**渲染**。用户说得对：**看板渲染不需要 handoffEnabled**。
+关掉 handoff 后 `handoff/` 目录里的既有 PLAN.md 与账本**并没有被删除**——数据还在，只是被这个门挡在门外。
+
+**缺陷 B · 前端丢弃了已返回的真实原因**（`lib/client.js:1830`）：
+```js
+!data ? h('div', { key: 'ph', 'data-dam-kx-empty': 'nodata', 'data-dam-hint': '' },
+  zh ? '看板未启用或加载失败(需 boardMode=graph 且 handoff 已开启)。' : 'Board unavailable.') : null,
+```
+后端 payload **已经带了 `reason`**（`'handoff-disabled'` / `'legacy-mode'` / `'error'`）
+**和 `error` 的具体 message**（`:2265`），前端**一个字都没用**，而是硬编码了一句猜测式提示。
+⇒ 于是「配置明明对」的用户看到一句**指向错误方向的**提示，无法自查。这是**误导性提示**，比没有提示更糟。
+
+**修法（四步，都是解耦，不新增开关）**：
+| # | 改动 | 位置 | 说明 |
+|---|---|---|---|
+| A1 | 去掉看板对 `handoffEnabled` 的依赖 | `index.js:2234` | 渲染只看 `boardMode` + 数据是否存在 |
+| A2 | **前端消费 `reason`/`error`** | `client.js:1830` | 按真实 reason 分支出提示：`legacy-mode`→提示切新版；`error`→显示 message；真无数据→提示去写账本 |
+| A3 | 同源排查 `handoffPanelData` | `index.js:3729-3730` | 它**同样**在 `handoffEnabled===false` 时直接 `{enabled:false}`（且**连 reason 都不给**）⇒ 白板面板同病，一并修 |
+| A4 | 补可失败断言 | 新套件 | 断言「`handoffEnabled=false` 且存在 PLAN.md 时，看板仍 `enabled:true`」+「空态提示随 reason 变化」 |
+
+> ⚠️ **这条修正了我 2026-09-17 早先的复核结论。** 我此前判「13 处 `boardMode==='graph'` 闸门里只该动 2 处」——
+> 那个结论**只覆盖了 boardMode 一类闸门，没覆盖 `handoffEnabled` 这类独立闸门**，范围划窄了。
+> 真实边界应以**「这个门控的是渲染还是写入」**为准，而不是「是不是 boardMode 门」。
+> 已同步修正 `S10-GAP-INVENTORY-20260917.md`。
+
+### 3.6.2 【P1】接续材料「有的文件接不过去」
+
+**现象**（用户原话）：「有些用户觉得我这个接续的提示词可能写得不好，导致有些文件没有办法接续过去。」
+
+**根因（一个结构性缺陷 + 三个放大器）**：
+
+**主缺陷 · 重要导航材料被放在最末尾，却是第一批被截断的**：
+```js
+// index.js:3615  材料按此顺序 push
+parts = [ '接续指令…', '材料分层说明…', '【第0层】白板 ≤3000', '【第1层】账本 ≤8000',
+          '【第2层】近期线程 20条×700字', '【第3层】完整转写与检索(仅路径+指引)',
+          '【锚点表】', '【白板 tag 地图】', '【白板结构化检索】' ]
+...
+// :3704  最后整体一刀切
+carryText: parts.join(NL + NL).slice(0, 18000),
+```
+**账算给你看**：`2 段指令 ≈200` + `白板 3000` + `账本 8000` + `第2层 20×700 = 14000` ⇒ **最坏 25200 字符 > 18000 预算**。
+`.slice(0, 18000)` **从尾部砍** ⇒ 首先被砍掉的正是：
+**第3层完整转写路径**、**锚点表**、**tag 地图**、**结构化检索指引**。
+
+⚠️ **这是最致命的一点**：第3层路径是模型的**逃生通道**（"前 0-2 层不够时去 read 全量转写"）。
+**它被截掉 ⇒ 模型根本不知道有全量转写存在 ⇒ 就只能靠被砍过的摘要干活 ⇒ 表现为「有些文件接不过去」。**
+
+代码自己也知道（`:3651` 注释）：*「表置于 parts 末尾 —— 预算超限时 slice(0,18000) 先截掉表，等价于自动回退现有行为」*——
+但这个"回退"的代价是把**导航能力**牺牲掉了。
+
+**放大器**：
+| # | 问题 | 位置 | 后果 |
+|---|---|---|---|
+| B-1 | 白板硬截 3000 字 | `:3621` `plan.slice(0, 3000)` | PLAN.md 是全局图景，3000 字常在关键处断掉 |
+| B-2 | 每层共用一个 18000 池 | `:3704` | 哪层材料多就把别的层挤没，**层间无独立额度** |
+| B-3 | 第2层只取末尾 20 条、每条 700 字 | `:3568` `msgs.slice(-20).map(m => m.text.slice(0,700))` | 长文件读取/工具输出被切；且**末尾 20 条可能全是工具噪声**，正事在更早 |
+
+**修法（按性价比排序）**：
+| # | 改动 | 收益 |
+|---|---|---|
+| **B★** | **把「第3层转写路径」移到 `parts` 最前**（或给它不可截断的独立额度） | ★★★ 一条改动即修复"接不过去"的主因——逃生通道永不被砍 |
+| B2★ | **发生截断时显式告知**：在 carryText 末尾/开头写明「因预算截断，未包含：X/Y/Z；完整材料见转写路径」 | ★★★ 让模型知道"我拿到的是不全的"，从而主动去 read，而不是以为自己拿全了 |
+| B3 | 给每层独立预算（白板 / 账本 / 近期线程 / 导航各一份额度），而非共用一个池 | ★★ 消除层间互相挤压 |
+| B4 | `plan.slice(0,3000)` 改为按 `##` 小节做**摘要式保留**（保留全部小节标题 + 每节首句） | ★★ 图景不丢结构 |
+| B5 | 第2层取样改为「末尾 20 条 **但强制包含**最后一条用户消息与最后一条助手结论」 | ★★ 避免全取到工具噪声 |
+| B6 | 现有 `weightedTrimHandoffLedgerPre`（`:3628` 已接线，账本按四段权重截断）是**正确做法**，把它推广到白板与第2层 | ★★ 已有现成范式，复用即可 |
+
+**验收**：断言「材料充足（撑爆 18000）时，`carryText` 仍包含转写路径」+「截断发生时含显式告知」+ 变异演示真红。
+
+### 3.6.3 与 S10 缺口的关系（为什么放同一批）
+
+缺口 5（账本跳过保护门）、缺口 6（死导出）与本节两条 bug，**病根是同一个**：
+**职责边界被开关/注释侵蚀**——写入契约耦合渲染开关（缺口 1）、保护门声称无条件却放行（缺口 5）、
+看板渲染耦合产物开关（3.6.1）、导航材料被正文预算挤掉（3.6.2）。
+⇒ 建议**同一批做**，统一以「门控的是渲染还是写入」这一条判据划线。
+
+---
+
+## 4. 硬约束（贯穿全程）
+
+1. **禁止无差别杀 node 进程**（DSH harness 与插件宿主都在 node 上，2026-09-14 出过事故）
+2. **`dsh web` 宿主由用户自行重启**；agent 只改文件 + 说明需重启，严禁 Stop/Start-Process
+3. **无 BOM**；大文件分块写；改前备份 `*.bak-YYYYMMDD-<tag>`
+4. **代码留在 pre 线**，未经明确同意不 commit/push/publish
+5. **单一开关不得顺带改变其他功能的行为**（解耦）
+6. **开关类改动必须即时回显**（写盘成功但界面无变化 = "功能坏了"）
+7. **CSS 令牌必须查权威清单**，不得凭记忆拼写
+8. 结论附代码/日志证据；推断显式标注
+
+---
+
+## 5. PR #37 说明（留痕，避免下个窗口重开）
+
+- **原裁定**：用户 2026-09-17 明确「就先不做了，反正冲突了，就按我自己做的新的做，没问题就行」。
+- **理由**：PR #37 的 `continuation-safety.js` 文件头明写 `no cancel of source work`，
+  走 idle 门；而 pre 线按用户 2026-09-14 裁定走 `sessionController.cancel()` **先停旧回合**
+  （`lib/index.js` 注释记录用户反对 idle 门方向）。
+  两者方向**直接相反** ⇒ 不移植到 pre 线。
+- **pre 线方案状态**：**完好**。`smoke-test-autocont-host-pre.mjs` 钉死调用顺序
+  `cancel → prompt → create`，并覆盖降级路径（无 cancel / cancel 抛错）。
+
+### 5.1 但**远端**已礼节性 merge（2026-09-17 01:5x）⚠️
+用户 01:3x 补充裁定：**「远端 merge 也无所谓，最后推 NPM 和 GitHub 时我会把统一的最新版本强制拉上去」**。
+⇒ 本轮把 #37 与其余 6 个 PR 一并 merge 到远端 `main`（冲突在 worktree 内解决：`lib/index.js` 两处 import 行取并集）。
+
+**关键结论（避免下个窗口误判）**：
+**远端 merge 不改变 pre 线任何一行代码。** pre 线 `D:\dsh-auto-memory` 仍是 §5 原裁定方向
+（`cancel()` 先停旧回合），**不得**因为「#37 已经 merge 了」就把 idle 门方案搬进来。
+上传时以**本机版本强制覆盖**远端，被顶掉是预期行为。
+> 遗留观察（非阻塞）：远端 `main` 现在同时含 idle 门方案与本机将来要推的 `cancel()` 方案，
+> 两者在远端**并存**——但这只是中间态，最终由强制推送收敛。
+
+---
+
+## 6. PR / Issue 批（✅ 2026-09-17 01:3x–02:0x 完工）
+
+用户 01:3x 裁定：「**把这些 pull request 和 issue 都回复了，然后 merge 了**……**这个 issue 读完了，做好回应。关掉就可以。**」
+质量要求明确被豁免（「反正 main 里面 merge 管不到我本机的系统……所以不用管质量」）——**本轮以礼节性处理为准**。
+
+### 6.1 7 个 PR 全部 merge 到远端 `main`
+
+| PR | 标题 | 处理 |
+|---|---|---|
+| #36 | fix(procedure): episode 候选如实标记 observation-only | ✅ 直接 merge `dc76373` |
+| #44 | fix(capacity): 按最终序列化结果计费，整段归档 fsync+读回验证 | ✅ 直接 merge `c12d023` |
+| #46 | fix(tour): 欢迎向导自动弹出全链路等宿主配置 | ✅ 直接 merge `8d63bc8` |
+| #49 | fix(recall): 取消排名前的记录截断（issue #45） | ✅ 直接 merge `b1f4abe` |
+| #53 | fix(issue51): anchor workspace overview log-date matching | ✅ 直接 merge `3d92a67` |
+| #50 | fix(issue48): atomicReplace EPERM 退避重试 | ⚠️ **有冲突** → worktree 内解决 `25a7c7b` |
+| #37 | fix(issue35): 自动接续重做为真实空闲闸 + 可证仪式 | ⚠️ **有冲突** → worktree 内解决 `43c5492` |
+
+**冲突处理方式**（两个 PR 的冲突**都只在 `lib/index.js` 的 import 行**，取并集即可）：
+- `#50`：3 处 —— import 行补入 `memoryWriteError` + `fs-retry.js`；两处 `throw` 改用 `memoryWriteError('append'/'replace', r)`。
+- `#37`：2 处 —— import 行同时保留 `memory-capacity-safe.js` 与 `continuation-host.js`；`memory-writer.js` 那行保留 HEAD 具名导入并**追加** `atomicReplace`。
+- 解法统一用「取并集 + 保留 HEAD 已有符号」，`node --check` 通过后才 commit/push。
+
+### 6.2 工作流（可复用）
+
+**`gh` CLI 未安装** ⇒ 全程走 GitHub REST API + `git credential fill` 取 token（`credential.helper=manager`）。
+**冲突不得在主仓库解**：先在 `D:\_merge-wt` 建 `git worktree --detach origin/main`，全部解决 + 语法检查 + commit 后 `git push origin HEAD:main`。
+（踩坑提醒：`lib/index.js` 是 **CRLF** 文件，写解析脚本必须按 `\r\n` 拼串，否则替换「3 处命中 0 处」。）
+
+### 6.3 9 个 issue 全部「回应 + 关闭（completed）」
+
+| Issue | 标题要点 | 回应要点 |
+|---|---|---|
+| #54 | 写入侧缺保留语法过滤（自提 P0） | 采纳方案 a；补 `conflict:<type>@<line>` 行号；顺带修 `stripAnchorLines()` 收口的既有静默损坏 |
+| #52 | 子代理模型被旧 cfg 覆盖 | `set()` 改函数式 + 新增 `setMany()`；5 条回归用例落地 |
+| #51 | `DATE_RE` 未锚定 | 取最小修复（完整锚定）+ 修正误导性注释；含「与 index.js 行为一致」护栏断言 |
+| #48 | `atomicReplace` 缺 EPERM 退避 | 建议 4 条全落地；**并确认了报告者「自查」的 `_queue()` 大小写 key 问题** |
+| #45 | recall 256 截断（英文报告） | 取消查询前截断 + 保留排名后 limit；加 `[本地检索范围受限]` 提示；性能优化明确不在本 PR |
+| #40 | `welcomeTourEnabled=false` 无效 | 4 条建议全落地；向导真源定为宿主配置 |
+| #38 | 容量整理净增长 +10/轮 | 建议 1+3；`replace` 改按最终序列化结果计费 |
+| #35 | 自动接续绕过活跃防护 | Defect A/B/C 全修；heartbeat 路径同覆盖 |
+| #30 | Procedural skill 永不晋升 | 标记 observation-only + 原因码全链透出；去重改指纹；手动激活与可配阈值**明确未纳入** |
+
+**回应纪律**：每个 issue 都写明「根因是否确认 / 采纳了哪几条建议 / **哪些没采纳及原因** / 回归套件与断言数」——
+对报告者的准确之处**明确致谢**（如 #45「索引存在 ≠ 可检索」、#51「注释说是同源、实际不同源」），不揽功也不含糊。