@furongjun1999/dsh-memory 0.4.11 → 0.5.0

package/docs//345/217/221/345/270/203/344/273/266/345/233/236/346/272/257/350/257/264/346/230/216_v0.1.md

@@ -1,82 +1,82 @@
-# 发布件回溯说明 v0.1
-
-> **一句话**：`@furongjun1999/dsh-memory` 的 **0.4.9 / 0.4.10** 两个已发布 tarball 夹带了
-> 非追踪件（实验工作区 + 白箱 KB 运行时数据 + 认知图孤节点 + 字节码缓存），合计约
-> **4009 件 / 28 MB**。该缺陷已由 `cee729a` 收口，**0.4.11 发布件为 1306 件**
-> （本地门禁实测）；已发布版本按「不回溯」处置（§5）。
-
----
-
-## 1 事实
-
-| 版本 | 发布件数 | `docs/experiments` | 白箱 KB 运行时 | 孤节点 | `__pycache__` | 体积 |
-|---|---|---|---|---|---|---|
-| 0.4.9 | 4008 | 2434 | 474 | 6 | 1 | ~28.0 MB |
-| 0.4.10 | 4009 | 2434 | 474 | 6 | 1 | ~28.0 MB |
-| **0.4.11（收口后）** | **1306** | 0 | 0 | 0 | 0 | — |
-
-**复算方式**：0.4.9 / 0.4.10 两行的件数与体积由第三方从 npm 镜像独立下载 tarball 后逐件
-分类（**不调用本仓任何脚本**），结论与 `publish-artifact-check` workflow 头部的自述
-**逐项一致**——即本缺陷属**如实披露**，非隐瞒。
-
-**0.4.11 一行的口径**：为**本地门禁实测**（`npm pack --dry-run` 清单 1306 件、
-非追踪件 0）。第三方报告在其基线 `1087ae4` 上测得 1302 件——该基线尚未包含后续提交的
-增量件，加之统计口径差异，故与本行不逐位相等；**此处以实测为准，不沿用引用值**。
-
-## 2 根因
-
-`package.json` 的 `files` 白名单包含 `md_cg` 与 `docs` 两个**目录**，而 npm 在存在
-`files` 白名单时**整体忽略根级 `.npmignore`**——只有「白名单目录自身的 `.npmignore`」
-才生效。于是白名单目录内、被 `.gitignore` 排除的运行时产物（实验脚本 / `result_*.json` /
-`_store` 数据目录 / 白箱 KB 的库与索引 / 认知图孤节点 / 字节码缓存）随包分发。
-
-**为什么本地自检没拦下**：门禁脚本的历史版本只校验「发布件清单 vs git 追踪件」的
-一致性，而这些目录属 `.gitignore` 忽略的**本地数据面**——它们在「非追踪件」判定里
-出现过，但当时未按严重度阻断发布。
-
-## 3 收口（`cee729a`，2026-09-20）
-
-改用**子目录级 `.npmignore`**：`docs/.npmignore` + `md_cg/.npmignore` +
-`skills/.npmignore`（共 54 行），覆盖三类：
-
-1. **认知图运行时状态**：`_keys.json` / `_keys.*.json` / `*_audit.jsonl` /
-   `_access.log` / `_index.json` / `_index.json.lock` / `_index_log/` / `_refindex.json`
-   —— 与 `_keys.json` 同级别的凭据信封与审计留痕，**绝不入包**；
-2. **Python 字节码缓存**：`__pycache__/` / `*.pyc` / `*.pyo` / `*.pyd`；
-3. **实验工作区与含沙箱绝对路径的文档**：`docs/experiments/`（可重跑再生产物）等。
-
-`md_cg/.npmignore` 同时排除白箱 KB 运行时数据与本地记忆面；`skills/.npmignore`
-排除纪律模板的中间产物。
-
-## 4 门槛（防复发）
-
-- `scripts/check_publish_artifact.py`：跑 `npm pack --dry-run --json` → 按规则分类 →
-  非追踪件白名单审阅 → `VERDICT=PASS / FAIL`；`--selftest` 覆盖清单解析健壮性与判据自身
-  （含 `prepare` 文本污染 stdout 的场景、数组与对象两形态）。
-- `.github/workflows/publish-artifact-check.yml`：本地模式 + registry 后置核验两种口径。
-- 判据形态：**红着即拦下一次发布**（0.4.11 门禁实测：清单 1306 件、非追踪件 24 = 允许
-  上限 24，`VERDICT=PASS`）。
-
-## 5 处置裁定：已发布版本不回溯
-
-- npm **不允许覆盖同版本号**，撤回（unpublish）会打断已安装用户的依赖解析——代价大于收益；
-- 已发布件不含凭据（`_keys.json` 从未入包，此项经第三方逐件复算确认）；
-- 措施落在「拦下一次」，并对本事实在此**留痕**，供使用者与审计者追溯。
-
-## 6 `files` 白名单与排除规则的一致性复核
-
-| 白名单条目 | 排除机制 | 复核结论 |
-|---|---|---|
-| `md_cg` | 子目录级 `.npmignore`（§3） | 运行时状态与本地记忆面已排除 |
-| `skills` | 子目录级 `.npmignore` | 中间产物已排除 |
-| `docs` | 子目录级 `.npmignore` | 实验区与含沙箱路径文档已排除 |
-| `lib` | 构建产物（`files` 白名单内，无运行时数据） | 无非追踪件 |
-| `src` | 源码（无运行时数据） | 无非追踪件 |
-| `dsh` / `codebuddy` / `zcode` | 接入模板与纪律产物 | 无非追踪件 |
-| `README.md` | 单文件 | — |
-
-复核以门禁脚本本地模式逐件判定为准：0.4.11 发布前 `VERDICT=PASS`（非追踪件 0）。
-
----
-
-生成：2026-09-20 · 依据：第三方独立验证报告（v15 §5.4）+ 本仓门禁复算 · 维护：随发布件口径变更同步
+# 发布件回溯说明 v0.1
+
+> **一句话**：`@furongjun1999/dsh-memory` 的 **0.4.9 / 0.4.10** 两个已发布 tarball 夹带了
+> 非追踪件（实验工作区 + 白箱 KB 运行时数据 + 认知图孤节点 + 字节码缓存），合计约
+> **4009 件 / 28 MB**。该缺陷已由 `cee729a` 收口，**0.4.11 发布件为 1306 件**
+> （本地门禁实测）；已发布版本按「不回溯」处置（§5）。
+
+---
+
+## 1 事实
+
+| 版本 | 发布件数 | `docs/experiments` | 白箱 KB 运行时 | 孤节点 | `__pycache__` | 体积 |
+|---|---|---|---|---|---|---|
+| 0.4.9 | 4008 | 2434 | 474 | 6 | 1 | ~28.0 MB |
+| 0.4.10 | 4009 | 2434 | 474 | 6 | 1 | ~28.0 MB |
+| **0.4.11（收口后）** | **1306** | 0 | 0 | 0 | 0 | — |
+
+**复算方式**：0.4.9 / 0.4.10 两行的件数与体积由第三方从 npm 镜像独立下载 tarball 后逐件
+分类（**不调用本仓任何脚本**），结论与 `publish-artifact-check` workflow 头部的自述
+**逐项一致**——即本缺陷属**如实披露**，非隐瞒。
+
+**0.4.11 一行的口径**：为**本地门禁实测**（`npm pack --dry-run` 清单 1306 件、
+非追踪件 0）。第三方报告在其基线 `1087ae4` 上测得 1302 件——该基线尚未包含后续提交的
+增量件，加之统计口径差异，故与本行不逐位相等；**此处以实测为准，不沿用引用值**。
+
+## 2 根因
+
+`package.json` 的 `files` 白名单包含 `md_cg` 与 `docs` 两个**目录**，而 npm 在存在
+`files` 白名单时**整体忽略根级 `.npmignore`**——只有「白名单目录自身的 `.npmignore`」
+才生效。于是白名单目录内、被 `.gitignore` 排除的运行时产物（实验脚本 / `result_*.json` /
+`_store` 数据目录 / 白箱 KB 的库与索引 / 认知图孤节点 / 字节码缓存）随包分发。
+
+**为什么本地自检没拦下**：门禁脚本的历史版本只校验「发布件清单 vs git 追踪件」的
+一致性，而这些目录属 `.gitignore` 忽略的**本地数据面**——它们在「非追踪件」判定里
+出现过，但当时未按严重度阻断发布。
+
+## 3 收口（`cee729a`，2026-09-20）
+
+改用**子目录级 `.npmignore`**：`docs/.npmignore` + `md_cg/.npmignore` +
+`skills/.npmignore`（共 54 行），覆盖三类：
+
+1. **认知图运行时状态**：`_keys.json` / `_keys.*.json` / `*_audit.jsonl` /
+   `_access.log` / `_index.json` / `_index.json.lock` / `_index_log/` / `_refindex.json`
+   —— 与 `_keys.json` 同级别的凭据信封与审计留痕，**绝不入包**；
+2. **Python 字节码缓存**：`__pycache__/` / `*.pyc` / `*.pyo` / `*.pyd`；
+3. **实验工作区与含沙箱绝对路径的文档**：`docs/experiments/`（可重跑再生产物）等。
+
+`md_cg/.npmignore` 同时排除白箱 KB 运行时数据与本地记忆面；`skills/.npmignore`
+排除纪律模板的中间产物。
+
+## 4 门槛（防复发）
+
+- `scripts/check_publish_artifact.py`：跑 `npm pack --dry-run --json` → 按规则分类 →
+  非追踪件白名单审阅 → `VERDICT=PASS / FAIL`；`--selftest` 覆盖清单解析健壮性与判据自身
+  （含 `prepare` 文本污染 stdout 的场景、数组与对象两形态）。
+- `.github/workflows/publish-artifact-check.yml`：本地模式 + registry 后置核验两种口径。
+- 判据形态：**红着即拦下一次发布**（0.4.11 门禁实测：清单 1306 件、非追踪件 24 = 允许
+  上限 24，`VERDICT=PASS`）。
+
+## 5 处置裁定：已发布版本不回溯
+
+- npm **不允许覆盖同版本号**，撤回（unpublish）会打断已安装用户的依赖解析——代价大于收益；
+- 已发布件不含凭据（`_keys.json` 从未入包，此项经第三方逐件复算确认）；
+- 措施落在「拦下一次」，并对本事实在此**留痕**，供使用者与审计者追溯。
+
+## 6 `files` 白名单与排除规则的一致性复核
+
+| 白名单条目 | 排除机制 | 复核结论 |
+|---|---|---|
+| `md_cg` | 子目录级 `.npmignore`（§3） | 运行时状态与本地记忆面已排除 |
+| `skills` | 子目录级 `.npmignore` | 中间产物已排除 |
+| `docs` | 子目录级 `.npmignore` | 实验区与含沙箱路径文档已排除 |
+| `lib` | 构建产物（`files` 白名单内，无运行时数据） | 无非追踪件 |
+| `src` | 源码（无运行时数据） | 无非追踪件 |
+| `dsh` / `codebuddy` / `zcode` | 接入模板与纪律产物 | 无非追踪件 |
+| `README.md` | 单文件 | — |
+
+复核以门禁脚本本地模式逐件判定为准：0.4.11 发布前 `VERDICT=PASS`（非追踪件 0）。
+
+---
+
+生成：2026-09-20 · 依据：第三方独立验证报告（v15 §5.4）+ 本仓门禁复算 · 维护：随发布件口径变更同步

package/docs//345/267/245/344/275/234/347/272/252/345/276/213_/350/256/244/347/237/245/345/233/276/346/235/241/347/233/256_v1.1.json

@@ -11,12 +11,12 @@
   "reject": []
  },
  "_comment": "identity负责端口分流; negative只否决明确域外; 无//注释(标准JSON)",
- "content": "工作纪律集: 4条方法论(理论先行/全面处理/白箱方法/根因) + 3条执行(验证/双副本/兜底) + 1条思考(中文思考/协作模式分级) + 1条保密(敏感信息隔离) + 3条图像线(选源护栏/历史查询优先/算法权威唯一) + 1条协作(访谈澄清:先问清再动手) + 1条合规(内容政策合规:公开产物过内容政策+隐私双清单) + 2条执行调度与运行环境(命令执行统一走python/UTF-8: 显式encoding+PYTHONUTF8=1, 规避GBK; 任务派发统一走蜂巢: 任何执行性任务经蜂巢spawn/submit执行并留痕, agent本体只做编排, L1出口=产物落点为只读判定(不改仓库/外部状态)可直跑须留痕) + 1条记忆闭环(任务收尾归档:每次任务执行完只将核心修改(内容/原因/位置/验证结论)按CCG六要素(功能名/生效条件/子功能/执行/验证方式/不适用条件)成文存入灵枢记忆, 不写中间过程)",
+ "content": "工作纪律集: 4条方法论(理论先行/全面处理/白箱方法/根因) + 3条执行(验证/双副本/兜底) + 1条思考(中文思考/协作模式分级) + 1条保密(敏感信息隔离) + 3条图像线(选源护栏/历史查询优先/算法权威唯一) + 1条协作(访谈澄清:先问清再动手) + 1条合规(内容政策合规:公开产物过内容政策+隐私双清单) + 2条执行调度与运行环境(命令执行统一走python/UTF-8: 显式encoding+PYTHONUTF8=1, 规避GBK; 任务派发统一走蜂巢: 任何执行性任务经蜂巢spawn/submit执行并留痕, agent本体只做编排, L1出口=产物落点为只读判定(不改仓库/外部状态)可直跑须留痕) + 1条记忆闭环(任务收尾归档:每次任务执行完只将核心修改(内容/原因/位置/验证结论)按CCG六要素(功能名/生效条件/子功能/执行/验证方式/不适用条件)成文存入灵枢记忆, 不写中间过程) + 1条信息获取(工作区索引优先: 查工作区文件先读 WORKSPACE_INDEX.md(仓根, 由 scripts/workspace_index.py 从 git 追踪面管线生成), 尚无则先跑 --write 生成再读, 不以重复全盘浏览代替; 索引是会陈化的手工件, 故须管线生成+机械守卫, 否则退化为误导源)",
  "execution": {
   "how": "按identity(端口)+任务类型路由到对应纪律"
  },
  "response": {
-  "direct": "按工作纪律路由: 重要/长期→理论先行; 有相关成果→全面处理; 已读4篇→白箱方法; 有偏差→根因纪律; 入库前→验证纪律; 多副本→双副本; MCP不可用→兜底纪律; 对外公开→内容政策合规(内容政策+隐私双清单)。命令执行→python/UTF-8(见第15条)。执行性任务派发→蜂巢(见第17条)。任务完成→任务收尾归档(见第16条)。"
+  "direct": "按工作纪律路由: 重要/长期→理论先行; 有相关成果→全面处理; 已读4篇→白箱方法; 有偏差→根因纪律; 入库前→验证纪律; 多副本→双副本; MCP不可用→兜底纪律; 对外公开→内容政策合规(内容政策+隐私双清单)。命令执行→python/UTF-8(见第15条)。执行性任务派发→蜂巢(见第17条)。查工作区文件→工作区索引优先(见第18条)。任务完成→任务收尾归档(见第16条)。"
  },
  "subgraph": {
   "nodes": [
@@ -428,6 +428,32 @@
     "response": {
      "direct": "按工作纪律第17条: 任务派发统一走蜂巢——任何执行性任务经蜂巢 spawn/submit 执行并留痕(spec/status/result), agent本体只做编排; 宿主自带subagent/team不是等价通道, 兜底须声明。L1只读判定(产物落点=不改仓库/外部状态)可直跑, 须输出「L1 直跑：<命令> — 风险/频次/可逆性」留痕。"
     }
+   },
+   {
+    "id": "discipline_workspace_index",
+    "semantic": "18.工作区索引优先",
+    "content": "查找工作区文件/需了解工作区结构时先读工作区索引(WORKSPACE_INDEX.md, 仓根, 由 scripts/workspace_index.py 从 git 追踪面生成): 已有则按其目录职责与关键入口直接定位, 尚无则先运行 --write 生成再读, 都不得以重复全盘浏览(ls/glob 遍历)代替. 目的: 索引一次生成长期复用, 把「每次重新探查」的线性成本降为常数. 原理: 索引是典型会陈化的手工件, 故必须管线生成+机械守卫(CI workspace-index-check.yml), 否则退化为误导源——与「手写行号必腐化」同构; 守卫面(顶层目录集合/根级文件集合/职责文案与关键入口/正文逐字)已在文档内显式声明, 承诺项与守卫面必须一致.",
+    "conditions": {
+     "apply": [
+      "查找工作区文件",
+      "需要了解工作区结构",
+      "跨目录检索定位",
+      "长会话续接/上下文压缩后查找工作区文件"
+     ]
+    },
+    "negative": {
+     "reject": [
+      "已明确路径的单文件操作",
+      "纯会话内对话/问答(无文件查找)",
+      "仓外路径/系统路径(git 追踪面之外)"
+     ]
+    },
+    "execution": {
+     "how": "定位工作区文件→先读 WORKSPACE_INDEX.md(仓根)→有则按表中职责/关键入口直接定位→无则先 python scripts/workspace_index.py --write 生成再读→守卫报陈化先重生成→不以重复全盘浏览代替; 新增顶层目录/根级文件须在脚本 DIR_ROLES/ROOT_FILES 登记后重生成; 上下文压缩/长会话续接后, 先 cg route『工作区索引』重建纪律视野(压缩会丢弃未留下执行痕迹的纪律, 只剩被声明过的条目——须主动召回)"
+    },
+    "response": {
+     "direct": "按工作纪律第18条: 工作区索引优先——查工作区文件先读 WORKSPACE_INDEX.md(仓根, 管线生成); 无则先跑 scripts/workspace_index.py --write 生成再读, 不以重复全盘浏览代替。"
+    }
    }
   ]
  }

package/dsh/README.md

@@ -1,82 +1,82 @@
-# DSH 端 · 灵枢插件配置
-
-本目录 = **DeepSeek Harness（DSH）harness 专属配置**。与 `codebuddy/`、`zcode/` 平级，
-共享层（`md_cg/` 大脑、`data/`、`docs/`、`scripts/`）在仓库根。
-
-## 目录内容
-
-| 文件 | 作用 |
-|---|---|
-| `cordis.patch.yml` | 插件 **bundle 入口**（`package.json` 的 `dsh.bundle.patch` 指向本文件；裸 insert 声明） |
-| `cordis.yml.example` | 插件配置示例（30+ 项：mdcg / memory / mutual / capability …） |
-| `cordis-patch-profile-web.example.yml` | profile `web` 的 config override **备份模板**（换 profile / 重装 / 升级后须核对仍在） |
-| `dsh-web-start.bat` | DSH web 宿主启动脚本（带 8GB heap 保护，防启动 OOM） |
-| `update-lingshu.ps1` / `update-lingshu.bat` | 灵枢插件一键更新：放行 pnpm 发布龄闸门 → 同步 lockfile → 停 DSH（释放目录锁）→ 安装并校验 → 重启。详见脚本头部注释 |
-| `hive-mcp.example.yml` | **蜂巢 MCP 接入样例**（追加进 `<profile>/cordis.patch.yml`）：把 `hive_spawn`/`hive_poll`/`hive_kill`/`hive_doctor` 以 `mcp__hive__*` 暴露给 DSH 模型。含 env 清洗、insert 形态、密钥传递等实测要点 |
-| `hive-mcp-probe.mjs` | 蜂巢 MCP server 探针：用 DSH 自带的 `@modelcontextprotocol/sdk` 直接握手 + `tools/list` + `hive_doctor`（`--spawn` 可跑一次真任务），**不动 DSH 进程**即可验证 server 侧 |
-
-## 安装
-
-```bash
-git clone https://github.com/FuRongJun-1999/dsh-memory.git
-cd dsh-memory
-npm install && npm run build          # tsc → lib/
-dsh plugin --profile web add .        # 必须走 dsh plugin，勿用裸 npm install 装进 profile
-```
-
-再参照 `cordis.yml.example` 在 `<profile>/cordis.yml` 启用配置。
-
-## 蜂巢（hive）MCP 接入（任务调度 + 多智能体并发）
-
-把 `hive/hive_mcp/mcp_server.py` 作为 MCP 服务器接进 DSH，模型即可直接调用 4 个工具：
-`mcp__hive__hive_spawn` / `mcp__hive__hive_poll` / `mcp__hive__hive_kill` / `mcp__hive__hive_doctor`。
-
-完整配置见 [`hive-mcp.example.yml`](hive-mcp.example.yml)（**必须用 `- insert:` 形态**追加到
-`<profile>/cordis.patch.yml`；模板内 4 个 `<REPLACE_WITH_...>` 占位符换成你自己的绝对路径）。
-三条最容易踩的点：
-
-1. **env 会被清洗**：`dsh-mcp-client` 只继承 12 个系统变量，`PYTHONPATH` / `PYTHONUTF8` /
-   `DEEPSEEK_API_KEY` 都得在配置里显式写出，否则 `python -m hive.hive_mcp.mcp_server` 起不来。
-2. **密钥要传下去**：serve 未存活时 `hive_spawn` 会自动拉起它，而 `hive/config.local.json` 里
-   `HIVE_API_KEY` 取自宿主环境变量 `DEEPSEEK_API_KEY`；漏传 ⇒ 拉起一个「没钥匙的 serve」。
-3. **重启才生效**：profile 的 `patchReload` 默认 `startup`。
-
-验证（两步，都不需要动正在跑的 DSH；探针脚本内是占位符，用环境变量传入）：
-
-```bash
-set DSH_ROOT=<DSH 安装目录>
-set HIVE_REPO=<dsh-memory 仓的绝对路径>
-set HIVE_LIB=<认知图库仓的绝对路径>
-set MDCG_ROOT=<认知图根的绝对路径>
-node dsh/hive-mcp-probe.mjs              # 直接连 server：握手 + tools/list + hive_doctor
-node dsh/hive-mcp-probe.mjs --spawn      # 再真跑一个任务，验证写路径
-dsh --profile web --dump-config | findstr mcp-hive   # 确认配置确实进了组合后的插件树
-```
-
-重启后在 DSH 里调用 `mcp__hive__hive_doctor` 应报 serve 存活；`hive_spawn` 一个最小任务
-（如「回复 HIVE_DSH_MCP_OK」）再 `hive_poll` 到 `done` 即端到端通。
-
-## 纪律注入（personaPrefix 受管块）
-
-DSH 端的 16 条工作纪律**不走独立文件**，而是以 `compact` 变体写入
-`~/.dsh/profiles/web/cordis.patch.yml` 的 `personaPrefix` 键，用受管标记块 `lingshu:discipline`
-原地修订（保留注释）：
-
-```
-python scripts/render_discipline.py --target dsh --write
-python scripts/verify_discipline.py --target dsh
-```
-
-> DSH 的 `personaPrefix` 是**每轮注入**的系统提示槽位，因此用 `compact` 变体；
-> CodeBuddy / ZCode 是**会话起始注入**，用 `full` 变体。三角色同源于
-> `docs/工作纪律_认知图条目_v1.1.json`，矩阵见 `docs/discipline/harnesses.yaml`。
-
-## 与「三层拆分规划」的关系
-
-本目录是**按 harness 维度**（DSH / CodeBuddy / ZCode）归置配置；
-[`../docs/mdcg/灵枢三层拆分规划_v0.1.md`](../docs/mdcg/灵枢三层拆分规划_v0.1.md) 讨论的是**另一种正交维度**
-（灵 / 脑 / 身 三仓职责分离，目标是主仓瘦身）。
-
-二者在 `dsh-web-start.bat` 上存在**归属分歧**：三层规划拟将其移出主仓至「身体仓（宿主启动）」，
-而本目录按 harness 维度将其收拢。该分歧**留待三层规划 Phase 裁决收敛**——本目录为其当前的
-可追踪落点，不改变三层规划的结论。
+# DSH 端 · 灵枢插件配置
+
+本目录 = **DeepSeek Harness（DSH）harness 专属配置**。与 `codebuddy/`、`zcode/` 平级，
+共享层（`md_cg/` 大脑、`data/`、`docs/`、`scripts/`）在仓库根。
+
+## 目录内容
+
+| 文件 | 作用 |
+|---|---|
+| `cordis.patch.yml` | 插件 **bundle 入口**（`package.json` 的 `dsh.bundle.patch` 指向本文件；裸 insert 声明） |
+| `cordis.yml.example` | 插件配置示例（30+ 项：mdcg / memory / mutual / capability …） |
+| `cordis-patch-profile-web.example.yml` | profile `web` 的 config override **备份模板**（换 profile / 重装 / 升级后须核对仍在） |
+| `dsh-web-start.bat` | DSH web 宿主启动脚本（带 8GB heap 保护，防启动 OOM） |
+| `update-lingshu.ps1` / `update-lingshu.bat` | 灵枢插件一键更新：放行 pnpm 发布龄闸门 → 同步 lockfile → 停 DSH（释放目录锁）→ 安装并校验 → 重启。详见脚本头部注释 |
+| `hive-mcp.example.yml` | **蜂巢 MCP 接入样例**（追加进 `<profile>/cordis.patch.yml`）：把 `hive_spawn`/`hive_poll`/`hive_kill`/`hive_doctor` 以 `mcp__hive__*` 暴露给 DSH 模型。含 env 清洗、insert 形态、密钥传递等实测要点 |
+| `hive-mcp-probe.mjs` | 蜂巢 MCP server 探针：用 DSH 自带的 `@modelcontextprotocol/sdk` 直接握手 + `tools/list` + `hive_doctor`（`--spawn` 可跑一次真任务），**不动 DSH 进程**即可验证 server 侧 |
+
+## 安装
+
+```bash
+git clone https://github.com/FuRongJun-1999/dsh-memory.git
+cd dsh-memory
+npm install && npm run build          # tsc → lib/
+dsh plugin --profile web add .        # 必须走 dsh plugin，勿用裸 npm install 装进 profile
+```
+
+再参照 `cordis.yml.example` 在 `<profile>/cordis.yml` 启用配置。
+
+## 蜂巢（hive）MCP 接入（任务调度 + 多智能体并发）
+
+把 `hive/hive_mcp/mcp_server.py` 作为 MCP 服务器接进 DSH，模型即可直接调用 4 个工具：
+`mcp__hive__hive_spawn` / `mcp__hive__hive_poll` / `mcp__hive__hive_kill` / `mcp__hive__hive_doctor`。
+
+完整配置见 [`hive-mcp.example.yml`](hive-mcp.example.yml)（**必须用 `- insert:` 形态**追加到
+`<profile>/cordis.patch.yml`；模板内 4 个 `<REPLACE_WITH_...>` 占位符换成你自己的绝对路径）。
+三条最容易踩的点：
+
+1. **env 会被清洗**：`dsh-mcp-client` 只继承 12 个系统变量，`PYTHONPATH` / `PYTHONUTF8` /
+   `DEEPSEEK_API_KEY` 都得在配置里显式写出，否则 `python -m hive.hive_mcp.mcp_server` 起不来。
+2. **密钥要传下去**：serve 未存活时 `hive_spawn` 会自动拉起它，而 `hive/config.local.json` 里
+   `HIVE_API_KEY` 取自宿主环境变量 `DEEPSEEK_API_KEY`；漏传 ⇒ 拉起一个「没钥匙的 serve」。
+3. **重启才生效**：profile 的 `patchReload` 默认 `startup`。
+
+验证（两步，都不需要动正在跑的 DSH；探针脚本内是占位符，用环境变量传入）：
+
+```bash
+set DSH_ROOT=<DSH 安装目录>
+set HIVE_REPO=<dsh-memory 仓的绝对路径>
+set HIVE_LIB=<认知图库仓的绝对路径>
+set MDCG_ROOT=<认知图根的绝对路径>
+node dsh/hive-mcp-probe.mjs              # 直接连 server：握手 + tools/list + hive_doctor
+node dsh/hive-mcp-probe.mjs --spawn      # 再真跑一个任务，验证写路径
+dsh --profile web --dump-config | findstr mcp-hive   # 确认配置确实进了组合后的插件树
+```
+
+重启后在 DSH 里调用 `mcp__hive__hive_doctor` 应报 serve 存活；`hive_spawn` 一个最小任务
+（如「回复 HIVE_DSH_MCP_OK」）再 `hive_poll` 到 `done` 即端到端通。
+
+## 纪律注入（personaPrefix 受管块）
+
+DSH 端的 16 条工作纪律**不走独立文件**，而是以 `compact` 变体写入
+`~/.dsh/profiles/web/cordis.patch.yml` 的 `personaPrefix` 键，用受管标记块 `lingshu:discipline`
+原地修订（保留注释）：
+
+```
+python scripts/render_discipline.py --target dsh --write
+python scripts/verify_discipline.py --target dsh
+```
+
+> DSH 的 `personaPrefix` 是**每轮注入**的系统提示槽位，因此用 `compact` 变体；
+> CodeBuddy / ZCode 是**会话起始注入**，用 `full` 变体。三角色同源于
+> `docs/工作纪律_认知图条目_v1.1.json`，矩阵见 `docs/discipline/harnesses.yaml`。
+
+## 与「三层拆分规划」的关系
+
+本目录是**按 harness 维度**（DSH / CodeBuddy / ZCode）归置配置；
+[`../docs/mdcg/灵枢三层拆分规划_v0.1.md`](../docs/mdcg/灵枢三层拆分规划_v0.1.md) 讨论的是**另一种正交维度**
+（灵 / 脑 / 身 三仓职责分离，目标是主仓瘦身）。
+
+二者在 `dsh-web-start.bat` 上存在**归属分歧**：三层规划拟将其移出主仓至「身体仓（宿主启动）」，
+而本目录按 harness 维度将其收拢。该分歧**留待三层规划 Phase 裁决收敛**——本目录为其当前的
+可追踪落点，不改变三层规划的结论。