dsh-completion-guard 0.4.2 → 0.5.0

package/docs/COMPATIBILITY.md

@@ -2,11 +2,15 @@
 
 Compatibility is pinned to exact host package sets. A nearby version or a partial package match is not treated as supported.
 
-## 0.4.2 source candidate (unreleased)
+## 0.5.0 support policy
 
-The repair candidate retains the existing five audited host cohorts and peer dependency ranges. It does not change the Codex upstream pin, host package identities, or digest-v3 fixtures. The package version is `0.4.2`; no CI, frozen-package, native-platform or publication result is implied by that version field.
+The active support target is exactly DSH `0.1.2-rc.1` with Cordis `4.0.2`. The npm peer dependencies advertise only `0.1.2-rc.1`, and the active host allowlist contains that single audited core graph. Alpha package sets and older RC sets remain recorded as historical identities in the shipped manifest and source registry so previously accepted annexes stay verifiable, but an installed runtime built from one of those sets fails closed (`host_lock_version_mismatch`) instead of certifying. No floating version range and no alpha support is claimed; future compatibility work starts from the next upstream RC.
 
-For old pending requirements, use the new proposal/confirmation flow rather than editing the session log. Old events remain under their recorded capture version. Checkpoint output is paged and byte-bounded; clients must follow each list's cursor or query an ID instead of assuming that `open_items` or `available_evidence` on the first page is exhaustive. `bindings` and the top-level `certified|incomplete|unknown` meanings are unchanged. Generic execution and GUI/visual checks still cannot certify user-level completion. See the [architecture](ARCHITECTURE.md) for the schema and the [acceptance record](LOCAL_ACCEPTANCE.md) for remaining gates.
+## 0.4.3 core-lock policy
+
+`dsh-core/v1` uses manifest version 2 and four exact 33-package DSH core graphs, retaining the previously audited DSH and Cordis versions. Market is not a core row. Its transitive dependencies remain part of active-graph traversal, so replacing or duplicating a core dependency still blocks certification. No floating DSH version range is introduced.
+
+The package keeps the same Codex semantic fixtures and digest-v3 encoder. The new manifest/cohort/policy values create a different host identity; an old injected lock requires fresh inspection and injection, and an old certificate stays historical. See [migration](HOST_LOCK_UPGRADE.md). Package version alone does not establish CI, native acceptance or publication.
 
 ## Recorded 0.4.0 release baseline
 
@@ -32,12 +36,12 @@ DSH rc.1 replaces the public `Session.events` getter with `snapshotEvents()` and
 
 ## Upstream adaptation policy
 
-Version 0.4.0 remains frozen on the alpha.3 setup above. Alpha.4 and later alpha releases are not new adaptation targets. Compatibility work resumed with DSH `0.1.2-rc.1`; that cohort is included in the published `0.4.1-rc.1` prerelease and retained by the 0.4.2 candidate. The upstream [tags page](https://github.com/deepseek-ai/deepseek-harness/tags) tracks later releases; a newer tag does not establish support.
+Version 0.5.0 targets DSH `0.1.2-rc.1`; alpha releases are observed for trend only and are never adaptation or validation targets. A newer upstream tag does not establish support by itself; support starts when that exact RC or release is added as its own audited cohort with source, CI, and native acceptance. The upstream [tags page](https://github.com/deepseek-ai/deepseek-harness/tags) tracks later releases.
 
 ## Platform and release evidence
 
 - **Source and CI:** the release commit must pass the repository matrix and the Ubuntu, macOS, and Windows Node.js 22/24 CI jobs.
-- **Exact package:** the repository packer emits one deterministic 26-file tgz with its full source commit in `gitHead`. That same SHA-256 must be used on both native platforms and published to npm without repacking.
+- **Exact package:** the repository packer emits one deterministic tgz with the declared package inventory with its full source commit in `gitHead`. That same SHA-256 must be used on both native platforms and published to npm without repacking.
 - **Native scope:** macOS and Windows acceptance separately cover isolated Web and Headless installation, complete host-lock readback, repeated injection, Web restart and recovery, intentional Headless credential failure, daily-profile preservation, and scoped cleanup.
 - **Public identity:** the annotated tag, npm manifest and downloaded tgz, GitHub Release target, checksum, and platform annexes must all resolve to the same release commit and package bytes.
 - **Daily profiles:** upgrading a user's daily DSH profile is a separate action and is not implied by release acceptance.
@@ -50,11 +54,9 @@ Version 0.4.0 remains frozen on the alpha.3 setup above. Alpha.4 and later alpha
 
 ## Rejection rules
 
-The five exact host sets are recorded in [`../manifests/supported-host.v1.json`](../manifests/supported-host.v1.json). Each set is a complete list of required packages and versions. Every row must match one set.
-
-Missing, mixed, duplicate, unidentified, unknown, or integrity-drifted rows leave the Guard unavailable. Unregistered substitutions such as alpha.3 with dshmarket `1.38.1` are rejected as mixed graphs. dshmarket is an authoritative lock input; skin-center is not.
+Current core graphs and original historical cohorts are recorded separately in [`../manifests/supported-host.v1.json`](../manifests/supported-host.v1.json). All core rows must match one complete graph. Missing, mixed, duplicate, unknown or integrity-drifted core rows reject certification.
 
-The selected set is part of the host-lock digest. Changing sets invalidates earlier certificates, and a platform is marked supported only after its complete set passes native checks there.
+Market versions do not select a core cohort. Market restart has its own protocol and loaded-instance checks; an unavailable adapter does not disable the core or erase pending restart work. Changing the actual core graph changes its digest and invalidates earlier certificates.
 
 ## Evidence links
 
@@ -66,13 +68,13 @@ The selected set is part of the host-lock digest. Changing sets invalidates earl
 
 The package exposes a named `apply(ctx)` function and a named `inject` array (`['sessions', 'commands']`) with no default export. Its `dsh.bundle.patch` points at `cordis.patch.yml`, which inserts the `context-guard` bundle row.
 
-The plugin accepts an `activation` configuration value of `opt-in` or `always`. The default is `opt-in`; `always` initializes the projection as enabled before the persisted session log is replayed. Invalid values fail during plugin configuration instead of silently falling back. A DSH profile can select `always` with an ID-targeted `config` override in its `cordis.patch.yml`; see the README quick start for the complete example and the replay implications for existing sessions.
+The plugin accepts an `activation` configuration value of `opt-in` or `always`. The default is `opt-in`; `always` means every session is protected automatically from its first real user message. Since 0.5.0, session start writes nothing into the session log: the versioned protocol boundary and first-step guidance are delivered inside the same step batch as — and ahead of — the first real user message, so a new session stays blank (`seq === 0`) and a DSH preset can be selected before anything is sent. An explicit `off` suppresses `always` in that session until the next `on`. Invalid values fail during plugin configuration instead of silently falling back. A DSH profile can select `always` with an ID-targeted `config` override in its `cordis.patch.yml`; see the README quick start for the complete example.
 
 ### Host-lock setup
 
 Before the Guard can certify work, generate and verify the host lock from the active DSH runtime and profile. Use the packaged `dsh-completion-guard-host-lock inspect|inject|verify-dump` flow in the README. The default patch has no `hostLockPackages`, so the Guard fails closed until this flow succeeds.
 
-Version 0.3 accepts the generated `hostLockPackages`, `hostLockPlatform`, and `hostLockProfile` values. Each critical package row records the exact resolved version and registry tarball integrity. The Guard does not infer a missing identity from a nearby lockfile: missing, duplicate, multi-version, or drifted rows fail closed. The audited identities are defined in [`../manifests/supported-host.v1.json`](../manifests/supported-host.v1.json).
+Version 0.4.3 injects `hostLockPolicy: dsh-core/v1`, the runtime/profile source roots, `hostLockPackages`, `hostLockPlatform`, and `hostLockProfile` together. Replay rechecks those actual graph sources; legacy configuration without the policy and roots reports `host_lock_migration_required`. Each critical package row records the exact resolved version and registry tarball integrity. The Guard does not infer a missing identity from a nearby lockfile: missing, duplicate, multi-version, or drifted rows fail closed. The audited identities are defined in [`../manifests/supported-host.v1.json`](../manifests/supported-host.v1.json).
 
 ### Capability groups
 
@@ -87,9 +89,9 @@ The host lock evaluates these groups independently:
 - Web control; and
 - jobs.
 
-A missing platform- or action-specific group disables only the path that depends on it. For example, a valid terminal or jobs group remains usable when the filesystem group is unavailable.
+Action-specific checks select their required groups only after the complete core graph is valid. An invalid core graph blocks certification; a missing optional market adapter blocks only its dependent operation.
 
-The filesystem group has a narrower contract of its own. It freezes the registered `read`, `write`, and `edit` tools; their closed result and presentation shapes; the local or sandbox `ctx.fs` implementation; the read-before-mutation observation policy; the sandbox policy; and the approval provider. A missing or drifted filesystem row disables `create`, `modify`, and ordinary filesystem facts without disabling unrelated capability groups.
+The filesystem group has a narrower contract of its own. It freezes the registered `read`, `write`, and `edit` tools; their closed result and presentation shapes; the local or sandbox `ctx.fs` implementation; the read-before-mutation observation policy; the sandbox policy; and the approval provider. A missing or drifted filesystem core row keeps the core lock unavailable.
 
 ## Peer dependencies
 
@@ -134,7 +136,9 @@ certifying capability, and has unknown outcome.
 
 ## Verified surfaces
 
-### Current visible behavior
+### Previously verified runtime behavior
+
+These observations belong to the historical native records linked below. Each new core-lock artifact requires fresh native acceptance.
 
 - `dsh --profile web --dump-config` and `--profile headless --dump-config` both include `context-guard`.
 - A real Headless boot loads the plugin: `apply`, `ctx.sessions` access, and listener registration succeed before the run reaches the intentional missing-provider-credentials boundary.
@@ -203,7 +207,7 @@ The action is rejected before executable inspection, command execution, HTTP, or
 ### Package operations
 
 - `install` requires the exact package id, version, and profile, and the package must be absent.
-- `apply` requires the exact package id, version, and profile, plus an existing package with a changed version or integrity.
+- `apply` requires the exact package id, version, and profile, plus an existing package with a changed version or integrity. It executes through the DSH CLI and verifies disk package identity. It does not prove a live process, UI or restart outcome; those requirements remain separate.
 - `publish` requires the exact artifact id, version, and canonical registry. Version 0.3 does not authorize `latest` or a version range.
 
 Publish executes the exact resolved tgz with `--ignore-scripts`. Capture, argv, and standard packument readback use the same canonical HTTPS registry base. Registries containing credentials, a query, fragment, encoded separator, control character, or ambiguous path segment are rejected.
@@ -222,7 +226,9 @@ Create and modify bind to the frozen target and expected transition described be
 
 ### Restart
 
-Restart requires the exact service id. It persists an intent before POST and closes only after the restored process reports a changed boot ID.
+Restart requires an exact service, compatible protocol and a trusted binding from the host to the loaded provider, profile, loopback origin, package identity and process generation. HTTP capability claims and disk manifests alone do not establish that binding. Current DSH provides no production verifier, so the market restart adapter is unavailable even when the core lock is supported.
+
+The version-2 service adapter binds provider and instance digests into its generation string. A persisted intent permits the intended new instance only for the same provider; arbitrary process drift, provider replacement and old version-1 credentials cannot close the action. This pre-execute check is not isolation against a concurrently malicious same-user process. Native direct market restart checks are not evidence that Guard can certify a market restart.
 
 ### Windows command shims
 

package/docs/HOST_LOCK_UPGRADE.md

@@ -0,0 +1,83 @@
+# Upgrading the core host lock
+
+The 0.4.3 line separates Guard's exact DSH core from optional market versions.
+A normal market update no longer changes the core digest. A plugin that changes
+which core packages actually resolve still invalidates the lock.
+
+## Upgrade an existing profile
+
+Choose the published Guard package and DSH version from the
+[compatibility guide](COMPATIBILITY.md). Keep the existing profile backup and
+its disabled/activation settings. Installation does not authorize enablement.
+Web and Headless are separate profiles and must be checked separately.
+
+If the profile still declares `dsh-context-guard`, replace it through DSH's
+plugin manager rather than loading both package names. Its internal
+`context-guard` id remains unchanged. Preserve session files and user settings;
+if a profile override names the old package, change only that package name.
+Headless does not need market added as part of this migration.
+
+After the new package is installed, use absolute paths for the actual runtime
+and profile. The following example targets a POSIX shell:
+
+```sh
+DSH_RUNTIME_ROOT=/absolute/path/to/.dsh-runtime
+DSH_PROFILE_ROOT=/absolute/path/to/.dsh/profiles/web
+GUARD_HOST_LOCK="$DSH_PROFILE_ROOT/node_modules/.bin/dsh-completion-guard-host-lock"
+"$GUARD_HOST_LOCK" inspect --runtime-root "$DSH_RUNTIME_ROOT" --profile-root "$DSH_PROFILE_ROOT"
+"$GUARD_HOST_LOCK" inject --runtime-root "$DSH_RUNTIME_ROOT" --profile-root "$DSH_PROFILE_ROOT"
+dsh --profile web --dump-config | "$GUARD_HOST_LOCK" verify-dump --runtime-root "$DSH_RUNTIME_ROOT" --profile-root "$DSH_PROFILE_ROOT" --dump-config -
+```
+
+For Headless, use its profile path and `--profile headless`. On Windows, use the
+installed `.cmd` launcher and Windows absolute paths. A strict repeat leaves
+the package and profile contents unchanged. Restarting or enabling a daily
+profile remains a separate user action.
+
+## Check a Headless profile before installation
+
+A DSH `0.1.2-rc.1` Headless profile can have no external dependencies and no private `node_modules` or lockfile. From an accepted package or matching source checkout, `node bin/dsh-completion-guard-host-lock.mjs inspect-graph --runtime-root <runtime> --profile-root <profile>` checks that state without initializing or launching the profile.
+
+This narrow case requires exactly the installation-owned `dsh-base` and `dsh-headless` bundles, a complete audited runtime core, and matching bundle versions, package-map origins and patch files. Declared but uninstalled dependencies, partial map/lock pairs, unexplained local modules and foreign parent-module fallbacks are rejected. Existing profiles with both graph files retain their active-importer checks; damaged files are not treated as an empty graph.
+
+The result labels `inspection_scope: pre_install_target` and `profile_graph.state: dependency_free_headless`, with the manifest hash and bundle identities. Its package rows describe the verified runtime core used for this installation target, not a private profile importer or a live boot. After installing Guard, the `inspect`, `inject` and runtime replay checks still require the profile's package map, lockfile and installed plugin binding. This pre-install result cannot replace those checks.
+
+## What changes in the lock
+
+The generator writes `hostLockPolicy: dsh-core/v1`, the actual runtime/profile
+source roots, platform/profile kind and the complete 33-row core graph. The
+core manifest is version 2. Runtime replay re-reads those graph sources and
+requires the same exact core before using certificate authority.
+
+An older injected configuration reports `host_lock_migration_required`.
+Removing its market row by hand is not migration. Reinspect, inject and verify
+the actual environment. Historical cohorts, requirements and session records
+are retained; old certificates do not become certificates for the new lock.
+The shared digest-v3 encoder and its upstream fixtures are unchanged.
+
+## Market and restart
+
+Core compatibility does not certify the optional market restart adapter.
+Market's current HTTP capability response and a matching disk manifest cannot
+prove which provider bytes the service has loaded. Current DSH provides no
+independent loaded-instance verifier, so this adapter remains unavailable.
+An explicit restart requirement stays pending with a binding-unavailable
+reason. Other guarded work continues; package apply proves disk state only.
+
+A trusted embedding can supply a loaded-instance verifier to the version-2
+service adapter. Its provider identity binds the actual version, integrity,
+loaded tree, profile, origin and protocol. Its instance identity additionally
+binds the process and boot. Only a persisted restart intent may connect the
+expected old instance to a verified new instance of the same provider.
+Provider replacement, arbitrary process drift and old version-1 credentials
+cannot close that intent. These checks do not isolate a process from a
+concurrently malicious process running as the same user.
+
+## Acceptance records
+
+Use the [native entrypoint](LOCAL_ACCEPTANCE.md) with explicit core targets
+and a Web market version. Supplied daily target paths are read-only preflight
+inputs. The driver creates its own isolated profiles, with no market in
+Headless. Real market HTTP lifecycle checks and protocol unit fixtures are
+separate from Guard adapter certification. Each native annex belongs to one
+exact artifact and platform; publication is recorded on its GitHub Release.

package/docs/LOCAL_ACCEPTANCE.md

@@ -2,28 +2,38 @@
 
 Each section names its evidence boundary. Deterministic checks, isolated DSH_HOME composition, native-platform lifecycle runs, model sessions, CI, and public release readback are separate claims; none substitutes for another.
 
-## v0.4.2 repair candidate (unreleased)
+## Host-bound acceptance for the 0.4.3 line
 
-This source candidate adds bounded feedback and root-confirmed rebinding. Local regression tests exercise compound capture, source authority, one-to-many replacement, stale/partial replay, target matching, large pages, snapshot changes, small recovery budgets and qualified pending boundaries. Local tests and the existence of a host driver do not establish native DSH acceptance.
+This line separates core and optional-provider acceptance while retaining completion feedback and root-confirmed rebinding. Local regression tests exercise compound capture, source authority, one-to-many replacement, stale/partial replay, target matching, large pages, snapshot changes, small recovery budgets and qualified pending boundaries. Local tests and the existence of a host driver do not establish native DSH acceptance.
 
-The versioned entrypoint is `scripts/native_acceptance.py`. Its default `portable_artifact` profile checks exact source/tgz identity, isolated installation, installed-file parity, second-install no-op and JavaScript syntax. `--gate-profile host_bound --runtime-root <audited-runtime>` additionally creates isolated Web and Headless profiles, injects and reads back their host locks, then runs `scripts/native_host_probe.mjs` inside the real DSH composition. The probe uses the host AgentRegistry, ToolRuntime and durable Session services for nonempty test certification, generic refusal, rebind confirmation, history queries, compact/resume and a qualified pending boundary. Web checks also require wrong-origin restart denial, same-origin acceptance, changed boot/process identities and listener cleanup. The installed launcher shim is checked separately.
+The versioned entrypoint is `scripts/native_acceptance.py`. Its default `portable_artifact` profile checks exact source/tgz identity, isolated installation, installed-file parity, second-install no-op and JavaScript syntax. `--gate-profile host_bound --runtime-root <audited-runtime>` additionally creates isolated Web and Headless profiles, injects and reads back their host locks, then runs `scripts/native_host_probe.mjs` inside the real DSH composition. The probe uses the host AgentRegistry, ToolRuntime and durable Session services for nonempty test certification, generic refusal, rebind confirmation, history queries, compact/resume and a qualified pending boundary. Web checks require an owned-host restart, a different host process, persisted-session recovery and listener cleanup; they do not depend on a market restart API. The installed launcher shim is checked separately.
+
+Supplied daily target paths use the [read-only installation preflight](HOST_LOCK_UPGRADE.md#check-a-headless-profile-before-installation). A dependency-free rc.1 Headless target may have no private map or lockfile; the preflight verifies its installation-owned bundles and labels that state separately. The isolated lifecycle still installs Guard before checking its private graph, lock and second-install no-op. A successful target preflight alone is not a native gate result or proof of live adoption.
 
 The host driver deliberately makes no model request. It first checks that the normal Headless task driver stops with `MISSING_CREDENTIAL` in the isolated environment, then disables that task driver for the separate real-service probe. A required package-update probe installs an inert local fixture at version 1, then clarifies and confirms a generic requirement, applies version 2 through the real producer/action tools, independently reads it back and requires a nonempty certificate. Capability skips appear in the returned annex. Never treat a synthetic test or an empty probe case set as a passed native run.
 
 After exact-candidate portability CI passes and one clean commit's tgz has been frozen, a native owner can run the following with Python 3.11+ (the same artifact is used on both platforms):
 
 ```text
-python scripts/native_acceptance.py --gate-profile host_bound --repo-root <clean-checkout> --runtime-root <audited-runtime> --artifact <frozen.tgz> --artifact-sha256 <sha256> --source-commit <full-commit> --output <outside-repository-annex.json>
+python scripts/native_acceptance.py --gate-profile host_bound --repo-root <clean-checkout> --runtime-root <audited-runtime> --web-cohort <exact-core-id> --headless-cohort <exact-core-id> --web-market-version <exact-version-or-none> --artifact <frozen.tgz> --artifact-sha256 <sha256> --source-commit <full-commit> --output <outside-repository-annex.json>
 ```
 
+Use `--target-web-profile` and `--target-headless-profile` together to compare actual consumer targets read-only before isolated installation. Both core identities are explicit; the Web market version is also explicit, and Headless installs no market. A target mismatch fails instead of selecting a historical fixture.
+
 The driver creates a new temporary DSH_HOME, explicit temporary HOME/USERPROFILE and credential-free environment; it does not select or enable a daily profile. It binds the annex to the artifact, source commit, host lock and probe bytes, and checks owned processes, ports and temporary-file cleanup. Do not run it from a dirty source tree, substitute a rebuilt package, or copy raw temporary logs into the repository.
 
-The earlier 0.4.2 candidate at `6b92b3b7a5eb642686df9f2a1b4d66d54455f503` passed [candidate CI](https://github.com/GreenLv/dsh-completion-guard/actions/runs/34128172642). Its frozen tgz SHA-256 was `9d3e0a0bb948b137f27303a98ad38d3ecc8a901c5c579ce7e3b3c664530c3b4a`. Native macOS and Windows each passed all 28 required host-bound gates, including the normal Headless credential boundary and package-update probe, with cleanup passed. Both annexes retained the `real_model_request` capability skip. These are historical candidate results, not a release or evidence for later package bytes.
+The historical 0.4.2 candidate at `6b92b3b7a5eb642686df9f2a1b4d66d54455f503` passed [candidate CI](https://github.com/GreenLv/dsh-completion-guard/actions/runs/34128172642). Its frozen tgz SHA-256 was `9d3e0a0bb948b137f27303a98ad38d3ecc8a901c5c579ce7e3b3c664530c3b4a`. Native macOS and Windows each passed all 28 required host-bound gates, including the normal Headless credential boundary and package-update probe, with cleanup passed. Both annexes retained the `real_model_request` capability skip. These are historical candidate results, not a release or evidence for later package bytes.
 
-The annex uses `native-acceptance/v2` with the DSH-specific `capability_skips`, `host_driver_sha256`, and `host_lock_digests` fields. A generic closed v2 validator correctly rejects those extensions. A consumer that provides the explicit `dsh-host-bound/v1` contract profile must validate the original annex with independently supplied expected commit, artifact SHA-256, and probe SHA-256; do not remove fields to make it pass. `host_driver_sha256` identifies `native_host_probe.mjs`, not the Python wrapper. Windows checkout CRLF bytes can produce a different probe hash from macOS LF bytes; bind each platform to its actual reviewed file bytes. Failed probe annexes may additionally contain bounded `host_probe_failures` diagnostics. The profile consumer is separate tooling and is not installed by this npm package.
+The core annex uses `native-acceptance/v2`, gate profile `host_bound_core`, and the DSH-specific `capability_skips`, `host_driver_sha256`, `host_lock_digests`, `host_lock_policy` and `market_interface` fields. A generic closed v2 validator correctly rejects those extensions. The historical 0.4.2 `host_bound` annex retains its original `dsh-host-bound/v1` contract; v1 and v2 are not interchangeable. A consumer that provides the explicit `dsh-host-bound/v2` contract profile must validate the original annex with independently supplied expected commit, artifact SHA-256, and probe SHA-256; do not remove fields to make it pass. `host_driver_sha256` identifies `native_host_probe.mjs`, not the Python wrapper. Windows checkout CRLF bytes can produce a different probe hash from macOS LF bytes; bind each platform to its actual reviewed file bytes. Failed probe annexes may additionally contain bounded `host_probe_failures` diagnostics. The profile consumer is separate tooling and is not installed by this npm package.
 
 Every subsequent frozen package needs its own CI and same-byte native annexes, recorded outside its packaged documentation. Publication and public readback are separate gates. A disabled daily installation remains disabled until the user separately requests an upgrade and enablement.
 
+## Historical 0.4.2 release
+
+The [0.4.2 release](https://github.com/GreenLv/dsh-completion-guard/releases/tag/v0.4.2) binds commit `df19d84db35369afb5b3a8041b6e5051db367155` and tgz SHA-256 `87deac307922fdff3391f1d6e0fa1b537c5b57e3a99e1d0943b0dc44b4e90068`. Its published annexes and public readback are specific to those bytes and the old market-1.41 fixture. They do not establish compatibility with a market-1.44 daily profile or the new core-lock policy.
+
+Direct market HTTP lifecycle checks exercise the installed market's actual interface. They do not substitute for the independent loaded-instance binding required by Guard's optional restart adapter. An unavailable adapter must leave an explicit restart requirement pending while core work remains protected.
+
 ## v0.4.0 release gates (2026-09-02, passed)
 
 Version 0.4.0 targets DSH `0.1.2-alpha.3` with dshmarket `1.39.0` and Cordis `4.0.2`. The repository does not place a candidate's own commit, checksum, or public status inside that candidate's packaged documentation: those facts are generated after the package bytes are frozen and are attached to the GitHub Release.

package/docs/SEMANTIC_COMPATIBILITY.md

@@ -126,9 +126,11 @@ DSH needs a deliberate follow-up, not a line-for-line port. The highest-value sh
 
 Work-unit scope and correction attribution are also shared semantic gaps and should gain portable regression cases before implementation. Stop-disposition handling is partly equivalent already, so it should be compared with the 0.11.0 cases before code is changed. Codex cache repair, Hook trust, and plugin installation remain Codex-only. Incident-corpus tooling may remain owned by Codex, while reviewed platform-neutral cases continue to be mirrored here.
 
-## 0.4.2 candidate boundary
+## 0.4.2 and 0.4.3 product boundaries
 
-The 0.4.2 candidate retains these exact mirrored fixtures and the recorded upstream pin. Its DSH-native rebinding, bounded checkpoint output, and recovery changes do not establish parity with later Codex releases. `upstream-deltas.json` is the dated 2026-09-03 comparison snapshot: its `currentRelease` fields name the releases compared then, not a live latest-version lookup. Refreshing that comparison requires a separate upstream audit; it does not happen merely because either product releases a newer version.
+The 0.4.2 release retained these exact mirrored fixtures and the recorded upstream pin. Its DSH-native rebinding, bounded checkpoint output, and recovery changes do not establish parity with later Codex releases. `upstream-deltas.json` is the dated 2026-09-03 comparison snapshot: its `currentRelease` fields name the releases compared then, not a live latest-version lookup. Refreshing that comparison requires a separate upstream audit; it does not happen merely because either product releases a newer version.
+
+The 0.4.3 core policy changes DSH-specific manifest values, not the shared digest-v3 encoding or byte-mirrored fixtures. Core manifest version 2 and `dsh-core/v1` produce a fresh identity after actual-graph inspection. Legacy cohorts remain historical inputs. Market service adapter `context-guard.service.v2` uses version `2.0.0`; old restart credentials cannot become new-instance credentials. Package apply remains a disk-state operation, and unavailable restart work remains pending.
 
 ## Validation boundaries
 

package/manifests/action-manifest.v1.json

@@ -6,7 +6,7 @@
     "context-guard.git.v1": "1.0.0",
     "context-guard.package.v1": "1.0.0",
     "context-guard.artifact.v1": "1.0.0",
-    "context-guard.service.v1": "1.0.0",
+    "context-guard.service.v2": "2.0.0",
     "context-guard.registry.v1": "1.0.0"
   },
   "actions": {

package/manifests/supported-host.v1.json

@@ -1,6 +1,6 @@
 {
-  "registryVersion": 1,
-  "description": "Audited host cohort registry. Each cohort is one exactly extracted package graph; a runtime graph must atomically match one cohort. Mixed, missing, duplicate, or unknown rows fail closed.",
+  "registryVersion": 2,
+  "description": "Exact DSH core graphs. The active support target is exactly dsh-0.1.2-rc.1-core-v1. Optional dshmarket instances are verified independently by the action adapter; their dependencies still participate in core graph resolution. Legacy cohorts are historical identities only and are not active support entries.",
   "packageGroups": {
     "base": [
       "@deepseek-ai/cordis",
@@ -38,7 +38,6 @@
       "@deepseek-ai/dsh-host-plugin-inventory"
     ],
     "web_control": [
-      "dshmarket",
       "@deepseek-ai/dsh-host-webserver",
       "@deepseek-ai/dsh-web-app"
     ],
@@ -61,6 +60,224 @@
     ]
   },
   "cohorts": [
+    {
+      "id": "dsh-0.1.2-rc.1-core-v1",
+      "manifestVersion": 2,
+      "supportedGoalVersions": [
+        "0.1.2-rc.1"
+      ],
+      "auditedPlatforms": [
+        "posix",
+        "windows"
+      ],
+      "platformAuditNote": "posix: exact graph extracted from the isolated 2026-09-03 native macOS rc.1 runtime with dshmarket 1.41.0. windows: exact graph extracted from the 2026-09-04 native Windows rc.1 runtime with dshmarket 1.41.0 and verified row-for-row identical (name, version, registry integrity) to the posix extraction; audited on the live Windows host via host-lock inspect/inject, composed-config verify-dump, and a cold Web boot. The Guard adapts the Session snapshotEvents API; unlisted host cohorts still fail closed.",
+      "capabilityExpectations": {
+        "goal_complete_precommit_guard": "required",
+        "goal_disarm_readback": "required",
+        "session_flush_before_control": "required",
+        "tool_guard_monotonic": "required",
+        "host_capability_model": "action-platform-v1",
+        "external_wait_jobs_readback": "dsh.jobs.v1",
+        "filesystem_tool_contract": "dsh.fs-tools.v1",
+        "host_lock_policy": "dsh-core/v1"
+      },
+      "supportedActions": [
+        "inspect_remote_updates",
+        "install",
+        "apply",
+        "create",
+        "modify",
+        "test",
+        "verify",
+        "pull",
+        "fetch",
+        "commit",
+        "push",
+        "restart",
+        "publish",
+        "generic_run"
+      ],
+      "packages": [
+        {
+          "name": "@deepseek-ai/cordis",
+          "version": "4.0.2",
+          "integrity": "sha512-asOnXP1TzFSFQlHb1iegDZp0z/8WD1c7YNrwJR/Tx2bzNuMXfcekE/I67Iv6SQXeLB4csxqCngzQKANP7gdw0g=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-agent",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-lfaqN34vUCWvbn1kJVHrhfJ6Dvt1HDHCm33ZCpmKkl07/5q6FxWqVv6rOdVX5QnM/9xz/uYiN0nQwUtBg4+Skg=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-commands",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-uBh4JTX7pOkFhmbWjXjVLnOQOawyccC7+DazbHrLRN6/wy4OgTRH+DaW0+ibLq+XRAO19OvBTtuoh3x/KkJx1Q=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-goal",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-djzY1oNZV5RwnOFXmDeWFbyswInV9RVWAD0qryxMznQtEDF31PUJ8BQfqs9tVrTV36V3a0neYrZP0DDvRP8ZCA=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-llm",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-7VYsha5AXsVLnsAwYJffWXz9bwUbElw8i5N8tlTSdai9Bupk3sMbsotzPf8ZbsuGAxQYErahMwQwgGEu4qZO6g=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-session",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-jRGNPTbQcvIx1F2MVmmkoiHLgpC3Btqo1wkl/3JDLlOWRVWKOuaC+5fQiMrFPOYfno6YiX/c2UvmA0td8qB92w=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-tools",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-W9kUio00s7WbM8kEwniyd4hfb3CeUxVczsjXbOcKtakfiTywNLeyRWkpx2fvwRAH2rBfg3qCgczVfS0DOw1csg=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-tool-goal",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-ooHKN6Eqy3owNS/oCDO7mR+UalEE4AxJMXou29waahIdSQsFAlk4pPApvhrwg1lpchF5CKwBPOtsVmjq2HfBKQ=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-agent-loop",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-4h16Gn/5oXLTFeorehdlKe5xmDKscR/eRsUu3cs6clKgaTrn6YvnWNB0XkYEg+AXiXbsyfl5MW5Bs4576t7vZw=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-tool-bash",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-xKc4oXVDBwM/PaicpjGdWEaJ1N14B7KPmOzdpQ7ynE4gKUnvGU/eTg18EHamdyDOidh5ox0fNUnxk0rQjVo2+Q=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-tool-pwsh",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-LaImOCdizIGkQnxzzkoaqzRWGZLsuDuqqF2adgJ3zeG0nDwan4Sz+1wYz4YSp0Gg6mJ79CYacsbYmGhYYyKY/g=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-shell",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-uFrSY0nNKzh5orGl2B0B4RfK7wTdIlwhPQc7aLA44jyjioLlqhF7PUek/NWtye2scwp3YHOw158XeOQUD8qTFg=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-subprocess-local",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-Spc/IXWvjEteGysifGr6JvCokcH8T88z0mdxIGcu9SFdgDyY8HKR+h5yq73+rbo4RYzT7+TBE43TIZy5LfmzgQ=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-bash-sandbox",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-dF9PfBWus80Juj3VjUmndbGw1/6cT1BY7BLFuXUi7SDMV1fA4iwA2c7HuvezYFGvpE/8QRZ+c5ZiRfxbWGYktw=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-pwsh-sandbox",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-QjJzrM/tJDkgvtVzYz2bmCxBzdSUo/YwI/rPBJeTwLbWBuehyhX6BueCwU6Ja1Bsdm9crz2D7rVc/DU/xrFttw=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-shell-env",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-o1VqxyHp1OrMB8aHnzYAPwuU4giUErCxBg0yr035r6f3Le36viS0sUHsnjcAsMdbaQJf/XvzbaokYDVrdVHE4A=="
+        },
+        {
+          "name": "@deepseek-ai/dsh",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-RPq48TzxvwpdT9/7W1tbhZDBMmeK+bxDrX9cqQC27Wx/LqtgJF8PSa3b3xriU8oxtvhwYmk21w2cej3uMQrnVA=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-host-plugin-inventory",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-MyLA5XncFdfk9btv29FZSg+ojFOOsHEiPkGWAQiRw+EG/2HlVUEm/9KqPxh2jxB5eFge9GahTg2e7x3Veziadw=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-host-webserver",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-QVcaf4qnIa1t215Y8TRiRhqkEz4Lu5/F+KqvWT+4sHOiyWmZr8g1JndqlwP6MBnMQEPmp0I/EKYJ7PWMV32gkA=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-web-app",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-QGh+XWRgrsVktKD3YHw+cY/knwBESq+2TtyOGNc+V7GU3LG9qL6EPB0M8pIDjxF1jLls+M71LIVbevuFx3oZ6Q=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-jobs",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-VuNPXosjgRbEg0tp+GXsdAqkicwSk5Ynl2AezUQheJgpmw5cvWy3rLEg79B686xGc72tIA6pCW6eBbZGnKOmIg=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-jobs-local",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-bfNV6IJRG7vPWg+Rp3siRCA0BVK8rB1aqn0BG2nPKzCIA2coKqeJ8uPbEm+GuyW/naMR4uCOrrCVLyrwBuMwzg=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-tool-jobs",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-ya7E6zToAdJ+GvNeZFPx8jNx0CfI52tlp0NCGzXHeB0S74haGWCV0iFe1nyoDJg7SDiN1xc1d2nV9klOqWtd5g=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-tool-fs",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-9a1lcPGD4Z3p7OLTMkkCdwN0w7Gl96Jlypq6qopUA0WMkKai83VfeLZvramPnTJo6ezpuPXcLFWGm/2UDSlbcA=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-fs",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-BSIB2j8WvATQ1mf7wUIpHPftDwbzz246qp6aUpLGSzBWGmLBdX3O1oDhyNV1YhgPmDQlwovac2odcAb62tuDdw=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-fs-local",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-tFHHKtD11tIk3FpkWF0vBKdX05zKbwqXQW9LhreA5hErCKEsulUsQLamf+kF1D8fuKqa8Yb+yWQIfYS93cy39w=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-fs-sandbox",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-nnZnsOYLWrN2AnoB0qvQBLhh2VdU4A39AqOgWwsxnT3JrScGpvBcBMCt4fpLP9l5VjOY1qhIbLf6xd5p93C/6Q=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-fs-observation-policy",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-Uw3ErcPwQZUvXylLSf+CDjzfAza5ZVNOMkG4hIJjvgG4WBg3tqoCOY2OQk4O1DGTie4EzL4mHpAe5auwoV4JTw=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-sandbox",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-nTO350NlVo9cvKzbeILcPIRIk9ijidrv29snRjTOx7kP5aO/BI2b4KxsRCYoXg8WGAMbIkGbsmZKUD4qz7hyXQ=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-sandbox-policy",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-nLARL84X6K4DCUJsqRWINg3+1EVxsw70hbP+Yl92W/PsquQVs/UJQc55gnhYGmIMf6eJ0vQv39fziNSnAxdx5A=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-user-approval",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-oYkLE4a/TwqVNi299pUf/QP1Yku6KScdUCTUyYbjaRBcN+/pXPpHikl2aoE2thH9D0uT/Kj6T2kz+wDDcFd9Xg=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-attachment",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-QISKUjEITusLvAkqPLRn70xDUt+GjjY41pISjtPKYcZ4EGmayzhgZ3VJNYEcC+rbaF44hs2o/0VhOwHA7lyxjw=="
+        },
+        {
+          "name": "@deepseek-ai/dsh-system-prompt",
+          "version": "0.1.2-rc.1",
+          "integrity": "sha512-7W93PZKIk4CHvjZGgLIxrrEKpk+6t8nQXje1vKR5vG73dfXH0t1MJ5WWH/fngadYc7c6KzM84ihQ66tJqJqyNQ=="
+        }
+      ]
+    }
+  ],
+  "runtimeIdentity": {
+    "source": "active-profile-package-graph",
+    "injectionConfigKeys": [
+      "hostLockPackages",
+      "hostLockPlatform",
+      "hostLockProfile"
+    ],
+    "missingBehavior": "fail-closed",
+    "cohortDigestBinding": "host_cohort capability row in hostLockDigest v3"
+  },
+  "lockPolicy": "dsh-core/v1",
+  "legacyCohorts": [
     {
       "id": "dsh-0.1.1-rc.2",
       "manifestVersion": 1,
@@ -1105,15 +1322,5 @@
         }
       ]
     }
-  ],
-  "runtimeIdentity": {
-    "source": "active-profile-package-graph",
-    "injectionConfigKeys": [
-      "hostLockPackages",
-      "hostLockPlatform",
-      "hostLockProfile"
-    ],
-    "missingBehavior": "fail-closed",
-    "cohortDigestBinding": "host_cohort capability row in hostLockDigest v3"
-  }
+  ]
 }