Native DeepSeek Harness integration

EXEPERT Desktop adds DeepSeek Harness as a third independent Chat source named DSH with an Experimental badge. EXEPERT remains a native Rust/GPUI application. It does not embed the DSH React client, Electron, a WebView, or a browser wrapper, and it does not route DSH through Codex.

Checkpoint 1 froze the architecture, public-package provenance, exepert.dsh.v1 wire envelope, deterministic fixtures, migration rules, and regression boundary. Checkpoint 2 implements the runnable exact-pinned @exepert/dsh-sidecar package, supported named profile, authenticated bridge, keyless replay provider, deterministic tool, and sidecar-focused tests. Checkpoint 3 implements the isolated native Rust supervisor, Windows Job Object launch, authenticated typed transport, bounded projection and transactional repair, Windows Credential Manager adapter and leases, safe settings, diagnostics primitives, and bounded recovery. Checkpoint 4 implements the independent native GPUI DSH source, workspace/session lifecycle, Chat and approvals, virtualized Trajectory and inspector, Harness panels, and accessible recovery controls. Checkpoint 5 implements the exact portable Node/DSH closure, full deployed provenance and license inventory, native startup verification, relocatable installation, and recovery gates. Checkpoint 6 completes the final source/package gates, release interaction, failure repair, regressions, screenshots, security review, performance observations, and delivery record. The only open literal native action is the documented human-authority gate for security-sensitive Allow, Deny, and Full Access decisions; no automated claim substitutes for those clicks.

The complete evidence and release record is Native DeepSeek Harness integration delivery.

Non-negotiable invariants

• EXEPERT, Codex, and DSH own independent runtime, session, draft, transport, permission, credential, diagnostics, and failure state.
• DSH 0.1.2-alpha.2 is exact. Every direct DSH dependency, every DSH-family override, and the frozen lockfile must resolve that version.
• The read-only repo-reference/deepseek-harness checkout is evidence only. Builds and packaged runtime must not read it or its node_modules.
• The DSH append-only session log is server-authoritative. Native memory contains bounded projections and render caches, never a second transcript authority.
• The sidecar binds only 127.0.0.1:0, authenticates every connection, validates Host and Origin, and negotiates exact protocol and runtime versions.
• A process-local capability secret crosses to the child through a capability pipe. It never appears in argv, environment values, readiness data, logs, settings, diagnostics, screenshots, fixtures, or documentation.
• Provider credentials live only in Windows Credential Manager. The native UI receives opaque present, missing, or error status.
• New sessions start in workspace-write with approvals. Full Access is explicit, high-friction, session-scoped, visible, and reset by every session or runtime restart.
• Central redaction runs before data reaches the bridge wire, diagnostics, logs, exports, screenshots, or crash reports.
• The UI discloses recorded source data under the label Recorded agent activity. It never invents or claims access to private hidden chain-of-thought.

Reference and provenance

The reference checkout is clean at commit 0a53fb55bea101816fa226bb964ae2bed71c343b, exact tag dsh-v0.1.2-alpha.2, package version 0.1.2-alpha.2, and MIT license. The reference root declares Node ^22.19.0 or at least 24.0.0, so Node 22.23.2 satisfies its Node 22 range.

The published DSH manifests use caret ranges for same-family transitive dependencies. An exact top-level CLI version therefore does not freeze the closure by itself. The sidecar package combines exact direct versions, a root override covering every resolved @deepseek-ai/dsh family package, a pnpm read-package hook that rewrites upstream DSH-family ranges, and the committed pnpm lockfile. The Checkpoint 2 audit finds 216 DSH-family package names, all at 0.1.2-alpha.2 with npm SHA-512 integrity records. Frozen install remains a release gate.

Machine-readable evidence lives in:

• services/dsh-sidecar/provenance/dsh-0.1.2-alpha.2.json
• services/dsh-sidecar/provenance/node-22.23.2-win-x64.json

The DSH record contains the exact Git commit/tag, license digest, registry tarball URLs, and npm SRI SHA-512 values for the direct architectural inputs. Packaging now derives the complete deployed closure from its independent frozen production lock and records every physical package location, unique name/version identity, license-evidence path, and runtime file checksum in the generated provenance manifest. The direct-input record remains deliberately narrower than that deployed manifest.

The portable Windows runtime is node-v22.23.2-win-x64.zip. Its official SHA-256 is 1177b4137ba5adaa56354ae40f1080c7450e8ae09cecb47da459d1c52ac99f97 from the Node 22.23.2 SHASUMS256 file. Packaging must preserve the Node license and bundled third-party notices.

Topology and process ownership

The desktop process owns the child process and every handle it creates. The child never attaches to an existing DSH or Codex process. Shutdown and recovery kill only the process tree assigned to this EXEPERT-owned Windows Job Object.

Supported named profile

DSH supports applications launched by its CLI through named profiles. Its shipped headless profile is deliberately one-shot and has no Host, HTTP, or browser layer, so it cannot supply the required persistent session, cancellation, reconnection, paging, and result lifecycle.

EXEPERT creates a named profile called exepert under the isolated DSH home and launches the published DSH CLI directly through the packaged Node executable:

dsh-runtime/node.exe dsh-runtime/node_modules/@deepseek-ai/dsh/lib/bin.js --profile exepert

This is the supported DSH CLI entrypoint selected through a named profile; it is not a direct in-process plugin tree or a package demo executable. The profile composes dsh-base plus an EXEPERT-owned patch/plugin layer. It mounts public DSH session, projection, persistence, query, model, tool, approval, goal, skill, subagent, settings, workspace, API Gateway, and plugin inventory capabilities behind the EXEPERT bridge.

The profile does not mount dsh-web-app, frontend-static, browser modules, client UI packages, or any browser-opening startup. It disables session-telemetry-otel unconditionally. Checkpoint 2 disables credentials-local, including its environment and .env fallbacks, and reports only deterministic missing status; the Windows Credential Manager adapter replaces that status-only seam in the native-runtime checkpoint. Full-text search uses an isolated SQLite index under the DSH home and never queries EXEPERT, Codex, Supabase, or RDS data.

The package-owned installer materializes the profile template and fixtures into an isolated DSH root for the published CLI. A versioned transaction marker hashes every EXEPERT-owned file, survives interrupted application, rejects local modifications, and rebinds only the owned sidecar package junction after relocation. DSH-generated node_modules, .dsh-module-fallback, and cordis.yml artifacts are preserved but must have their expected root entry type. Legacy pre-marker profiles are adopted only when every EXEPERT-owned file still exactly matches the packaged template. A malformed, locally changed, or incompatible profile stops startup with recovery guidance.

Runtime state and timing

The native state machine is:

not-started -> locating -> starting -> ready -> incompatible -> failed ready -> recovering -> starting ready | recovering | incompatible | failed -> stopping -> not-started

The corresponding Rust type is DshRuntimeState with NotStarted, Locating, Starting, Ready, Recovering, Incompatible, Failed, and Stopping variants. This lifecycle timing is separate from the per-turn response timing projected into Chat; runtime health intervals and recovery delays are never presented as model work or reasoning time.

Before launch, the supervisor verifies the packaged provenance manifest, Node archive/runtime checksum, bridge files, frozen package closure, license inventory, protocol version, and exact DSH/Node versions. It never falls back to PATH, a developer checkout, or the reference tree for packaged startup.

The launcher generates a 32-byte secret with the Windows operating-system CSPRNG. It creates one inherited anonymous input pipe for that secret and one inherited output pipe for readiness. STARTUPINFOEX with PROC_THREAD_ATTRIBUTE_HANDLE_LIST restricts inheritance to the two intended child pipe ends; unrelated parent handles are never inheritable by this launch. Only non-secret numeric handle identifiers enter the child environment. The launcher writes one length-bounded secret record, closes its write end, starts the child hidden and suspended, assigns it to a kill-on-close Job Object, and then resumes the primary thread. The child consumes the secret once, zeroes its temporary buffer, and closes the capability pipe.

Readiness has a ten-second deadline and contains only protocol version, bridge version, DSH version, Node version, and the ephemeral port. Health checks run every five seconds with a two-second response deadline. Two consecutive health failures enter recovery. Unexpected exit retries after 1, 2, and 4 seconds, then stops in Failed until explicit Restart. A successful Ready generation resets the retry budget.

Graceful shutdown has two seconds to stop accepting work, interrupt owned active turns after confirmation, flush the DSH log, close the bridge, and exit. Expiry closes the Job Object for bounded forced termination. Dropping UI state never blocks the GPUI thread on pipe or process joins.

Trust boundaries and authentication

The native client is the only supported bridge peer. The WebSocket listener binds the IPv4 literal 127.0.0.1 with port zero. Readiness publishes the selected port over the dedicated pipe.

Every upgrade request must satisfy all of these checks before business dispatch:

1. Host is exactly 127.0.0.1 followed by the readiness port.
2. Origin is exactly http://127.0.0.1 followed by the same port.
3. Sec-WebSocket-Protocol is exactly exepert.dsh.v1.
4. Authorization carries the process capability as a Bearer value.
5. The capability comparison is constant-time.

localhost, alternate loopback spellings, another port, missing or null Origin, query tokens, cookies, and certificate bypasses are rejected. Host or Origin failure returns 403 before authentication. Missing or invalid capability returns 401. None of the headers are copied into diagnostics. The capability exists only in the two processes for that runtime generation and is destroyed on restart.

The child receives a minimal allowlisted environment needed by Node and Windows plus DSH_HOME and non-secret inherited-handle identifiers. It never receives the whole parent environment, provider credentials, Supabase values, Codex credentials, or a DSH permission override. The public base profile therefore applies its own workspace-write plus approval-ask default.

After WebSocket upgrade, both sides exchange the exact hello and hello_ack records from the shared schema. Any protocol, bridge, DSH, Node, frame-size, or required-capability mismatch enters Incompatible. The UI shows the observed safe versions and recovery steps; it never continues with undefined behavior.

exepert.dsh.v1 protocol

The single schema source is services/dsh-sidecar/contracts/exepert.dsh.v1.schema.json. Rust and TypeScript consume the same schema and fixtures rather than translated copies.

Frames are UTF-8 JSON text with a maximum encoded size of 1,048,576 bytes. Binary, fragmented overflow, malformed UTF-8, malformed JSON, duplicate object keys, non-finite numbers, and a response carrying both result and error fail the connection safely. Each request has a bounded stable ID and receives exactly one success or error response. Unknown v1 methods are rejected; they are not routed dynamically.

The v1 method namespace covers:

• runtime description, health, and graceful shutdown;
• workspace list, create, and open;
• session list, search, create, resume, rename, archive, fork, prompt, cancel, page, subscribe, unsubscribe, payload paging, export;
• model catalog and selection;
• tool catalog;
• approval decisions;
• goal reads and updates;
• skill catalog;
• subagent list, follow-up, and cancellation;
• safe settings reads and updates;
• credential status refresh; and
• sanitized diagnostics.

Credential creation and deletion are deliberately absent from the bridge. The native credential form writes directly to Windows Credential Manager and asks the sidecar only to refresh opaque status.

Session event envelope

Every DshSessionEvent contains:

Field	Contract
protocol_version	Exactly exepert.dsh.v1
type	event
source	dsh
session_id	Opaque source-qualified dsh identifier
cursor	The monotonic DSH event sequence represented by this envelope
time	Exact upstream Unix epoch milliseconds
kind	Exact upstream event type; open vocabulary
turn_id and step_id	Present only when recorded by the source
parent_session_id	Present for recorded parent-child activity
payload	Redacted, JSON-safe upstream data or a bounded head/tail projection
upstream	DSH format, type, sequence, time, surface metadata, unknown fields, redaction, and payload-window facts

The bridge reads raw objects so it can retain fields unknown to its TypeScript declarations. It preserves unknown top-level event fields in both the event and upstream.unknown_fields. The Rust reducer retains bounded unknown JSON and renders an unknown event as an inspectable generic trajectory row instead of dropping it.

DSH 0.1.2-alpha.2 uses session format zero. Its stored reader may refuse an unknown required upstream type whose ignorable marker is absent. EXEPERT reports that refusal as an incompatible-session recovery state; it never skips a record and pretends reconstruction succeeded. An unknown event that DSH successfully forwards remains visible generically regardless of whether native code has a specialized projector.

History pages may contain DSH packed Assistant chunk runs. The bridge losslessly expands each run into individual assistant/chunk envelopes using the packed fragment and timestamp-gap data before assigning cursors. Live records are already individual. The bridge never fabricates an event, timestamp, duration, turn, step, usage value, or tool result.

Tool arguments, results, schemas, usage, request headers, system/context records, and provider metadata are forwarded faithfully after central redaction. An inline payload may retain at most 262,144 bytes. A larger redacted value carries a stable payload_ref, SHA-256, original redacted byte count, and bounded head/tail window. session.payload.page reads the bounded process-local redacted page cache; an expired reference is repaired by paging the canonical history again. UI truncation therefore does not become canonical data loss.

The bridge validates fatal UTF-8 decoding, duplicate JSON object keys, the closed client-message schema, upstream event identity/cursor/time, and every redacted outbound envelope. Malformed or oversized input closes safely. Unknown ignorable event kinds and fields remain open inside the versioned event envelope.

session.prompt first offers exact slash-command input to DSH's injected command registry. A recognized command remains a DSH command and is not sent to the model. The deterministic compaction gate uses /compact; @deepseek-ai/dsh-command-compact invokes the scoped DSH compaction engine and records command lifecycle plus compaction/start, compaction/summary, and compaction/end. No extra v1 bridge method or private compaction call is added.

Redaction records whether it changed a payload and only the matched secret classes and count. The replacement marker is deterministic. Redaction covers API keys, cookies, bearer tokens, Authorization headers, capability secrets, credential-shaped values, sensitive environment keys, and credential payloads. The implementation may add a redaction class without weakening prior ones.

Provider-exposed reasoning content is treated like other recorded content only when DSH actually records and forwards it. Private hidden reasoning that no provider or DSH event exposes does not exist in this protocol.

Backpressure and acknowledgement

Each bridge direction uses a serial queue with an exact 512-envelope admission bound. Normal producers await completion, providing backpressure; a 513th concurrent admission fails closed rather than dropping or reordering an accepted envelope, while canonical DSH history remains available for repair. The GPUI adapter drains bounded batches and repaints once. The active native projection retains at most 1,000 trajectory records plus explicit older-history paging state. Each rendered body retains at most 256 KiB of head/tail content, and diagnostics retain at most 200 sanitized 4 KiB entries.

The native client acknowledges only the highest contiguous cursor durably applied to its process-local projection. It never acknowledges a gap or merely received frame. A separate presentation cursor prevents reconnect hello state from outrunning a projection notification that the bounded native consumer did not accept; a reconnect first signals the already-applied projection, then advances resume state and acknowledges it. Acknowledgements are connection-generation and session qualified.

Canonical log, replay, and recovery

DSH append-only events, not WebSocket delivery or native rows, are canonical. Rename is the DSH durable title operation. Archive is EXEPERT bridge metadata keyed by source-qualified session ID and never rewrites the DSH log. Export is a redacted projection of canonical records with provenance and omission markers.

Reconnect follows this order:

1. Open the DSH follow stream before the baseline page so new events cannot race the read.
2. Send the native last acknowledged contiguous cursor for each subscribed session.
3. Page canonical history through the follow opening cursor.
4. Expand packed chunk runs and sort only by their recorded sequence.
5. Deduplicate exact records by source-qualified session ID and cursor.
6. Treat the same cursor with different content as a protocol error.
7. Pause live application on a sequence gap, page the missing inclusive range, and require exact continuity.
8. Atomically replace or prepend the repaired bounded projection.
9. Resume the live tail and acknowledge the new contiguous cursor.

A transient carrier loss keeps the last safe projection marked stale. A new Ready generation repeats the algorithm. A DSH persistence or semantic continuity failure is terminal for that session until explicit recovery; it is not hidden behind indefinite retries.

Cold session list, search, history pages, skill discovery, and workspace inspection do not activate an Agent. Resume, prompt, model change, cancellation, and other live mutations use the Session Controller policy. The native UI never interprets a local queue success as a durable DSH acknowledgement.

Persistence and storage

DSH state is isolated under %LOCALAPPDATA%\EXEPERT\dsh:

dsh
home
profiles\exepert
sessions
storages
settings.yaml index\session-query.sqlite archive\archive-v1.json runtime-cache
diagnostics
logs
dsh-settings-v1.json

DSH_HOME is the home directory shown above. sessions contains canonical append-only DSH data. storages contains DSH-owned projection/cache domains. The SQLite index is derived and rebuildable. archive-v1.json stores only session IDs, archive state, and bounded timestamps. Diagnostics and logs are sanitized, size-bounded, rotated, and never authoritative.

dsh-settings-v1.json persists only:

• version and stable profile identifier;
• exact expected protocol, DSH, and Node versions;
• last source-qualified workspace and session identifiers; and
• non-content Chat/Trajectory view preferences.

It cannot represent prompts, transcripts, tool payloads, provider keys, capability secrets, approval decisions, Full Access grants, runtime logs, raw events, or credential values. The shared schema defines DshSettingsV1 with unknown fields denied.

EXEPERT and Codex persistence remain unchanged. The existing persisted source enum gains the additive snake-case value dsh; exepert and codex retain their exact serialized values and a missing legacy source still defaults to exepert. Unknown values fail closed. DSH transcripts never enter Codex settings, NativeChatState, ChatPersistence, Supabase, feedback, affect, collaboration, or Conversation Brain semantic analysis.

Credentials and access policy

In the completed native boundary, each provider credential uses an EXEPERT DSH v1 Credential Manager target derived from the stable DSH profile and provider ID. The native credential form writes through CredWriteW, clears its input, and sends credential.refresh with no secret. The DSH credential adapter reads through CredReadW only when the selected provider requests the named credential. Raw bytes remain in memory for that call and are zeroed when released where the platform/runtime permits.

The native adapter returns only present, missing, locked, or error status to bridge state. Debug, Display, and error implementations are redacted. Deleting a credential requires confirmation and does not delete a session.

The custom profile disables DSH credentials-local and all .env/environment credential fallbacks. Provider configuration may store safe provider IDs, base URLs allowed by that provider, model metadata, and the opaque credential target reference, never the value.

Every new session uses workspace-write with approval ask. A tool request becomes a visible native card containing the recorded operation, scope, risk, allow-once, and deny actions. No request auto-approves.

Full Access maps to DSH danger-full-access but is a product-level two-step action:

1. Show a blocking warning with the exact workspace/session scope and effects.
2. Require the user to type FULL ACCESS and confirm.

The grant exists only in live session state. It is visible in the session header and composer. It is cleared on session restart, sidecar restart, native restart, crash recovery, fork creation, and new-session creation. A stale Full Access control cannot answer a request from another session or runtime generation.

Native state and UI projection

The native boundary lives under desktop/exepert-desktop/src/dsh and shares no mutable state with desktop/exepert-desktop/src/codex.

The core types are:

• DshRuntimeState for lifecycle;
• branded, source-qualified DshWorkspaceId and DshSessionId;
• DshSessionEvent matching the v1 envelope;
• DshTrajectoryRecord with row kind, status, hierarchy, payload/result/schema, usage, exact source timing, and paging state;
• DshTurnTimingProjection for read-only Worked/Thought presentation derived from resident canonical records;
• DshPermissionMode with WorkspaceWrite and session-only FullAccess; and
• versioned non-content DshSettingsV1.

Source switching saves and restores independent DSH draft, attachment, model, permission display, scroll, selection, popover, workspace, and session state. A DSH failure does not initialize, stop, mutate, or clear EXEPERT or Codex state. If DSH was persisted as active but the runtime is missing or incompatible, the DSH tab remains selected and shows truthful recovery rather than silently switching sources.

Session navigation and Chat

The DSH sidebar provides workspace create/open, session list/search/create/resume/rename/archive/fork, running status, cancellation, recovery, and redacted export. All identities remain source-qualified.

Chat streams recorded user and assistant messages, tool calls/results, approval state, errors, goals, skills, subagents, compaction/context changes, and cancellation. It exposes the DSH provider/model catalog and provider-specific options without replacing adapters with an EXEPERT catalog. Credential state is opaque. Full Access remains visible in both header and composer.

Each resident turn receives a Worked disclosure only when an explicit duration or matching turn/start and terminal source timestamps provide an exact value. A running newest turn may use a process-local monotonic anchor for the live label only. Failed or cancelled turns display Stopped after … when the terminal boundary is exact; incomplete or partially paged boundaries omit the timer.

A separate Thought disclosure is projected only from recorded reasoning block/delta boundaries. Overlapping spans are merged, multiple model steps are summed, and tool or approval gaps are excluded. Its text is assembled from the already-redacted provider-visible reasoning records, bounded before rendering, and never represents private hidden reasoning. Records consumed by that card are suppressed from Chat to avoid duplication, but the canonical records and their source timing remain untouched in Trajectory.

Attachments are offered only when the DSH model/provider and bridge advertise the exact supported intake. Missing capability disables the control with explanatory copy.

Trajectory

The native view reproduces DSH structure and behavior with EXEPERT styling:

• Chat and Trajectory tabs;
• Input, Model, and Tools overview lanes;
• Duration, Turns, and Calls modes;
• turn dividers and step markers;
• SYSTEM, USER, CONTEXT, ASSISTANT, TOOL, SUBTOOL, SUBAGENT, COMPACTION, STATUS, and ERROR rows;
• search, folding, selection, virtualized paging, tail-follow, and keyboard navigation;
• recorded parent/child hierarchy; and
• a right-side inspector with Summary, Payload, Result, Schema, Timing, Request, System Prompt, Tools, Options, Usage, and Diff when recorded.

Initial system prompt and request-header changes are distinct chronological records. Exact source timestamps and durations are used. A running call displays a start marker with no fabricated elapsed value. A missing field says Unavailable from source. Chat-only timing disclosure and reasoning deduplication do not remove, rewrite, or combine Trajectory records. Large or sensitive payloads are collapsed by default and render bounded head/tail content; explicit paging is user-driven.

Goals, skills, tool catalog, active/completed subagents, provider settings, runtime versions, credential status, log location, restart, and recovery use native panels. Subagent parent-child links navigate back to the matching trajectory records.

Packaging

The release layout is:

exepert-desktop.exe dsh-runtime
node.exe node_modules
services\dsh-sidecar
profile-template\exepert
licenses
THIRD_PARTY_NOTICES.md provenance.json

dsh-runtime is produced beside the release executable by reproducible scripts. The generated directory, Node binaries, installed node_modules, logs, runtime cache, and user profile are ignored and never committed. Source control contains only scripts, manifests, schema, fixtures, exact package metadata, and notices. services/dsh-sidecar/runtime is an independent production-only package with a committed pnpm 9.15.4 lock, a read-package hook that rewrites every DSH-family dependency edge to 0.1.2-alpha.2, and a hoisted copy linker so the deployed tree is physical and relocatable rather than a graph of checkout-bound junctions.

Packaging starts from a clean staging directory, performs frozen source and production-only installs, verifies all 216 DSH-family names and npm integrities, downloads Node 22.23.2 from the official archive, verifies SHA-256 1177b4137ba5adaa56354ae40f1080c7450e8ae09cecb47da459d1c52ac99f97, and executes only the exact reviewed lifecycle-script allowlist. It copies the physical runtime closure, sidecar, profile template, direct provenance, and license material; then generates the full checksummed file/package/license manifest and notices. Independent verification runs both before and after relocation, followed by a named-profile composition smoke using only the relocated portable Node binary. The final directory replaces an existing generated target recoverably only after all gates pass.

Release startup rehashes the manifest and every listed file, rejects unlisted or missing files and all reparse points, validates source-record digests, requires the exact 216-name DSH family, verifies complete license coverage for every unique package identity, probes the packaged Node executable for exact version 22.23.2, and only then installs the profile and launches DSH. There is no signing claim or ambient trust fallback: a missing/tampered bundle, version drift, or missing portable Node fails closed while EXEPERT and Codex remain available.

The packaged runtime must work without installed Node, pnpm, the DSH reference checkout, or developer node_modules. It must not contact a model provider during readiness, health, deterministic replay, package verification, or native offline acceptance.

Failure behavior

Failure	Native behavior
Missing/tampered runtime	Incompatible or Failed recovery screen; EXEPERT and Codex remain usable
Wrong protocol, DSH, Node, or bridge version	Incompatible; no business request is sent
Host, Origin, subprotocol, or capability failure	Reject before dispatch; sanitized counter only
Malformed/oversized/binary frame	Close generation and recover from last acknowledged cursor
Identical duplicate	Deduplicate without another row
Conflicting cursor	Stop stream; surface protocol error; repair from canonical log
Sequence gap	Pause tail, page exact gap, then resume
Unknown event	Preserve and show a generic inspectable trajectory record
Slow UI/inspector	Backpressure transport; canonical DSH history remains intact
Unexpected sidecar exit	Bounded 1/2/4 second owned-process restart and replay
Exhausted restart budget	Failed with explicit Restart; no infinite loop
Credential unavailable	Provider unavailable status; no key prompt in logs or settings
DSH stored-log incompatibility	Session-specific recovery; never skip required history

Extension and upgrade rules

DSH extensions remain DSH plugins mounted through the named profile. Provider adapters register with DSH model services; tools register with the DSH tool registry; durable facts extend the DSH SessionEventMap; UI-only specialization adds a Rust trajectory projector while the generic row remains the fallback. The deterministic provider is a narrow EXEPERT-owned DSH plugin and traverses the same session, persistence, bridge, transport, reducer, and UI layers as real providers.

An ignorable event kind or additional event field may remain in exepert.dsh.v1 because the envelope preserves it. Adding a method, changing a required field, changing cursor semantics, increasing access, reducing authentication, or changing redaction/persistence obligations requires a new negotiated protocol version.

An upgrade repeats provenance capture, exact registry/lock verification, DSH session/API diffing, fixture expansion, TypeScript and Rust contract checks, packaged relocation validation, security review, native acceptance, and license regeneration. No version range is widened as an incidental upgrade.

Checkpoint validation boundary

Checkpoint 1 proves the source artifacts parse, deterministic cursors and adversarial expectations are coherent, direct provenance is exact, existing settings tests remain intact, and documentation builds.

Checkpoint 2 additionally proves frozen root installation; a 216-package exact DSH-family closure with registry integrities; strict TypeScript build/typecheck; the published CLI plus named-profile launch; safe readiness; one-shot descriptor capability input; per-connection auth, Host, Origin, and version rejection; bounded queues/frames/payloads; centralized redaction; schema-closed implementation of all 35 frozen bridge methods; DSH workspace/session lifecycle; model/tool/approval/goal/skill/subagent capabilities; explicit DSH compaction; cancellation; paging/follow/reconnect; non-destructive archive; redacted export; crash replacement; replay and recovery. The deterministic provider is keyless and makes no network call.

Checkpoint 2 does not prove the native Rust reducer/supervisor, Job Object ownership, Windows Credential Manager, GPUI geometry or interaction, permission reset UI, portable Node packaging/relocation, deployed license inventory, release build, or native computer-use acceptance. Later checkpoints must implement and validate those layers before delivery can claim completion.

Checkpoint 3 additionally proves exact Node version gating; shared child-launch inheritance serialization; fd 1/fd 3 capability transport; kill-on-close process ownership; authenticated request/response correlation on a bounded priority lane; typed timeouts; bounded subscriptions; duplicate-free reconnect; initial cursor-zero delivery; transactional multi-page gap repair; deterministic replay; transient reconnect versus incompatible failure classification; runtime health and owned-process recovery; safe settings; bounded diagnostics/redaction; and versioned, chunked, generation-bound Windows Credential Manager operations. The real Rust integration gate launches the published named profile, describes it, requests shutdown, observes a new sidecar connection generation, uses the recovered runtime, and performs bounded final shutdown. Checkpoint 3 still does not prove native GPUI interaction, packaged relocation/checksums, release acceptance, or screenshots.

Checkpoint 4 additionally proves additive dsh source persistence without changing existing EXEPERT/Codex values; source-local draft, permission, runtime, session, and selection state; native workspace/session create, resume, rename, archive, fork, export, search, cancellation, retry, and recovery; recorded Chat streaming; exact provider/model selection; safe workspace-write reset and generation-scoped Full Access; bounded goals, skills, tools, and subagents; virtualized Chat/Trajectory projection, paging, folding, tail-follow, selection, and recorded-field inspector; and stable accessibility controls. The real product integration drives the published named profile through Rust, while direct Windows GPUI interaction proves native folder selection, deterministic streaming, truthful AccessKit approval labels, allow/deny decisions, replay cleanup, Trajectory selection, and Summary/Payload inspection. Checkpoint 4 still does not prove portable runtime relocation/checksums, deployed license inventory, Windows release packaging, or final packaged screenshots.

Checkpoint 5 additionally proves a clean production-only frozen closure with 503 physical package locations, 501 unique package identities, all 216 DSH-family names exact at 0.1.2-alpha.2, and no reparse points; exact portable Node 22.23.2 download and execution; complete generated checksum, source, and license inventories; pre/post relocation verification; named-profile composition without the reference/developer checkout; transactional profile migration; native Rust startup re-verification; tamper, self-consistently rehashed version drift, and missing-Node rejection with exact restoration; and a real release executable reaching native DSH Ready with PATH limited to C:\Windows\System32. Checkpoint 5 does not by itself prove the complete packaged lifecycle matrix, final screenshots/accessibility record, EXEPERT/Codex release regression, security review, performance observations, or delivery hygiene required by Checkpoint 6.

Checkpoint 6 additionally proves the final frozen install and 23-test sidecar suite; 392 native library tests and 128 enabled integration tests; both opt-in native renderer smokes; strict pinned format/Clippy/release gates; final runtime verification and recovery injection; packaged DSH startup, cancellation, replay, Trajectory/inspector interaction, keyboard selection, goal lifecycle, diagnostics, export, completed-session fork/rename/archive, runtime crash/recovery/restart, full application restart, and EXEPERT/Codex source regressions; twelve reviewed screenshots; and the final security, provenance, performance, and hygiene record. The adversarial review additionally hardened stale approval invalidation across the pinned session/end-seed boundary, runtime access resets, and older browse windows that omit newer terminal history. The deterministic product integration records both approval outcomes plus skill/subagent projections, while exact Full Access confirmation/reset is unit-tested. Literal automated clicks on the native Allow, Deny, and Full Access security controls are not claimed and remain a documented human-authority acceptance boundary.