Plugin-only architecture

This document defines the implementation boundary for the Extension Center on DeepSeek Harness 0.1.2-alpha.3. The compatibility target is the unmodified official source tag dsh-v0.1.2-alpha.3 at deepseek-ai/deepseek-harness@dd6322d604e00eec1ba5e0c8541159906a21094a. The Center is distributed as a deterministic GitHub-hosted tarball and does not require an npm publication. Stable Center 0.1.0 evidence remains historical and scoped only to official DSH 0.1.1-rc.2.

Product boundary

DSH remains the official Host. The Extension Center is one independently installed DSH bundle and must not require a DSH source patch, a fork-only package, or an upstream Host pull request. Its Host half, Web Client half, catalog discovery and admission, plans and grants, journals and receipts, verification, recovery coordination, continuation, and acceptance tests ship from this repository.

The Center itself is installed, updated, or removed only through the official external command dsh plugin --profile <profile> .... A running Center never attempts to replace or remove itself.

Extensions acquired through the Center use Center-owned control records and type-specific physical owners:

• The Center stages, verifies, and retains exact admitted Plugin archives and owns the approved operation, journal, receipt, recovery selection, and verification evidence. Package membership changes for every admitted child Plugin Bundle, whether Host-only or Host+Client, use the official dsh plugin --profile CLI; only the official Profile package manager writes dependencies, lock data, node_modules, Bundle membership, and the resulting Loader row. Pure configuration replaces the exact managed row through the official Loader and is verified on the same Host process. The Center never writes package-manager locations directly or edits official DSH code. Install, update, uninstall, and restore require a later Host boot to verify the exact official Profile dependency, Loader contribution, and declared consumer before terminal success.
• MCP connections use a Center-owned durable desired-state provider. Enabled records mount the official @deepseek-ai/dsh-mcp-client; disable, update, remove, restore, and purge dispose or replace only the fibers and records owned by the Center.
• Skills remain files and records owned by the Center and are projected through the official ctx.skills registry. Scope and invocation flags remain Skill-specific.
• Original-task continuation uses a Center-owned durable claim store and the official Agent, Session, and persistence services. A verified single-use claim resumes only the original session and never retains the original task text.

Plugin, MCP, and Skill states remain distinct even though Store discovery, policy, review, authorization, receipts, and recovery share one product surface.

Official extension points

The implementation may depend only on public behavior exposed by exact official DSH 0.1.2-alpha.3:

• the official dsh plugin --profile CLI for every admitted child Plugin Bundle installation, update, downgrade, and removal;
• Cordis Loader public configuration and observation methods for applying and verifying pure configuration of the Profile-managed Plugin contribution, never direct package installation;
• ctx.tools and ctx.skills registration with effect-scoped disposal.
• @deepseek-ai/dsh-mcp-client for one admitted MCP connection runtime.
• ctx.agentPresets, ctx.agents, Sessions, Session persistence, and the public Agent/Session lifecycle events for same-session continuation and reconciliation.
• the Connection-authenticated @deepseek-ai/dsh-client-connection browser RPC channel and dsh.client Web bundle declaration for the Center UI. Official release acceptance uses the ordinary Web Profile on its default loopback bind.

Any missing service fails Center acquisition closed with a precise capability projection. It does not trigger installation of a Host patch.

Ownership and recovery

Every action has one Center-owned operation record, a monotonic revision, an immutable approved plan, a per-target lock, an append-only journal, a verification result, and a content-addressed receipt. Center archive storage uses private directories, no-follow reads, canonical paths, exclusive creation, and atomic pointer replacement. Before invoking the official Plugin CLI, the Center fences the observed Profile dependency and rejects a foreign or drifted target. The official Profile package manager remains the physical owner of its dependency, lock, node_modules, Bundle membership, and Loader row. The official 0.1.2-alpha.3 external CLI exposes no lock or compare-and-swap token to the Center, so the per-target lock serializes Center operations only. Acceptance therefore runs one controlled external-CLI ABA ordering and requires recovery-required rather than false success; its receipt does not claim every possible process interleaving.

Catalog and owner revisions are live admission fences until the approved plan is consumed. Consumption creates the durable execution authority. Provider execution, restart settlement, rollback, and break-glass reconciliation then use only the consumed plan and authorization, the exact durable intent payload, the journal, and the provider snapshot. Terminal receipt repair and target-lock release use the consumed plan, authorization, and terminal journal even if the intent that caused a pre-mutation failure is unavailable; task-continuation bookkeeping retries separately when its intent payload is readable. A Plugin rollback first verifies the exact restored state, then persists the terminal receipt, removes transient absent-state proof, and finally releases the target lock. Every authoritative record removal synchronizes its parent directory before the next lifecycle phase; a failed synchronization is surfaced and keeps the operation fenced for startup recovery. Startup recovery retries proof removal when the receipt is durable; without a receipt, unavailable provider proof retains the lock. A later catalog revision or candidate removal cannot strand an already authorized rollback. Catalog removal is not an emergency revocation mechanism.

The standalone recovery executable is package-owned, hash-pinned, and independent of a working Center or Host boot. Recovery binding schema v5 contains official-execution binding v2: it pins the recovery bytes and Center root; the canonical Node executable, version, and digest; a package-owned process-group supervisor; the private bundled pnpm@11.21.0 registry SRI, complete tree, entrypoint, shim, and POSIX shell; and the exact official DSH 0.1.2-alpha.3 package, entrypoint, hostHome, timeout, and recursively resolved installed production-dependency closure. Both normal and standalone mutation verify every pin, require the exact official Profile workspace, reject .npmrc, pnpmfiles, and manifest execution fields, and construct a minimal environment with per-operation XDG/config directories. For an installed Profile, the Center strictly parses the exact pre-mutation manifest, pnpm 11 lock and modules metadata, and referenced installed package manifests. It synthesizes owner-only pnpm abbreviated and full registry metadata into a content-addressed generation whose identity binds those source digests, the existing canonical store, every generated file, its manifest, and the pinned pnpm runtime. The Plugin provider recovery snapshot carries that binding; normal rollback and standalone break-glass therefore verify the same generation before use. Missing, changed, symlinked, or mismatched cache material fails before the next official CLI Profile write. Package-manager execution stays offline with lifecycle scripts disabled; generation does not contact a registry or promise unavailable package bytes. Only a Profile with neither lock nor node_modules installation receives a Center-private per-Profile store. The supervisor terminates the complete mutation process group on timeout, caller signals, or caller stdin loss, including caller SIGKILL; an exact execution record prevents stale-lock recovery while that process group remains live. Mutation and recovery support macOS and Linux and fail closed on Windows. Recovery then verifies the journal-bound provider before-state, invokes the bound official CLI to restore that exact Profile state, verifies the result, and only then commits Center control state. Once provider apply begins, an unavailable mutation proof remains recovery-required with its exact lock instead of becoming a failed receipt. Exact rc.0 pnpm 11.7.0 version and SRI pairs remain readable only as durable history. Before owner reconciliation, startup cross-checks their consumed authorization against the journal or pre-journal reservation and reads the Center and owner sidecar projections without initializing the owner; any unfinished operation, any Plugin rollback awaiting finalization, and any failed Plugin journal still referenced by durable owner state retain the exact target lock, expose no recovery command, and cannot reach provider, Loader, Node, pnpm, or official CLI execution. Unknown or mixed runtime identities are corruption, not compatibility input. The Center does not call a fork-only protocol, edit DSH source or packages, or write Profile dependency, lock, node_modules, Bundle membership, or Loader state directly.

Artifact acquisition rejects all IPv4 and IPv6 literals in initial and redirect URLs, binds the consumed authorization to the signed coordinate captured in the immutable plan, and verifies the admitted size and digest. Hostnames and DNS remain untrusted because this check does not resolve names; it does not claim DNS-rebinding protection.

Optional extended release provenance

This section records the historical and future public-Release proof model. It is not required by the current latest-official-DSH compatibility gate and does not require publishing the Center to npm.

The only eligible release candidate is the deterministic tarball, SHA256SUMS, and self-digested attestation uploaded by the exact main-push Node 22 CI job. The CI verifier binds the GitHub Actions archive digest, run id and attempt, exact bounded three-entry ZIP payload, each entry's byte digest and size, source commit, packed manifest, bundled pnpm tree, and tarball bytes. It accepts only the fixed GitHub API artifact URL followed by one admitted GitHub Actions or Azure Blob storage redirect. A public Release must contain exactly those three assets with identical bytes, and its protected lightweight tag must refer directly to the release commit. The public verifier resolves that tag through bounded Git refs metadata, then uses GitHub CLI 2.88.1 or newer to verify the explicit tag and each downloaded asset. It admits only the current signed Release v0.2 predicate and verified GitHub release-service identity, and records the concrete Release id, tag-ref digest, signed statement, bundle digest, and per-asset verification result. An update also binds the previous Release to its own exact CI receipt; the 0.1.0-rc.0 bootstrap records previous CI evidence as null. Runtime, public-release, and composite receipts cross-bind these exact artifacts. Separate official DSH installations share the exact version, audited source, registry, and registry integrity. Each lane fingerprints the complete installed package tree before the lifecycle, recomputes it afterward, and requires exact equality. The input receipt retains that lane-local fingerprint and the composite receipt binds its bytes; pnpm-generated .bin shims embed the isolated installation path and cannot serve as a cross-install byte identity. Repository Release immutability and protected v* tags prevent later mutation but do not establish the status of a concrete Release.

Current proof status

Proof is split by receipt instead of a mutable status paragraph. The current latest-DSH compatibility receipt binds the deterministic Center tarball, exact official DSH package and integrity, standard Plugin CLI install and removal, real Host and Client Store/RPC observation, and an unchanged official DSH package tree. The packaged signed revision 11 catalog remains immutable historical rc.2 data, so current alpha.3 child-candidate mutations stay unavailable until those exact entries receive a reviewed signed alpha.3 admission. Historical stable 0.1.0 receipts remain scoped to official DSH 0.1.1-rc.2. A live-provider run is advisory and cannot substitute for deterministic evidence.

Compatibility and extended P0 acceptance

The compatibility gate installs one deterministic packed Center artifact into an isolated Profile using exact official dsh@0.1.2-alpha.3 and the standard Plugin CLI; publishing the Center to npm is not required. Extended candidate-lifecycle receipts then prove:

1. Store discovery and task-driven retrieval use the same verified catalog.
2. Plugin install, exact update, uninstall, restore, restart verification, and break-glass package recovery use Center-pinned archives and the official Plugin CLI; pure configuration uses and verifies the official Loader on the same Host process, without direct package-manager writes by the Center.
3. MCP configure, enable, update, disable, remove, restore, purge, handshake, and Tool visibility operate through the official MCP Client.
4. Skill install, configuration, update, disable, enable, uninstall, restore, purge, and registry visibility operate through the official Skill registry.
5. An approved task acquisition passes the keyless official Replay gate, produces verified capability evidence through the real Agent, Session, Tool, Skill, continuation, and receipt path, and dispatches one continuation to the original Session.
6. Removing child Plugins and the Center through the official CLI leaves the official DSH source and package tree unchanged, records expected Profile package-manager changes, and preserves only explicitly retained Center recovery data.

Passing against a modified DSH checkout or an unpacked source tree does not satisfy the current compatibility gate. A mock-only owner or a read-only Store does not satisfy the separate extended candidate-lifecycle gate. A live-provider smoke may add compatibility evidence but cannot replace a future deterministic Replay receipt.