Write the user job before the package
Choose one capability small enough to verify: transform a known input, expose one tool, or add one bounded UI behavior. Define input, output, configuration, failure state, and permissions before choosing file names. This becomes the smoke-test contract.
A scaffold is useful only when it follows the current runtime
DSH describes an everything-is-a-plugin architecture built around Cordis. HarnessBase will derive the scaffold from the current official packages rather than invent a generic npm plugin shape.
Test load, use, failure, and unload
A creation guide should prove the plugin is discovered, its configuration is read, the feature executes, a malformed configuration fails clearly, and removal leaves the host usable. Record console output without keys, local machine paths, or unrelated environment data.
- Install/load result.
- Feature smoke test.
- Invalid configuration result.
- Permission and network observation.
- Remove or disable result.
Document for verification, not promotion
The README should identify supported DSH versions, exact install command, configuration fields, permission needs, example task, expected output, limitations, update policy, and repository ownership. A topic tag helps discovery but does not establish compatibility.
Implementation gate
HarnessBase will build and load the minimal plugin, retain the fixture and logs, then add a downloadable scaffold. Until that succeeds, this page stays a transparent research draft.
Sources and evidence boundary
Primary sources establish product facts. HarnessBase labels direct testing separately and does not convert community observations into verified results.
- Official product page ↗ — Everything-is-a-plugin product model.
- Official repository ↗ — Current packages and runtime architecture.
Target query cluster: create DeepSeek Harness plugin · build DSH plugin · DeepSeek Harness plugin development