DSH Plugin Radar: a self-hosted availability index for DeepSeek Harness plugins

The problem: DSH plugin discovery is a GitHub search box

DeepSeek Harness is described in the README as a coding agent where everything is a plugin. That design pushes the ecosystem problem onto the user: plugins are ordinary GitHub repositories, so the only way to find one is to search for a topic, open repositories one by one, and guess from the README whether the package actually loads. A repository can look complete and still fail at the point where DSH tries to import it.

DSH Plugin Radar exists to answer one question before installation: which plugins work. Its own framing is blunt about the difference between a listing and a verdict, and the README repeats the warning that inclusion is not compatibility, a static check is not runtime usability, and runtime usability is not a security audit. The intended audience is anyone who has to hand a plugin list to other people: marketplace operators, platform teams, and maintainers of curated collections. The catalog that most readers will encounter is, in the project's words, just an artifact the pipeline generates.

Discovery, validation, and the build-artifact catalog

The pipeline has four visible stages. Discovery runs on a six-hour cadence and pulls candidates from GitHub Search across two topics and three keywords, with a local repository sweep and deduplication by repository id. Private organization repositories are excluded, and the README notes a 35-second stagger, 403 backoff, and a dshow blacklist as operational guards. The snapshot in the README reports 21,355 candidates at 65 minutes of age.

Validation is where the project separates itself from a link list. A driver loop inspects each candidate's package.json for a name plus a main, exports, or dsh field. A candidate that fails that check is deleted to save space. A candidate that passes is treated as a plugin and sent to a Kubernetes test: one pod per plugin, concurrency of 10, running a dsh agent against Qwen with de-stream enabled. The README's diagram shows the total verdict count at 13,460, split into 8,714 runtime-usable and 3,382 needing adaptation, with 1,364 environment-class retries fed back into the test stage. A separate radar-probe process runs every 15 minutes with seven metric streams on a 60-second interval for self-healing. Results are aggregated, classified, and delivered as a bot pull request to two repositories, described as idempotent and superseding.

The architecture principle is stated plainly: the catalog is a build artifact. That has a practical consequence for anyone who wants to consume the data. The featured board, bundles, category listing, and compatibility matrix are all regenerated, and the README marks featured and bundle membership as the only human-curated parts, with stars and statuses refreshed by bots.

Getting the radar engine and reading its pipeline docs

The README does not give a pip install line or a docker run command. It points at the open-source engine directory for the radar source and at the pipeline documentation for the overview, architecture, and data contracts. Phase 2 of the open-source plan, covering discovery, aggregation, rendering, distribution, and operations self-healing, is marked as open in engine/. Phase 3, the test engine, is not: the lightweight local edition and the Kubernetes server edition are marked as opening after stabilization. So the honest first step is to clone the repository and read what is actually present before assuming the whole pipeline is runnable.

A local checkout looks like this. The repository layout lists engine/, schema/, data/, catalog/, generated/, reports/, docs/, and scripts/ at the top level.

git clone https://github.com/AdamPlatin123/dsh-plugin-radar
cd dsh-plugin-radar
ls engine/ docs/ schema/

What you should see is the engine source, the pipeline documentation, and the schema directory that the data contracts describe. The README's own quick-navigation table maps each goal to a path, so the second step is to follow the one that matches your goal rather than guessing. The README links docs/radar/overview.md and docs/radar/data-contracts.md from that table.

If you only want the data, you do not need the engine at all: the README points marketplaces at docs/api.md for a stable JSON interface that it says can be used with attribution only. That is the lower-risk integration path, because the JSON is a published contract while the engine is staged source.

Four status labels and what they do not tell you

The README defines a four-tier status vocabulary, and the badges make the counts visible: 8,714 runtime-usable, 1,489 to-test, and 3,382 needs-adapt. The fourth tier is the one people forget, and the project's own warning names it: inclusion is not compatibility. A repository can be discovered, indexed, and still be sitting in the to-test bucket.

The classification is also versioned, and that detail matters more than it looks. The snapshot header names the classifier as unified-v2-bridge, and the status badges carry the version 0.1.1-rc.2. A verdict is therefore a statement about a plugin under a particular classifier build, not a permanent property of the plugin. If the classifier changes, old verdicts are not automatically comparable to new ones, and the README does not describe a re-classification policy for previously judged plugins.

The second limitation is scope. A Kubernetes pod running a dsh agent against Qwen tests whether the plugin loads and executes in that environment. It does not test the plugin's permissions, its dependency tree, or its licence. The README tells readers to review plugin source, permissions, dependencies, and licence before installing, which is an admission that the radar stops short of those questions. Anyone treating a green runtime-usable badge as a safety signal is reading it wrong.

Where the radar is the wrong tool

Three cases stand out. The first is security review. Nothing in the pipeline inspects what a plugin does after it loads, so a plugin that passes the runtime test and then exfiltrates environment variables would still be classified as runtime-usable. The README says this directly rather than leaving it implied.

The second case is reproducibility. The catalog is regenerated on a 15-minute snapshot cadence, and the README describes the delivery step as an idempotent supersede. That is the right behaviour for a live index and the wrong behaviour for anyone who needs a frozen artifact, such as a release manifest or a compliance record. There is no retrieved release in the repository data, so there is no tagged version of the catalog to pin against. If you need a fixed list, you would have to snapshot the generated output yourself and record the snapshot identifier, such as 20260916T021501Z, alongside it.

The third case is a team that just wants to install a few plugins. Running the full engine means operating GitHub Search credentials, a Kubernetes cluster with one pod per plugin at concurrency 10, and a probe that fires every 15 minutes. For a handful of plugins, reading the published catalog is cheaper than reproducing the pipeline.

Alternatives: topic search, awesome lists, and plugin marketplaces

The nearest alternative is the GitHub topic search the radar itself uses as its discovery input. Searching the dsh-plugin topic returns the same repositories the radar finds, with no delay and no infrastructure. The difference is that topic search gives you a repository and a README, while the radar gives you a verdict from an actual run. Topic search also cannot tell you that a plugin was tested and needs adaptation; it just shows you the repository as if it were fine.

A hand-maintained awesome list is the second alternative, and the project has one inside it: the featured board is described as human-curated, 55 plugins in 11 groups, with membership changed by pull request to data/awesome-50.json. A standalone awesome list gives you editorial judgement and a stable file, which the radar's regenerated catalog does not. What it cannot give you is freshness at scale, because a human has to notice when a listed plugin breaks.

A plugin marketplace is the third. The README positions the radar as a supplier to marketplaces rather than a competitor, pointing them at docs/api.md and describing the JSON as stable and usable with attribution. The difference in approach is the direction of the dependency: a marketplace decides what to show and owns the user relationship, while the radar only produces availability data. If you are building a marketplace, consuming the JSON is the intended integration; if you are building a curated list, the featured board is a starting point, but its membership is edited by pull request, not by your own criteria.

Maintenance cost, licence, and the staged open-source plan

The repository is MIT licensed, which is permissive and places no copyleft obligation on downstream consumers. The README's marketplace section says the JSON data can be used with attribution only, so the practical licence question for a consumer is not whether you may use the data but how you credit it and whether the underlying plugin licences are compatible with your distribution. The radar's own licence says nothing about the licences of the plugins it indexes, and the README tells readers to check each plugin's licence themselves.

Maintenance cost depends on which half you run. Consuming docs/api.md and rendering your own view is close to free. Running the engine means operating a Kubernetes test cluster, a six-hour discovery cycle, a 15-minute probe, and a bot that opens superseding pull requests to two repositories. The README's operational notes about staggering, 403 backoff, and a blacklist suggest those guards were added in response to real rate-limit pressure, which is the kind of thing a new operator will meet again.

The open-source plan is staged, and the staging is the main risk to plan around. The pipeline docs and the radar engine are marked open. The test engine, both the local lightweight edition and the Kubernetes server edition, is marked as opening after stabilization. Until that phase lands, a self-hoster can reproduce discovery, aggregation, rendering, and distribution, but not the runtime validation that gives the catalog its value. The last push to the repository was on 2026-09-16.

Editorial conclusion

Adopt DSH Plugin Radar if you run a plugin marketplace, an internal agent platform, or a curated list for a team that installs DSH plugins, and you want a dated availability signal instead of a star count. Do not adopt it if you need a security audit, a stable release artifact, or a turnkey service: Phase 3 of the test engine is not open sourced, there are no retrieved releases, and the catalog is regenerated every 15 minutes. Before relying on it, check whether your own plugin is classified as runtime-usable, needs-adapt, or to-test in the current snapshot, and read the classifier version string next to that snapshot, because the verdict is only as good as the classifier that produced it.

Frequently asked questions

Official sources

1. AdamPlatin123/dsh-plugin-radar on GitHub
2. Issues
3. License: MIT
4. Project website
5. README