dsh-safe-plugin-manager

DSH STORE | DeepSeek Harness Plugin Marketplace

DSH STORE is a third-party DeepSeek Harness (DSH) plugin marketplace and guarded lifecycle manager. It is the canonical project behind dsh.store, where users discover plugins, inspect pinned sources and permissions, and follow a recoverable access path.

DSH STORE 是一个运行在 DeepSeek Harness（DSH）设置页中的第三方 插件商城与安全生命周期管理器。它使用标准 DSH Bundle + Host Plugin + Client Bundle 结构，不开发独立桌面端，不修改 DSH 源码，也不替换任何 @deepseek-ai/* 官方包。

想把插件上架到 DSH-Store？ 提交一个公开 GitHub 项目地址 即可。机器人会自动读取必要文件，不再要求手填整份 Catalog。开发或提交前，建议先用 build-dsh-plugin 制作或执行只读商城预检。

打开在线插件商城 · 阅读项目 Wiki · 提交项目上架 · 使用 build-dsh-plugin · 查看机器目录 · 目录准入规则 ·

旧版更新安全修复： 如果商城或其他插件更新出现

ERR_PNPM_GIT_DEP_PREPARE_NOT_ALLOWED，不要放开整个 Profile 的 prepare 权限，也不要手改

Profile。请通过国内站或

GitHub Pages

查看官方修复/升级方案；修复页只有在 Catalog 固定到包含修复器的完整 Commit 后才会生成命令。

在 DSH 原生「发现」中添加商城

DSH 0.2.1-alpha.4 新增实验性「自定义插件市场」。在 插件 → 实验性插件 → 更多 中打开它，再进入 发现 → 添加索引源，填入：

• 国际站：https://dsh.store/plugin-market.json
• 国内站：https://dsh-store.cn/plugin-market.json
• GitHub Pages：https://ai-scarlett.github.io/DSH-Store/marketplace/plugin-market.json

原生索引按官方 format: 1 生成，仅包含已批准条目，来源锁定完整 Git Commit；兼容范围只包含 Catalog 明确声明兼容的版本。未知版本不会自动扩大支持范围。发布时间取该固定 Commit 的公开时间。索引会随正式站点每三小时刷新；添加索引源属于当前 Profile，安装仍需核对 DSH 确认框中的来源。关闭实验性市场或删除索引源可撤销接入。

DSH 从此版本优先读取插件的 engines.dsh，缺少它时才检查所有 DSH peer。Store 保留逐版本声明与隔离运行证据；范围声明、源码检查和真实 Desktop 验收分别记录。

安装插件商城

前置条件

• 已有对应版本的安装、启动和卸载证据；只有版本范围或 Peer 声明时仍视为待验证。卸载后的 Profile 还原与版本降级回滚分别验收，unknown 不等于通过。Web Profile 的包操作需要官方 dsh CLI；
• Node.js ^22.19.0 或 >=24.0.0；
• 一个启用了 Web 客户端的目标 Profile。下面以 web 为例，如果你的 Profile 名称不同，

请替换命令中的 web。

首次安装发生在本管理器尚未运行之前，因此还没有计划确认、自动备份、健康检查和失败 回滚保护。运行命令前，请先备份目标 Profile 的 package.json、pnpm-lock.yaml、 pnpm-workspace.yaml 和 cordis.patch.yml（文件存在时）。

使用固定 GitHub Commit 安装

优先使用上方的原生索引，或从当前修复入口核对受审的固定源码。 当前 0.9.8 已在官方 RC.1 / RC.2 的一次性 Web Profile 中完成安装、启动、鉴权接口、卸载与原 Profile 还原验证；真实 Desktop 界面和版本降级回滚未验收。 通过 DSH 官方 CLI 安装当前 Catalog 固定的 0.9.8 Commit：

dsh plugin --profile web add --ignore-scripts --config.auto-install-peers=false 'git+https://github.com/AI-Scarlett/DSH-Store.git#8150c5ff43ca11b89aac4151c0f78e2c34777fb6'

这条命令会修改目标 Profile 的依赖、锁文件、工作区文件、node_modules 和 Bundle 列表。 不要把 Commit 换成 main 等浮动分支，也不要绕过 DSH CLI 直接运行 pnpm 或手工编辑 Profile。命令失败时请保留完整错误和安装前备份，不要连续重复执行。

历史引导固定点 git+https://github.com/AI-Scarlett/DSH-Store.git#0bc733064bfc8ff16f6e8144188a7ac563092e12 对应 0.8.5，仅供历史审计；它不是当前安装入口，不能用于 RC.1 / RC.2。

重启与验收

1. 运行 dsh --profile web --dump-config，确认配置可以成功合成；
2. 在商城中用独立计划安装随包提供的 DSH Guardian；它由 macOS launchd 在 DSH 进程外运行，

不是另一个普通 DSH 插件。安装器会先验证新 Guardian 的独立心跳，再在 HTTP 响应返回后交接旧 Host；验证失败会恢复 Guardian 文件且不关闭当前 Host；

1. 包操作完成后，商城会明确标记“待重启”。只有 Guardian 心跳正常时才允许生成一次性的

RESTART DSH 计划；

1. Guardian 是 DSH web Profile 的唯一启动所有者。启用后不要再手工运行 pnpm dsh web 或

dsh web，否则第二个实例会因争抢 127.0.0.1:3080 而以 EADDRINUSE 退出；

1. Guardian 同时验证首页 HTTP、商城 runtime API、Profile 和 Boot ID；只有身份一致并持续稳定

30 秒才判定健康。连续探测失败才执行有界重启，5 分钟内最多失败 3 次；

1. 页面检测到新的 Boot ID 后重新读取插件清单与健康报告，只有通过才显示“已重启并生效”；
2. 如果安装、重启或页面显示异常，请在

GitHub Issues 提交原始错误， 不要提交凭据、完整 Profile 文件或环境变量。

安装完成后，从商城发起的安装、更新、迁移、停用、启用和卸载才会进入一次性计划、 精确确认、Profile 前置哈希、备份、健康检查和失败回滚流程。

官方 Desktop

官方 Desktop 使用独立的 desktop Profile 与应用自身的插件管理器。商城在该环境中绑定当前 Desktop Profile，提供目录、已安装状态和只读诊断；安装、更新、启停、卸载与 Host 重启请使用 DSH 官方“插件”页及应用更新入口。商城不会将 Desktop 操作误送到 web Profile，也不会让固定 3080 端口的 Guardian 接管 Desktop。Desktop 打包应用中的可见界面仍需单独实测，不能由 Web Profile 的自动测试推定。

当前概况

项目 · 当前状态 商城版本 · 0.9.8 收录条目 · 以 GitHub registry/catalog-index.json 的实时 entries.length 为准 可安装 · 以实时 Catalog 中 status: approved 的条目数为准 商城不可安装 · 以实时 Catalog 中 blocked / unlisted 的条目数与 statusReason 为准 分类 · 22 个 推荐 · 商城“只看推荐”与官网推荐榜共享公开作者互动名单，完整分页；推荐不改变审核或安装资格 目录来源 · GitHub 仓库 + 不可变 Commit

0.9.4 在官方 dsh-app:// 渲染器中停用依赖 Web Host 的商城请求和 Guardian 轮询；如果商城面板被桌面端加载，会显示只读说明并引导至 DSH Store 网页目录和桌面端内置“插件”页面。它不访问或修改 Web Profile。此安全交接不代表商城已能在桌面端内嵌浏览或安装插件；Catalog 仍只声明 web Profile，真实打包桌面端 UI 尚未验收。版本号同步提升至 0.9.4，避免已安装用户因同版本修复无法收到商城更新。

0.9.3 将官方 Desktop 绑定到其实际 Profile，并在服务端拒绝不受支持的商城写入、Guardian 与重启操作；商城界面明确展示只读模式。版本面板从 Desktop 内置的官方 DSH 包读取当前版本，不提供修改桌面应用运行时的 npm 命令。0.2.0-rc.2、0.2.1-alpha.1、0.2.1-alpha.2 已在 PR 的一次性 Web Profile 中完成安装、启动、卸载和精确回滚验证。@deepseek-ai/dsh-client-runtime 的 0.2.x 尚无独立 npm 包，但其精确 Peer 版本声明是官方 Host 安装前检查的契约；移除后一次性 Profile 安装在最新三版均失败。源码、Catalog、生产站点和真实 Desktop 界面各自需要独立验收。

0.8.14 修复“开发者提交了新代码但没有提升插件版本号”时新用户无法安装新代码的问题：自动任务会把同版本的新 Commit 纳入与正常版本更新相同的固定源、身份、许可证、Bundle、权限和最新三个 DSH 版本兼容审查；通过后移动 Catalog 的完整 Commit 固定点，因此未安装用户会直接安装审核后的新 Commit。已经安装相同版本的用户不会在商城里收到覆盖式更新，商城只展示 Catalog 固定 Commit 与 GitHub 手动命令，并明确说明该操作不受商城备份、健康检查和失败回滚保护。真正提升 SemVer 的版本仍使用商城事务更新。

0.8.13 适配官方 DSH 0.1.2 预发布系列的浏览器令牌认证：Guardian 现在把未认证根路径的预期 401 视为 Web 端口存活，但仍必须通过商城运行时接口核对 Profile 与 Boot ID，不能把未知占用者误认成 DSH。当前官方最新预发布版是 0.1.2-rc.1，商城按 0.1.2-alpha.4、0.1.2-alpha.5、0.1.2-rc.1 维护动态三版本窗口；没有精确证据的字段保持 unknown，不会由版本范围猜测成已验证。无生命周期脚本插件更新保护和独立 launchd Guardian 交接器保持不变。

0.8.11 修正分表发布的历史客户端回归：registry/catalog.json 继续作为低于 2 MiB 的 schemaVersion 1 兼容桥，但现在为每个索引条目保留旧版验证器、搜索、权限展示和固定来源操作所必需的有界字段；因此尚未升级的 0.8.5–0.8.7 客户端也能看到完整目录，而不是只看到商城自身。长证据摘要、逐版本操作记录和其他详情仍只存放在独立详情文件中。公共 watchdog 同时从详情文件水合商城 Commit，避免把三个正常修复入口误报为失败。

兼容桥会省略旧版验证器可准确还原的空 unknown 证据记录；仅当完整目录逼近 2 MiB 上限时，按固定级数减少旧客户端的搜索别名。每条插件的身份、状态、原因、兼容性、权限和固定 Commit 仍保留，v2 索引与详情继续保存完整搜索词及证据。超出上限且无法安全压缩时自动化仍会停止，不发布截断目录。

0.8.9 把 Catalog 分成三层：registry/catalog.json 是旧版兼容桥，并用 indexPath、SHA-256、字节数和条目数固定下一层；registry/catalog-index.json 是完整轻量主索引，只承载插件编号、中英文名称、版本、推荐标记、顺序、GitHub 地址及有界分页辅助字段；registry/catalog/details/.json 保存权限、兼容性、完整证据和安装信息。新商城验证桥接摘要后读取索引，并且每页只懒加载 20 个详情；桥、索引或详情身份不一致时失败关闭，不会混用远程索引与本地详情。兼容桥和主索引上限均为 2 MiB，单详情上限为 512 KiB。0.8.8 先把旧的单体 Catalog 读取上限有界提高到 4 MiB，作为迁移过渡。

0.8.10 为历史安装增加 Catalog 固定的官方安全修复器和双站 /repair/ 页面。修复器只接受 完整 Git Commit 和交互式确认，备份 Profile 后通过官方 DSH CLI 使用 --ignore-scripts 更新，不执行任何第三方生命周期脚本；配置合成失败会恢复 Profile 和依赖。 Guardian 可用时，修复器会写入可回滚冷启动记录、请求重启并等待新的 Boot ID 稳定；没有 Guardian 时明确停在“等待安全重启”，不把包更新误称为运行验收。修复页只有在 Catalog Pin 完成后才显示命令，避免源码 PR 与目录固定之间出现可执行的浮动窗口。

历史用户保留与更新路径

• 已安装 0.8.5、0.8.6 或 0.8.7 的用户仍可读取低于 2 MiB 的 registry/catalog.json 完整兼容目录，正常看到全部条目，并从商城自身条目发现固定 Commit 的最新修复版本；三个历史版本的原始 Catalog 验证器、搜索和更新卡片逻辑均有回归测试覆盖。
• 更新到 0.8.8 后，商城仍可读取兼容目录；更新到 0.8.9 及之后版本后，则验证并使用轻量主索引和按页详情懒加载。无论从哪个历史版本升级，都不依赖浮动分支或未知生命周期脚本。
• 0.8.9 验证 indexPath 与 SHA-256 后读取完整索引，后续 Catalog 增长不会再次堵住商城自身的更新入口。
• 所有真实 Profile 更新仍使用商城已有的一次性计划、精确确认、官方 DSH CLI 固定参数、前置哈希、备份、健康检查和失败回滚；GitHub 发布不会自动修改任何已安装 Profile，也不要求执行未知修复脚本。
• 0.8.12 起，Catalog 声明为无生命周期脚本的所有插件在安装、更新和迁移时都会加 --ignore-scripts；只有 Catalog 明确列出的目标插件脚本才使用仅限该包的 --allow-build=。因此历史用户修复商城后，更新其他插件也不会再被 Profile 中无关 Git 依赖的 prepare 阻断。
• 0.8.14 起，同版本新 Commit 审核通过后只改变新安装的固定来源；已有安装不会出现商城“更新”按钮，用户如确实需要覆盖，只能复制界面显示的 GitHub 完整 Commit 命令自行操作，并自行承担备份、重启和回滚。

0.8.7 把自动更新、商城兼容展示和 Catalog 门禁统一到官方 npm latest/alpha/beta/rc 最高有效通道，排除 next 独占和 deprecated 版本，并动态要求最新三个 DSH 版本的精确兼容证据；旧版本独占或全为 unknown 的已上架插件会被可逆地下架并进入不可安装复核候选。商城自身的自动审查允许单个运行文件最多 4 MiB、总运行文件最多 8 MiB，其他插件继续使用更严格的通用上限；Owner Report 的各明细表最多展开 20 条，完整记录保留在 Run Artifact。0.8.6 增加稳定版与官方预发布标签的联合检查。0.8.5 增加旧版商城自举更新桥：Catalog 仍保留 partial 的真实语义，但可以用 status: unknown 加 evidenceStatus: partial 的 schemaVersion 1 兼容编码发布。0.8.2 会保守地把这些记录显示为“未知”，不会再因为不认识 partial 而拒绝整个目录；当前版本则继续显示“部分验证”。这样已安装用户可以直接在商城里看到固定 Commit 的管理器更新，经过一次性计划、确认、备份和健康检查后更新，再由 Guardian 引导重启，不需要手动运行 CLI。

0.8.4 是 AI-Scarlett/DSH-Store 的规范仓库迁移版本：运行时 Catalog、候选库、Bundle 默认配置、静态商城、提交入口、自动化策略、部署脚本和 Pages 监测均使用新地址。npm 包名和 DSH Bundle 入口仍为 dsh-safe-plugin-manager。

0.8.3 修复远端 Catalog 使用“部分验证”（partial）证据时被旧枚举误判为 CATALOG_INVALID、进而回退内置快照的问题。运行时仍然先验证 GitHub Raw Catalog；未知或畸形内容仍会失败关闭并清楚标记为内置快照。此兼容修复以新的 SemVer 发布，避免同版本源提交无法被商城更新流程识别。

0.8.2 延续每页 24 条的有界加载和来源排序，并新增动态 DSH 兼容矩阵：最新版本从官方 npm Registry 读取，失败时退回目录版本且不阻塞插件列表；只有精确目录证据显示“兼容”，仅命中声明范围的新版本显示“范围支持·待验证”，生命周期证据继续保持未知。该版本还新增所有标签页常驻的 Boot Guard：插件更新或 Guardian 重启后先校验新 Boot ID、Guardian healthy 状态和首页资源，连续稳定后再用带 Boot 参数的新 URL 恢复；BroadcastChannel 同步多标签页，轮询作为降级，同一 Boot 只导航一次；推荐条目在默认排序中置顶，可信安装支持“只看推荐”筛选，同版本源仓库提交不再误报为插件升级阻断。

商城已经在真实 DSH web Profile 中完成只读扫描、GitHub 在线目录刷新、配置合成、 Host API 和设置页显示验证。单元、契约和事务测试已通过；真实生产 Profile 的完整 “安装—重启—停用—启用—更新—卸载—回滚”闭环仍是独立验收项，不能由测试结果替代。

功能介绍

插件发现与分类

• 将 registry/candidates.json 候选发现库与 registry/catalog.json 可信安装库物理隔离；候选条目没有包名、安装路径、入口 ID、权限或安装动作，必须经过固定 Commit 审核后才能晋级；
• 从 GitHub 在线目录读取插件，网络失败时只回退到随包发布的已知快照；
• schemaVersion 1 兼容桥和 v2 主索引都保持在 2 MiB 内，单个详情文件保持 512 KiB 上限；迁移期单体 v1 Catalog 仍可在 4 MiB 内读取；超限、网络失败或完整性不一致时失败关闭并标记回退原因；
• 按名称、包名、分类或 GitHub 仓库搜索；
• DSH 内嵌商城由 Host 每次最多返回 20 个条目，搜索、分类和翻页都使用有界响应；候选发现库只在打开候选视图后读取；
• 公共商城使用 20 条一页的上一页、页码、下一页导航；完整目录不再内嵌到 HTML，避免首屏解析兆字节级脚本数据；主索引与详情文件可分别缓存和读取；
• 支持 22 个分类筛选、推荐置顶、可信安装中的“只看推荐”筛选、上架、商城不可安装和下架；
• 默认按照 approved、推荐、官方最新 DSH 的精确兼容证据、范围支持待验证、GitHub 固定来源更新时间和安装量依次排序；范围不支持、证据未知或长期未更新的条目依次排在后面；
• 目录中的安装目标固定到 40 位 Git Commit，不接受 npm-only、任意下载地址或浮动分支；
• 商城页面和 DSH 内置界面共享同一组 catalog.json 兼容桥、catalog-index.json 主索引和独立详情文件。

四级可信证据

• Discovered：只证明项目已被发现或进入可信目录，不代表能够安装；
• Installable：必须有固定 Commit、标准 Bundle、明确入口和可复现的静态安装证据；
• Runtime Verified：必须绑定具体 DSH 版本、系统、Profile、时间和公开证据，单元测试不能替代；
• Security Reviewed：只表示指定方法和证据范围内完成了代码风险审查，不承诺代码绝对安全；
• 任何缺少公开证据的状态都保持 unknown，approved、作者声明、Stars、推荐或推广位都不会自动提高证据等级；
• promotionIndependentOfVerification 是目录的强制信任策略：推广只能改变曝光，不能改变审核结论、兼容性或安全状态。

安装与生命周期管理

• 安装 GitHub 目录中的标准 DSH Bundle；
• 不依赖商城服务端巡检全部仓库：仅在用户本机按需检查已安装插件或用户主动选择的插件；
• 从插件 GitHub 默认分支解析最新完整 Commit，绝不直接安装浮动 main；
• 安装前在该 Commit 上核对版本、许可证、Bundle Patch、入口 ID、生命周期脚本和变更中的权限信号；
• 更新差异展示旧/新 Commit、提交跨度、文件新增/删除/修改、增删行、网络主机、文件/命令/凭据风险信号和 DSH 官方目录触碰；页面不返回源码 Patch 正文；
• 低风险候选可以生成固定 SHA 更新计划；高风险候选在本机展示权限、脚本、依赖和代码变化，由用户逐次确认是否更新；
• 修改 DSH 原生代码、冒用 @deepseek-ai/*、停用/覆盖受保护组件或来源与安装契约不可验证的候选，商城禁止安装/更新，只显示不受商城保护的 GitHub 外部入口；
• 停用、启用和卸载第三方插件；
• 识别 link:、file:、workspace: 等本地开发来源，并单独提供“迁移到商城版”；
• 识别并标记不是通过本商城安装、来源漂移或与目录 Commit 不一致的插件；
• 商城自身仅允许更新，禁止停用和卸载。

DSH 版本检测

• 商城标题右侧显示当前运行中的 @deepseek-ai/dsh 版本，并按需读取 npm 官方 Registry 的最新版本；
• 检测使用 10 分钟缓存、请求超时、响应大小与包身份校验，失败不会阻断插件目录；
• 发现旧版本时提供官方 Release 和固定目标版本的 npm install --global @deepseek-ai/dsh@ 复制入口；
• 官方 DSH CLI 尚无自升级子命令，因此商城不会静默执行全局 npm/pnpm，也不会对源码工作区运行 git pull 或修改 DSH 源码。

安全事务与失败回滚

• 所有页面加载、搜索、目录刷新、健康检查和计划生成均为只读操作；
• 每次写操作都先生成一次性计划，展示目标 Profile、固定 Commit、生命周期脚本、

影响文件和精确确认语；

• 执行前检查 Profile 文件哈希并获取文件锁，防止并发修改；
• 通过官方 DSH CLI 使用固定参数数组执行包操作，不拼接 Shell 命令；
• 写入前创建备份，完成后执行配置健康检查，失败时自动回滚；
• 永久保护 DSH 源码、官方包、官方插件清单、用户 Patch 区块、会话、设置和凭据。

商城内置 DSH Guardian

• Guardian 随商城发布，但复制到商城自己的持久状态目录并由 launchd 独立运行；DSH

启动失败时不依赖 Host Plugin 或设置页存活；

• 安装 Guardian 仍需一次性计划、精确确认和文件哈希预条件，并明确展示将替换的启动任务；先验证

新 Guardian 的 launchd 注册、随包文件哈希和新鲜心跳，HTTP 响应成功后才延迟交接旧 Host； 验证失败会恢复原 Guardian 文件且不关闭当前 Host；

• 使用固定参数数组启动 DSH，不使用 bash -c，记录心跳、启动状态、失败次数和熔断状态；
• 将管理器验证过的命令 PATH 固化到 Guardian 配置；即使 launchd 与 Node 运行时 PATH 中没有

Homebrew，启动与离线依赖恢复仍能从全局 DSH CLI 安装位置找到可执行的 pnpm；

• Guardian 是 DSH web Profile 的唯一启动所有者；商城不再提供会启动第二个实例的复制命令；
• 健康判定要求首页 HTTP 和 /api2/dsh-safe-plugin-manager/runtime 同时成功，并核对 Profile 与

Boot ID。单纯能连接 3080 端口不再代表 DSH 健康；

• 端口若由外部 DSH 或未知进程占用，Guardian 会明确报告未持有所有权并停止启动，不会杀死、

冒充接管或再启动一个 DSH；