T-Auto/dsh-std
DSH Plugin Interoperability Meta-Protocol / DSH 插件互操作元协议
Project Overview项目介绍
DSH Standard (repository T-Auto/dsh-std, MIT-licensed) is an interoperability protocol suite authored explicitly for the DeepSeek Harness ecosystem, published as a monorepo of npm packages. The centerpiece @dsh-std/core is a meta-protocol that defines only how protocols are identified (apiVersion + kind), declared (requires / supports), and matched through pure-function negotiators, while remaining completely ignorant of commands, models, or UI. Domain protocols such as Command, Tool, Model, and Presentation sit on top as independently versioned contracts, and downstream hosts are free to implement only the slice they need; the repository ships @dsh-std/adapter-dsh as the dedicated shock-absorber between the DSH upstream runtime and the universal protocol layer.
For plugin authors and ecosystem teams the architecture delivers several concrete superpowers: a single plugin package, written once against the standard contracts, runs unmodified in TUI terminals, Web browsers, remote SSH services, and headless daemon containers; the Facet model activates only the frontend or backend facets a host actually needs and garbage-collects listeners, timers, and resources when a plugin is disabled. Static manifests (dsh-plugin.json) let marketplaces, hosts, and CI compute compatibility in milliseconds without executing any plugin code, eliminating crash-roulette installations, and the pure-data negotiator keeps unit tests fast under lightweight Node.js and CI. Newcomers are pointed at docs/architecture.md, the Chinese proposal index, the endpoint-connection draft, and packages/README.md, with projects that want a familiar "Host + Plugin Manifest" experience guided toward the TUI Profile carried by dsh-ecosystem-spec.
Build and release requirements are stated up front: development requires Node.js ^22.19 || >=24 together with pnpm, and the repository is validated locally with pnpm install followed by pnpm check. Package versions live directly inside each packages/*/package.json, so a push to main compares them with the previous commit, packs every bumped package, publishes to the npm registry via OIDC, tags the release, and opens a GitHub Release; prerelease identifiers become npm dist-tags (rc, alpha, beta) while stable releases use latest. The release job is restricted to the repository owner's GitHub ID, so forks cannot publish and ownership transfers do not disable it. The README flags the code and proposals as early drafts that evolve through their own CHANGELOG.md files, and reminds maintainers that, after the transfer to T-Auto/dsh-std, each npm package's trusted publisher must be reconfigured to owner T-Auto, repository dsh-std, workflow release.yml with no environment.
DSH Standard(仓库 T-Auto/dsh-std,MIT 协议)是面向 DeepSeek Harness 生态的"通用互操作协议集",核心包 @dsh-std/core 是一个元协议,定义协议如何声明、协商(apiVersion + kind、requires / supports、纯函数协商),本身不含任何命令、模型、UI 等领域概念。在它之上独立版本化地承载 Command、Tool、Model、Presentation 等领域协议。仓库提供 @dsh-std/adapter-dsh 作为 DSH 上游运行时与协议层之间的单向适配器,吸收上游重构带来的破坏性变更,让 TUI、Web、远程 SSH、无头守护进程等宿主都能平等接入。
面向作者与生态团队,DSH Standard 提供一次编写、多宿主运行的契约:插件按标准协议写作,附带静态 dsh-plugin.json 清单,市场端可在不执行代码的情况下毫秒级判定兼容性;按需激活的 Facet 模型让前端 UI 与后端逻辑共包、按宿主需要加载,禁用即彻底回收监听器与计时器。开发者可阅读 docs/architecture.md、docs/proposals/(含端点连接草案)以及 packages/README.md 选择最小可用包面,追求"Host + 插件清单"形态的项目可参考 dsh-ecosystem-spec 提供的 TUI Profile。
依赖与发布:开发要求 Node.js ^22.19 || >=24 与 pnpm,执行 pnpm install 与 pnpm check 完成本地校验;版本号写入各 packages/*/package.json,推送 main 后自动 OIDC 发布到 npm 并打 tag、生成 GitHub Release,rc/alpha/beta 用作对应 dist-tag。文档明确说明状态仍为早期草案,欢迎社区以自愿方式实现并通过一致性套件。
请帮我安装这个 DSH 插件。安装前先完成【兼容性检查 + 安全性检查】,检查通过再动手。
插件:dsh-std(T-Auto/dsh-std)
仓库:https://github.com/T-Auto/dsh-std
本站详情页:https://www.yhbd.top/plugins/t-auto-dsh-std/
本站登记:类型 plugin · 归类 原生 DSH 插件 · 许可证 MIT · ⭐ 151 · 最近提交 2026-10-03 · 主语言 TypeScript · 未检测到 DSH 插件清单
按下面顺序执行,每步先把结论告诉我,再进入下一步:
【1 兼容性检查】
① 我这边:DSH 版本、Node 版本、操作系统、当前 profile(web / desktop)。
② 读它的 README、package.json、插件 manifest,列出它要求的 DSH 版本 / Node 版本 / 操作系统 / 外部依赖 / 需要另外先装的运行时。
③ 逐条比对,结论只写「满足 / 不满足 / 未知」三种;不满足的给出可行替代方案。
④ 检查是否和我已装的插件冲突:命令名重复、skill / tool 重名、端口占用、重复注册的 MCP server。
【2 安全性检查】
① 仓库可信度:和上面「本站登记」是否一致;star / fork 数、创建时间、最近提交,是否归档或长期停更。
② 安装脚本:逐行看 package.json 的 preinstall / install / postinstall,以及 install.sh、setup.ps1 之类脚本。出现 curl|bash、下载后直接执行、混淆代码、访问与插件功能无关的域名,立刻停下来告诉我,不要继续装。
③ 依赖:列出新增依赖,标出无人维护、或与知名包拼写近似的可疑包(typosquatting)。
④ 权限与副作用:它会读写哪些目录、访问哪些域名、需要哪些 DSH 权限(filesystem / network / shell / clipboard 等),以及怎么卸载和回滚。
⑤ 如果它要求 sudo / 管理员权限,或权限明显超出功能所需,先停下来问我。
【3 安装】
上面两步没有「不满足」和「高危项」时才执行;用官方推荐方式安装,不要自行提权。
【4 汇报】
用表格输出:检查项 / 结论 / 依据 / 是否需要我决策。拿不准的一律写「未知」并说明要我怎么确认——不要猜,也不要替我决定。
Send this message to DSH in your current session: it verifies compatibility and security first (answering met / not met / unknown item by item) and only installs once everything checks out — it will stop and ask you if it finds a high-risk item. The box scrolls; the copy is the full prompt. CLI install commands may not be accurate across systems, so DSH is the safer route.把上面这条消息直接发给当前会话里的 DSH:它会先核对兼容性与安全性(逐条给「满足 / 不满足 / 未知」),确认没问题再安装,有高危项会停下来问你。框内可滚动,复制到的是完整提示词;安装命令不一定准确,发给 DSH 更稳。
- No DSH plugin manifest detected - it may only carry the dsh-plugin topic, so the install method must be confirmed on the spot未检测到 DSH 插件清单:可能只是打了 dsh-plugin 话题,安装方式要现场确认
DSH walks through these 9 checksDSH 会逐条核对这 9 项
Compatibility兼容性
- DSH, Node, OS and profile requirementsDSH 版本 / Node 版本 / 操作系统 / profile 是否满足要求
- External dependencies and runtimes (Electron / Python / Docker, ...)外部依赖与运行时(Electron / Python / Docker 等)是否齐备
- Conflicts with installed plugins: command names, skill / tool names, ports, duplicate MCP registration与已装插件是否冲突:命令名、skill / tool 重名、端口占用、重复 MCP 注册
Security安全性
- Repo matches the facts registered here; archived or abandoned?仓库是否与页面登记一致,是否归档或长期停更
- Safety of preinstall / install / postinstall and install.sh / setup.ps1preinstall / install / postinstall 与 install.sh、setup.ps1 是否安全
- curl|bash, download-then-execute, obfuscation, unrelated domains → stop immediatelycurl|bash、下载即执行、混淆代码、无关域名 → 立刻停止
- Typosquatting or unmaintained packages among the new dependencies新增依赖里有没有 typosquatting 或无人维护的包
- Requested permissions vs. what the feature actually needs申请了哪些权限、是否超出功能所需(filesystem / network / shell / clipboard)
- Any sudo / admin requirement, plus uninstall and rollback是否要求 sudo / 管理员权限,以及卸载与回滚方式
Anything uncertain must be marked unknown with a note on how to confirm it. This site's signal screen is a static snapshot, not a security audit.拿不准的必须标「未知」并说明要我怎么确认。本站的信号筛查是静态快照,不能替代安全审计。
Or use CLI install (for developers)或使用命令行安装(适合开发者)
CLI Install命令行安装
dsh plugin --profile web add github:T-Auto/dsh-std
把 T-Auto/dsh-std 加入你的 DSH 配置(web profile)即可启用。
READMEREADME
DSH Standard
English | 中文
In plain terms, DSH Standard is a set of universal interoperability protocols. Its goal is simple: let DSH plugins, background runtimes, and various user interfaces (TUI terminals, Web UIs, desktop apps, headless daemons) decouple cleanly and work together smoothly.
@dsh-std/core is a "meta-protocol" (the protocol about protocols). Domain-specific protocols—like Command, Tool, Model, and Presentation—sit on top of this meta-protocol substrate for discovery and negotiation, each versioned independently. Different hosts and applications only implement the parts they actually need.
Reference packages provide types, validators, and pure-function negotiators. Conforming implementations are not required to depend on these npm packages, nor do they need to run inside DeepSeek Harness.
What is a "Meta-protocol" (The Protocol About Protocols)?
Most protocols you deal with handle specific domain tasks:
- A Command protocol handles how commands are registered and executed;
- A Model protocol governs how LLM providers are plugged in;
- A Presentation protocol handles UI dialogs, questions, and approvals.
In contrast, @dsh-std/core knows zero domain business fields (it doesn't even know what a command or a model is). It is purely the "protocol about protocols":
- It defines universal primitives: how protocols are identified (
apiVersion+kind), how participants declare what they need (requires) and what they provide (supports), and how to run pure-function negotiations to output a structured compatibility report. - An analogy: It works like the USB interface specification. The core only cares about physical pinouts, slot dimensions, and handshake negotiation. Whether you plug in a mouse, keyboard, thumb drive, or webcam, the core never needs to know or change.
Why is this powerful?
Monolithic frameworks hardcode every capability (commands, storage, events) into a central SDK; whenever a new domain arises, the entire framework requires a release or a breaking change. Under a meta-protocol architecture, the protocols themselves are pluggable plugins: public standards, community extensions, and private protocols alike register as standalone protocol definitions. The core never changes, letting the ecosystem evolve boundlessly on its own.
Showing the opening section of the README — the full document lives in the repository以上为 README 开头摘要,完整文档在仓库内 · View the full README on GitHub →在 GitHub 查看完整 README →
yogsoth-ai/de-anthropocentric-research-engine
ZSeven-W/dsh-openpencil
HanaAyane/dsh-reasoning-effort
HuanLinOTO/dsh-plugin-better-sidebar-plugin-office
joeseesun/qiaomu-rss-dsh