Skip to content

Repository files navigation

Session Coordinator for DeepSeek Harness (SCDP)

English | 简体中文

Session Coordinator for DeepSeek Harness (SCDP) is the coordination substrate for multi-Session, multi-Workstream systems built on DeepSeek Harness (DSH). It gives related DSH Sessions a stable Workstream identity, exact Session addressing, durable coordination records, and an explicit recovery protocol that other plugins and user interfaces can share.

Use SCDP when one body of work spans independent DSH Sessions and ad hoc prompts or task titles are no longer enough to answer four practical questions: which Sessions belong together, which exact Session should receive a record, what delivery evidence exists, and how should work resume after a restart or an uncertain transport result?

What SCDP provides

Stable Workstreams and exact Session membership

SCDP groups existing DSH Sessions under an opaque WorkstreamId. Membership is stored against the native DSH SessionId; it is not inferred from a title, sidebar position, fork label, or model-written text. A Workstream can be created, listed, renamed with revision checks, closed, and queried in either direction between Workstream and Session.

SCDP does not replace a DSH Session or alter its native identity, log, fork lineage, workflow, goal, or plan. It adds a durable relationship above those Sessions.

Immutable, addressable coordination records

Plugins can accept generic message, request, and outcome records addressed to one exact Session or to the frozen membership of a Workstream. Each record carries a caller-supplied recordId, correlationId, optional causal record, source Session, and immutable content. Repeating the same complete input under the same identity is idempotent; reusing an identity with different immutable content fails with an explicit conflict instead of silently creating a second meaning.

Higher-level products can use these generic records to carry conventions such as Result Notices, decisions, dispositions, and acknowledgements. SCDP preserves their identity, correlation, recipients, and delivery facts; it does not interpret their policy meaning.

Delivery state that keeps uncertainty visible

Acceptance into the SCDP ledger is distinct from delivery and acknowledgement. Each recipient has one of five delivery states:

  • pending — accepted, but no durable delivery proof yet;
  • delivered — the recipient Session log contains the DSH inbox splice;
  • acknowledged — the Session log contains the corresponding durable user message;
  • failed — a definite terminal failure such as cancellation or message-ID conflict;
  • unknown — transport or persistence evidence is insufficient to determine the effect.

Record, correlation, revision, and delivery conflicts are surfaced as typed errors rather than folded into unknown. After an interruption, callers reconcile the same record identity against durable Session evidence. SCDP does not blindly resend an unknown, conflicting, delivered, acknowledged, or failed delivery as if it were new.

Persistence and restart recovery

Workstreams, memberships, records, acceptance order, and delivery state live in a package-owned DSH storage domain. Delivery reconciliation reads the durable DSH Session log through Session persistence. Startup validates the SCDP logical schema before the service becomes usable, and restart recovery reopens the stored coordination state instead of reconstructing it from UI labels or chat summaries.

The currently qualified provider combination is DSH JSON coordination storage plus JSONL Session persistence. Other providers are not implied by this statement.

Surfaces for plugins and people

  • The Host exposes the typed same-process service as ctx.sessionCoordinator, with lifecycle, membership, record, reconciliation, and processing methods.
  • Runtime-validated DTOs and error outcomes cross the generated unary Remote surface for browser clients.
  • The Client contributes a namespaced sidebar action and Session Coordinator overlay. Its lists and status projections are derived views, but the UI is not globally read-only: it exposes explicit create, rename, close, attach, detach, accept, reconcile, and process commands. The Host remains authoritative for validation and state transitions.
  • The overlay can open a member through DSH's native Client Session service; it does not replace Conversation or Trajectory views.
  • SCDP ships no Work Charter policy prompt, role engine, or approval tool. Model-visible coordination input uses DSH's durable Session message path so it can be reconstructed from the Session log.

The public package surfaces are the Node ESM Host entry, typed contracts under session-coordinator-dsh/types, generated Remote support under session-coordinator-dsh/remote and session-coordinator-dsh/typert, and the DSH browser assembly entry under session-coordinator-dsh/client. The Client entry is DSH's lazy-CJS assembly format, not a general CommonJS API.

What SCDP deliberately does not decide

SCDP is coordination infrastructure, not a Work Charter, workflow, role, approval, policy, or acceptance engine. It can record that an upstream plugin asserted an outcome and can show how that record was delivered; it cannot decide whether the work was authorized, compliant, correct, or acceptable.

It also does not replace DSH persistence, fork/resume, subagent control, workflow, goal, plan, approval, sandbox, or agent-loop semantics. It is not a distributed consensus system, an exactly-once message broker, or a general-purpose queue.

When another plugin should depend on SCDP

A DSH plugin is a good SCDP consumer when it needs stable cross-Session identity, exact recipients, correlated durable records, and restart-safe delivery recovery, while keeping its own business policy above that substrate.

work-charter-dsh is the reference downstream example. It uses SCDP for Workstream identity, Session membership and addressing, Result Notice delivery, correlation, and recovery. WCDP—not SCDP—owns Work Charter roles, writer rules, decisions, evidence, acceptance, and stop policy.

Install the current alpha Pre-release

The current release is v0.1.1-alpha.1, published as a GitHub Pre-release with latest=false. The package is MIT-licensed, retains "private": true, and is not published to npm.

This release is qualified only against official DSH tag dsh-v0.1.2-alpha.1 at commit cd5ef8148158c3a752a658978873241fdf8e2bbc. Download the tarball together with its SHA-256, SHA-512, and unsigned provenance assets from the Release page. The accepted tarball is 97,138 bytes with SHA-256:

9575d1edf782f16b2d87b49bc27e290ecf841fa607a7d4a4468a41de2389b269

Artifact documentation note: the immutable published tarball was produced from accepted commit 8bed40f3e18b106c69e3dadbef6f029092e73424 before the GitHub publication step. Its embedded README.md, CHANGELOG.md, SECURITY.md, and THIRD_PARTY_NOTICES.md therefore retain packaging-time candidate wording. That wording is historical; it does not mean the tag or Pre-release is absent. This post-publication documentation closeout does not replace the tarball or change the accepted bytes and hashes above.

Verify the downloaded file before adding it to a profile:

Get-FileHash -Algorithm SHA256 .\session-coordinator-dsh-0.1.1-alpha.1.tgz
dsh plugin --profile <profile> add .\session-coordinator-dsh-0.1.1-alpha.1.tgz
dsh --profile <profile> --dump-default-config

SCDP intentionally has no dsh.bundle declaration, so dsh plugin installs it as a plain profile dependency and may print an orientation warning. A compatible consuming bundle or composition must mount SCDP before using ctx.sessionCoordinator; adding the tarball alone does not create a standalone configuration layer. For a WCDP-based profile, consult the WCDP repository and use only a WCDP artifact that explicitly pins this SCDP release.

This is an artifact-bound alpha route, not a stock registry installation: the exact DSH alpha.1 package set used for qualification was not available from npm.

Compatibility and verified scope

Subject Current qualified statement
SCDP session-coordinator-dsh@0.1.1-alpha.1; public contract 3; logical schema 2
DSH Exact dsh-v0.1.2-alpha.1@cd5ef8148158c3a752a658978873241fdf8e2bbc; no version range
Runtime Package engine `^22.19.0
Persistence JSON coordination storage plus JSONL Session persistence
Distribution GitHub Pre-release tarball and checksum/provenance assets; private: true; no npm publication
Runtime evidence Real Loader and Remote composition, Workstream records and delivery/recovery, restart, browser UI, and an exact downstream WCDP consumer on the pinned artifact graph

These statements do not qualify SQLite or other providers, other DSH versions, Node 22 execution, multi-process or cross-host coordination, distributed ordering, arbitrary downstream plugins, production maturity, or a support SLA. No exactly-once or general reliability claim is made.

Documentation, security, and license

About

No description or website provided.

Topics

Resources

Security policy

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages