seek://map/dsh-plugin-radar
DSH Plugin Radar
#discovery #verification #catalog #automation
TL;DR
An open ecosystem radar for DSH plugins — per its README: scheduled discovery, runtime-level verification on a k8s cluster, snapshots on a short cadence; PLUGINS-ALL.md, the curated featured list, bundles and the compatibility matrix are all pipeline artifacts, with the radar engine open-sourced.
The ecosystem needed a machine for answering "will this plugin actually run?" — and this radar automates the answer: scheduled discovery feeds a runtime-test harness that runs each candidate plugin in its own pod and issues a tiered verdict, with snapshots published on a short cadence and every catalog (the full PLUGINS-ALL.md, a hand-curated featured list, bundles, a dated compatibility matrix) regenerated as a build artifact. Per its README the engine and pipeline docs are open source while the test engine is a later phase, and its own caveat — indexed is not compatible, runtime-verified is not security-audited — is the right dose of skepticism for a project whose whole product is verdicts. Its catalogs feed downstream consumers such as dshfind; the sibling awesome-dsh-plugins list under the same owner is indexed separately on this map.
Facts
- license
- MIT
- note
- README 数据面板为快照产物、随时变动（数据截至快照 20260908T000002Z）；README 自带提示：收录不等于兼容，运行可用也不等于安全审计。
Key points
- The pipeline runs recurring discovery, short-cadence probes, and — per its README — runtime-level tests on a k8s cluster, each plugin in its own pod, to award a tiered compatibility verdict
- The catalog is a build artifact: PLUGINS-ALL.md, the human-curated featured list, integration bundles and the dated compatibility matrix all regenerate from machine-readable snapshots
- The radar engine is open source under engine/, with pipeline overview, architecture and data-contract docs published; open-sourcing the test engine is listed as a later phase
- Two stable JSON endpoints expose availability data to downstream consumers such as dshfind, attribution required
- Adding the dsh-plugin topic gets a repo auto-indexed; the README's own caveat separates indexed, static-checked, runtime-verified and security-audited as different levels
FAQ
Does indexed mean usable?
No. Per the README's own notice: indexing is not compatibility, static checks are not runtime usability, and runtime usability is not a security audit; before installing third-party plugins, check source, permissions, dependencies, license and test dates yourself.
How does a plugin get indexed?
Add the dsh-plugin topic to the repository to enter the automatic indexing flow, or register via the project's PR template.
What is its relation to the awesome-dsh-plugins list on this map?
Both repositories share the same owner: the radar's artifacts (PLUGINS-ALL.md, the featured list, the compatibility matrix) are generated and refreshed inside this repository, while the awesome-dsh-plugins list repository is indexed separately on this map.
Official references