DSH-Store｜DSH 第三方插件商城

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

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

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

安装插件商城

前置条件

• DeepSeek Harness 0.1.0-rc.7 或更高版本，并且官方 dsh CLI 可用；
• Node.js 22.13.0 或更高版本；
• 一个启用了 Web 客户端的目标 Profile。下面以 web 为例，如果你的 Profile 名称不同， 请替换命令中的 web。

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

使用固定 GitHub Commit 安装

通过 DSH 官方 CLI 安装经过目录固定的 GitHub Commit：

dsh plugin --profile web add 'git+https://github.com/AI-Scarlett/dsh-safe-plugin-manager.git#8bb4b17836b593ebc29c77882503bc70f759bbc6'

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

重启与验收

1. 运行 dsh --profile web --dump-config，确认配置可以成功合成；
2. 在商城中用独立计划安装随包提供的 DSH Guardian；它由 macOS launchd 在 DSH 进程外运行， 不是另一个普通 DSH 插件。安装器会先验证新 Guardian 的独立心跳，再在 HTTP 响应返回后交接旧 Host；验证失败会恢复 Guardian 文件且不关闭当前 Host；
3. 包操作完成后，商城会明确标记“待重启”。只有 Guardian 心跳正常时才允许生成一次性的 RESTART DSH <profile> 计划；
4. Guardian 是 DSH web Profile 的唯一启动所有者。启用后不要再手工运行 pnpm dsh web 或 dsh web，否则第二个实例会因争抢 127.0.0.1:3080 而以 EADDRINUSE 退出；
5. Guardian 同时验证首页 HTTP、商城 runtime API、Profile 和 Boot ID；只有身份一致并持续稳定 30 秒才判定健康。连续探测失败才执行有界重启，5 分钟内最多失败 3 次；
6. 页面检测到新的 Boot ID 后重新读取插件清单与健康报告，只有通过才显示“已重启并生效”；
7. 如果安装、重启或页面显示异常，请在 GitHub Issues 提交原始错误， 不要提交凭据、完整 Profile 文件或环境变量。

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

当前概况

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

功能介绍

插件发现与分类

• 从 GitHub 在线目录读取插件，网络失败时只回退到随包发布的已知快照；
• 按名称、包名、分类或 GitHub 仓库搜索；
• 支持 22 个分类筛选、推荐置顶、上架、商城不可安装和下架；
• 目录中的安装目标固定到 40 位 Git Commit，不接受 npm-only、任意下载地址或浮动分支；
• 商城页面和 DSH 内置界面共享同一个 registry/catalog.json 数据源。

安装与生命周期管理

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

DSH 版本检测

• 商城标题右侧显示当前运行中的 @deepseek-ai/dsh 版本，并按需读取 npm 官方 Registry 的最新版本；
• 检测使用 10 分钟缓存、请求超时、响应大小与包身份校验，失败不会阻断插件目录；
• 发现旧版本时提供官方 Release 和固定目标版本的 npm install --global @deepseek-ai/dsh@<version> 复制入口；
• 官方 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；
• 重启前扫描 Profile Patch 与所有已安装 Bundle Patch 的入口 ID；发现重复入口时将包操作 判为不健康并立即恢复事务备份，不关闭当前 Host；
• Guardian 连续失败会打开熔断并保留脱敏故障摘要，不会把“端口暂时出现”误报成插件已健康。
• Guardian 将端口、首页 HTTP、runtime 身份、耗时、响应字节数和重启判断写入商城自己的 probe-log.jsonl。失败探测逐次记录，健康探测每分钟采样；不保存响应正文、Profile 内容或 凭据。日志仅保留 24 小时，并额外限制为 4 MiB，清理失败不会中断 Host 监督。
• 商城会比较随包 Guardian 与已部署守护文件的 SHA-256；版本漂移时禁用一键重启，并要求 用户通过新的单次计划和精确确认升级 Guardian。

健康检查与来源识别

• 检查 Profile 清单、依赖、管理器托管 Patch、DSH 配置合成与冷启动入口 ID 冲突；
• 合并 Bundle 和依赖信息，显示已安装版本、声明来源和官方/第三方属性；
• 区分“已验证”“部分验证”“商城不可安装”和“尚未验证”，不把声明态当成运行态；
• 运行态 Loader/Fiber 状态继续以 DSH 官方清单为权威，商城不直接控制官方运行时。

插件详情与权限画像

• DSH 0.1.0-rc.7 中使用紧凑的响应式卡片、状态圆点、清晰的操作区和无障碍列表语义；
• 每张商城卡片可打开详情弹窗，集中显示插件类型、安装来源和许可证；
• 列表与详情均显示由 GitHub 仓库链接可靠派生的发布者账号；组织仓库显示组织账号， 不把它误写成具体个人开发者；
• 展示权限等级，以及文件、网络、命令和凭据访问范围；
• 展示外部依赖、审核状态、DSH/Node.js 版本、系统和 Profile 兼容性；
• 字段来自 GitHub 目录固定 Commit 的 manifest、README 与代码信号；无法确认时显示 “未知”或“未声明”，不会用本地猜测覆盖目录数据；
• 自动扫描、人工检查和作者认证只表示元数据核验层级，均不等于安全审计。

上下架、推荐与安装计数

• approved：正常上架并允许生成安装计划；
• blocked：商城中继续展示并提供 GitHub 手动安装入口，但不提供商城安装操作；
• unlisted：公共商城隐藏，已安装用户仍可停用或卸载；
• featured: true：在全部视图和所属分类中优先显示；当前仅推荐 DSH-Store、DSH WeCom CLI、 Build DSH Plugin 和 Agent Workflow；
• 可选安装回执只发送插件 ID 和版本，不发送设备、Profile 或用户标识；默认关闭；
• GitHub Pages 不能直接写回 catalog.json，真实计数需要独立匿名聚合服务。
• 0.4.7 内置幂等安装回执与 Cloudflare Worker + D1 聚合器；只在商城安装、健康检查通过后提交插件 ID、版本和随机事务 ID，不提交账号、设备或 Profile。计数服务未部署或未配置时保持关闭，不显示虚假安装量。

使用方式

安装并启动管理器后，在 DSH 中打开：

设置 → 插件 → 插件商城

界面包含三个视图：

1. 插件市场：搜索、分类筛选、查看推荐、安装、更新或迁移；
2. 已安装：查看来源、版本、商城托管状态，并停用、启用或卸载；
3. 健康检查：检查 Profile、依赖、托管 Patch 和配置合成状态。

健康检查不会自动替用户批准权限。有待选项时，顶部操作会定位到逐插件权限列表；只有 所有声明权限均明确选择“允许”或“拒绝”后，底部重新检查按钮才会启用，并显示检查中、 完成时间或失败原因。审核选择只保存在当前浏览器，并绑定包名、已安装版本、固定来源、 目录身份和权限声明；版本、固定 Commit 或权限声明变化后会自动失效并要求重新确认。

刷新按钮会重新读取 GitHub main 分支上的在线目录。以本地开发链接安装的管理器或 插件不会被普通“更新”静默覆盖；需要先生成并确认“迁移到商城版”计划。迁移只切换 目标 Profile 的依赖来源，不删除或修改原本地项目。

开发历程

完整的验证边界与发布证据见 验证记录，产品与架构决策见 产品需求 和 技术架构。

已收录插件

★ 表示推荐。当前仅推荐 DSH-Store、DSH WeCom CLI、Build DSH Plugin 和 Agent Workflow； 推荐不会绕过固定 Commit、来源和风险校验。以下列表与当前 registry/catalog.json 一致。

商城不可安装说明

• DSH Memory Evolve：固定 Commit 的 manifest 未声明 dsh.bundle.patch；
• DSH TUI：属于独立终端入口，Bundle Patch 会覆盖或停用多项基础 Profile 行；
• DSH Explorer：完整功能需要两个独立 Bundle，当前目录尚不支持多包原子安装和回滚；
• DSH Web Plugin Manager：会禁用官方 ui-settings-plugin-inventory；
• DSH Plugin Hub：第三方仓库声明受保护的 @deepseek-ai 官方命名空间。

“商城不可安装”不是下架：用户仍可查看项目介绍和 GitHub 仓库，并按项目文档自行决定 是否手动安装，但商城不会为其生成安装计划。手动安装可进入只读健康检查，但没有固定 目录证据，也不受商城的备份或失败回滚保护。目录收录也不代表完成安全审计；第三方插件会以 DSH 进程权限运行，安装前 仍应核对仓库、固定 Commit、许可证、生命周期脚本和影响范围。

详细健康检查与权限选择

健康检查覆盖当前 Profile 中的全部声明项，包括商城安装、外部安装、目录外插件和官方 组件，并分别显示本地 manifest、Bundle 注册、来源与固定 Commit、版本漂移、安装脚本、 配置合成以及运行时证据。报告不会用单一 pass 代替未知事实；没有独立业务探针时会明确 显示“未验证”。

第三方插件的文件、网络、命令和凭据权限默认处于“待选择”。用户可逐项选择允许或拒绝， 目录外插件则需决定是否接受未知权限边界。选择只保存在当前浏览器，并绑定包名、版本、 固定来源、目录身份和权限声明；清除浏览器站点数据，或这些事实变化后，必须重新选择。 它仅用于形成个人健康审核结论，不会修改 Profile，也不会限制插件进程的真实能力；真正的 权限隔离仍由 DSH 宿主和沙箱负责。

架构

GitHub catalog.json ──> 搜索 / 分类 / 推荐 / 固定 Commit 来源复核
                              │
DSH Web Settings ──> 只读查看与操作计划 ──> 精确确认语
                                              │
                                              ▼
                        Profile 锁 → 备份 → 官方 dsh plugin
                                              │
                                  健康检查 → 成功 / 自动回滚

Host 端使用 ctx.inject(['webServer'], ...) 等待可选 Web 服务。Client 端通过 DSH 官方 ModuleLoader 与 Settings Slot 注册“插件商城”页签，不导入 Host 模块。

目录维护

• 机器目录：registry/catalog.json；
• GitHub Pages 页面：marketplace/index.html；
• 新增或更新插件必须通过 Pull Request；
• 每个可安装条目必须固定 GitHub Commit，并通过 manifest、版本、Bundle Patch、 DSH 入口 ID 和生命周期脚本复核；
• 同一个 DSH packageName 只允许出现一次，避免安装和更新身份冲突；
• 收录不代表安全审计，商城不可安装和未验证状态必须保留真实原因。

提交插件上架申请

如果你开发或发现了值得收录的 DSH 插件，只需打开 项目上架入口 并填写公开 GitHub 地址。仓库只有一个 DSH 插件时无需填写其他技术字段；若机器人发现多个 插件，会列出候选目录，此时编辑 Issue 补一个 Plugin path 即可。

开发新插件或准备提交前，建议安装并使用 build-dsh-plugin。它可以从 Brief 生成标准 Host Plugin + Client Bundle，判断 R0–R3 风险，生成 Catalog 候选并做只读预检；它不会 静默修改 DSH-Store 或真实 Profile。可以直接告诉支持该 Skill 的 Agent：

使用 $build-dsh-plugin，只读检查这个 DSH 插件是否满足 DSH-Store 上架条件：
https://github.com/owner/repository
不要安装到真实 Profile，不要执行第三方生命周期脚本。

上架必要条件

1. 仓库必须公开托管在 GitHub；最终安装源固定到完整 40 位 Commit，不接受浮动分支、 npm-only、本地路径或任意下载 URL；
2. 目标目录包含有效 package.json，声明语义化包版本和可解析的 dsh.bundle.patch；
3. Bundle Patch 至少声明一个唯一 DSH 入口 ID，且不禁用、替换、遮蔽或冒充 @deepseek-ai/* 官方组件与官方插件清单；
4. 包名、版本、许可证、preinstall/install/postinstall/prepare 生命周期脚本必须与固定 Commit 的实际文件一致；第三方包不得使用 @deepseek-ai 命名空间；
5. README 至少说明插件用途、安装或启用方式、外部依赖和主要风险；monorepo 必须能唯一定位 插件目录；
6. 上架前必须明确 DSH/Node.js、系统和 Profile 兼容范围，以及文件、网络、命令、凭据权限。 无法确认时必须写“未知”，不得把“没有搜到”推断成“不访问”；
7. 插件应具备清晰用途，并在“热门、有用、有趣”至少一个维度具有收录价值；高权限、安装 脚本和外部服务不会自动拒绝，但必须显著披露并接受更严格复核；
8. 自动预检、人工检查和作者认证都不等于完整安全审计；可安装插件仍需在一次性 Profile 中 完成适配版本的安装、配置合成、页面或工具可见性与卸载/回滚验收。

GitHub 自动检查

Issue 创建、编辑或重新打开后，GitHub Actions 会自动取得默认分支当前 HEAD 的 40 位 Commit， 读取仓库树、目标 package.json、README 和 Bundle Patch，并检查：公开/归档状态、包名和版本、 许可证、Bundle 声明、入口 ID、生命周期脚本、受保护命名空间、现有 Catalog 冲突，以及 manifest 中明确声明的 Node.js、系统和 Profile 兼容信息。结果会更新到同一条机器人评论，并设置 submission-passed 或 submission-failed 标签。

工作流不检出申请仓库，不执行第三方 install、prepare、build 或 test。静态证据不能 可靠证明的权限、凭据和外部依赖保持“未知”，由人工阅读固定源码后补齐；预检通过只表示进入 人工评审的结构门槛，不会自动改 catalog.json、创建 PR、上架、推荐或合并。

人工复核与自检清单

• 对照固定 Commit 复核 README、许可证、生命周期脚本、权限、外部依赖和供应链来源；
• 确认入口 ID 与现有插件不冲突，且没有修改 DSH 核心、官方包或官方清单；
• 判断直接安装、monorepo 子目录、需要 Adapter 或应阻止上架，并给出真实原因；
• 在一次性 DSH 0.1.0-rc.7 Profile 中使用官方 CLI 验证安装、配置合成和功能可见性；
• 高权限或原生构建依赖需要额外核对 allowBuilds、平台支持、失败清理和回滚；
• 最终目录字段、推荐状态和公开页面必须从 GitHub registry/catalog.json 读回后才算完成。

联合审核任务每天北京时间 06:00 和 18:00 依次处理 GitHub 主动发现项目与用户提交， 只处理带 submission-passed 的申请，统一去重后按照“热门、有用、有趣”三个维度筛选，并复核许可证、来源、权限、兼容性、 Bundle Patch、受保护条目和固定 Commit。审核通过只会生成候选目录草案与一次性变更计划； 实际写入商城目录、提交 Pull Request 或合并仍需要逐次人工确认。

本地验证

npm run check
npm run verify:registry-sources

测试使用临时目录，不会修改真实 ~/.dsh。更完整的开发和验收资料：

GitHub 默认 CodeQL 已启用，对 Actions 与 JavaScript/TypeScript 变更执行代码扫描。

• 产品需求
• 技术架构
• 开发路线
• 验收方案
• 验证记录
• 研究与来源
• 安全约束

下一步

在一次性 Profile 中补齐 GitHub 安装、更新、启停、卸载和故障回滚的真实闭环，覆盖 headless、损坏 manifest、缺失依赖、坏链接和无 Web Server Profile 等异常矩阵； 生产 Profile 的每次写操作仍必须由用户查看计划并输入精确确认语。

许可证

本项目采用 MIT License 开源。Copyright (c) 2026 AI-Scarlett。