Harness Registry — DeepSeek Harness Plugin Registry

Harness Registry is a searchable DeepSeek Harness plugin registry for DSH users and plugin authors. It combines a community-curated catalog with GitHub discovery, verifies the installable dsh.bundle manifest contract, and exposes comparable plugin metadata and copy-ready install commands.

Status: pre-release. The registry is available at plugin.dshdesk.com and the source is released under the MIT License. See launch readiness.

Quickstart

Requirements: Node.js 22 and npm.

git clone https://github.com/majiayu000/dsh-plugin-registry.git
cd dsh-plugin-registry
npm ci
npm run dev

Open http://localhost:5173 to browse, search, filter, and inspect the registry.

What it provides

• A searchable web directory with categories, trust labels, Stars, Forks, and install commands.
• Curated entries vendored from the community catalog into sources/curated.json.
• Automatic discovery from the GitHub dsh-plugin topic.
• Manifest verification: discovered repositories must declare a valid dsh.bundle object in package.json, and its referenced patch file must exist.
• Supply-chain pinning: each verified plugin records the exact verifiedCommit HEAD its manifest was checked against.
• A public JSON snapshot with schema validation, health gates, and a separate audit queue.
• Snapshot freshness on every page, with a stale warning past 24 hours and an automatic GitHub issue when a scheduled sync fails.
• Strict per-page Content-Security-Policy with icons restricted to GitHub-hosted domains.
• A repository checker that explains whether a plugin is eligible for automatic discovery.
• An optional on-site review form that creates an assigned, public GitHub Issue through a protected Cloudflare Pages Function.

Query the registry data

The generated snapshot lives at public/data/plugins.json and follows schema/registry.schema.json.

jq '.stats | {published, curated, automaticallyDiscovered, pendingReview}' public/data/plugins.json

Inspect one plugin:

jq '.plugins[] | select(.id == "omdsh-dev/dsh-at-file") | {id, trustLevel, install}' public/data/plugins.json

Validate the snapshot and run the governance tests:

npm run validate:registry
npm test

Backfill GitHub primary-language metadata without rerunning full discovery:

GH_TOKEN=... npm run backfill:languages

How discovery works

Vendored curated catalog (sources/curated.json) ─┐
                                                 ├─ normalize ─ verify ─ governance ─ public registry
GitHub topic ────────────────────────────────────┘                              └──── audit queue

Curated repositories receive the curated trust level. Automatically discovered repositories are installable only when their root package.json contains a valid dsh.bundle; these receive manifest_verified. Pending repositories remain visible as GitHub candidates without an install command, while blocked and quarantined repositories stay hidden. The full policy is documented in registry governance.

The scheduled GitHub Actions workflow refreshes the snapshot every two hours. When the registry changes, the same workflow commits the snapshot and deploys its verified build artifact to Cloudflare Pages, so sync commits created with GITHUB_TOKEN do not depend on a second push event. A health gate prevents an unauthenticated partial discovery run, an unexpectedly smaller complete snapshot, or a partially answered GitHub GraphQL batch from replacing healthy data. If a scheduled sync fails, the workflow opens a titled tracking issue and closes it after a subsequent sync successfully deploys.

Detail delivery on Cloudflare Pages

The homepage and dashboard are prerendered. Plugin detail URLs are served by a Pages Function that returns complete HTML (including canonical URLs, structured data, and inline hydration data). GET /api/plugins/{owner}/{repo}/{qualifier...}/ returns the same detail record as JSON for install buttons; both routes support HEAD. Missing plugins return 404, malformed paths return 400, and broken snapshot assets fail with 500. Errors are not cached.

The build derives 256 detail shards from the existing registry snapshot. Each request reads the small data/detail-build.json version artifact. On a cache miss, HTML loads one shard and the compiled HTML template; JSON loads only the shard. Successful responses use the Workers Cache API and Cache-Control: public, max-age=0, s-maxage=300. Browser requests revalidate; the edge cache key includes a fresh version generated into that artifact on each build, so a new deployment cannot reuse the previous build’s HTML or data. No build-environment variables are required at runtime. This avoids a full snapshot parse per request and removes one-file-per-plugin deployment growth. Static assets continue to use Pages delivery. Dynamic requests still consume Pages Functions quota, and shard size grows with the dataset.

This adapts the snapshot-backed dynamic routing used by the Astro integrations directory. Per-plugin static HTML would retain the file-count ceiling; a full database-backed registry adds infrastructure this read-only catalog does not need. No new database, storage binding, or frontend framework is required.

Use npm run dev:cloudflare to build and run the actual detail routes locally. npm run dev remains useful for frontend work, but Vite alone does not run Pages Functions. Verification: npm test, npm run build, npm run check:performance, then exercise HTML/JSON, cache hits, 404s, and installs with Wrangler Pages dev.

Add a plugin

For automatic discovery:

1. Publish a real, public, non-fork GitHub repository.
2. Declare an installable dsh.bundle object in the plugin package.json (root or a path listed in dsh.bundles).
3. Make sure the referenced patch file exists and is a top-level YAML array (empty [] is valid).
4. Add the dsh-plugin GitHub topic.
5. Wait for the next registry sync.

Check a local checkout before publishing:

npm run check:plugin -- ./hello-plugin

Use the repository checker at http://localhost:5173/publish.html. When the Cloudflare submission channel is configured, authors can submit a trackable review request without leaving the page; GitHub remains available as a fallback. See submission review setup.

Known limitations

• Manifest and patch-file verification confirm the bundle overlay exists and is a top-level YAML array; they are not an installation test, security audit, or endorsement of plugin code.
• GitHub install commands are pinned to verifiedCommit when that SHA was recorded. npm-style specs are not commit-pinned.
• Stars, Forks, descriptions, Topics, and primary languages are point-in-time GitHub metadata and can lag until the next sync.
• A complete discovery refresh requires a GitHub token; unauthenticated runs inspect only recent candidates and cannot overwrite a complete snapshot.
• The browser-based repository checker uses the unauthenticated GitHub API and may encounter rate limits.
• The Cloudflare Pages site tracks main; formal versioned releases are not yet available.

Development

npm ci
npm test
npm run validate:registry
npm run build

To refresh registry data, provide a GitHub token with public repository read access:

GITHUB_TOKEN=... npm run sync:plugins

To regenerate the vendored curated catalog from the current snapshot:

npm run export:curated

Do not commit tokens or generated credentials. See CONTRIBUTING.md for the change workflow.

Project structure

• assets/ contains the registry UI modules, styles, and translations.
• public/data/plugins.json is the generated public registry snapshot.
• scripts/ contains discovery, normalization, and validation tooling.
• functions/ contains Cloudflare Pages server-side routes for review submissions.
• schema/registry.schema.json defines the published snapshot contract.
• tests/ covers registry governance and browser-facing behavior.

Support and security

• Bugs, data corrections, and feature requests: GitHub Issues
• Sensitive vulnerabilities: private vulnerability report
• Security policy: SECURITY.md

License

Harness Registry is available under the MIT License.