# work-charter-dsh specification

Status: the current source implements the approved successor. Qualification and remaining gates are owned by STATUS and VERIFICATION. The published `v0.1.0-alpha.1` remains a separate historical release. Sections beginning at **Bound identities and compatibility** describe that historical release, not the current package.

## Successor design: Work Charter 0.9.1 and SCDP retirement

### Authority and current work boundary

On 2026-09-27 the user requested retirement of the separate SCDP dependency, asked that any necessary remainder live inside WCDP, identified the installed Codex Work Charter `0.9.1` as the improvement baseline, and then approved proceeding with that direction. Subsequent SC-01 through SC-03 approvals authorize successor source implementation, necessary tests and canonical documentation within the stated scope. They do not authorize installation, publication, Git commits, upstream edits, or deletion of historical artifacts. The current primary owns implementation and repairs; an independent read-only Reviewer inspects stable material changes. No separate O/P/E workflow or development Charter is activated by this product work.

Confirmed direction:

- Derive successor semantics from the verified installed Codex Work Charter `0.9.1`, not from the current WCDP's `0.3.0` mapping.
- Retire SCDP as a separate runtime dependency for the successor; retain only demonstrated Charter-specific needs inside WCDP, rather than copying the generic SCDP service.
- Prefer native DSH execution and messaging. Preserve old releases, contracts, evidence, and material failure history without relabeling them as successor evidence.
- Reuse the existing canonical owners. This section owns the design; STATUS owns progression and writer state; VERIFICATION owns source provenance and qualification results.

### Product decisions

`SC-01 — Supported collaboration boundary` (APPROVED, 2026-09-27): the user selected option A, native Team scope. Direct operates in one Session; Team/Phased operate within one native DSH Team, on one host/process and shared checkout. Existing independent root Sessions are not attached to a common successor Charter; cross-Team and multi-worktree coordination are unsupported in this successor scope. This removes the general Workstream membership service and lets users start one Lead and its persistent teammates. Independent Sessions may still run their own Direct work. This approval does not choose release/schema versions, authorize installation or migrate existing data.

`SC-02 — Successor identities` (APPROVED, 2026-09-27): the user confirmed package `0.2.0-alpha.1`, public WCDP contract `2`, logical WCDP storage schema `2`, and exact DSH target `dsh-v0.1.7-rc.2@477b4f420553e8a52c2fbccc464d7561b239c443`. These identities express incompatible public/data shapes and an experimental runtime target. The Codex Skill release `0.9.1`, portable contract format `arrangement-v1`, role-model YAML `schema_version: 2`, and WCDP's own package/API/storage identities remain independent. Physical storage-domain version `1` is retained only if the isolated-store design needs no physical-layout change; a different physical version requires its own version decision.

`SC-03 — Existing-data behavior` (APPROVED, 2026-09-27): the user confirmed a fresh isolated successor profile/store, keeping legacy WCDP/SCDP stores and the old runnable profile intact. No automatic in-place migration, reinterpretation, or loss of an active legacy Charter is permitted. Users requiring continuation of an existing Charter need an explicit per-subject transition preserving authority, findings, evidence consumption, unresolved decisions, and predecessor identity. A separate importer is outside the approved implementation.

SC-01 through SC-03 are approved. Implementation may proceed within these boundaries; exact dependency acquisition and material native-capability gaps retain their stated gates. The approval does not authorize commit, push, installation, publication, upstream changes, or changes to legacy runtime data.

The subsequent explicit publication continuation on 2026-09-27 is recorded separately in STATUS. It authorizes commit, ordinary main integration/push and GitHub Pre-release after the bounded release checks, plus the separately owned SCDP retirement and GitHub profile updates; it does not change SC-01 through SC-03 or grant legacy-data mutation.

### Semantic model and responsibility boundaries

| Concern | Successor working design | Existing shape that must not be carried over mechanically |
|---|---|---|
| Arrangement | `direct`, `team`, or `phased`, with actual responsibilities and review route | Four `protection` values mixing continuity and hierarchy |
| Continuity | `current-task` or `durable`; Team/Phased require a common recoverable control location | Treating every task as a new Charter or every durable agreement as another hierarchy |
| Contract and run state | Separate contract state (`draft`, `proposed`, `approved`, `superseded`) from run disposition (`active`, `paused`, `closed`); only approved, non-superseded contracts may be active | A single `draft/active/paused/closed` field |
| Roles | Direct primary and applicable R; Team P/E and applicable R; Phased O/P/E and applicable R | Equating `controller`/`assessor` with new roles or letting R decide P/O acceptance |
| Review | Stable input, original author, independent R, cumulative findings, authorized repair/re-review route, designated acceptance owner | One fixed `writer` or `standard-phase` message route for every reviewed product |
| Authority | Referenced user authorization and bounded delegated choices; separate permission, execution, and durable recording | Treating a transport receipt or model assertion as approval |
| Evidence | Subject/revision, observed coverage, invalidation, and actual consumption point; preserve consumed or invalid evidence | Assuming every failed preflight consumed a scarce opportunity, or treating every check as a handoff |
| Recovery | Stable logical work subject and approved carrier bindings; compare revision, writer, evidence, and next authorized action | Equating Charter identity with a Team root, Session, task, branch, or retry name |

The Host remains authoritative for WCDP-owned records and checks at WCDP mutation boundaries. This is not authority over all DSH tool execution, a filesystem lock, or proof that an Agent obeyed instructions. Native DSH messaging and shell actions can exist outside WCDP; the UI and model instructions must disclose that protection boundary. Candidate behavior cannot establish its own semantic acceptance.

### Minimal retained WCDP data and behavior

Keep one authoritative Charter record with a stable id and compare-and-set revision, `contractFormat`, arrangement, continuity/control locator, separate contract/run states, four proposal layers, authority references, role/carrier bindings, writer observation, evidence/checkpoints, material decisions, and the next permitted action or stop. Exact field layout is replaceable implementation work; it must express these semantics without creating a second competing authority store. Current-task continuity makes no promise of recovery outside its available Session; durable continuity requires a bounded, discoverable control location.

Keep only material result/review/disposition records necessary to link an assessed product and checkpoint to the named author, Reviewer, acceptance owner, recipient, and next action. Technical review findings, acceptance, dispatch observation, and canonical recording are separate facts. A formed decision cannot be inferred from receipt. One current notice per logical route/checkpoint prevents unchanged duplicate handoffs; new stable corrected input gets a new checkpoint and preserves previous findings. Pure factual notices and terminal dispositions create no automatic reply obligation.

The logical result relation replaces the need for a general-purpose correlation/causation message API. Record native message ids when returned, together with the Charter result/checkpoint reference, but do not duplicate arbitrary Team messages or build another mailbox, replay loop, delivery-state service, broadcast mechanism, or coordination UI. Native `queued`/`accepted` observations are not WCDP acceptance and do not prove inspection or model consumption. A caller-side retry must not invoke native `sendMessage` again merely because a response was lost: its admission allocates a new id. Persist the material handoff identity before a non-idempotent send; on uncertain outcome preserve the known state and stop dependent work. Recovery first reads authorized existing records; absent proof remains UNKNOWN, never permission to create a competing writer or replacement message.

WCDP must derive a mutating model-tool actor from the exact executing DSH Agent. It must resolve current native Team membership and the approved role/carrier binding before a Team/Phased mutation, and fail closed on detached, stale, foreign-Team, or incomparable identity. Browser surfaces remain read-only unless a separately proved trusted mutation identity exists. Same-process Host code remains within the trusted plugin boundary; no caller-supplied Session id becomes an authentication credential.

Model selection follows the complete `0.9.1` configuration contract: whole-object provider/model/parameters replacement, selected-source priority, arrangement lookup, v1 compatibility and Direct ambiguity handling, frozen combinations, and rejection of unsupported required parameters. Package defaults are not automatically appropriate DSH provider selections. Mapping to a native role-creation API must be qualified; no model substitution or silent parameter dropping is permitted. Installation never rewrites the user's model configuration.

Source inspection after SC-01 approval confirms that native `SpawnTeammateRequest` exposes name, description, prompt, context, subagent-transport `provider`, and signal, but no Agent model/effort options; roster creation passes prompt and parent to `startContinuable`. This `provider` is not the Work Charter model-provider field. The public subagent seam documents Agent-option overrides on other request paths, which does not prove propagation through Team creation. Do not implement role models by changing the Lead temporarily, altering a child after its initial prompt, importing internals, or silently inheriting a different combination. Qualification must establish a supported pre-first-request binding and durable resume semantics; if unavailable, stop that role delivery and return the concrete compatibility decision without changing the approved Team scope.

The selected runtime exposes public `agent/request` replacement before model prompt admission. The adapter persists a named-role selection before creation, matches exact live Team membership including provisioning, and applies the complete native call configuration on first request and restart. A durable native roster description `WCDP/2:<charterId>:<role>` associates the carrier with its store; missing or mismatched bindings reject the call. Never use a roster's displayed model as actual-call evidence: the current roster reads inherited Agent creation options, while the waterfall replaces call configuration. YAML parsing, whole-object lookup, persisted role binding and native request replacement remain separate test subjects.

The file loader accepts an explicit absolute `modelConfigPath`, otherwise the existing user `~/.config/work-charter/role-models.yaml`, then package defaults. Invalid/unreadable selected sources do not fall through. The adapter currently maps only `reasoning_effort` and `max_output_tokens`; other selected parameters fail explicitly, while legal inert JSON parameters on unused roles remain valid. Existing Lead settings are host-owned and are not rewritten. Direct's primary remains in its Session; an applicable short independent R uses a fresh teammate of that same root, never an attached independent root.

Contract-2 notice history preserves admission, transport observations and explicit reconciliation. `reconcile-notice` is a paused-owner record of inspected native-log evidence (matching notice, sender, destination and message id), not independent proof that this assertion is true. It never resends or automatically resumes. A correction references the latest same-subject result and preserves author/recipient/R; the previous record remains. Notices carry authority revision so previous authority's acceptance cannot close a newly revised Team/Phase. Writer release precedes R; Team closure needs an accepted E result, Phased closure additionally needs P-to-O acceptance. Review necessity must be declared by the applicable contract/notice; the Host does not infer it from arbitrary prose or a filesystem diff.

Material `queued` handoffs are not delivered and stop dependent continuation. Result/review/disposition gates require accepted/local delivery, and explicit observation can advance a queued notice only with the same native message id. Supersession cannot bypass prepared/unknown/queued material handoffs or clear an unreleased writer. A P-to-O result freezes its current E result ids in Host-owned `dependsOn`; new E results require a current P-to-O result and O acceptance before close. Original authors may request R through a product-bound `review-request`, including O's own direction/Mandate; this does not let O direct E/P review by bypassing P. Persisted WCDP child ids remain protected from model fallback even when native Team membership/service is unavailable.

### Native DSH composition and Phased limits

Direct should initialize without SCDP or experimental Agent Teams. Team/Phased use the public `ctx.agentTeams` service plus required native model tools in an explicitly enabled composition; absence produces a specific unavailable capability for those operations, not startup failure for Direct. Qualification must establish the exact public package exports, optional service lifecycle, engine, model-parameter path, and current Client interfaces before implementation relies on them. The old alpha.1 package graph is not a substitute.

For the proposed single-Team scope, Team maps P to native Lead with E/R teammates. Phased maps O to Lead with separately bound P/E/R teammates. Native topology does not confer governance authority: P owns Definition, execution/review routing and target acceptance; O owns direction and phase acceptance. Only Lead can create native teammates. A bounded setup may have Lead provision the explicitly authorized role set; the design does not grant P a nonexistent nested-spawn capability or allow O to bypass P to direct E/R. Later provisioning or carrier replacement must use an actually supported, authorized route and preserve logical work identity; otherwise stop that operation. Review independence, shared-checkout writer handoff, user intervention, and return reachability require runtime evidence, not role names alone.

WCDP owns a small internal adapter for these bindings, capability checks and native message observations. It uses public exports, never upstream `internal` imports. The existing optional Client offers Charter inspection and native navigation without duplicating Team roster/task-board ownership. The successor profile must not load SCDP. Its package, exported types, health shape, profile patch, model context, tools, fixtures and current install guidance must be free of runtime SCDP dependencies; historical evidence references stay intact.

### Implementation order and acceptance floor

1. Resolve SC-01 through SC-03 and exact dependency acquisition authority. Qualify the selected DSH public service/export, actor, model-selection, Session-context and Client seams read-only first; obtain any missing task-local dependencies only under a concrete approved acquisition plan. An inaccessible source is a source gap, not permission to use an internal API.
2. Amend the current-product rules in AGENTS and SPEC for the adopted successor while retaining the old release contract as historical. Implement strict TypeScript domain schemas and policy, including separate states, roles/review routes, authority/evidence history, and bounded recovery. Keep the governance used to develop the plugin outside candidate model context.
3. Replace the SCDP type and service coupling with native DSH Session identities and the small Team adapter. Implement Direct without Team, the approved Team/Phased role paths, one-shot handoff admission and uncertain-send stop behavior. Wire the model configuration only through supported native parameters.
4. Update model tools/Skill/runtime snapshots, read-only Client and profile/package surfaces. Gate incompatible legacy storage before mutation; use the approved fresh profile/store and leave old profiles/artifacts untouched. No automatic migration or historic evidence reuse.
5. Verify domain rules before native consumers: arrange/continuity/state combinations; role/actor and foreign-Team rejection; stale revisions; R versus assessor separation; original-author/same-R correction; one-writer observations and pause on drift; evidence invalidation/consumption; factual versus material notices; duplicate checkpoint and uncertain send; preservation of predecessor/history; legacy-store rejection without writes; model lookup/ambiguity and unsupported-parameter rejection.
6. Qualify exact built artifacts with native runtime and restart checks: Direct boots without either SCDP or Team; Team messages and persistence use the official service; restart preserves material results and uncertainty without WCDP replay; Phased routes respect P/O authority on the flat roster; required model parameters are actually accepted; model-visible context is reconstructable from Session logs. Verify Client coexistence on the new public surfaces, dependency absence and single shared runtime identities. Deterministic fixtures do not establish natural-language efficacy.
7. Run an independent review of the stable implementation and canonical documentation, repair through the same author and valid Reviewer, then report supported results and UNKNOWN separately. Commit, publication, global installation, historical cleanup and broad efficacy claims remain outside current authority.

Acceptance of the successor requires these behaviors on its selected exact graph; the old release's PASS rows do not transfer. A network/dependency/API blocker stops only its dependent implementation/qualification. If the native Team scope cannot support approved Phased behavior, return the concrete mismatch to the user rather than silently removing Phased or rebuilding SCDP.

## Bound identities and compatibility

- `WC-UPSTREAM`: installed Codex Skill `junwei529/work-charter` version `0.3.0`, package SHA-256 `7b67ea1f7073fa66ac91c36f3e39c735b54c04174e2fa3672068f8fa8948a5b2`, normalized package tree `0ac3cbb0f1fa8fa51d8f832c8127eabc9863ec9e`.
- DSH source target: official tag `dsh-v0.1.2-alpha.1`, commit `cd5ef8148158c3a752a658978873241fdf8e2bbc`, Node `^22.19.0 || >=24.0.0`.
- Coordination dependency: private package `session-coordinator-dsh` `0.1.1-alpha.1`, public contract version `3`, logical storage schema `2`, adapted to that exact DSH alpha.1 source line and distributed as a checksumed GitHub Pre-release artifact.
- Package contract: external package id `work-charter-dsh`; its current candidate version and MIT SPDX metadata are owned by `package.json`, with the full grant in the root `LICENSE`.

Compatibility is exact and artifact-bound, not a range claim. Static/source checks establish that the candidate follows the pinned public contracts. A task-local graph made only from packed candidates and artifacts produced from the exact clean DSH tag establishes bounded clean-consumer and runtime behavior for that graph. A frozen, offline, two-producer build binds the exact DSH artifact set and published scdp artifact and establishes local release reproducibility for this WCDP candidate. The exact alpha.1 DSH packages and scdp package are not published to npm, so ordinary registry-backed installation and every other DSH version remain `BLOCKED`/`UNKNOWN` rather than inheriting the local result.

## Outcome

Provide a DSH-native policy layer that makes consequential work explicit and recoverable through Work Charter concepts: outcome, scope, authority, current writer, evidence, acceptance, stop/decision conditions, and recovery. Supply missing multi-Session continuity through the public scdp contract instead of reimplementing it.

## Product boundary

`work-charter-dsh` owns:

- Charter records, schema, lifecycle, and compare-and-set revisions;
- outcome/scope and four-layer contract declarations;
- authority, role, one-writer, evidence, decision, stop/resume, and acceptance policy;
- the policy meaning of checkpoint-bound Result Notices and dispositions;
- model-visible Charter context, DSH Skill/tool surfaces, and UI projections.

It consumes but does not own:

- scdp `WorkstreamId`, Session membership, addressing, correlation, immutable coordination records, delivery state, and delivery reconciliation;
- DSH Session persistence, dynamic runtime-context logging, tools, skills, approvals, sandbox, goals, plans, workflows, subagents, agent loop, and Trajectory;
- Git/worktree operations, native review, installation, release, or external authorization supplied by the surrounding Harness/project workflow.

A Charter never expands any of those permissions. The Host is authoritative; model instructions and browser components are policy consumers and affordances.

## Identity and assessment separation

Development and evaluation keep four identities separate:

1. `WC-GOVERNANCE`: any external Work Charter used to govern development;
2. `WC-UPSTREAM`: the immutable Codex Skill baseline above;
3. `WC-DSH-CANDIDATE`: the exact candidate source/build/install identity under test;
4. an independent assessor whenever acceptance requires semantic judgment.

The candidate cannot govern, approve, accept, or assess itself. External governance instructions must not enter baseline or candidate model context; leakage invalidates causal efficacy conclusions.

## Semantic adaptation

### Activation and protection

Skill discovery, loading, or mention is not Charter activation. For an indirect match, the Skill proposes applicability and the smallest status read, then waits for confirmation without creating policy or prescribing Charter workflow. Direct user intent or confirmation permits the workflow to begin but grants no implementation or external-effect authority. A Charter starts as `draft`; Host activation requires an externally referenced `approved` authority, an eligible assigned writer, a current Charter revision, and a current authority revision. The least sufficient protection is selected from:

- `current-task` or `durable-single-agent`: exactly one Controller; a Session target must name that Session;
- `planner-executor`: a Workstream target with distinct Planner and Executor, plus an optional Assessor independent of the Executor;
- `standard-ope`: a Workstream target with distinct Orchestrator, Planner, and Executor, plus an optional Assessor independent of the Executor.

### Contract layers

The durable contract keeps these separate:

1. Confirmed Contract — externally confirmed outcome, acceptance, scope, exclusions, and required effects;
2. Necessary Guardrails — permissions, safety, reversibility, trust, compatibility, and authoritative project rules;
3. Working Proposal — replaceable files, functions, algorithms, commands, and sequence;
4. Assumptions / Open Decisions — uncertainty that cannot silently become fact.

### Lifecycle and fail-closed rules

The normal lifecycle is `draft -> active -> paused -> active -> closed`. An active Charter always retains one eligible writer. Ordinary writer release or handoff requires `draft` or `paused`; accepted close clears the active writer atomically with the terminal transition. A paused Charter may persist revoked or unknown authority so the loss of authority is durable, while `resume` remains fail-closed until externally referenced approved authority is restored. `closed` is terminal for transitions, Result Notices, and dispositions. Before every Workstream-target transition, the Host reopens the Workstream and revalidates the acting Session's current scdp membership; membership lookup failure fails closed, while activation and resume additionally revalidate every assigned role. New Result Notice and disposition transport likewise revalidates both Workstream endpoints before any transport or Charter write. Host operations reject stale Charter or authority revisions, ineligible/ambiguous writers, unauthorized or detached roles, revoked or unknown authority for active work, open material decisions, invalid evidence replacement, and invalid terminal acceptance.

One-shot evidence is consumed when recorded, including a failed or unknown result, and its entire consumed record cannot be replayed, altered, or removed by contract revision; pending evidence cannot carry consumption metadata. Accepted close is valid only from `active` and requires approved authority, an independent eligible acceptance actor, one current eligible writer that the terminal transition releases atomically, no open decisions, all required evidence passed, and no Result Notice awaiting a disposition. Missing or conflicting identity, storage, coordination, delivery, or recovery proof remains `UNKNOWN`.

### Cross-Session result flow

The current writer may submit one checkpoint-bound Result Notice to an eligible Planner, Assessor, Controller, or Orchestrator only while no material decision remains open. A route permits only one notice for a given checkpoint and cannot advance to a distinct checkpoint while its latest notice still awaits disposition. A corrected result uses a new checkpoint while preserving the prior outcome; accepted close requires the latest notice on every used route to have an `accepted` disposition. For `standard-ope`, the assigned Planner may additionally submit the phase-level Result Notice to the assigned Orchestrator only when the latest Executor Result Notice has received an `accepted` disposition from its exact Planner or Assessor recipient. The Host causally binds that phase notice to the accepted execution disposition, asks scdp to accept the immutable addressed coordination record, and records the exact correlation, record identity, and observed delivery state. The exact recipient may return one causally linked disposition: `accepted`, `correction-required`, or `decision-required`.

An unknown scdp accept is reopened using the same record identity. A matching immutable record may be recovered; a conflicting record fails explicitly, and a read failure preserves delivery as `UNKNOWN`. The plugin never blindly substitutes a new notice identity.

## DSH surfaces

### Host service and storage

The Cordis service key and Typert Remote namespace are `workCharter`. The public same-process Host service supports health, create/get/list, Session list, transition, Result Notice submission, and disposition return. The browser Remote is intentionally read-only: it exposes health, get/list, and Session-list operations with JSON-compatible runtime validation, but no create, transition, Result Notice, or disposition mutation. DSH alpha.1 does not supply a trusted caller identity on that direct Remote boundary, so a client-provided Session id is never treated as mutation authority. Model tools derive their actor from the executing DSH Agent Session; other Host callers remain inside the same-process trust boundary and must supply the exact actor identity.

Authoritative state uses storage domain `work_charter_dsh`, table `charters`, physical schema `1`, logical schema `1`. Reopen validates domain metadata, row identifiers, and every durable invariant; incompatible state fails as `SCHEMA_INCOMPATIBLE` rather than being silently migrated.

### Skill, tools, and logged model context

The bundle registers the DSH Skill `work-charter` and these model tools:

- `work_charter_status`;
- `work_charter_create_draft`;
- `work_charter_transition`;
- `work_charter_result_notice`;
- `work_charter_disposition`.

The draft tool cannot approve or activate authority. Active/paused Charter context is bounded and assembled through DSH dynamic runtime context. The snapshot includes identities, revisions, authority, roles/writer, the four contract layers, evidence, open decisions, awaiting notices, pause state, and the no-permission disclaimer. The exact local runtime fixture proves that DSH persists active and paused snapshots plus the inactive clear marker in the Session log, and that a restarted Agent recovers that history without a redundant snapshot. If scdp state cannot be read, the snapshot and status tool say coordination is `UNKNOWN` rather than clearing policy context or claiming that no Charter exists.

### Browser Client

The lazy-CJS browser half contributes one fresh id, `work-charter-dsh`, to additive seats:

- `sidebar.footer.action` for the global entry;
- `conversation.session.header.actions` for a per-Session badge;
- `shell.overlay` for read-only list/detail inspection.

The Client does not occupy or shadow goal, plan, workflow, approval/question composer, subagent lineage, Conversation root, or Trajectory owners. UI state is not authoritative and cannot grant permissions. All Charter mutations use Host-side surfaces with an established actor identity; the Client never submits an actor Session id.

For the alpha.1 split Client architecture, the bundle consumes only the public ownership faces needed by those seats: `@deepseek-ai/cordis` for `Context`, `@deepseek-ai/dsh-api-remotes/client` for the Remote projection, `@deepseek-ai/dsh-client-ui-renderer/client` for `SlotRegistry`, `@deepseek-ai/dsh-client-ui-session/client` for Session-scoped standard props, and the Conversation/Layout/Sidebar Client declarations for their respective SlotMap entries. It does not recreate an aggregate Client runtime.

## Packaging and runtime alignment

- Strict TypeScript/TSX production sources target ES2024; the Host emits Node ESM.
- `./client` is DSH's lazy-CJS closure-factory artifact inside an ESM package, not a general CommonJS surface.
- the package declares `dsh.bundle.patch` as `./cordis.patch.yml`; that patch inserts `session-coordinator-dsh` before `work-charter-dsh`, so the required coordination service is available before the policy service activates;
- the qualified profile-install route adds the checksum-bound scdp and WCDP tarballs to the same exact DSH profile through `dsh plugin`; scdp remains a plain profile dependency and WCDP is the bundle layer;
- the private scdp candidate, Cordis, consumed DSH Service Definitions, and React are exact peer plus development dependencies so the containing profile supplies one runtime identity;
- Zod validates durable, wire, model/tool, and user-controlled inputs.
- the browser artifact bundles Zod, so the package includes its exact installed-version MIT notice in `THIRD_PARTY_NOTICES.md`; peer dependencies are not represented as bundled payload.
- The bundle consumes only scdp's public package/Service Definition and does not import or modify implementation internals.
- Type generation uses DSH Typert; generated Remote object codecs are hardened to strict objects.

## Non-goals for v1

- Reimplementing scdp transport, Workstream identity, membership, or its coordination ledger.
- Replacing DSH goal, plan, workflow, approval, subagent, Session, sandbox, agent loop, or Trajectory capabilities.
- Claiming compatibility with unqualified DSH versions or broad parity with every Harness.
- Candidate self-governance, self-acceptance, or self-assessment.
- Treating documentation, typechecks, unit tests, or model self-report as runtime or semantic-efficacy evidence.

## Acceptance contract

v1 is acceptable only when evidence shows that:

- `dsh plugin` records the external WCDP package as a bundle layer, its composed profile contains the ordered scdp/WCDP rows, and an actual profile boot loads both with the exact pinned DSH and scdp identities;
- Host ESM, declarations, Remote artifacts, and lazy-CJS Client format resolve from a clean consumer;
- a Charter can be created, attached, persisted, restarted, reopened, and recovered for a Workstream and Session;
- stale/unauthorized transitions fail closed at the Host while authorized transitions remain usable;
- scdp Result Notice/disposition delivery, unknown-state recovery, and conflict handling work through the public service;
- model-visible Charter context is reconstructable from the DSH Session log and absent when not active;
- Work Charter UI coexists with native goal, plan, workflow, approval, Conversation, and Trajectory UI;
- deterministic unit, integration, restart, keyless snapshot, and browser checks pass;
- identities and governance isolation are recorded; and
- any semantic efficacy claim comes from a controlled comparison and independent assessment, not candidate self-report.

## Current acceptance disposition

The exact final local-artifact graph satisfies the package/type, two-producer release reproducibility, real DSH CLI/profile bundle activation, clean-consumer, Loader, Host enforcement, JSON restart/reopen, base scdp coordination, logged-context, bounded Chromium, and Standard O/P/E L4 acceptance layers recorded in `docs/VERIFICATION.md`. The dedicated L4 run uses three distinct real DSH role AgentLoops and the Work Charter/scdp path for all six messages. The Host rejects a premature Planner phase report, permits it only after an accepted Executor result, causally links P→O to the execution disposition and O→P to the phase notice, and emits distinct phase-level message schemas. All six deliveries reach durable `acknowledged` state and are consumed by their target role models.

Overall v1 acceptance also remains open because no controlled upstream-baseline/candidate comparison or independent semantic assessment has run. The current browser evidence proves additive seat ownership and Work Charter behavior in real Chromium; native goal/plan/workflow/approval/Conversation/Trajectory entries are ownership sentinels in the qualification fixture, not full semantic end-to-end tests of those native features.