Source association
Confirms the relationship among package, source repository, and publisher. It proves provenance only, not function or safety.
Registry methods and boundaries
Validation standards
Understand what each passing result proves, what it does not prove, and where public facts come from.
This is not a “safety certification”
Registry presents source, runtime tests, permissions, risks, maintenance, and freshness separately instead of combining them into a vague trust or safety score.
Test evidence
Five independent validation dimensions
Passing one stage does not automatically pass the next.
Install and boot
Installs an exact version in isolation and boots DSH. This alone does not prove the plugin’s core capability works.
Functional smoke
Runs an observable assertion for the plugin’s primary capability and records environment, input, result, and time.
Full lifecycle
Validates upgrade, uninstall, recovery, and cleanup separately. Any missing stage remains explicitly not tested.
Composition validation
Checks permissions, order, conflicts, outcome, and recovery when exact versions of multiple plugins run together.
DSH version compatibility
Prioritize current Stable, NEXT, and Developer channels and record the exact DSH version or commit, profile, platform, architecture, and test time.
- Declared support:Provided by the plugin author.
- Observed pass:Produced by a Registry TestRun.
- Not tested:Means current evidence is absent; it is neither a failure nor a pass.
Permissions and risks
Permission declarations and Registry observations remain separate. Risks describe only evidenced exposure and never claim absolute safety.
- Missing information is shown as unknown.
- Every evidence item binds to an exact plugin version.
- Stale evidence remains in history but does not count as current coverage.