Plugin Install Ecosystem Report
The queue caught up — half the registry still isn't runtime-verified
Every dsh version with real install records, on one ladder — 0.1.2-α.1 → 0.1.2-rc.1 → 0.1.3-α.1 → 0.1.3-α.2. Runtime-verified by version: 5,543 → 6,252 → 6,448 → 7,175.
- L5 wins — "runtime verified" requires a passing L5 (web boot · HTTP · loader inventory); L4 alone means installed, not running.
- Version-scoped — a verdict is valid only for the dsh version it was measured on; every figure below is scoped to 0.1.3-alpha.2.
- Gray is not broken — unknown = installed but declaring no dsh.bundle, so dsh mounts nothing: a plain dependency, not a failure.
A Verdict mix per versionstacked to max 14,494 · current 0.1.3-α.2
B L4 installed vs L5 runsdecided pass rate · current 0.1.3-α.2
C Registry mix · 0.1.3-alpha.214,496
D Install ladder L1 → L5 · 0.1.3-alpha.2bar = pass rate
E Channel duel · 0.1.3-alpha.2delta 25.2%pp
F Runtime failure profile · 0.1.3-alpha.2records verbatim
01 What the numbers say
An editorial read, not a second data source: every claim below points at a figure already shown above, and nothing new is introduced here.
The queue caught up — the loss is no longer "untested"
99.99% coverage: 14,494 of 14,496 listable plugins carry a real verdict on 0.1.3-alpha.2 (2 not tested). Of those, 7,175 run (49.5%), 3,202 fail (22.1%) and 4,085 are plain dependencies (28.2%). Runtime-verified rose 6,448 to 7,175 (+727, +11.3%) from the version Vol.1 closed on.
Scope. Coverage is a property of the queue, not the ecosystem: every L5 verdict landed inside one two-day batch (2026-09-08/09). Limitation. Untested is not failing — and here untested is 2. The open question is now verdict quality, not reach.
The channel gap is packaging discipline, not breakage
npm-pinned installs verify at 71% versus 45.8% for source installs (25.2%pp gap). Failure rates are nearly the same (19.7% npm vs 22.5% source) — the real split is the gray bucket: 31.5% of source installs declare no dsh.bundle versus 8.9% of npm ones.
Scope. Channel is the winning record's evidence.parsed.channel, with a same-version fallback; the "other" bucket is empty this window. Limitation. Declaring dsh.bundle is a packaging choice, not a quality score: an unmounted dependency is not a broken plugin.
Runtime failure is one shape, not a long tail
3,202 failures = 115 sandbox install failures (L4) + 3,087 web-runtime failures (L5). 2,853 of the runtime failures (92.4%) carry the identical record text "plugin tree failed to load" on check L5.2_WEB_BOOT_READY; the remaining 234 spread over 6 other recorded forms.
Scope. Buckets are the failing check's own summary text, verbatim; nothing is reclassified or renamed into a taxonomy. Limitation. One shared shape points at a common gate or cause, not at 3,087 independent plugin defects — this is a symptom tally, not a root-cause analysis.
The release train is ahead of the verification queue
Three dsh releases landed after the tested version — 0.1.5-alpha.1 (2026-09-08), 0.1.5-alpha.2 (2026-09-09) and 0.1.5-rc.1 (2026-09-10) — and carry zero verification records. Every figure in this report is scoped to 0.1.3-alpha.2.
Scope. Version scoping is deliberate: a verdict is only valid for the version it was measured on; older verdicts are kept as history and never silently upgraded. Limitation. The next version switch moves the current version, and these coverage and verified figures will drop until the retest queue catches up again. That is accounting, not regression.
02 Methodology
- Verdict rule (L5 wins): newest real L5 verdict per version wins; no L5 → newest L4. Only an L5 pass counts as "runtime verified".
- State layers (record layer unchanged): Failed = install/boot/HTTP failure. Gray = installed but no dsh.bundle — dsh installs it as a plain dependency, unmounted as a plugin (web runtime gate not applicable). Record layer calls it unknown (neither pass nor fail); this report names it by its semantics, never as failure.
- Failure profile: the current version's failed verdicts split into L4 sandbox install failures and L5 web-runtime failures; the latter are bucketed by the failing check's own summary text (check id when a record carries no summary). No taxonomy is invented over the records.
- Window / version scope: the window is every dsh version with real run records — not a fixed count, it grows as the ladder covers new releases; a verdict holds only for the version it was tested on; older coverage uses today's registry as denominator.
- History is never rewritten: earlier volumes keep the figures they were published with, even as the registry and the current dsh version move on.
Q Is "installed" (L4) the same as "runtime verified"?
No. L4 means the sandbox install completed; L5 means the web runtime boots, serves HTTP and lists the plugin in the loader inventory. Only an L5 pass is counted as runtime-verified — 13,683 plugins install, 7,175 run.
Q Why does this report stop at 0.1.3-alpha.2 when newer releases exist?
Because 0.1.3-alpha.2 is the highest version with real records. 0.1.5-alpha.1 / 0.1.5-alpha.2 / 0.1.5-rc.1 are published but have not been run through the ladder yet; their columns would be empty. Coverage figures are version-scoped by construction, so they will drop at the next version switch and climb again as the queue catches up.
03 More
- Where a number comes from: every figure re-aggregates at build time from 14,908 append-only sandbox records. Per plugin: GET /data/install/<id>.json.
- Live view: /verification/ applies the same verdict rule to the current dsh version and refreshes every build.
- Earlier volumes: Vol.1 (0.1.2-alpha.1 → 0.1.3-alpha.1), kept as published.
- Independence: dsh.so is an independent project, not affiliated with DeepSeek; a verdict is an observation over sandbox records, never an endorsement.
Q How should I read 3,202 failures?
As two different events. 115 never installed in the sandbox; 3,087 installed but failed the web runtime gate — 92.4% of them with the identical recorded text "plugin tree failed to load". Treat that as a shared gate symptom, not 3,087 independent plugin quality verdicts.
Q Is a runtime-verified plugin a safe plugin?
No — verification and security are independent axes. Runtime verification says the plugin installs and runs; it says nothing about what it does. Security is reported separately on each plugin page.
Cite this report
dsh.so — DeepSeek Harness Plugin Install Ecosystem Report, Vol.2 (published 2026-09-10). Window: 0.1.2-alpha.1 -> 0.1.2-rc.1 -> 0.1.3-alpha.1 -> 0.1.3-alpha.2 · verification batch started 2026-09-08 17:18:15 (UTC+8) Registry: 14,496 · runtime verified (L5) 7,175 · installed (L4) 13,683 · failed 3,202 https://dsh.so/reports/install-vol2/