Test DeepSeek Harness Plugins

Select the smallest set of test levels that proves the change is correct. Do not run the full suite by default or repeat checks that have already passed.

Test Harness Version Migrations

When adapting an existing plugin to a new DSH host version:

1. Read references/version-migration-testing.md, build a migration ledger for the exact from/to versions, and scan all seven touchpoint classes.
2. Add a targeted regression test for every applicable breaking or behavior change. A change-level test proves only that migration mapping; it does not prove the whole plugin is valid.
3. Cold-start the exact target version through the real product entry point and complete a full user turn. Typechecking, config parsing, Loader smoke tests, and mock Contexts cannot replace this runtime proof.
4. Report unavailable credentials, providers, operating systems, browsers, PTYs, and destructive-migration boundaries honestly. Do not claim comprehensive compatibility when any remain unverified.

The commands and repository paths below use test-level names from the official Harness monorepo. For external plugins, use equivalent scripts and paths from their own repositories. Do not add nonexistent Harness root commands or impose the monorepo layout on them.

Run a Docker Release Smoke Test

For a pre-release external plugin check, read references/docker-release-smoke.md and use the included runner on the packaged artifact. Pin one exact DSH version and a non-latest Node image, install the artifact into an isolated Profile, cold-start the real DSH entry, and add one argv-based functional probe when startup alone does not exercise the changed behavior.