dsh-distribution

让不同的 DSH 整合包，都能被同一种方式识别和管理。

你可以把 DSH 打包成一建安装包，也可以吧 DSH 做成独立桌面应用、机器人。但当别人想知道“这是什么版本”“配置和聊天记录在哪”“换电脑时该带走哪些文件”，每个项目往往都有自己的答案，管理工具也得逐个适配。

dsh-distribution 是一套 DSH 环境描述与管理协议：用一份统一的环境说明，把这些信息交代清楚，让支持它的工具不必再猜你的项目是怎么组织的。

对整合包作者来说，可以这样理解：

我的项目遵守 dsh-distribution，就有了统一的环境身份、组成说明和数据管理信息，更容易被工具识别、管理和迁移。

接入后有什么好处？

你关心的事	统一协议带来的帮助
让别人认得出我的整合包	明确项目、版本和某次安装的身份，避免把不同版本、不同安装混在一起。
不用每个管理工具都重新适配	用相同格式说明组件、配置、记录和数据的位置，减少针对各项目硬编码。
多套 DSH 环境放在一起更好管理	说清哪些资源属于哪套环境、哪些是共享的，为管理工具区分边界提供依据。
备份、换电脑时少猜少漏	说明哪些数据可以带走、哪些需要额外处理、哪些不能自动复制，让工具有依据地规划迁移。
出问题时更容易定位和恢复	用统一方式表达环境状态、迁移进度和恢复记录，方便支持这些功能的工具展示和处理。
以后换界面、换打包方式更自由	协议不绑定任何目录名或安装器，不为了接入而限制产品形态。

这些优势来自工具能够读懂同一份说明，不是多写一个文件就自动完成隔离或搬家。实际备份、复制和恢复仍由管理工具实现。

我需要做什么？

让你的项目提供一份符合协议的环境说明。 可以把它理解成随整合包附带的“产品说明书”，既给人看，也给程序读。

它把一个环境作为整体描述：

• 它是谁：项目标识、发布版本，以及如何区分每次安装。
• 它由什么组成：运行时、界面、插件等组件的来源。
• 它的数据在哪里：配置、聊天记录、扩展、缓存等位置，以及管理归属。
• 外部工具怎么管理它：如何找到它、了解状态，以及搬家时哪些内容能处理、失败后如何恢复。

你不需要先学一套新架构，也不需要改成指定的目录结构。你负责说明项目的真实情况，格式和校验可以交给 AI 或接入工具处理。 不适用的信息按规范处理，尚未实现的能力如实说明，不必为了填写说明编造功能。

查看接入指南 → · 查看环境说明示例 →

我用 AI 写项目，怎么让它接入？

把下面这段交给你的编码助手：

请按照 https://github.com/T-Auto/dsh-distribution 的接入指南，为我的 DSH 项目接入 dsh-distribution。先检查项目的身份与版本、组件组成、配置和数据位置、安装管理方式及迁移条件，再生成符合规范的环境说明并验证。请把它作为一次完整的环境接入处理，不要让我逐个选择内部协议包。无法确定的事实先问我，不声明尚未实现的能力，不擅自改变现有目录和启动方式，不执行真实迁移。最后告诉我哪些信息已经可被工具读取，哪些操作仍需要管理工具支持。

可直接复制的完整提示词 →

会不会影响我原来的项目？

协议不决定你的项目怎么运行，只统一它如何向外部说明自己。

• 原来怎么打包、怎么启动，仍然可以怎么做。
• 不要求重写插件、替换界面或采用指定的管理器。
• 不要求把本仓库的开发依赖装进整合包。
• 不规定所有项目都必须有本地目录、常驻进程或激活命令。

终端工具、桌面应用、容器、在线服务都可以描述自己的真实情况。它们遵守的是同一套协议，不需要长成同一种产品。

现在能用到什么程度？

当前是 Draft（草案），仓库已提供环境说明格式、校验工具、发现示例，以及迁移计划和恢复日志模型，欢迎试用和反馈。

这里不是安装器，也不提供真实文件迁移执行器。 格式校验通过不等于数据安全认证；密码、密钥不要写进说明文件。现有 DSH 工具是否能读取或操作这些信息，需要看具体工具的适配情况。仓库中的 npm 包尚未发布，接入方式见指南。

和其他 DSH 项目有什么关系？

• dsh-std：让插件、界面和运行时互相配合。
• dsh-distribution：让一整套 DSH 环境能被外部工具识别和管理。
• dsh-ecosystem-spec：生态总入口。

开发者资料

接入工具、管理器或参与协议开发时，可以查阅：

开发指南 · 架构 · 规范提案 · 包索引 · 一致性测试 · 安全边界 · 兼容性 · 贡献规则

License

MIT