Blog · Analysis
A plugin store that said no to 1,225 entries: reading the DSH-Store admission numbers with you
August 31, 2026 · dshbase · rewritten field note
Rewritten analysis based on facts reported in the WeChat article 几千个插件,为什么 DSH-Store 只让两百多个进场 (account: 山海只能局). The source author discloses involvement in the DSH-Store project; all funnel numbers are their self-report.
Source clue (WeChat via Sogou; not a verbatim reprint) — Rewritten analysis based on facts reported in the WeChat article 几千个插件,为什么 DSH-Store 只让两百多个进场 (account: 山海只能局). The source author discloses involvement in the DSH-Store project; all funnel numbers are their self-report.
The DeepSeek Harness plugin ecosystem has a numbers problem. The Awesome DSH Plugin machine catalog recently crossed 1,411 entries, and stacking market sites, GitHub topics and sub-collections on top of each other easily runs into the thousands. One community response is DSH-Store, which reports admitting just 253 of those records. As the site that test-installs community plugins for a living, we think the funnel behind that number is more interesting than the number itself.
Why fewer is a claim worth auditing
A plugin is not an article. A listing that turns out wrong gives you bad information; a plugin that turns out wrong gets to run inside your agent's process with your file system, your network and your API keys in reach. Node.js install lifecycles make this concrete: scripts like preinstall, install and prepare fire automatically during installation, so clicking add is closer to running someone's program than downloading a file.
Stars do not audit that program. A license does not either — it settles redistribution rights, not whether the code phones home. That is why an admission gate, rather than a bigger shelf, is a defensible product choice.
The funnel, layer by layer
Development gate. The build-dsh-plugin skill checks host fit first: a browser extension or standalone MCP server may feel similar but lacks the dsh.bundle contract a profile can actually load. Plugins are then risk-tiered — R0 for read-only UI work, R1 for host services or own state, R2 for external processes, network or credentials, R3 for anything touching profile lifecycle or restart. Each tier buys itself evidence: source review, automated tests, throwaway-profile runs, real-profile acceptance, recovery proofs.
Publishing gate. The store pins every admission to a full 40-character commit and refuses floating branches, because the link you approved today can point at different code tomorrow. Manifest, package name, license, bundle patch, entry id and lifecycle scripts must agree with what is in the tree. A catalog entry claiming zero install scripts while the pinned commit carries a prepare hook is treated as a supply-chain identity failure, not a typo.
Local gate. At install time, DSH Safe Plugin Manager re-reads the catalog, generates a short-lived single-use plan listing exactly which files change, hashes the profile and takes a file lock, then installs through the official CLI with fixed arguments — no shell string concatenation. A failed post-install health check restores the backup, and restart observation is handled by a separate guardian process.
Checking the author's math — and their conflict of interest
The reported pipeline: 1,411 records merge to 1,365 unique repos; 492 reach npm same-origin verification; 335 clear structure; 230 clear source boundaries; 192 clear fixed-commit review; 186 land in the catalog, taking the store from 48 to 234. A second pass over 99 submitted addresses added 19 more (61 rejected, 19 duplicates) for the current 253, of which 248 get a protected install path. The drop-offs are mostly identity failures long before any security verdict: no matching npm package, no license, no installable bundle structure.
One caveat we have to state plainly: the article describing this funnel is written by someone who discloses working on DSH-Store. The numbers are self-reported and the mechanism grades its own project. Our own spot checks on dshbase reached a compatible conclusion from a different direction — of 101 community plugins we test-installed, only 11 came cleanly out of npm. A directory where most entries fail on identity and packaging is not surprising to us; it matches every install log we have kept.
What the three gates do not prove
Fixed commits prove you reviewed the artifact you install, not that it is harmless. Automated checks prove the rules fired, not the absence of misses. A passing install proves the transaction completed, not that the feature works. Anyone reading admission as a lifetime safety certificate has misread the model — the store itself says review conclusions expire when the version, dependencies or install path move.
The useful takeaway for installers is smaller and more portable: before adding any community plugin, check that its npm package, GitHub repo and pinned commit agree, look at what its lifecycle scripts run, and pin the version yourself even when the installer does not.
On dshbase
Before installing random GitHub plugins, check the verified directory and audit notes.