插件注册中心 dsh-pub/dsh-pub

DSH Pub

dsh.pub 是 DeepSeek Harness 插件生态的双语注册表，每个条目都有公开源码可查。它收录当前内置模块，说明运行时与 UI 能力，并把原子模块、内置配置档分层、社区包区分开，社区包都锁定到公开源码。

DeepSeek Harness source
│ pinned catalog sync
▼
219 source packages ──► 170 loadable plugins ──► Astro pages in English + Chinese
│
└── 3 manifest-declared bundles ──► built-in profile activation layers

Browser submission ──► Turnstile ──► Worker + D1 ──► Cloudflare Workflow
│
└─► GitHub App ──► submission PR
│
Cloudflare Workers ◄── main deploy ◄── automatic merge
│
└── community Git bundle ──► dshpub CLI ──► native dsh plugin add
└─► D1 completed-install count

工作区

apps/
├── web/ Astro static registry
├── server/ Cloudflare Worker install API and locale routing
├── cli/ GitHub bundle installer (dshpub)
└── dsh-plugin/ In-DSH bilingual visual directory
packages/
└── catalog/ generated Harness snapshot and typed access
migrations/ D1 event and aggregate schema

本地开发

npm install
npm run build:og
npm run build
npm run dev --workspace @dsh-pub/web

要在生产构建里启用 Google Analytics，请提供公开的 GA4 Measurement ID：

PUBLIC_GA_MEASUREMENT_ID=G-XXXXXXXXXX npm run build

要启用 Google AdSense 账户标签和可选的手动广告单元：

PUBLIC_ADSENSE_CLIENT_ID=ca-pub-XXXXXXXXXXXXXXXX \
PUBLIC_ADSENSE_SLOT_DETAIL=1234567890 \
PUBLIC_ADSENSE_SLOT_CATALOG=0987654321 \
npm run build

设置 PUBLIC_ADSENSE_CLIENT_ID 后，每个页面都会输出 AdSense 账户 meta 标签并加载 adsbygoogle.js。手动广告单元只在对应的 slot 环境变量设置后才渲染：详情页用 PUBLIC_ADSENSE_SLOT_DETAIL，目录页用 PUBLIC_ADSENSE_SLOT_CATALOG。提交流程从不托管广告单元。apps/web/public/ads.txt 必须与发布商 ID 保持一致。站点通过审核后，可以在 AdSense 控制台开启自动广告；建议优先用上面的手动 slot，让发现类页面保持克制的布局。

构建会输出双语站点地图索引，位于 /sitemap-index.xml；爬虫策略位于 /robots.txt；每个可索引页面都带 canonical、hreflang、Open Graph、Twitter Card 和 JSON-LD 元数据。

Web 应用运行在 http://127.0.0.1:4321。要在本地跑通完整的 Worker 边界：

npx wrangler d1 migrations apply dsh-pub --local
npx wrangler dev --local --port 8787

目录同步

生成的目录固定到已知的 DeepSeek Harness commit，遇到脏的源码检出会拒绝。

node scripts/sync-harness-catalog.mjs

只有想验证另一个本地路径时，才覆盖默认的相邻检出：

node scripts/sync-harness-catalog.mjs --source /path/to/deepseek-harness

命令行

npx dshpub add owner/repo \
--path packages/my-bundle \
--profile web

这条命令把公开的 GitHub ref 解析成确切的 commit，校验选中的包是否声明了 dsh.bundle.patch，删除校验用的检出，再把一个持久化、固定 commit 的 Git spec 传给 dsh plugin --profile … add …。只有原生安装成功才会报告完成。遥测是尽力而为，可以用 DO_NOT_TRACK=1 或 DISABLE_TELEMETRY=1 关掉。

目前这三个 Harness bundle 是内置的 monorepo 配置档层，不是独立的 Git 包：它们的 workspace: 依赖需要 Harness workspace。所以目录把它们显示为内置配置档层，不带安装命令，也不带安装次数。

DSH 插件目录

仓库还提供 @dsh-pub/plugin-directory。它在 DSH 设置里加了一个只读的可视化目录——和网站相同的公开插件/bundle 界面，支持双语搜索、八个能力主题、来源/运行时/分发/类型筛选，以及确定性排序，且不加载第三方代码。它的宿主部分还注册了一个内嵌的 dsh-pub 技能，因此挂载了 DSH 技能注册表的配置档里的智能体，可以用自然语言搜索机器可读的 https://dsh.pub/plugins.json，并通过网站发布的、固定 commit 的 npx dshpub … 命令安装真正可安装的 Git bundle。

npx dshpub add dsh-pub/dsh-pub --path apps/dsh-plugin --profile web

更新和验证流程见 apps/dsh-plugin/README.md。

提交插件

使用双语提交页面 dsh.pub/submit。浏览器把一个公开的 GitHub 仓库 URL 和一个 Turnstile token 发给 Worker。验证之后，Worker 在 D1 里存一条提交任务，启动 Cloudflare Workflow，并立刻返回一个状态 URL。页面轮询这个 URL，同时 Workflow 用仓库范围的 dsh.pub GitHub App 创建或找到对应的 submissions/.json 分支和 Pull Request。你不需要 fork 仓库，也不需要点 GitHub 的 Propose changes。

受信任的 GitHub Actions 提交流程从确切的 Pull Request commit 读取提交的文件，不检出、不执行不受信任的插件代码。它解析插件仓库当前公开默认分支的 commit，校验其已提交的 bundle 契约，并跑完整的 dsh.pub 质量门禁。通过的 Pull Request 用 merge commit 合并，然后受信任的 main 工作流会重新生成并提交目录。现有的 Cloudflare Workers Git 集成会自动部署 main。任何人都可以提名公开仓库；提交者不会被当作已验证发布者，已有的仓库/包路径坐标也不能通过这条流程覆盖。

网页提交页还会生成 Markdown 和 HTML 徽章片段。注册表提交部署之前，实时徽章显示 not listed，部署后变为 listed（有短暂缓存）。Pull Request 和签入的提交文件构成公开审计轨迹。

仓库自动化通过两个范围很窄的 token 使用同一个 GitHub App。Pull Request 基线漂移恢复只申请 pull_requests: write；受信任的目录集成只申请 contents: write，而且必须在 lint、测试、E2E 和构建全部通过之后。为这些工作流配置仓库变量 DSH_PUB_APP_CLIENT_ID 和仓库密钥 DSH_PUB_APP_PRIVATE_KEY_PKCS8。App 只能安装在 dsh-pub/dsh-pub 上，并拥有 Contents 和 Pull requests 的读写权限。这些 Actions 名称有意与 Worker 的 GITHUB_APP_ 绑定不同，因为 GitHub 保留了 GITHUB_ 前缀。Pull Request 校验永远不会拿到 App 密钥或 token。

用两条生效的仓库规则集保护 main。main-pr-gate 要求走 Pull Request，并且只把 dsh.pub GitHub App Integration 列为 always 绕过执行者，让受信任的目录任务可以提交经过审计的快进提交。main-ref-integrity 没有绕过执行者，阻止删除和非快进更新。把这两类控制分开，可以防止 App、仓库管理员和 GitHub Actions 绕过删除或强制推送保护；不要往任何一条绕过列表里添加管理员角色或 GitHub Actions Integration。

dsh-plugin GitHub topic 每天 01:00 Asia/Shanghai 同步一次。工作流会截取截止快照，固定每个公开默认分支的提交，在不执行第三方代码的前提下校验根 bundle 契约，更新目录和可安装注册表，并把接受和拒绝的结果记录到 packages/catalog/src/topic-analysis.generated.json。截止之后新增或更新的仓库顺延到下一次运行。如果 Topic 连接在三次完整分页尝试后仍然漂移，分析会记录未解决的覆盖范围，并保留上一份快照中未见的记录，而不是把它们当作已移除。收录只能证明固定的公开 bundle 契约和必需的已提交文件通过了自动化检查；它不是人工审查、安全审计、运行时冒烟测试、质量评分、发布者身份核验或官方背书。标为 community-reviewed 的旧记录保留其历史来源。

公开指标的含义是 CLI 报告的已完成安装数。它不是独立用户数，也不是 GitHub clone 流量、活跃使用量，或直接通过 Git 或原生 DSH 命令完成的安装。

公开安装器是 npm 上的 dshpub 包。用 npx dshpub 运行。

质量门禁

npm run lint
npm run test
npx playwright install chromium
npm run e2e
npm run build

Playwright 只需安装一次，装完后目录筛选 E2E 就不再依赖机器的系统浏览器。CI 会安装同一个 Chromium 修订版，并带上它所需的操作系统依赖。

npm run eval 仍然单独运行，因为它可能调用真实模型并消耗凭据。

Cloudflare 部署

Worker 把 apps/web/dist 作为静态资源提供，并优先处理 /、/api/* 和插件详情路由。插件源码和文档留在 GitHub。D1 存储安装事件计数器和提交任务状态；它绝不存储 GitHub App 私钥、安装令牌或 Workflow 步骤凭据。生产环境的 Workers Builds 监听 dsh-pub/dsh-pub main 上的每条路径，运行 npm run build，然后执行 wrangler deploy（它把 community-automated 详情 HTML 打包成分片文件，让上传量保持在 Workers 免费版 20,000 文件限制之内）。同一个 Worker 发布静态资源、HTTP API、D1 绑定和 PluginSubmissionWorkflow。

插件提交所需的运行时绑定如下：

| 绑定 | 用途 |
| TURNSTILE_SITE_KEY | 返回给提交页面的公开站点密钥 |
| TURNSTILE_SECRET_KEY | 服务端 Turnstile 校验密钥 |
| GITHUB_APP_CLIENT_ID | 用于签发 App JWT 的 GitHub App 客户端 ID |
| GITHUB_APP_INSTALLATION_ID | 限定到 dsh.pub 仓库的安装 |
| GITHUB_APP_PRIVATE_KEY_PKCS8 | PKCS#8 PEM 私钥，只在 Worker 内部使用 |
| GITHUB_TARGET_REPOSITORY_ID | 创建安装令牌时允许使用的数字仓库 ID |
| PLUGIN_SUBMISSION_WORKFLOW | Wrangler Workflow 绑定；在 wrangler.jsonc 中配置 |
| DB | 已有的 D1 绑定；在 wrangler.jsonc 中配置 |

部署值不要进版本控制。上面六个字符串绑定都通过 Cloudflare secrets 配置（站点密钥和数字标识并不机密，但整套运行时值统一处理可以避免环境漂移）：

npm run build
npx wrangler d1 migrations apply DB --remote
npx wrangler secret put TURNSTILE_SITE_KEY
npx wrangler secret put TURNSTILE_SECRET_KEY
npx wrangler secret put GITHUB_APP_CLIENT_ID
npx wrangler secret put GITHUB_APP_INSTALLATION_ID
npx wrangler secret put GITHUB_APP_PRIVATE_KEY_PKCS8
npx wrangler secret put GITHUB_TARGET_REPOSITORY_ID
npx wrangler deploy
这个顺序是有意安排的：先构建，再迁移生产环境的 D1 数据库，然后配置运行时密钥，最后部署依赖新 schema 和绑定的 Worker 版本。本地开发时，把非生产环境的值放进已被忽略的 .dev.vars 文件。绝不要把 GitHub App 私钥或 installation token 放进 D1、Workflow 事件负载，或持久化的 Workflow 步骤结果里。

参见产品决策、架构和研究证据。

License

DSH Pub 基于 MIT License 发布。由 DeepSeek Harness 生成的目录文档，其上游声明保留在 THIRD_PARTY_NOTICES.md 中。