DSH Engineering Control Plane

What it is

dsh-engineering-control-plane is a governed engineering workflow plugin for DeepSeek Harness. It turns an implementation, fix, refactor, migration, or release-validation request into an auditable Mission with explicit policy, attempts, evidence, verification, and a deterministic Quality Gate.

Mission at a glance

Each Mission advances through one ordered phase sequence. Digest-bound role output, verification, optional external assurance, and workspace evidence feed the deterministic Quality Gate; revision CAS and separate execution/write leases reject stale or conflicting mutation.

If an agent can change code but cannot answer who changed it, what was frozen beforehand, whether the evidence is complete, or why the result was released, that is an unauditable write operation. Control Plane fixes the boundary as Mission → Evidence → Quality Gate → Receipt.

Highlights

• One non-terminal Mission per canonical worktree.
• Repository identity, branch, HEAD, and Effective Policy are frozen at start.
• Planner, Tester, and Reviewer are read-only; Developer cannot commit, switch branches, or rewrite history.
• Verification commands come from host-owned configuration.
• Only the deterministic Quality Gate can produce APPROVED.
• Missing, corrupt, truncated, or indeterminate evidence fails closed.
• External Assurance Subjects bind both Git state and a byte-exact baseline-to-produced-change fingerprint.
• Durable SQLite state, Evidence manifests, immutable Receipts, and versioned Snapshots.

Three-minute install in Harness Web

Requires Node.js ^22.19.0 || >=24.0.0 and the DeepSeek Harness CLI:

1. Download the tarball from the matching Release.
2. Install it and inspect the composed profile with the commands below.
3. Start Harness Web from the Git repository you want to govern.

dsh plugin --profile web add D:\Downloads\dsh-engineering-control-plane-0.1.13.tgz
dsh --profile web --dump-config
dsh web

Download the package from the v0.1.13 Release. Install this plugin before Security Assurance when using both, because it supplies the shared invariant registry. The launcher working directory becomes current-workspace; default checks are pnpm test, pnpm run typecheck, and pnpm run build.

Python/uv repositories can start from the packaged profiles/erii-python.cordis.patch.example.yml. It requires explicit DSH_ERII_PYTHON, an out-of-worktree DSH_ERII_TEMP_ROOT, and a pre-warmed offline UV_CACHE_DIR; it preserves the complete ERII dogfood scope across tests, secret scanning, Ruff, Compileall, inventory validation, and offline builds. Copy it into the target Harness Profile and inspect --dump-config; it is an explicit host-policy example, not an automatic replacement for other repositories.

Invocation

Users can describe an engineering goal in natural language, or explicitly run:

/mission Run release validation for the current repository; tests, typecheck, and build must pass.

Use “direct mode, do not create a Mission” when governance is intentionally not required. Nested Mission creation is rejected inside delegated Mission roles.

The package exposes mission_start, mission_status, mission_resume, mission_cancel, and mission_rework. Every mutation requires the exact revision returned by mission_status; stale control intent is rejected.

Read-only doctor

dsh-control-plane doctor --pretty

The doctor checks SQLite identity, schema, leases, Evidence references, and digest bindings without creating, repairing, migrating, clearing, or deleting state. Exit codes are 0 (pass), 1 (issue found), and 2 (invocation failure).

Public entries

• dsh-engineering-control-plane: Cordis Service and Kernel contracts
• dsh-engineering-control-plane/tools: strict model tools
• dsh-engineering-control-plane/client: browser-safe projection cache
• dsh-engineering-control-plane/invariant: startup diagnostics
• dsh-engineering-control-plane/assurance-provider: optional Security Assurance contract

When Security Assurance is selected, the Control Plane freezes the baseline HEAD, Git-status fingerprint, and byte-exact produced-change fingerprint into the post-implementation execution Subject. The Provider can independently verify the exact Mission output without receiving a repository path.

The current package targets Harness 0.1.2-alpha.1 and declares the exact additional verified versions 0.1.2-alpha.2 through 0.1.2-rc.1, 0.1.3-alpha.1, 0.1.3-alpha.2, 0.1.5-alpha.1, 0.1.5-alpha.2, 0.1.5-rc.1, and 0.1.5-rc.2. The Security Assurance-owned Harness Compatibility matrix verifies this closed set.

Development

pnpm install
pnpm run lint
pnpm run typecheck
pnpm test
pnpm run build
pnpm pack:dry-run
pnpm pack:profile-smoke
pnpm release:check

The current main branch gate passes 33 test files and 154 tests, plus linting, typecheck, build, packaging, a fresh Harness Profile installation, and a live Web probe. Public CI repeats the gate on Ubuntu, macOS, and Windows. The Harness Compatibility workflow also validates the dual-plugin matrix against the declared Harness versions. See CONTEXT.md, docs/adr/, and SECURITY.md for the domain model, decisions, and security policy.