The evidence boundary
A static repository check can find a bundle manifest and a documented command. Install verification crosses a different boundary: it executes that published command in an isolated environment, then reads the profile manifest written by DSH itself. A successful process exit is not sufficient evidence.
The verdict model
Every completed run lands in one named state. Infrastructure errors such as registry throttling are omitted rather than misreported as plugin failures.
| Verdict | Observed result | What it means |
|---|---|---|
| Passed | Package installed and appears in dsh.profile.bundles. | Registered in the disposable profile. |
| Not a layer | Package landed as a dependency but declares no dsh.bundle. | Install worked; this package is not a profile layer. |
| Needs approval | A build or prepare script was refused. | Potentially recoverable through a reviewed allowBuilds entry. |
| Rejected | The published string is outside the runner command contract. | Nothing executed; fix or manually review the install path. |
| Failed | No usable manifest or bundle registration appeared. | A real install or packaging defect was observed. |
| Timeout | The isolated run exceeded its wall-clock budget. | No compatibility conclusion; investigate the install path. |
A reproducible environment
A verdict is useful only when its environment is named. Each registry result records the DSH release, Node version, package-manager version, platform, command, timestamp, and pinned runner commit. A later run never silently overwrites the meaning of an older environment.
- One fresh container and DSH home per command.
- No host mount and no credentials inside the install container.
- Dropped Linux capabilities, no privilege escalation, and fixed memory, CPU, PID, and time limits.
- Network remains enabled because package resolution is part of installation; this is isolation, not proof that code cannot exfiltrate public network data.
Install verification is not runtime verification
Registration proves that DSH recorded a bundle. The registry then asks the same disposable environment to compose the named profile through --dump-config. Runtime verification still requires a small capability-specific smoke test, and combination testing is another layer because two plugins can each work alone and still conflict together.
| Field | Install run answers it? | Stronger evidence required |
|---|---|---|
| Registered in profile | Yes | Read dsh.profile.bundles after installation. |
| Profile composition | Yes, after registration | Run dsh --profile <name> --dump-config in the same container. |
| Capability works alone | No | Run a deterministic capability smoke test. |
| Combination tested | No | Test a named plugin set against the same profile. |
| Safe to trust | No | Source review, dependency intelligence, and an explicit threat model. |
DeepSeek Harness is in developer preview. Recheck official documentation and plugin evidence when the host version changes.
Sources and evidence
Official documentation and community evidence are labeled separately in the source pages and in this article.