DSHX Plugin Development
Build the requested plugin from project evidence and verify the actual DSH path it depends on. Keep DSHX build-time and runtime-thin; official DSH and Cordis retain runtime ownership.
Establish the project contract
Read references/development-workflow.md before changing files. Classify the workspace as a new plugin, an existing DSHX plugin, or the DSHX framework repository. Inspect git state, lockfile/package manager, package manifest, config, entries, installed versions, Profile evidence, and tests. Use pnpm for DSHX repository work and generated Preview examples. Preserve unrelated work.
Prefer evidence in this order:
- installed package types, manifest, and lockfile;
- offline
dshx check diagnostics;
- runtime
dshx inspect results for the active Composition;
- current published DSHX references;
- adjacent DSH source only for investigation, never as published compatibility proof.
Route to the required authoring surface
Read only the relevant section of references/api-map.md. Do not reconstruct public signatures from memory.
- Keep Node, secrets, filesystem, validation, and privileged actions in Host code.
- Keep React and Hooks in Client code; shared modules must remain portable contracts.
- Use
defineLocale() for plugin-owned zh/en copy. Do not ask authors to augment LocaleNamespaceMap; raw namespace strings are only for provider-owned advanced integrations.
- Declare official runtime/provider packages at the manifest boundary. Generated Cordis injects do not replace
dsh.client.inject package edges.
- Let official services own registries, scope, ordering, Prompt assembly, persistence, transport, replay, HMR, and disposal. Register long-lived resources with the official lifecycle.
- Treat Conversation Components and programmatic Tooling as Experimental.
Prove the requested behavior
At minimum run the plugin's offline check, relevant tests, and build. Use runtime check and a real dshx dev session when the result depends on a Profile, registration, transport, UI, restart, or HMR. Verify the exact user path; distinguish offline/type/build evidence from real DSH evidence.
If packaging or Preview publication is requested, also read references/release-checklist.md. Inspect the actual archive and preserve npm latest. Publishing, pushing, deploying, catalog submission, and Profile mutation beyond the requested development loop require explicit authorization.
1---2name: dshx-plugin-development3description: Create, modify, diagnose, review, package, or Preview-publish an out-of-tree DeepSeek Harness plugin authored with DSHX. Use for @becomeopc/dshx, create-dshx, dshx.config.ts, Host/Client contributions, defineLocale, Prompt, Settings, typed API, Slots, Conversation Components, dshx check/build/dev/inspect/add, and DSH Profile verification. Do not use for DSH core implementation or Framework Hub administration.4---56# DSHX Plugin Development78Build the requested plugin from project evidence and verify the actual DSH path it depends on. Keep DSHX build-time and runtime-thin; official DSH and Cordis retain runtime ownership.910## Establish the project contract1112Read [references/development-workflow.md](references/development-workflow.md) before changing files. Classify the workspace as a new plugin, an existing DSHX plugin, or the DSHX framework repository. Inspect git state, lockfile/package manager, package manifest, config, entries, installed versions, Profile evidence, and tests. Use pnpm for DSHX repository work and generated Preview examples. Preserve unrelated work.1314Prefer evidence in this order:15161. installed package types, manifest, and lockfile;172. offline `dshx check` diagnostics;183. runtime `dshx inspect` results for the active Composition;194. current published DSHX references;205. adjacent DSH source only for investigation, never as published compatibility proof.2122## Route to the required authoring surface2324Read only the relevant section of [references/api-map.md](references/api-map.md). Do not reconstruct public signatures from memory.2526- Keep Node, secrets, filesystem, validation, and privileged actions in Host code.27- Keep React and Hooks in Client code; shared modules must remain portable contracts.28- Use `defineLocale()` for plugin-owned `zh`/`en` copy. Do not ask authors to augment `LocaleNamespaceMap`; raw namespace strings are only for provider-owned advanced integrations.29- Declare official runtime/provider packages at the manifest boundary. Generated Cordis injects do not replace `dsh.client.inject` package edges.30- Let official services own registries, scope, ordering, Prompt assembly, persistence, transport, replay, HMR, and disposal. Register long-lived resources with the official lifecycle.31- Treat Conversation Components and programmatic Tooling as Experimental.3233## Prove the requested behavior3435At minimum run the plugin's offline check, relevant tests, and build. Use runtime check and a real `dshx dev` session when the result depends on a Profile, registration, transport, UI, restart, or HMR. Verify the exact user path; distinguish offline/type/build evidence from real DSH evidence.3637If packaging or Preview publication is requested, also read [references/release-checklist.md](references/release-checklist.md). Inspect the actual archive and preserve npm `latest`. Publishing, pushing, deploying, catalog submission, and Profile mutation beyond the requested development loop require explicit authorization.
liyown