English | 中文
Each package owns one independently versioned part of the proposal. Consumers should depend on the narrowest package that defines the behavior they use.
| Package | Responsibility | Depends on a product |
|---|---|---|
@dsh-std/core |
Protocol declarations, definition registration, and meta-negotiation | No |
@dsh-std/manifest |
Draft dsh-plugin.json manifest, schema, and static validation |
No |
@dsh-std/composition |
Facet selection, static preflight, and composition plans | No |
@dsh-std/lifecycle |
Activation instances, cleanup, and the publication barrier | No |
@dsh-std/sdk |
TypeScript facet and typed-protocol helpers | No |
@dsh-std/command |
Declarative human-command trees | No |
@dsh-std/ui-browser |
Optional browser-realm UI surfaces and module ABI | No |
@dsh-std/storage |
Component-private JSON key-value storage | No |
@dsh-std/messages |
Read-only message observation events | No |
@dsh-std/model |
ModelProvider resources and the shared ModelCatalog | No |
@dsh-std/tool |
Tool discovery and live availability | No |
@dsh-std/skill |
Declarative, lazily loaded Skill instruction resources | No |
@dsh-std/presentation |
Invocation-scoped user-facing operations | No |
@dsh-std/connection |
Endpoint negotiation and implementation-neutral invocation | No |
@dsh-std/adapter-dsh |
DeepSeek Harness and Cordis integration | Yes |
dsh-std |
Unscoped npm name reservation | No runtime API |
Protocol packages may depend on @dsh-std/core and may explicitly adopt the capability helper in @dsh-std/connection when they use an RPC shape. They must not depend on product adapters. Adapters may depend on the protocol packages they map into a product.