SaaS Metrics
GitHub Issue
Design partner: dshmarket@1.12.0 passes initial DSH Testkit lifecycle
## Proposed design-partner lifecycle validation
We are maintaining [DSH Testkit](https://github.com/iiwish/dsh-testkit), an unofficial Docker-based real-host lifecycle gate for DSH plugins. We ran the current public npm artifact `dshmarket@1.12.0` as a candidate design-partner subject.
### Initial evidence
- Artifact: `dshmarket@1.12.0`
- Tarball digest: `sha256:8d3bb4a346182175a21d879bd7bed17a396e013f11de3017cd0187f7d9012647`
- Testkit: `0.3.1`
- DSH: `0.1.0-rc.6`
- Runner: Docker, Linux arm64, Node `22.23.2`, pnpm `11.1.3`
- Expected bundle row: `dsh-market`
The full `quick` suite passed: resolve, exact DSH install, package, plugin install, profile assembly, boot, runtime probe, uninstall, reboot, and cleanup. No process, port, or canary residue was observed. The report is bound to this exact artifact and host scenario; it is not a security certification or marketplace ranking.
### Invitation
Would the maintainers like to participate as a design partner? We can:
1. Confirm the smallest deterministic scenario and the supported DSH release train.
2. Add only the public row/service/tool expectations that the plugin contract actually promises.
3. Generate an opt-in least-privilege GitHub Actions workflow with `dsh-testkit init`.
4. Rerun the immutable release artifact after any change and share the machine-readable evidence.
The initial run is intentionally conservative: it verifies the bundle row and lifecycle cleanup, but does not assume any UI capability as a tool or...
View Raw Thread
Developer & User Discourse
iiwish • Aug 18, 2026
Thank you — this is exactly the level of contract detail we needed, and I confirm the partnership.
I recorded the supported floor (`0.1.0-rc.6`), the loader/package name distinction (`dsh-market` / `dshmarket`), the host-route surface, and the smallest scenario in [DSH Testkit #18](https://github.com/iiwish/dsh-testkit/issues/18).
The first follow-up will stay deliberately narrow: pinned published artifact → boot → `GET /dsh-market/status` with HTTP 200 and artifact-matching `version` → exact loader row → uninstall/reboot/residue check. I will keep update/rollback and CRLF patch cases as later opt-in scenarios rather than expanding the first gate.
I will also treat the route response as evidence only, not a certification or ranking, and keep the route probe restricted to the disposable host. Once the route assertion surface is implemented, I will rerun `dshmarket@1.12.0` against the exact digest already verified here and attach the machine-readable report.
Thanks for the careful wa...
I recorded the supported floor (`0.1.0-rc.6`), the loader/package name distinction (`dsh-market` / `dshmarket`), the host-route surface, and the smallest scenario in [DSH Testkit #18](https://github.com/iiwish/dsh-testkit/issues/18).
The first follow-up will stay deliberately narrow: pinned published artifact → boot → `GET /dsh-market/status` with HTTP 200 and artifact-matching `version` → exact loader row → uninstall/reboot/residue check. I will keep update/rollback and CRLF patch cases as later opt-in scenarios rather than expanding the first gate.
I will also treat the route response as evidence only, not a certification or ranking, and keep the route probe restricted to the disposable host. Once the route assertion surface is implemented, I will rerun `dshmarket@1.12.0` against the exact digest already verified here and attach the machine-readable report.
Thanks for the careful wa...
fkysly • Aug 18, 2026
Agreed on all of it, and keeping the first gate narrow is the right call.
One implementation detail that would otherwise cost you a confusing failure: **`version` in `/dsh-market/status` only exists from 1.11.2 onward.** It was added so a screenshot of a bug report carries the version, and the status route inherited it.
So the assertion "`version` matches the artifact under test" is correct for 1.11.2 and newer, and will fail on anything older for a reason that has nothing to do with the plugin working. If you ever pin an older artifact for comparison, fall back to the loader row and a 200 from the route.
The other fields you named are older and safe across the whole supported range: `pnpm`, `boot`, `restart`, `installed`.
Nothing else from us — go ahead and rerun against the digest when the assertion surface is ready. If a scenario fails against a released artifact, an issue here with the machine-readable report is exactly the right channel, and we will treat it as a real report r...
One implementation detail that would otherwise cost you a confusing failure: **`version` in `/dsh-market/status` only exists from 1.11.2 onward.** It was added so a screenshot of a bug report carries the version, and the status route inherited it.
So the assertion "`version` matches the artifact under test" is correct for 1.11.2 and newer, and will fail on anything older for a reason that has nothing to do with the plugin working. If you ever pin an older artifact for comparison, fall back to the loader row and a 200 from the route.
The other fields you named are older and safe across the whole supported range: `pnpm`, `boot`, `restart`, `installed`.
Nothing else from us — go ahead and rerun against the digest when the assertion surface is ready. If a scenario fails against a released artifact, an issue here with the machine-readable report is exactly the right channel, and we will treat it as a real report r...
iiwish • Aug 18, 2026
Thanks for the refinement. We will encode the `1.11.2` threshold in the route scenario rather than assuming `version` exists on every historical artifact:
- `>=1.11.2`: assert `version` equals the immutable artifact version;
- older artifacts: assert HTTP 200, the stable status fields, and the exact loader row without treating a missing `version` as a failure.
That gives us a narrow, reproducible first gate while preserving useful historical comparisons. I will update the Testkit issue and use this contract when the route assertion surface is implemented.
- `>=1.11.2`: assert `version` equals the immutable artifact version;
- older artifacts: assert HTTP 200, the stable status fields, and the exact loader row without treating a missing `version` as a failure.
That gives us a narrow, reproducible first gate while preserving useful historical comparisons. I will update the Testkit issue and use this contract when the route assertion surface is implemented.
fkysly • Aug 18, 2026
That encoding is right, and it is the version of the rule I would have written. Nothing further needed from us on the contract.
One heads-up that touches your first gate specifically, since it landed today: **1.12.2 is out**, and what it changes is the path your scenario exercises.
A Windows desktop host was launching dsh without the Node install directory on PATH. Node was running; `npm` and `corepack` were not reachable; one-click pnpm setup could not succeed, and with no pnpm the market installs nothing (#167). The fix looks for the toolchain beside `process.execPath` — the one directory the process cannot be wrong about, since it is executing out of it.
This matters to you because "install the artifact into a fresh profile" is exactly the step that needs a package manager present. If your disposable host is a clean Windows image, that step could have failed on 1.12.0 for an environment reason rather than a plugin one — and a first gate that red-lights on its own harness is worse...
One heads-up that touches your first gate specifically, since it landed today: **1.12.2 is out**, and what it changes is the path your scenario exercises.
A Windows desktop host was launching dsh without the Node install directory on PATH. Node was running; `npm` and `corepack` were not reachable; one-click pnpm setup could not succeed, and with no pnpm the market installs nothing (#167). The fix looks for the toolchain beside `process.execPath` — the one directory the process cannot be wrong about, since it is executing out of it.
This matters to you because "install the artifact into a fresh profile" is exactly the step that needs a package manager present. If your disposable host is a clean Windows image, that step could have failed on 1.12.0 for an environment reason rather than a plugin one — and a first gate that red-lights on its own harness is worse...
```
claimed 8d3bb4a346182175a21d879bd7bed17a396e013f11de3017cd0187f7d9012647
actual 8d3bb4a346182175a21d879bd7bed17a396e013f11de3017cd0187f7d9012647
```
That is the tarball npm serves for `dshmarket@1.12.0`. Starting from a published artifact is the part that makes this worth reading.
Answers to your four points, in the order you raised them.
## 1. Supported DSH release train
**0.1.0-rc.6 and newer.** rc.6 is a hard floor, not a preference: below it the client primitives the market renders with do not exist, and it disables itself deliberately rather than throwing mid-render.
Both rc.6 and rc.7 are supported and both are verified — we ran our own layer-3 lane against each yesterday, not just the newer one. Your run used rc.6, which is the floor, so it is the more interesting of the two to keep pinned.
One rc.7-only surface exists (a settings c...