Verification levels

What is the difference between L1 and L2?

L1 verifies that a GitHub repository exists, is non-empty, and has a README. L2 goes one step further: the manifest or package.json is valid and carries the key fields needed to catalog the plugin (name, license, description). Most entries pass L1 or L2 because those checks are automatable against public repository data.

Why is not every plugin verified at L3 or above?

L3 is the paper spec: the install command can be parsed from the manifest with a declared DSH version requirement — nothing is installed yet. L4 actually executes that command in an isolated sandbox — it installs. L5 then has dsh load the plugin and pass a runtime smoke — it runs. All three checks execute automatically at registry scale; a level is only claimed when real evidence exists and labels are never silently upgraded.

What does the L4 install test actually do?

It executes each plugin's declared install command inside a throwaway, permission-restricted sandbox and checks that installation completes without dependency errors. Failures usually mean environment or compatibility issues and are recorded as quality signals — verification only answers "can it be installed, can it run", an independent dimension from security and health.

What does the L5 smoke verification add?

On top of a passing L4 install, the dsh web UI is booted with the plugin inside the same sandbox: dsh loads the plugin and runs a restricted allowlist smoke action (ping / health / metadata / fixture), while the pipeline verifies UI readiness and the HTTP response; some plugins additionally get inventory and client-bundle checks. A failed boot usually means a compatibility issue with the current dsh version.