Packages

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/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.