dsh-plugin-shop

---

📦 安装

下面两条路做的是同一件事，按读者是谁挑一条。

🧑 给人看

前置条件： Node.js。运行 harness 本身无需安装——上游文档的形式是 npx -y @deepseek-ai/dsh web。插件管理经由 dsh plugin，它会分别 spawn dsh 命令和 pnpm——用一条命令装好两者：npm install -g @deepseek-ai/dsh pnpm，并用 dsh --version 和 pnpm --version 验证。

# dsh 在 PATH 上（全局安装）。必须钉版本号：pnpm 11 会拦下刚发布的新版本，
# 不写版本号的裸安装可能给你旧版。下面是当前版本——用
# `npm view dsh-plugin-shop version` 查最新值。
dsh plugin --profile web add dsh-plugin-shop@0.9.4
# 或全程走 npx，什么都不装：
npx -y @deepseek-ai/dsh plugin --profile web add dsh-plugin-shop@0.9.4

如果你用的不是 web profile，把它换成你自己的。然后重启一次 dsh——新加的 bundle 不会作用于 已在运行的进程——再打开

左侧栏里的 插件商店

进去是一片插件卡片货架，带搜索框。首次加载要联网读目录，可能要等几秒，期间由一层扫光骨架占位。

🤖 给 agent 看

全程非交互，无提示、无需确认。--profile 是必填的——不给它，dsh plugin 会以 error: required option '--profile <name>' not specified 退出。

1. 确定 profile 名。 profile 是 $DSH_HOME/profiles 下的目录（$DSH_HOME 默认 ~/.dsh）。那里还会出现 node_modules，它不是 profile。

ls -1 "${DSH_HOME:-$HOME/.dsh}/profiles" | grep -v '^node_modules$'

2. 安装。 钉版本号——显式钉版本能绕过 pnpm 的发布冷却期，确定性安装本来也是 agent 路径的要点。

dsh plugin --profile <profile> add dsh-plugin-shop@0.9.4

3. 验证——这步别省。 第 2 步返回 0 只说明 pnpm 解析到了这个包，不代表 profile 会加载它。 要断言的是 bundle 列表：

dsh plugin --profile <profile> list --depth 0

dsh-plugin-shop 必须出现并带有已解析的版本号。想直接读清单也行，同一事实位于 $DSH_HOME/profiles/<profile>/package.json 的 dsh.profile.bundles。

4. 重启该 profile——dsh --profile <profile>，web profile 用 dsh web。启停已安装的 插件是热生效的；新增 bundle 不是。

失败模式

🖼️ 界面预览

✨ 能做什么

🔎 货架是怎么来的

目录不是谁手工维护的名单。每天跑六步，其中两步是这个货架值得一读的原因：

1. 全网爬取。 npm 上带 dsh-plugin 或 deepseek-harness 的包全部过一遍，外加把这些关键字 用作 topic 的 GitHub 仓库。不需要提交，也没有排队。
2. 逐个筛查。 采到的东西大多进不了货架； 仓库 README 顶部的实时徽章同时统计两边的数量。没有 dsh.bundle 的是库，不是插件；没有许可证或仓库的无从审查；npm 上已废弃的直接出局；仓库来源还额外要求无构建 脚本、无 workspace: 依赖——这两样任一都会让安装在你机器上失败；名字跟热门包只差一两个字符 的会被扣住，等人核过才放。十七种记录在案的拒收理由，全是 机械判定，每条拒收都附一句作者能读懂的话。
3. 分类与记录。 七个分类，每个插件必需的 peer 模块——只记名字，从不记版本范围——以及作者 自己声明的 dsh.compatibility（如果有）。
4. 发布。 内容寻址的 JSON，同时发到 npm 与 GitHub Pages。
5. 在你这边拉取。 本包竞速多个来源，并在信任任何字节之前校验 sha256。
6. 依赖检测也在你这边。 你的安装拿那些 peer 名字去查你自己的 profile，再剔除 dsh 网页端 自己就提供的模块。两边都没有的，卡片显示不兼容并列出缺了什么；作者声明支持的 dsh 版本或 profile 跟你正在用的不符，卡片同样显示不兼容，并写明声明的是什么、你实际运行的是什么。 这个结论必须在你机器上算，因为答案取决于你实际跑的是哪个 harness，而不是构建当时跑的那个。

完整流程图在 仓库 README。

有一件事它没有做：没有任何一条收录被人读过。今天 verified.yml 是空的，全部条目都是社区 层。机械筛查不等于评审。

🧩 结构

一个包里装了两半，两者之间的分界就是安全边界：

攻破浏览器那一半，攻击者拿到的就是那九个调用，别无其他。

⚙️ 配置

插件目录会从几个来源里挑最先响应的那个读：npm 包 dsh-plugin-shop-catalog（走你配置的 registry、npmmirror 或 npmjs），或者 https://LivXue.github.io/dsh-plugin-shop/v1/。几个来源的内容完全一致，之所以要赛跑，是因为不同网络到它们的快慢可以差出几百倍。设了 DSH_SHOP_CATALOG_URL 就不再赛跑，只读你指定的那个。

📚 目录

每日从公共 npm registry 构建，以静态 JSON 发布：

• /v1/index.json —— 指针，携带 schemaVersion、builtAt、收录数 count 与过滤数 rejected（上面的徽章实时读它们）和内容哈希
• /v1/plugins.<sha256>.json —— 数据，内容寻址，可无限期缓存

指针足够小，适合轮询。在信任数据文件的任何一个字节之前，商店会先用指针里的 sha256 校验它。

⚠️ 不作何承诺

出现在货架上不等于背书。

capabilities 只是作者对自己包的自述。v0 没有沙箱，界面也从不把这个字段渲染成一份被强制 执行的权限清单。verified 层的含义是有人读过那个确切版本；一旦发布新版本就降级为 verified-stale，评审记录仍钉在它当初对应的版本上——所以过一次评审，买不到后续每个版本的信任。

🏷️ 面向插件作者

在 package.json 里加上采集关键字——"keywords": ["dsh-plugin"] 或 "keywords": ["deepseek-harness"]——然后发布；或者不走 npm：把关键字作为 GitHub 仓库的 topic， 并在仓库根放一个带 name 和 dsh.bundle 的 package.json——目录会收录该仓库并把默认分支的 commit 钉为版本。每日构建就会找到你，不需要向本项目提交任何东西。声明 dsh.catalog 段可以自己掌控分类、简介和 capabilities；不声明，目录会从 你的 npm description 推导一条 listing。

完整参考：docs/schema.zh.md。

📄 许可

Apache-2.0 © LivXue