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),本站尚未单独看过那个仓库,它的定位按本仓库的收录说明照录。

信息表

authors
T-Auto(作者)
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

属性

分类 ecosystem.spec 规格状态 current 仓库内路径 README.md 上游 T-Auto/dsh-ecosystem-spec 上游地址 https://github.com/T-Auto/dsh-ecosystem-spec 最后更新 2026-10-02

开发者 / 团队(1)

T-Auto 作者

支持的 DSH 版本

本站尚未收录它的 DSH 版本声明。