DSH 社区生态互操作规范（dsh-ecosystem-spec）

DSH Community Ecosystem Interoperability Specification

别名：社区生态规范、生态互操作规范、生态入口、dsh-ecosystem-spec

社区侧的生态「规范入口与事实层」：把各协议仓库以 git submodule 挂载固定 revision 引用（不复制、不改写），用 `registry/` 提供机器可读索引，用 CI 保证「索引 ↔ 挂载 ↔ 文档」三者一致。当前收录 `dsh-std` 与 `dsh-distribution`（均 Draft）、`dsh-dpx` 与 `dsh-skin`（均 Experimental），并明确声明自己并非官方标准。

一句话

它是 DSH 社区生态的规范入口与事实层：不写协议正文，只把各家的协议挂载进来并登记清楚。用官方仓库与它的分工说，就是——官方仓库回答「我们自己的实现是什么」，它回答「整个社区生态是什么、谁实现了什么、如何验证、如何演进」。

它自己把「非官方」写在明处：不声称 DeepSeek 官方认证、官方采用或唯一标准。所有收录条目的状态（Draft / Experimental / Candidate / Stable / Deprecated）都照录上游仓库的声明，本仓库不自行晋级任何条目。

四层内容模型

这是它最有价值的部分——把生态里的东西按「离协议多远」分成四层，单向约束：

层挂在哪是什么当前收录
1 元协议vendor/meta-protocols/<id>定义「如何声明、发现、协商」，本身不含领域业务字段dsh-std、dsh-distribution
2 子协议vendor/sub-protocols/<id>站在元协议之上，定义具体领域行为，独立版本化dsh-skin
3 范例实现vendor/examples/<id>按协议真做出来的产品，用来证明可描述，不是标准dsh-dpx
4 产品准入profiles/<profile>/在协议之上加某个产品形态的准入要求，必须标注适用范围尚未收录

层与层是单向的（它自己的原话口径）：下层不得修改上层语义；任何一层都不得把某个产品的实现细节，变成对所有生态的强制要求。

它收录了什么（状态照录上游）

类别条目上游声明的状态挂载
元协议dsh-stdDraftvendor/meta-protocols/dsh-std
元协议dsh-distributionDraftvendor/meta-protocols/dsh-distribution
范例实现dsh-dpxExperimentalvendor/examples/dsh-dpx
子协议dsh-skinExperimentalvendor/sub-protocols/dsh-skin（上游在 DSH-EAC/dsh-ui-skin-loader-convention）
Profile——尚未收录——

注意那两个 Draft：生态里目前还没有任何一条协议走到 Candidate / Stable——所以看到"社区协议"时，第一件事是看它自己声明的状态，而不是把它当成既成标准。

它自己定的规矩（治理细则）

这些是它约束自己的规则，也是判断"这份规范可不可信"的依据：

  • 挂载不复制：协议一律用 git submodule、固定在具体 revision 引用；不得在本仓库复制协议 schema 后用同一名称维护；
  • 一份索引一条挂载：registry/ 里每条记录必须且只能对应一条挂载，类别与挂载路径前缀必须匹配；
  • 升级走独立 PR：挂载 revision 升级要写明升级原因、受影响协议坐标、兼容性影响、文档同步项与上游验证证据；
  • 证据不是认证：参考实现与宿主只能提供 evidence，不能自我认证；任何 evidence 都不是安全保证；
  • 自由度红线（最硬的一条）：任何收录条目都不得要求某个产品采用固定目录、固定环境变量、固定注册位置或固定管理器——「协议可选、实现平等、范例不认证」；
  • CI 强制：本仓库自己的规则由 scripts/verify-structure.mjs 在 CI 里校验（索引 ↔ .gitmodules ↔ 挂载目录 ↔ 文档路径四者一致）。

机器可读的 registry/

registry/ 是它作为"生态入口"的数据层，人和 CI 都读它：登记条目的 id、显示名、类别、上游仓库与维护方、挂载路径、照录上游的状态、说明文档路径。它明确不做的事：不授予状态、不认证实现、不规定目录形状。

与 dsh-std 是什么关系

一句话：dsh-ecosystem-spec 是总目与治理层，dsh-std 是协议正文。

dsh-std（DSH Universal Interoperability Meta-Protocol，生态通用互操作元协议）是一个独立的仓库——它自己有 244 个文件、docs/architecture.md 与 20 多份协议提案（command / model / session / permission / events / storage / skill / sdk / conformance 等），star 数（136）也高于总目（72）。而 dsh-ecosystem-spec 把它作为 submodule 挂在 vendor/meta-protocols/dsh-std，只做引用、索引与治理，不复制内容。

所以两者关系不是"上下级替代"，而是目录 ↔ 正文：要读协议怎么写，去 dsh-std；要知道生态里有哪些协议、谁实现了、什么状态，来这里。

未核实

  • 本页依据是它的 README、docs/overview.md、governance/rules.md、registry/README.md、.gitmodules 五处公开文件，没有逐条读 registry/*.json 的全文，也没有读 docs/directory-guide.md §6 的完整校验清单；
  • 状态与收录会变：Draft / Experimental 是 2026-10-02 的快照；它自己的规矩是不自行晋级，所以状态变动以上游仓库声明为准；
  • 它与 DeepSeek 官方是否有任何沟通或认可，本站未核实（它自己在多处声明"非官方、不声称认证"）；
  • dsh-skin 的上游在另一个组织（DSH-EAC），本站尚未单独看过那个仓库，它的定位按本仓库的收录说明照录。

信息表

category
ecosystem.spec
fileName
README.md
repo
T-Auto/dsh-ecosystem-spec
specStatus
current
titleEn
DSH Community Ecosystem Interoperability Specification
updatedAt
2026-10-02
url
https://github.com/T-Auto/dsh-ecosystem-spec

标签：规范、社区、生态地基

按标签浏览：规范（3） · 生态地基（3）