③ 在

/cordis.yml 启用（配置示例见 dsh/cordis.yml.example）


```yaml
- id: lingshu-memory
  name: '@furongjun1999/dsh-memory'
  config:
    mdcg:
      # 记忆唯一真源（md 认知图）。留空 = 用户级默认位置
      # ~/.dsh/.dsh-memory/data/mdcg（更新插件不丢）；换位置请填**绝对路径**。
      # 勿填包内相对路径（如 'data/mdcg'）——那会把记忆写进插件包目录，
      # pnpm 更新该包时连目录一起删掉（详见 dsh/cordis.yml.example 头注）。
      root: ''
    identity: '灵枢'
    tools: 'core'            # 'core'(默认, 仅 cg/stg) | 'brain' | 'all'

装完即可对话，无需理解任何理论——DSH 端自动记忆钩子已挂 session/event，你只管像往常一样对话（其它宿主可直接让 Agent 调用同一批工具）：

你说	背后发生什么（真实工具链）
「请记住：我们团队的发布窗口是每周三」	自动记忆钩子沉淀 → `cg(op=write)` 过三道闸门 → 认知图节点落盘
（新开会话）「我们的发布窗口是哪天？」	自动召回注入 → `mdcg_recall` 检索命中并带入回答
「把上次定的接口约定讲一遍」	`cg(op=route)` 条件路由 + `stg(op=timeline)` 时间线回溯，跨会话取出

首次使用记忆库为空，召回返回空结果属正常现象；未配写入凭据时以只读 guest 运行（读得到、写不进），要真正落盘见写入凭据。

前置：Node ≥ 22.19 · DSH 内核 ≥ 0.1.2-rc.1 · 大脑零安装（md_cg 随包自带，无需 pip 装任何引擎）· Python 解释器（插件按平台自动选：Windows python / Linux·macOS python3；解释器名特殊时用 MDCG_PYTHON 覆盖）
写权限默认关闭：不配凭据即以只读 guest 运行（读 / 召回 / 时间线可用，写入不落盘）。要真正落盘见「写入凭据」
完整配置项（30+ 项）· 自动记忆机制 · DSH 看门狗 → README 详细版
非 DSH 宿主（CodeBuddy / ZCode / Codex CLI / Claude Code）：走多 harness 接入，各端有独立三步接入说明
装后验证：重启 DSH 后对 Agent 说「列出你的记忆工具」应看到 cg / stg（tools: 'all' 时还有 mdcg_*）；大脑直连验证：python -m md_cg.mcp_server（Windows）/ python3 -m md_cg.mcp_server（Linux·macOS）（stdio JSON-RPC）收到 initialize 应答即通；若工具始终不注册、日志刷「灵枢调用超时」，先看桥探针 ~/.dsh/logs/lingshu-bridge-debug.log 里的 spawn … ENOENT——那是第一因（解释器名与平台不匹配），「调用超时」只是次生现象。更多细节见 README 详细版

📊 六家记忆系统横向对比

100 题中英双查（bench6 v1.0 · 零干扰上界对照集 · CC BY-NC 4.0）：六家系统、同一份中文语料、同一套 hit@1 / hit@5 / MRR 评分器（md_cg/eval_common.py）。下表按「英→中查询提升幅度」降序：

系统	en hit@1	zh hit@1	英→中提升
灵枢（词法 + meta）	54.0%	99.0%	+45.0pp
灵枢（四路融合 · 真开 bucket）	37.0%	81.0%	+44.0pp
纯向量 RAG	71.0%	97.0%	+26.0pp
Letta（归档直插）	73.0%	96.0%	+23.0pp
mem0	68.0%	89.0%	+21.0pp
GraphRAG	18.0%	31.0%	+13.0pp
Graphiti	46.0%	58.0%	+12.0pp
Letta（agent 自主入库）	0.0%	0.0%	（入库丢标记壳臂）

核心结论：将查询由英文换为中文（同一份英文语料、记忆系统均不变）：六家已有记忆系统的检索命中全部大幅提升（+12 ~ +45pp），无一例外；灵枢是最佳——中文查询 hit@1 99.0% 全表登顶，英→中提升幅度 +45pp 亦居本表之首（双语入库在中文查询下同时拿到最高命中与最大提升）。 诚实口径（非选择性引用，与横评报告一致）：英文查询侧由 Letta 归档直插（73.0%）与纯向量 RAG（71.0%）领跑，灵枢四路融合在本池低于单词法基线（81.0% 完整题型分解 / MRR 全表 / 逐家入库取证 / 偏差判定单 → 六家横评报告 · 题集 → data/benchmarks/bench6-100-zh-en/

🧪 弱证据会干扰检索：三分离与证据防火墙（实证）

外部源码级评审（GPT）与四臂弱语义噪声注入实验共同实证的一个反直觉结论：语义完整度 ≠ 证据强度 ≠ 召回价值——语义高度省略的「弱证据」语料恰恰是最需要被召回的 episodic 事实；而条件判断层（负条件 / 否定反事实）的弱证据节点会冒充正确答案，干扰检索。

实证语料「我在喝水」：语义上高度省略（谁在喝？在哪喝？均未说），但作为 episodic 事实承诺明确。当提问是「你刚才在干什么？」时，问句与语料词面零重叠——纯词法检索 top1 命中 0/8（省略式 episodic 全部漏召），而语义路作为候选生成器把 8/8 拉进 top10。词法满格的前提（词面共享）在事件类记忆上不成立。
条件判断的弱证据干扰检索：同一实验中 8 个否定反事实节点（「我没喝水」）与 gold 词面高度相似，无防线时冒充前排；灵枢四层证据防火墙（召回前负条件路由 → 候选生成排除 → judge_ranking 白箱终排 → 资格标注）将其 8/8 全部 REJECT 剔除，top10 无冒充。
可复现：python -m md_cg.test_sem_noise（42 节点确定性语料，四臂 A_lex / B_sem / C_fusion / D_firewall 对照，7 断言）。

🌐 中英双语检索差距：我们用中文语义归一化解决英文检索（实证）

直接回答：英文检索问题，我们用中文翻译 + 语义归一化解决——英文 query 经 AI 语义归一化为中文标准关键词（归一主体=AI，系统只供词表真源），再经中→英字级原子映射与双语原子库匹配，返回英文原文。同一份 500 题语料上，给定中文标准关键词时检索效果 hit@10 = 99.8%（hit@1 96.8%；检索侧上界口径——AI 归一环节的质量未纳入该评测，机械归一的端到端下界见下表 ④）。三条对照边界：不做归一化、拿英文原题直接词面匹配只有 78.2-81.2%（同义词鸿沟硬边界）；机械词典查表归一端到端实测仅 57.6%；而 ②路对归一噪声高度鲁棒——漏 20% 关键词 / 错译 20% / 混入噪词，hit@10 仍稳在 99.2-99.8%。结论：路线成立且不要求 AI 归一完美，只需大致方向对；99.8 是检索侧上界，端到端真实水平由 AI 归一质量决定（机械下界 57.6，AI 上界趋近 99.8）。

第三方独立验证（2026-09-15，报告全文）：上述关键数字已被第三方独立复现——②路 96.8/99.8/99.8 逐位一致，中文 96.4→96.8（噪声内）；并实证该 99.8 由中文摘要层挣得（去英文处理层 hit@10 反为 100.0%），英文标准归一化组件自身端到端为 81.0%（写入侧机械归一口径，较不归一 +58pp），检索失败 100% 归因归一化丢词/错译而非排序。本节口径标注与该实证一致：99.8 是「给定中文标准关键词」的检索侧上界，不声称英文机械归一化独立达到该水平。

测试报告（灵枢公开仓评测，方法学与口径真源 → md_cg/semantic/REPRODUCE.md）：

方法	hit@1	hit@5	hit@10	语料
① 中文原子语义（md_cg 主链路：char-bigram + 四路 RRF + 同义扩展 + terms）	94.6%	99.2%	99.2%	locomo-zh-500 · 500 题（中文题面）
② 英文检索 · 中文语义归一化桥接（主路线）：AI 归一为中文关键词 → 字级英文原子映射 × 双语原子库 Jaccard（给定关键词的检索侧上界）	96.8%	99.8%	99.8%	locomo-zh-500 · 500 题（同 qids）
③ 英文原题直接原子匹配（不做归一化的对照）	50.0%	74.6%	81.2%	locomo-zh-500 · 500 题（同 qids 英文原题）
④ 英文问句 → 机械词表归一端到端（②链路的机械化对照：归一不借助 AI 的真实下界）	24.6%	46.2%	57.6%	locomo-zh-500 · 500 题（同 qids 英文原题；2026-09-15 第三方错译暴露面修正后 24.0/46.0/57.2→本行，CEDICT 层低置信标记已落地）
英文反事实：硬套中文 char-bigram 主链路（默认态）	27%	45%	56%	bench6 · 100 题（口径不同，只看量级）

②③是同一评测集上的隔离实验：② 的 query 走中文关键词语义链（AI 归一化的输出形态），③ 连归一化也不做、直接拿英文自由表达提取原子——②③ 之差（99.8 vs 81.2）=「关键词级语义链」与「自由英文词面」两种 query 输入形态在检索链路里的效果差（同义词鸿沟 + 归一化桥接的合并贡献）。AI 归一环节本身的质量未单独评测——其机械替代的端到端下界由 ④ 给出（57.6%）。②路鲁棒性实测（query 确定性扰动后走同一 ② 链路）：漏 20% 关键词 ⑤=99.4 / 插 3 噪词 ⑥=99.8 / 错译 20% 关键词 ⑦=99.2（hit@10）——归一结果只要过半正确，hit@10 即稳 99%+，AI 归一的实际门槛远低于完美归一。doc 侧各臂相同（中文五槽加工面的字级原子映射 ∪ 英文正文归一词，与 ① 同属写入侧加工口径）。历史沿革：早期无加工面语料口径测得 ②=87-88、③=79.0（dsh 端文档口径），方法学真源见 REPRODUCE.md；机械词级归一→纯中文库（u2，33.6% 上界）已裁定排除并归档证据链。

差距三层归因（按权重排序）：

同义词鸿沟（根本原因，语言固有属性）。中文「概念 → 表达」约 1:1~1:2（95 个同义词对），字面重叠天然命中，词面匹配几乎不打折；英文每概念平均 5.2 种表达（CC-CEDICT 语料统计，8,493 汉字展开出 172,950 个英义对，1,820 倍于中文）。上表 ② vs ③ 就是这道鸿沟的直接隔离实验：同一语料，query 侧做中文语义归一化得 99.8%，不做归一化直接英文词面匹配即降至 81.2%——鸿沟真实存在，但在查询侧做一次语义归一化即可闭合，不需要向量嵌入。
归一化是正解，机械归一是死路（主路线裁定的依据）。机械词典查表翻译端到端实测仅 57.6%（④臂：英文问句 → CEDICT 28294 键词表直译 → ②同链路），且低于「完全不归一」的 81.2%（③臂）——机械直译把可译词错译为错误原子（race→人种），反而毁掉原本有效的词面贡献；更早的机械词级归一→纯中文库口径上界也只有 33.6%（已排除）。根因是英文自然问句的信息密度远低于标注关键词（词面交集 p50=1 vs 8），机械替换无法补足信息差；查询侧归一化由 AI 完成（理解式归一，如 take up a hobby → 培养爱好），系统只供词表真源与字级映射——②的 99.8%（上界）与机械路 57.6%（下界）之间的空间，就是 AI 归一要填的部分；⑤⑥⑦证明这个要求只需「大致方向对」。
架构非对称（设计裁定）。中文链路的四路 RRF / 同义扩展 / terms 字段全部建立在「字面=语义」的中文前提上，直接跑英文实测劣于独立路（反事实 56%）——英文按裁定走「归一化桥接 + 原子 Jaccard」独立路，不硬套中文 char-bigram 管线，是有意的取舍而非遗漏。中→英字级映射覆盖 6,319 字（97.2%），长尾派生词（happy/happiness）不折叠——残余失配由查询侧 AI 归一化吸收，这正是 ② 反超 ③ 21.6pp 的来源。

要不要上语义向量检索？ 向量嵌入可以弥合同义鸿沟，但会引入嵌入模型依赖与索引体积，与灵枢「零重依赖、纯词面可复现」的公开仓原则冲突，当前明确不做；归一化桥接已把检索侧上界做到 hit@10 99.8%（鲁棒性：归一不完美时仍 99%+），满足「答案在候选池」的记忆系统主用途。

渐进式语义检索（Progressive Semantic Retrieval，正式机制 v0）。查询不是固定语义结构，而是不断收紧的约束集合——语义解析的完整性与检索的必要性不是同一个问题：从最小可靠语义（部分归一原子）开始宽检索，再按候选间区分度逐步增加条件使语义收敛；DEFER ≠ 失败，=「当前语义分辨率不足，继续获取条件」，与证据防火墙四态天然衔接。同一份 500 题实测：一次性全原子 96.8/99.8/99.8（=②锚点）；只宽检 50% 核心原子 85.2/95.8/97.0；宽检索→区分性条件渐进收紧（平均 +2.97 个条件）收敛到 93.6/98.8/99.0——与一次性差 0.8pp，实证「不必一句话完成语义理解」。受控干扰池进一步实证排序面消歧（top1 稳 gold、渐进不引入新冒充），并如实暴露边界：条件面冒充（生效条件被伪造为 gold 同款）不被内容词渐进消除——词面条件确认必要非充分，真伪判据=证据基底分离（另案）。控制器 md_cg/progressive.py（纯函数、确定性、评分器注入式），实验 md_cg/bench_progressive.py。

📚 公开评测数据集

📎 全部随仓库公开（CC BY-NC 4.0），可直接下载用于你自己的记忆系统对照评测：

基准	归属	状态
locomo-zh-500	自建（LoCoMo 中文派生 · 500 题 / 567 turns / 0.6 MB）	已随仓库公开 `data/benchmarks/locomo-zh-500/` · 可复现 · 我方成绩：中文 hit@1 94.6% · hit@5 / hit@10 99.2%（md_cg 完整主链路）；英文（语义归一化桥接）hit@10 99.8%——见上中英双语检索差距①② 行 · 第三方独立复现：中文 96.8/99.6（自报 96.4/99.8 噪声内）、英文主路线 96.8/99.8/99.8 逐位一致 → 第三方验证报告
bench6 · 六家横评	自建（LoCoMo 中文派生 · 100 题 / 137 turns · 中英双查 / 约 90 KB）	已随仓库公开 `data/benchmarks/bench6-100-zh-en/` · 六家同口径对照（灵枢 5 口径 / 纯向量 RAG / mem0 / Graphiti / GraphRAG / Letta 两模式）· 报告 → 横评_六家100题中英双查_v1.0.md
LoCoMo	第三方 `mteb/LoCoMo` BEIR（1976 题 / 5882 turns）	上游来源（英文原版）
memory-bench-1000	自建	SNR 见评分报告 v2.0；已公开 `data/memory-bench-1000.jsonl`

上表四行性质不同，勿混读：locomo-zh-500 的分数是本仓库我方成绩（基于LoCoMo自建并公开的评测集，可复现）；bench6 · 六家横评 是同源派生的小型同口径对照集（零干扰池，只做六家系统横向对照，非我方单方成绩）；LoCoMo 一行指上游英文原版 1976 题，本仓库未在其上产出完整成绩；memory-bench-1000 是自建记忆库的评分报告。 该成绩的性质（非虚假声明）：locomo-zh-500 的分数是写入侧结构化加工后的检索成绩——入库前把每轮对话加工为「身份 / 时间 / 摘要 / 词 / 条件四槽」条目，再走词法 + 同义扩展检索。这与主流记忆系统所用的向量化嵌入 + 关键词/摘要压缩属同一类写入侧加工，差异只在索引与检索算法，不在「是否对原文做了加工」。因此该口径可用于同口径对照，不是对裸文本直读的虚高取巧。 locomo-zh-500 是本仓库对外发布的检索评测集：供外部在同一份中文题面上对自己的记忆系统做可对照评测。它只评检索命中（hit@k / MRR），不评答案正确性；被测池为零干扰（池内全是 gold），故高命中率不可外推为端到端记忆能力——完整边界与许可见 data/benchmarks/locomo-zh-500/README.md。 bench6-100-zh-en 沿用同一口径，并每题提供中英两套词面（评「换查询语言后是否仍命中」）；它同样是上界对照集——家间差距小于约 16% 不可判为显著；评测入口已随仓库公开（run_bench.py：零依赖口径复现 + Adapter 协议接入你自己的系统），接入任意llm和向量方法都可复现，详见横评报告与 data/benchmarks/bench6-100-zh-en/README.md。

复现我方成绩（零上游依赖）：

python -m md_cg.bench_locomo_zh_public   # 中文：只读 data/benchmarks/locomo-zh-500/，产出公开词法口径参考量级（hit@1 93.6% 单路 / 97.6% +同义扩展）；上表 94.6/99.2 为 md_cg 完整主链路（四路 RRF + 同义扩展 + terms）成绩
python -m md_cg.bench_en_atoms_public    # 英文：语义归一化桥接七臂（② 96.8/99.8/99.8 主路线·检索侧上界 · ③ 81.2 不归一对照 · ③a 78.2 纯正文对照 · ④ 57.6 机械归一端到端下界 · ⑤⑥⑦ ②路鲁棒性 99.2-99.8）；英文原题面为上游派生不入库，自备后即可全量复现
python -m md_cg.bench_progressive        # 渐进式语义检索双实验（G0 96.8/99.8/99.8 =②锚点自校验 · 只宽检 85.2/97.0 · 渐进收敛 93.6/99.0 · 受控池排序面消歧+条件冒充边界）

# 签发（明文不进配置文件）
python -m md_cg.tokens issue --role designer --actor dsh-memory --clearance internal ^
  --ops-allow info,route,read,write,recent,goal,identity,whitebox,verify ^
  --layers-allow knowledge,contextual,structural,self,goals,unresolved,rejected
setx MDCG_TOKEN "mdcg1.xxxxx"     # 然后重启 DSH

    env:
      MDCG_TOKEN: !!js process.env.MDCG_TOKEN

--role recorder 为最小权限版（只能自动记忆 / 转录；whitebox、identity、verify 会被拒）。 落盘充要条件 = 最终判定 ACCEPT：cg(op=write) 需依次穿过 audit → 一致性 → gated 三问四态三道闸门，非 ACCEPT 均不新增落盘点。 别把 ok: true 当写成功：未落盘时返回体形如 {"ok": true, "committed": false, "moved_to": "review_queue"}——ok 只表示请求被受理，是否落盘只看 committed。首次写入最常踩的坑：content_kind 省略或填 text 时，未配置规则库（MDCG_POLICY_FILE）的审核器一律判 DEFER（"缺能力返回 DEFER，绝不假装通过"），内容进审核队列而非落盘；要立刻落盘请用可验证类型，如 content_kind: 'code'（AST 解析通过即 ACCEPT）。

❓ 常见问题（FAQ）

为什么不能用裸 npm install 安装进 profile？

必须用 dsh plugin --profile add . 安装：插件声明了 6 个 peerDependencies（cordis / dsh-llm / dsh-session / dsh-system-prompt / dsh-tools / schemastery），dsh plugin add 走 pnpm 正确解析宿主提供的 peer 版本；裸 npm install 会把错误版本的依赖装进 profile 导致加载失败。仓库根目录的 npm install 仅用于开发构建（npm run build）。

装完插件 / 配完凭据没有生效？

DSH 采用 Cordis bundle 机制，新增或更新插件后必须重启 DSH 进程（或刷新 Web UI 页面）才会重新加载；通过 setx 配置 MDCG_TOKEN 后同理，须重启才可见（见写入凭据）。

怎么确认 Agent 真的把记忆写进去了？

看返回体的 committed 字段，别把 ok: true 当写成功——{"ok": true, "committed": false, "moved_to": "review_queue"} 表示请求被受理但未落盘（内容进了审核队列）。落盘充要条件 = 三道闸门最终判定 ACCEPT。

为什么我的写入没有落盘？

三个最常见原因：① 未配写入凭据 → 只读 guest，写入不落盘（配凭据见写入凭据）；② content_kind 省略或填 text 且未配置规则库（MDCG_POLICY_FILE）→ 审核器一律判 DEFER（"缺能力返回 DEFER，绝不假装通过"）→ 用 content_kind: 'code' 等可验证类型（AST 解析通过即 ACCEPT）；③ 未穿过 audit → 一致性 → gated 三问四态任一闸门。

CodeBuddy / ZCode / Codex CLI / Claude Code 等其它宿主也能用吗？

能。大脑 md_cg/ 是标准 stdio MCP server（python -m md_cg.mcp_server），任何支持 MCP 的宿主可直接挂载；五端接入差异只在纪律注入方式，见多 harness 接入。

📚 文档导航

文档	内容
docs/ 目录索引	六域快速索引（mdcg / swarm / hive / theory / eval / plans）· 新文档归域规则
README 详细版	完整能力说明 · 配置项全表 · 安装与验证细节
发布说明 v0.4.5	本版变更 / 兼容性 / 升级指引
AGI 七维评分报告 v2.0	逐维得分依据 / 扣分项 / 实库证据 / 诚实边界
第三方复评 · 统一评分 v7	独立评估者七轮对照（灵枢 vs deja-vu）：八维加权 / 收敛轨迹 7.79→9.258 / 评审偏差声明 / 自身建议全撤回勘误
第三方验证 · LoCoMo 独立复现	独立实现评测全流程：自报数字逐位复现 / 归因拆解（中文摘要层 vs 英文归一化 81.0%）/ 静默错译样本 / 数据集区分度证伪检查（配图 `第三方验证报告_LoCoMo_灵枢_.png`）
功能调用映射表	任何功能 → 调用哪段代码（含行号、MCP op）
护栏宪章 v2.0	对外部智能体与人类使用者的行为边界
教学四篇	白箱智能是什么？ · 智能的认知过程 · 智能的公理化基石 · 信息差为什么必然存在
工作纪律·认知图条目 v1.1	自我约束的 18 条工作纪律（嵌套认知图条目 `work_discipline`）
六家记忆系统横评 v1.0	100 题 · 中英双查 · 六家同口径对照；含判定单 / 条件层归因 / 诚实边界（题集 → data/benchmarks/bench6-100-zh-en/）
Rust 检索库	`mdcg_eval` 三形态：库内嵌大批量检索 / `--serve` 多智能体进程实例 / 公开数据集评测器（零依赖 · 与 Python 口径逐位对齐）
蜂群多智能体	`swarm/` 多进程蜂群执行层（2026-09-13 自 protocol-compiler 迁入，大脑核心内部能力）：.pbc 确定性实例 + Gossip/拓扑/水位信箱/WAL-HMAC/信任聚合/健康评分（Rust 纯 std 零依赖 · 159 断言回归全绿）

多 harness 接入（按端分目录）

主推路径：MCP 直挂——各端接入的共性是挂载同一个 stdio MCP server（python -m md_cg.mcp_server）：任何支持 MCP 的宿主直接挂上即可，不依赖任何插件系统。

共享层（md_cg/ 大脑 · data/ · docs/ · scripts/）在仓库根；harness 专属配置按端归置，下表列的只是各端纪律注入方式的差异（纪律如何进入上下文），大脑与记忆真源零改动：

目录	harness	接入文档	纪律注入方式
`dsh/`	DeepSeek Harness	dsh/README.md	`~/.dsh/profiles/web/cordis.patch.yml` 的 `personaPrefix`（compact · 每轮）
`codebuddy/`	CodeBuddy	codebuddy/README.md	项目根 `CODEBUDDY.md`（full · 会话起始）
`zcode/`	ZCode	zcode/README.md	项目根 `AGENTS.md`（full · 会话起始）
`codex/`	Codex CLI	codex/README.md	项目根 `AGENTS.md`（full · 会话起始）
`claude/`	Claude Code	claude/README.md	项目根 `CLAUDE.md`（full · 会话起始）

五端纪律同源（docs/工作纪律_认知图条目_v1.1.json），由 scripts/render_discipline.py 渲染、 scripts/verify_discipline.py 守卫漂移；矩阵见 docs/discipline/harnesses.yaml。

可选补充：插件形态安装（仅 Claude Code / Codex CLI · 省手工复制，非主推路径）

等价于按上表手工配置，只是把纪律 skill 与配置样例随插件一起拿到；不装插件不影响任何能力。

宿主	安装	插件位置	装后一步
Claude Code	`/plugin marketplace add FuRongJun-1999/dsh-memory` → `/plugin install lingshu-memory@lingshu`	`claude/lingshu-memory/`（纪律以 skill 分发，`/lingshu-memory:linglu-discipline` 可显式调用）	复制插件内 `mcp.json.example` 为项目根 `.mcp.json`，填 `PYTHONPATH`
Codex CLI	`codex plugin marketplace add` → `codex plugin add lingshu-memory@lingshu`	`codex/lingshu-memory/`（skill 三级渐进加载；`.codex-plugin/plugin.json` 清单）	把插件内 `config.toml.example` 两段合并进 `~/.codex/config.toml`，填 `PYTHONPATH`

marketplace 清单：Claude 端在仓根 .claude-plugin/marketplace.json，Codex 端在仓根 .agents/plugins/marketplace.json。插件不含大脑本体（md_cg/ 不随插件分发）——MCP 装好后大脑仍是你本机的 dsh-memory 仓库；插件形态的纪律 skill 同样由真源渲染（skill 变体，矩阵槽位 claude-code-plugin-skill / codex-plugin-skill），漂移由同一 verify_discipline.py 守卫。

🛠️ 开发

npm install                          # NODE_ENV=production 时须加 --include=dev
npm run build    # TypeScript 编译
npm test         # 真实集成测试（spawn 本机灵枢，验证握手/往返/注册/卸载）

NODE_ENV=production（或 --omit=dev）会省略 devDependencies，tsc/tsx 不在位；此时 prepare 跳过构建并在 stdout 明示（不再让 npm install 因 tsc 缺失而整体失败），需要构建请用 npm install --include=dev。另：engines.node >=22.19 之下运行会收到 EBADENGINE 警告（仅提示，不阻断）。

测试不依赖 DSH 全组件——用最小 Cordis host（SystemPrompt + ToolRegistry + 插件）隔离不稳定面。

安装

说明文档

③ 在