7d3cb39047
# Conflicts: # .agents/notes/implemented/feature/2026-06-30-interception-seams.md # docs/config-catalog.md # docs/cookbook/adding-a-tool.i18n.yaml # docs/cookbook/adding-a-tool.md # docs/cookbook/adding-a-tool.zh.md # docs/cordis-catalog/events.md # docs/cordis-catalog/services.md # docs/core-data-structures/tools.md # docs/event-producer-consumer.md # docs/persistence-catalog.md # examples/acp-agent/tests/snapshots/cordis-inspect-jsdoc/session.jsonl # examples/acp-agent/tests/snapshots/cordis-inspect-jsdoc/stdout.expected.jsonl # packages/bash/tool-bash/src/index.ts # packages/core/agent-loop/src/tool-calls.ts # packages/core/agent-loop/tests/cancel.spec.ts # packages/core/agent-loop/tests/contract-regressions.spec.ts # packages/core/agent-loop/tests/tool-calls.spec.ts # packages/core/tools/README.md # packages/core/tools/src/index.ts # packages/core/tools/tests/code-mode.spec.ts # packages/core/tools/tests/tools.spec.ts # packages/fs/tool-fs-search/tests/integration.spec.ts # packages/fs/tool-fs-search/tests/tools.spec.ts # packages/fs/tool-fs/tests/integration.spec.ts # packages/mcp/mcp-client/src/tools.ts # packages/timeout/timeout-policy/tests/timeout-policy.spec.ts # packages/web/tool-web/tests/integration.spec.ts # packages/web/tool-web/tests/tool-web.spec.ts
examples/ — ready-to-run demo bundles
Pre-composed plugin bundles a thin leaf cordis.yml loads instead of assembling the spine and a front door by hand. These are demo / reference packages — the -demo npm suffix marks each one as non-product surface, readable straight off the package name. The runnable leaves under the repo-root examples/ and the Python SDK runtime are the consumers; each is just its swappable backends plus one bundle entry.
| Package | npm name | Role |
|---|---|---|
agent-spine-demo/ |
@deepseek-ai/dsh-agent-spine-demo |
The executor-less/UI-less agent spine as one bundle plugin, with an opt-in persisted-goal stack |
tui-demo/ |
@deepseek-ai/dsh-tui-demo |
Full-screen terminal app: the spine + persisted goals + /goal command + JSONL persistence + dsh-tui + a pre-created main agent, with a boot bin |
cli-demo/ |
@deepseek-ai/dsh-cli-demo |
Headless one-shot app: the spine + JSONL persistence + a pre-created main agent, with text and DSH-native JSON output |
acp-demo/ |
@deepseek-ai/dsh-acp-demo |
ACP server app: the spine + persisted goals + /goal command + JSONL persistence + the acp bridge (no stdout logger), with a boot bin |
jsonrpc-demo/ |
@deepseek-ai/dsh-jsonrpc-demo |
Bin-only runtime that boots an external cordis.yml for the stdio JSON-RPC SDK client |
agent-spine-demo is the shared bundle; tui-demo, cli-demo, and acp-demo compose it with full-screen terminal, headless one-shot, and ACP front doors and own their boot bins. jsonrpc-demo mounts no composition of its own — it boots whatever tree the deployment's cordis.yml names, and is what the Python SDK runtime launches.
These are not product API. The spine pieces they bundle live in core/, the bridges/channels/boot-glue in ui/, and the swappable backends (LLM adapter, bash executor) in their capability groups; a demo bundle just picks one concrete composition of them. Swap or fork one freely.
Do not confuse this group with the repo-root examples/: that directory holds the runnable cordis.yml leaves; this group holds the bundles those leaves load.
The jsonrpc bin/exe names are legacy
jsonrpc-demo renamed like its siblings, but its bin is still dsh-jsonrpc-agent and the single-file executable is still dsh-jsonrpc-agent-pkg (referenced across the Python distribution). Those names are the SDK's runtime-startup surface; they are reconciled when the SDK unifies that startup flow, not by this move.