Harness packages use the @deepseek-ai/dsh-* scope. Each is a Cordis plugin: a default Service subclass or functional plugin declaring ctx keys/events through declaration merging and contributing through ctx.effect(), ctx.on(), or ctx.waterfall(). Authoring conventions: AGENTS.md and root AGENTS.md § Conventions.

Hierarchy

Packages are grouped by modular role at packages/<group>/<pkg>/. The group directory is a pure container (no package.json); the package name stays @deepseek-ai/dsh-<pkg> regardless of group. Each group README is the canonical per-package map — package roles, ctx keys, and the product-vs-support split live there, next to the code.

Group	Role	Release expectation
`core/`	Product API spine: session, system-prompt, tools, agent, and the concrete loop	Product — stable surface
`llm/`	LLM capability family: the abstract service + provider adapters	Product — stable surface
`bash/`	Bash capability family: the executor seam, a local impl, and the model-facing tool	Product — stable surface
`code-runtime/`	Code-execution capability family: the abstract runtime seam for model-written programs + a worker-thread backend	Product — stable surface
`sandbox/`	Process-confinement seam; bwrap/Landlock/Seatbelt backends	Product — stable surface
`fs/`	Filesystem capability family: the abstract seam, a local impl, and the model-facing file tools	Product — stable surface
`skill/`	Skill capability family: the provider registry, local provider, and model-facing catalog/loader	Product — stable surface
`compact/`	Compaction capability family: the abstract seam + a basic backend (tool deferred)	Product — stable surface
`subagent/`	Subagent capability family: the provider-registry seam and the model-facing delegation tool	Product — stable surface
`workflow/`	Workflow capability family: the script-engine seam, the worker-thread engine, and the model-facing `workflow` tool	Product — stable surface
`web/`	Web capability family: the abstract seam, search/fetch provider impls, and the model-facing web tools	Product — stable surface
`timeout/`	Tool-call timeout policy: the `tools/execute` deadline enforcer	Product — stable surface
`todo/`	Todo/planning family: the model-facing `todo_write` tool	Product — stable surface
`guard/`	Loop-hygiene guards: advisory repeat-call reminders	Product — stable surface
`cordis/`	Self-referential runtime toolset: inspect the live runtime's plugins and services, mount/unmount model-written plugins (design)	Product — stable surface
`hooks/`	Hook bridges + the shared Claude Code / Codex wire-protocol library	Product — stable surface
`session-persistence/`	Persistence capability family: the seam + JSONL/SQLite backends	Product — stable surface
`ui/`	Editor/client integration surfaces: ACP bridge, app packages, user-approval and user-interaction seams, ask-user tool	Product — stable surface
`support/`	Dev/test/example infrastructure (invariants, replay adapter, subagent mock)	Support — lower compatibility expectations
`util/`	Low-level zero-dependency utilities shared across groups (the `Branded<B>` primitive)	Support — small, stable, harness-dep-free

The split is the point: a package's group says whether it is part of the product API or support/test/example infrastructure, so release and removal decisions do not treat every package as an equal public contract. New packages join an existing group; adding a new top-level group is a deliberate act (extend the group READMEs and this table).

Dependencies

The inter-package dependency graph is generated: docs/module-graph.md (pnpm run gen-module-graph, freshness-gated in CI).

The rule it must obey: extension plugins depend on interfaces, never on the concrete loop. dsh-agent-loop is swappable — UI/hook/tool plugins keep working against the dsh-agent vocabulary if the loop is replaced. The sanctioned exception is a composition/bundle package like dsh-agent-core, whose whole job is to assemble the concrete spine: it depends on dsh-agent-loop (and the other concrete spine plugins) on purpose. The rule constrains plugins that EXTEND the system, not the bundle that COMPOSES it. A swappable capability splits into interface / implementation / consumer packages (the bash trio is the template — see capability seams).

Each package has its own README.md with purpose, service API, events, extension points, deliberate non-goals, and the standard Model Experience table.