dsh 插件合集 Kostas-Xafis/dsh-plugins

dsh-plugins

一组用于 DeepSeek Harness（dsh）的插件——这些浏览器端扩展用于定制 dsh web 配置文件：一个主题选择器、一个 API 高峰时段指示器，以及通知提示音。

每个插件都是一个自包含的包，拥有自己的 package.json、README.md 以及已提交的 lib/ 打包产物。没有构建步骤：客户端模块按提交时的原样提供给页面。

这里有什么

| 插件 | 功能 | 显示位置 | 测试 |
| dsh-theme-gallery | 十二套完整调色板（内置 Original 加十一个主题），通过在主题服务上叠加一个令牌覆盖层来绘制。 | Settings → Plugins → Plugin configuration 中的一张卡片，位于 _Shell_ / _Agent loop_ / _Subagent_ / _Web search_ 旁边。 | 22 |
| dsh-peak-hours | 一个实时的高峰/非高峰计费指示器，带有到下一次切换的倒计时以及各模型的实际价格。 | 侧边栏中的一个胶囊标签，位于 New Session 正下方。 | 7 |
| dsh-notify-sound | 三种简短的 Web Audio 提示音——消息已发送、请求提问/批准、代理空闲。无需音频资源。 | 可听见，无可见 UI。 | — |

这三个都是仅客户端（web 平台）：宿主端部分刻意保持惰性，其存在只是为了让包有一个加载器行，而正是这一行将其浏览器打包产物放入客户端模块启动图中。

安装

每个插件都是一个自描述的包：它附带一个 cordis.patch.yml，并在其清单中声明 dsh.bundle.patch。这正是 dsh plugin add 既能安装_又能_激活它的原因——无需克隆，无需手动编辑 YAML。

1. 前置条件：pnpm

dsh plugin 是一个轻量的 pnpm 转发器，因此 pnpm 必须在 PATH 上，否则它会失败并提示
pnpm not found on PATH。使用随 Node 一起提供的 corepack：

corepack enable pnpm

2. 安装

all three
for p in dsh-theme-gallery dsh-peak-hours dsh-notify-sound; do
dsh plugin --profile web add "github:Kostas-Xafis/dsh-plugins#path:/plugins/$p"
done

or one at a time
dsh plugin --profile web add "github:Kostas-Xafis/dsh-plugins#path:/plugins/dsh-peak-hours"
每条命令都是独立的——只安装你想要的插件。#path:/plugins/ 会从这个 monorepo 中选中单个包（pnpm 的 git 子目录支持）。

3. 重启服务器

打包层在启动时组合，所以仅执行 add 还不会激活任何东西。CLI 会把该包追加到 dsh.profile.bundles，而这个列表会在 profile 加载时被读取——只有 cordis.patch.yml 是被实时监视的。重启服务器，然后重新加载页面：

停止正在运行的服务器（Ctrl-C），然后再次启动它
dsh web

插件自身的补丁层会在启动时插入它的宿主行，而这又会把它的浏览器 bundle 放入客户端模块图中。

跳过重启是得出“安装没有生效”这一结论的最常见原因：包已安装并列出，但没有任何行被组合。

管理已安装的插件

dsh plugin --profile web list # 已安装的内容
dsh plugin --profile web update # 拉取最新提交
dsh plugin --profile web remove dsh-peak-hours # 卸载并停用

- list 打印该 profile 的插件依赖。
- update 会就地重新解析 git 引用，并保持 dsh.profile.bundles 不变，因此不会停用任何东西。
- remove 会一并移除该依赖、它在 dsh.profile.bundles 中的条目以及它的加载器行。

update 和 remove 带来的更改同样是打包层更改，因此它们也需要重启才能生效。

无需构建步骤

lib/ 已提交到仓库，因此通过 git 安装不需要 prepare 脚本，也永远不会触发 pnpm 的“构建脚本被阻止”提示。

替代方案：按路径挂载

如果要在原地修改插件，你仍然可以克隆仓库并直接挂载这些目录。打包行使用与下面这些行相同的 id，并且每一行都是最后一层生效——因此，如果你从一种方法迁移到另一种方法，请移除你正在替换的那些行。

git clone https://github.com/Kostas-Xafis/dsh-plugins.git \
~/.dsh/profiles/web/plugins/dsh-plugins

将 examples/cordis.patch.yml 追加到 ~/.dsh/profiles/web/cordis.patch.yml。id 是任意的，但必须唯一；name 相对于 ~/.dsh/profiles/web/ 解析。

由于这是编辑 cordis.patch.yml 而不是 bundle 列表，它是唯一一种实时生效的安装方法——patchReload: live 会在不重启 dsh web 的情况下组合该层，因此只需重新加载页面即可。这使得在迭代插件时，按路径挂载是更好的选择，而上面的 bundle 安装则更适合稳定的设置。

开发

需要 Node.js ≥ 20。唯一的外部依赖是 @deepseek-ai/schemastery，它由 harness 本身在运行时提供；它被声明为 devDependency，以便宿主半部分的测试可以在 harness 之外运行。

npm install
npm test

测试针对已提交的 bundle 运行——lib/client.js 会在一个 vm 上下文位于一个伪造的模块加载器门面之后，而不是从源码重新导入——因此它们能捕获任何已发布打包产物可能悄然出错的问题：语法错误、不是 { light, dark } 图层的调色板，或者一个从未触及它所声称要绘制的服务的应用器。

布局

plugins/
dsh-theme-gallery/ package.json, cordis.patch.yml, lib/{index,client}.js, test/, README.md
dsh-peak-hours/ package.json, cordis.patch.yml, lib/{index,client}.js, test/, README.md
dsh-notify-sound/ package.json, cordis.patch.yml, lib/{index,client}.js, README.md
examples/
cordis.patch.yml path-mount rows, for the alternative install

每个插件都在一个清单中声明两个面：dsh.client（浏览器那一半，由客户端模块图发现）和 dsh.bundle（挂载它的配置文件补丁层）。每个插件自己的 README.md 是其行为、调优旋钮、无障碍模型和已知限制的权威依据。

说明

- 每个包都故意设置 "private": true：它们从 git 安装，而不是从 npm。只有在你想要发布它们时，才应将其翻转（并添加一个作用域以避免名称冲突）。
- lib/ 已提交，因此 git 检出即可立即加载。在运行中的配置文件下编辑 lib/client.js 会被客户端模块的 HMR 监视器拾取，并以新的哈希重新提供。
- Bundle 行以裸包名而非子路径来命名插件：客户端模块扫描器读取已解析模块最近的 package.json，而指向嵌套文件的行会被跳过——宿主那一半会挂载，而浏览器那一半会悄然永不加载。

许可证

MIT — 参见 LICENSE。