dsh-completion-guard 0.5.0 → 0.5.2

package/docs/COMPATIBILITY.md

@@ -2,9 +2,42 @@
 
 Compatibility is pinned to exact host package sets. A nearby version or a partial package match is not treated as supported.
 
-## 0.5.0 support policy
+## 0.5.2 support policy
 
-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.
+Version 0.5.2 supports exactly **DSH `0.1.5-rc.2` or `0.1.5-rc.1`**.
+These are the latest registered release and the verified minimum. There is no
+backward compatibility: the previous Session V2 API, the V2 event vocabulary,
+and every older host cohort remain removed.
+
+Two separate judgments decide whether a host is usable, and neither replaces the
+other:
+
+1. **Exact published set** — top-level `engines.dsh`, nested
+   `dsh.engines.dsh`, and every DSH peer dependency publish the newest-first
+   union `0.1.5-rc.2 || 0.1.5-rc.1`. Older versions, unregistered stable
+   `0.1.5`, and future releases are not advertised as supported. The minimum
+   comparison remains a diagnostic that distinguishes old hosts from newer but
+   unregistered hosts.
+2. **Host identity** — membership in the published set is not enough. The exact
+   33-row DSH core graph must match one registered cohort row for row. Missing,
+   mixed, or unknown graphs are reported as unsupported.
+
+If you are upgrading from a profile that ran DSH 0.1.2-rc.1, start a **new
+session**. Guard does not migrate V2 logs, proposals, or certificates, and old
+user data is never deleted or reinterpreted.
+
+### Exact rc.1 and rc.2 host sets
+
+The registered cohorts are `dsh-0.1.5-rc.1-core-v1` and `dsh-0.1.5-rc.2-core-v1`. Each contains 33 exact package identities from the corresponding npm release. A complete set must match atomically; mixing rc.1 and rc.2 rows fails closed.
+
+Both record `auditProvenance: registry-derived-pending-native-audit`, an empty `auditedPlatforms` list and `acceptedPlatforms` containing `posix` and `windows`. These fields describe the registry source of the shipped graph, not a live acceptance result. The provenance is included in `hostLockDigest`. Native acceptance must be established by a separate annex bound to the exact Guard artifact, host cohort and platform; a host-lock certificate alone is insufficient.
+
+Every older cohort — `0.1.1-rc.2`, `0.1.2-alpha.2`, the alpha.2 + dshmarket
+1.39.0 combination, `0.1.2-alpha.3`, and `0.1.2-rc.1` — stays in the shipped
+manifest and source registry as a historical identity so previously accepted
+annexes stay verifiable. An installed runtime built from one of them fails
+closed (`host_lock_version_mismatch`). No floating range and no alpha support is
+claimed.
 
 ## 0.4.3 core-lock policy
 
@@ -32,11 +65,11 @@ DSH is still a developer preview and may make breaking changes. Version 0.4.0 th
 - Audited platforms: native macOS/posix runtime, plus the native Windows rc.1 host graph verified on the live Windows host (host-lock inspect/inject, composed-config verify-dump, cold Web boot)
 - Evidence boundary: host-graph audits are source/runtime-level evidence and do not replace the cross-platform exact-artifact acceptance of one frozen package; unregistered host cohorts keep failing closed
 
-DSH rc.1 replaces the public `Session.events` getter with `snapshotEvents()` and `eventAt()`. The candidate uses `snapshotEvents()` when present and retains `events` only for older registered cohorts. The underlying Guard-consumed event vocabulary, flush path, Goal disarm, and `update_goal` contract remain unchanged by the focused upstream source audit.
+DSH rc.1 replaces the public `Session.events` getter with `snapshotEvents()` and `eventAt()`. The 0.4.1-rc.1 candidate used `snapshotEvents()` when present and retained `events` for older registered cohorts. **Superseded by 0.5.1**, which supports only the Session V3 API and refuses a session that does not expose `snapshotEvents()`; the historical fallback no longer exists in the shipped plugin. The flush path, Goal disarm, and `update_goal` contract noted here still hold.
 
 ## Upstream adaptation policy
 
-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.
+Version 0.5.2 advertises only DSH `0.1.5-rc.2` and `0.1.5-rc.1`, with rc.1 retained as the implemented and tested baseline; 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 registered cohort with source, CI, and native acceptance. The upstream [tags page](https://github.com/deepseek-ai/deepseek-harness/tags) tracks later releases. The host-side API differences that this adaptation had to absorb are listed in the repository's upstream API audit (`UPSTREAM_API_AUDIT.md` at the repository root), which is a maintainer document and is not part of the published package.
 
 ## Platform and release evidence
 
@@ -48,9 +81,16 @@ Version 0.5.0 targets DSH `0.1.2-rc.1`; alpha releases are observed for trend on
 
 ## Historical compatibility cohorts
 
+These are verification records, not support entries. An installed runtime built
+from any of them fails closed under the 0.5.2 policy.
+
 - DSH `0.1.1-rc.2` + dshmarket `1.36.0` + Cordis `4.0.1` is a retained, published-line cohort.
 - DSH `0.1.2-alpha.2` + dshmarket `1.38.1` + Cordis `4.0.2` is the published 0.3.2 cohort checked natively on macOS and Windows.
 - DSH `0.1.2-alpha.2` + dshmarket `1.39.0` + Cordis `4.0.2` remains a deterministic compatibility cohort. It is no longer a native 0.4.0 release blocker.
+- DSH `0.1.2-alpha.3` + dshmarket `1.39.0` + Cordis `4.0.2` is the recorded 0.4.0 release baseline.
+- DSH `0.1.2-rc.1` + dshmarket `1.41.0` + Cordis `4.0.2` is the 0.4.1-rc.1 / 0.5.0 cohort, checked natively on macOS and Windows.
+- DSH `0.1.5-rc.1` + Cordis `4.0.2` is the verified minimum 0.5.2 cohort, with no dshmarket row.
+- DSH `0.1.5-rc.2` + Cordis `4.0.2` is the latest 0.5.2 cohort, with no dshmarket row.
 
 ## Rejection rules
 
@@ -106,7 +146,16 @@ The ordinary runtime packages are host-provided peers:
 
 Goal support uses two exact optional peers as one capability. `@deepseek-ai/dsh-goal` owns Goal state, while `@deepseek-ai/dsh-tool-goal` owns the audited `update_goal` name, schema, and arguments. Both host-graph rows and the live Goal service and tool must agree. A profile without this complete pair can still load, but Goal-dependent integration stays inactive.
 
-Peer ranges accept only the registered DSH version lines: `0.1.1-rc.2 || 0.1.2-alpha.2 || 0.1.2-alpha.3 || 0.1.2-rc.1`, with Cordis `4.0.1 || 4.0.2`. These are not floating support claims. Runtime acceptance still requires an exact injected host lock and atomic selection of one complete cohort.
+Version 0.5.2 publishes `0.1.5-rc.2 || 0.1.5-rc.1` in top-level
+`engines.dsh`, nested `dsh.engines.dsh`, and every DSH peer dependency. Cordis
+is versioned independently and remains `^4.0.2`. Plugin markets and package
+managers therefore see the same two exact host releases as the host-lock
+registry; neither an unregistered stable release nor a future version is
+implicitly admitted.
+
+The development dependencies retain exact `0.1.5-rc.1` pins as the build
+baseline. Historical peer declarations belong to their own release sections
+above and are not part of the 0.5.2 contract.
 
 ## Terminal outcome contract
 
@@ -117,6 +166,17 @@ exit; it does not append `[exit code: 0]`. Version 0.1.1 therefore accepts an
 unmarked completed foreground `bash` result as successful evidence, matching the
 existing `pwsh` behavior.
 
+Version 0.5.1 re-checked that rule against the shipped 0.1.5-rc.1 renderer
+sources. The two session renderers registered by `@deepseek-ai/dsh-base`
+(`dsh-tool-bash`, `dsh-tool-pwsh`) append a marker only for negative facts and
+non-zero exits in both host versions, so an unmarked completed foreground
+result stays a clean success **for those two names under a supported host
+lock**. The out-of-bundle persistent renderer gained two markers in 0.1.5-rc.1 —
+`[Command finished with exit code N]` and `[Command timed out or OOM]` — and
+both are now classified explicitly, so a persistent result is read by its own
+marker instead of falling through to the unmarked rule. That package is not in
+the registered cohort, so such a host also fails the whole graph lock closed.
+
 This does not make arbitrary shell text authoritative. A result-level error or
 negative terminal marker wins over output text; background commands remain
 unknown; and the generic `shell` alias remains unknown without an explicit exit

package/docs/HOST_LOCK_UPGRADE.md

@@ -29,14 +29,34 @@ GUARD_HOST_LOCK="$DSH_PROFILE_ROOT/node_modules/.bin/dsh-completion-guard-host-l
 dsh --profile web --dump-config | "$GUARD_HOST_LOCK" verify-dump --runtime-root "$DSH_RUNTIME_ROOT" --profile-root "$DSH_PROFILE_ROOT" --dump-config -
 ```
 
+**Run this block after the runtime is already on the target DSH version, not
+before.** `inject` records the absolute runtime and profile roots and binds the
+graph it finds there, and runtime replay re-reads those same roots. Injecting
+against the old runtime therefore writes a lock that describes a graph the new
+runtime no longer has, and it will fail on the next replay. Order: upgrade the
+runtime, restart it, then inspect/inject/verify.
+
+`inject` **writes to `<profile>/cordis.patch.yml`** — it replaces or adds Guard's
+managed block in that file. Back the file up first. The same file is the one
+`docs/LOCAL_ACCEPTANCE.md` tells you to preserve.
+
+**Read the verdict from the JSON body, not from the exit status.** All three
+commands print a JSON object whose `status` is the verdict — `supported`,
+`unsupported` or `unavailable` — together with `cohort_id`, `host_lock_digest` and
+`audit_provenance`. Note that `inspect`, `inject` and `verify-dump` exit **0** even
+when that status is `unsupported`; only `inspect-graph` exits non-zero on an
+unsupported graph, and only a thrown error produces `status: "unavailable"` with a
+`reason_code` on stderr and exit 1. So a shell check of `$?` alone will not tell
+you whether the graph was accepted.
+
 For Headless, use its profile path and `--profile headless`. On Windows, use the
-installed `.cmd` launcher and Windows absolute paths. A strict repeat leaves
+installed `.cmd` launcher and Windows absolute paths. The published 0.5.1 artifact passed separate native macOS and Windows acceptance on DSH `0.1.5-rc.2`; see the [acceptance record](LOCAL_ACCEPTANCE.md). That result does not cover other artifacts or host versions. 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.
+A DSH `0.1.5-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.
 
@@ -49,9 +69,26 @@ 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
+Version 0.5.1 registers separate DSH `0.1.5-rc.1` and `0.1.5-rc.2` core graphs. Their package identities come from exact published npm tarballs. The immutable package records `auditProvenance: registry-derived-pending-native-audit` and an empty `auditedPlatforms` list; this provenance is part of the lock digest.
+
+The later macOS and Windows native runs on rc.2 are recorded in the [0.5.1 release annexes](https://github.com/GreenLv/dsh-completion-guard/releases/tag/v0.5.1). They establish native acceptance for that artifact and host version without modifying its registry or digest. A lock readback by itself proves the registered graph match, not a native run. Successful inspection, injection and dump verification report `audit_provenance` alongside the cohort and digest; a failed check reports only its status and reason.
+
+**Which failure code you see depends on the lock generation you are holding**, and
+that matters for deciding whether you are migrating or just drifting:
+
+- A **pre-0.4.3** lock — no `hostLockPolicy: dsh-core/v1`, or no recorded
+  runtime/profile roots — reports `host_lock_migration_required`. Removing its
+  market row by hand is not migration. Reinspect, inject and verify the actual
+  environment.
+- A **0.4.3-or-later** lock already carries the policy and the roots, so it never
+  reports `host_lock_migration_required`. It reports the mismatch instead:
+  `host_lock_version_mismatch` when the installed core package versions differ from
+  the cohort, or `host_lock_installed_graph_drift` when the re-read graph resolves
+  to a different digest than the lock recorded. Both are the expected answers after
+  a DSH upgrade, and both are cured by re-running inspect, inject and verify against
+  the new runtime rather than by editing the lock.
+
+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.
 

package/docs/LOCAL_ACCEPTANCE.md

@@ -2,13 +2,31 @@
 
 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.
 
+## 0.5.1 published release (2026-09-11)
+
+[Version 0.5.1](https://github.com/GreenLv/dsh-completion-guard/releases/tag/v0.5.1) is published on GitHub and [npm](https://www.npmjs.com/package/dsh-completion-guard/v/0.5.1). The annotated tag and npm `gitHead` identify commit `aefdeaf2737ef1c99f1170085140c93a515e1125`. The frozen 303460-byte, 27-file tgz has SHA-256 `5e00ddf2f9772b1ae2ca3665d7c4ce858b814dc26a4116388082db2d625da28d`.
+
+The local deterministic matrix and [exact-candidate portability CI](https://github.com/GreenLv/dsh-completion-guard/actions/runs/34553623984) passed. Separate macOS and Windows runs on DSH `0.1.5-rc.2` each passed all 28 required host-bound gates for these same bytes, with cleanup passed. Both annexes retain the `real_model_request` skip; no real-model task is claimed. These isolated runs do not establish daily-profile adoption or native acceptance on rc.1.
+
+Anonymous public readback verified the annotated tag target, npm version and `latest` tag, embedded `gitHead`, registry integrity and downloaded tgz bytes. All seven GitHub Release attachments matched the accepted files: the tgz, checksum, artifact manifest, and separate native annexes and transfer receipts for macOS and Windows. The packaged registry provenance remains `registry-derived-pending-native-audit`; the later native results are carried by the exact-artifact annexes, not by a changed host-lock digest.
+
+This section and the updated main-branch installation guidance are post-release documentation. The published tag and npm package retain their original bytes.
+
+## 0.5.1 validation scope
+
+The release supports exact DSH `0.1.5-rc.1` and `0.1.5-rc.2` core graphs. Development tests retain the rc.1 baseline; rc.2 graph tests additionally reject missing, mixed, forged and unregistered package identities. Dependency-free Headless preflight selects the matching registered cohort and checks its launcher version.
+
+Candidate results are recorded outside packaged documents after the source and package bytes are frozen. Require the local deterministic matrix, exact-candidate portability CI, and separate macOS and Windows native annexes for the same frozen tgz. An earlier rc.1 artifact's result does not establish acceptance of an artifact that adds rc.2 support. Real-model behaviour, daily profile adoption and publication remain separate gates.
+
+The shipped graphs retain their registry-derived provenance in the host-lock digest. Read a matching native annex for platform acceptance; the provenance field alone establishes neither a native pass nor a failed native run.
+
 ## Host-bound acceptance for the 0.4.3 line
 
 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 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.
+Supplied daily target paths use the [read-only installation preflight](HOST_LOCK_UPGRADE.md#check-a-headless-profile-before-installation). A dependency-free `0.1.5-rc.1` or `0.1.5-rc.2` 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.
 
@@ -24,7 +42,7 @@ The driver creates a new temporary DSH_HOME, explicit temporary HOME/USERPROFILE
 
 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 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.
+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; the historical v1/v2 profiles and the current v3 profile are not interchangeable. A consumer that provides the explicit `dsh-host-bound/v3` 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.
 

package/docs/PORTING_NOTES.md

@@ -15,6 +15,28 @@ fixtures and an explicit delta ledger.
 | portable protocol and digest fixtures | Mirror exact upstream bytes and verify their hashes |
 | product-specific or newer Codex behavior | Record explicitly in the delta ledger before porting |
 
+## Current host boundary (0.5.2)
+
+Version 0.5.2 admits exactly DSH `0.1.5-rc.2` and `0.1.5-rc.1` and keeps no path back to the
+older host or ahead to an unregistered host. Concretely:
+
+- Session history is read only through the DSH Session V3 `snapshotEvents()`
+  API. The V2 `events` getter is gone, and a session that does not expose the
+  V3 API is refused instead of being treated as an empty log.
+- Dispatch evidence comes from the current `tool/ptc-dispatch-start` and
+  `tool/ptc-dispatch` vocabulary. The retired `tool/code-dispatch*` names are
+  ignored, so an old log cannot mint evidence under the new protocol.
+- A V3 `system/message` is a plugin-sourced surface node, never root
+  authority, and a compaction checkpoint message stays plugin context.
+- Guard never resumes a Goal the user paused: its Goal access surface has no
+  resume entry point, and turn stopping yields while a Goal is paused, blocked,
+  completed, or not yet read back.
+
+The host identifier is the exact 33-row DSH core graph. The rc.1 verified-minimum
+and rc.2 latest cohorts are registry-derived, and that
+provenance is bound into the host-lock digest rather than inferred from a
+version number.
+
 The DSH port derives guard state from native DSH session events, connects the
 completion gate to Goal handling, and fails closed when it cannot verify the
 host or evidence. Version 0.3.2 has passed same-package Web and Headless

package/docs/SEMANTIC_COMPATIBILITY.md

@@ -79,6 +79,30 @@ event vocabulary `root_message`, `delegated_message`, `tool_result`,
 runner executes every mirrored case without skips and compares the bounded
 result contract; it does not translate a missing capability into a pass.
 
+## 0.5.1 host adaptation note (2026-09-10)
+
+The DSH host moved from Session format 0 to format 3 under Guard 0.5.1. That is
+a host-side change, and one part of it touches a shared asset: the
+session-identity digest input.
+
+DSH Session V3 moved the fork-inherited prefix length out of the session header
+(`seedLength`) onto the Session itself (`inheritedEventCount`). Guard feeds that
+same durable value into the existing `seedLength` token and leaves the
+`ccg.sessionRefDigest.v3` domain unchanged, so **every byte-mirrored digest
+vector still reproduces identically** and no re-mirror is required. V3's
+`header.isSeeded` marker was deliberately left out of the shared domain: an
+absent optional field still encodes a presence-0 row, so adding it would change
+every digest and silently invalidate the pinned parity evidence. The decision,
+its root cause, and its impact boundary are recorded in
+[`upstream-deltas.json`](upstream-deltas.json).
+
+Everything else in the host adaptation is host-specific and stays out of the
+shared fixture: the V2→V3 event vocabulary, the required `surfaceOp` metadata,
+the renamed PTC dispatch events, the terminal renderer markers of 0.1.5-rc.1,
+and the registry-derived host cohort. The maintainer document
+`UPSTREAM_API_AUDIT.md` at the repository root records those differences; it is
+not part of the published package.
+
 ## Recorded 0.4.0 alignment status (2026-09-03)
 
 The semantic implementation described here entered the DSH `0.4.0` line from implementation baseline `ffc6fe9e1246a815f0bb630943c59d14b6505716`. The shared-contract reference is the Codex `0.10.0` source at `e4fccf690bcbc2be79d0b8d42a1a269f87072120`; this covers only the named contracts, not full product parity. Exact release commit, artifact, native-platform, and publication identities are recorded outside this semantic document because each is a separate evidence scope.

package/docs/distribution.md

@@ -25,16 +25,22 @@ version and annotated tag are retained for audit history; the npm version is
 deprecated with `Release metadata incomplete; use dsh-completion-guard@0.3.1.`
 Version 0.3.1 repairs the provenance-bearing frozen-package workflow.
 
-## Published v0.4.0 destinations
+## Published v0.5.1 destinations (2026-09-11)
+
+1. [GitHub Release `v0.5.1`](https://github.com/GreenLv/dsh-completion-guard/releases/tag/v0.5.1) is a non-draft, non-prerelease release. Its annotated tag identifies commit `aefdeaf2737ef1c99f1170085140c93a515e1125`.
+2. [`dsh-completion-guard@0.5.1` on npm](https://www.npmjs.com/package/dsh-completion-guard/v/0.5.1) is published and `latest` resolves to `0.5.1`. Its `gitHead` equals that release commit. The registry download and Release tgz match SHA-256 `5e00ddf2f9772b1ae2ca3665d7c4ce858b814dc26a4116388082db2d625da28d`.
+3. All seven Release attachments were downloaded and matched the accepted files. The separate macOS and Windows annexes each record 28 required gates passed on DSH `0.1.5-rc.2`, with real-model requests skipped. See [acceptance details](LOCAL_ACCEPTANCE.md).
+
+## Historical v0.4.0 destinations
 
 1. [GitHub Release `v0.4.0`](https://github.com/GreenLv/dsh-completion-guard/releases/tag/v0.4.0)
-   is the latest non-draft, non-prerelease release. Its annotated tag peels to
+   remains a historical non-draft, non-prerelease release. Its annotated tag peels to
    release commit `d5cd0ca17833d05bfdf41457ae203864bde8056b`. The Release
    carries the frozen tgz, checksum, artifact manifest, and separate macOS and
    Windows native-acceptance annexes. The tgz has SHA-256
    `71ce205dedeffe72566ad399e001f0b337d057cede297e1d2249acec67cde1f2`.
 2. [`dsh-completion-guard@0.4.0` on npm](https://www.npmjs.com/package/dsh-completion-guard/v/0.4.0)
-   is published and `latest` resolves to `0.4.0`. The registry `gitHead`
+   remains published. The registry `gitHead`
    equals the release commit, and a fresh registry download is byte-identical
    to the frozen Release tgz.
 3. Source commit, candidate/main/tag CI, native macOS and Windows acceptance,
@@ -83,9 +89,9 @@ install target.
 
 | Channel | Entry | Status | Evidence |
 |---|---|---|---|
-| [awesome-dsh-plugin](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin) | `GreenLv/dsh-completion-guard` (category `security`) | Listed | Added via [PR #3693](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin/pull/3693) (merge commit `299f0b5c`, 2026-08-29). The shorter plain-language English and Chinese descriptions merged via [PR #3977](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin/pull/3977) (merge commit `bdf5145`, 2026-09-01) and were read back from the current generated READMEs, source YAML, and public [`plugins.json`](https://awesome-dsh-plugin.com/plugins.json). The detail page still showed the earlier wording and GitHub install command at readback, so that page refresh remains pending. Screenshots are declared in this repository's [`screenshots.json`](../screenshots.json); image changes do not need a listing PR. |
-| [dsh-market](https://dsh-market.com/) | `dsh-completion-guard` (Tools / Development workflow) | Listed | Added via [PR #1285](https://github.com/zhu1090093659/dsh-web/pull/1285) (merge commit `be426da`, 2026-08-31); read back on 2026-09-01 from the public [`manifest/plugins.json`](https://dsh-market.com/manifest/plugins.json) at rank 51. The market reads the listing text from its community index; npm download counts and likes are updated separately by the site. |
-| [Awesome DeepSeek Harness](https://github.com/Dominic789654/awesome-deepseek-harness#security--permissions) | `GreenLv/dsh-completion-guard` | Listed | Rows merged via [PR #332](https://github.com/Dominic789654/awesome-deepseek-harness/pull/332) (merge commit `ba414c4`, 2026-08-29) and read back live the same day from both generated READMEs (`README.md` line 940, `README.zh-CN.md` line 946), under **Security & Permissions** alongside the other fail-closed gates and verifier plugins. |
+| [awesome-dsh-plugin](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin) | `GreenLv/dsh-completion-guard` (category `security`) | Listed | Added via [PR #3693](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin/pull/3693) (merge commit `299f0b5c`, 2026-08-29). The shorter plain-language English and Chinese descriptions merged via [PR #3977](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin/pull/3977) (merge commit `bdf5145`, 2026-09-01) and were read back from the current generated READMEs, source YAML, and public [`plugins.json`](https://awesome-dsh-plugin.com/plugins.json). On 2026-09-11, the detail page showed the updated bilingual description and npm install command. Its embedded README still described 0.4.0 and the public index version remained 0.4.3; those generated caches await the directory publisher's refresh. Screenshots are declared in this repository's [`screenshots.json`](../screenshots.json); image changes do not need a listing PR. |
+| [dsh-market](https://dsh-market.com/) | `dsh-completion-guard` (Tools / Development workflow) | Listed | Added via [PR #1285](https://github.com/zhu1090093659/dsh-web/pull/1285) (merge commit `be426da`, 2026-08-31); read back on 2026-09-01 from the public [`manifest/plugins.json`](https://dsh-market.com/manifest/plugins.json) at rank 51. A browser readback on 2026-09-11 confirmed the Completion Guard detail page, matching bilingual description, repository identity and unversioned npm install command. The market reads the listing text from its community index; npm download counts and likes are updated separately by the site. |
+| [Awesome DeepSeek Harness](https://github.com/Dominic789654/awesome-deepseek-harness#security--permissions) | `GreenLv/dsh-completion-guard` | Listed | Rows merged via [PR #332](https://github.com/Dominic789654/awesome-deepseek-harness/pull/332) (merge commit `ba414c4`, 2026-08-29) and read back live the same day from both generated READMEs (`README.md` line 940, `README.zh-CN.md` line 946), under **Security & Permissions** alongside the other fail-closed gates and verifier plugins. The English source README still contained the matching version-independent entry on 2026-09-11. |
 
 ## Update route
 

package/docs/upstream-deltas.json

@@ -1,7 +1,7 @@
 {
   "ledgerVersion": "2",
   "description": "Current, evidence-bounded delta ledger for behavior shared between codex-context-guard and dsh-completion-guard. It separates aligned behavior, partial host-native equivalents, missing shared behavior, and Codex-only lifecycle features.",
-  "updatedAt": "2026-09-03",
+  "updatedAt": "2026-09-10",
   "source": {
     "product": "codex-context-guard",
     "currentRelease": "v0.11.0",
@@ -11,10 +11,10 @@
   },
   "target": {
     "product": "dsh-completion-guard",
-    "currentRelease": "v0.4.0",
-    "currentReleaseHead": "d5cd0ca17833d05bfdf41457ae203864bde8056b",
+    "currentRelease": "v0.5.1",
+    "currentReleaseHead": "uncommitted candidate on 09df9ecfdc94d7880ddabb37774e626486aca972",
     "implementationBaseline": "ffc6fe9e1246a815f0bb630943c59d14b6505716",
-    "host": "DSH 0.1.2-alpha.3 / dshmarket 1.39.0 / Cordis 4.0.2"
+    "host": "DSH 0.1.5-rc.1 / Cordis 4.0.2 (registry-derived cohort; native audit pending)"
   },
   "alignmentClaim": "DSH 0.4.0 aligns the named evidence and proof obligations with Codex 0.10.0. It does not claim full product parity and does not include all Codex 0.11.0 changes.",
   "dispositions": [
@@ -113,6 +113,32 @@
       "plainLanguage": "Codex Hook trust, plugin-cache recovery, and the Codex installer do not exist in the DSH host model.",
       "implementation": "DSH uses Cordis bundles, DSH profiles, host-lock checks, and DSH-native lifecycle events. Shared safety behavior must be adapted through those mechanisms rather than copied.",
       "tests": []
+    },
+    {
+      "capability": "session-identity-digest-across-host-format-bump",
+      "introducedBy": "dsh-completion-guard v0.5.1 (host adaptation: DSH Session V2 -> V3)",
+      "disposition": "aligned",
+      "targetRelease": "dsh-completion-guard v0.5.1",
+      "plainLanguage": "The shared session-identity digest keeps one meaning even though the host moved where it stores the inherited-prefix length, so certificates from either side stay comparable.",
+      "implementation": "DSH Session V3 moved the fork-inherited prefix length from SessionHeader.seedLength to Session.inheritedEventCount. Guard feeds that same durable value into the existing seedLength digest token and leaves the ccg.sessionRefDigest.v3 domain unchanged. V3 header.isSeeded is deliberately NOT added as a digest input: an absent optional field still encodes a presence-0 row, so adding it would change every digest and break the byte-mirrored vectors upstream. Identity remains bound by id, createdAt, parentSession, seedLength, delegationDepth, origin and formatVersion, and a non-V3 header is refused before hashing.",
+      "impactBoundary": "No shared fixture byte changes; all 29 mirrored digest_v3 vectors still reproduce identically. Cross-repository parity therefore needs no re-mirror for this round. If upstream later wants isSeeded inside the shared domain, that is a new shared-semantics decision requiring a new fixture family and a joint re-pin.",
+      "tests": [
+        "tests/domain/digest-v3.test.ts",
+        "tests/domain/v051-dsh015-adaptation.test.ts"
+      ]
+    },
+    {
+      "capability": "turn-boundary-continuation-ownership",
+      "introducedBy": "dsh-completion-guard v0.5.1 (host fact: DSH 0.1.5-rc.1 pauses a Goal immediately and only a human resume re-arms it)",
+      "disposition": "partial-equivalent",
+      "targetRelease": "dsh-completion-guard v0.5.1",
+      "plainLanguage": "When no Goal is running, the shared rule for whether a turn may be continued is unchanged. When a Goal exists and is paused, blocked, completed, or not yet read back, the DSH product yields instead of continuing, because only the user may restart paused work.",
+      "implementation": "decideTurnBoundary is part of the portable production surface. Guard 0.5.1 added one guard before the root-persistence correction steer: if projection.currentGoalRef is set but the Goal is not the active+armed continuation owner, the decision is stop with goal_paused_by_user_safe_yield (paused) or goal_not_continuable_safe_yield (blocked, complete, or phase not yet read back). Guard's Goal access exposes only get and disarm; there is no resume entry point anywhere in the plugin.",
+      "impactBoundary": "All 37 mirrored portable cases behave identically: exactly one case uses force_continue (stop-protocol-correction-once) and it carries no Goal reference, so the shared continuation path is untouched. The divergence is confined to an input state the Codex product has no equivalent for, which is why the two new reason codes are deliberately NOT added to the mirrored reasonCodeVocabulary — that fixture is a byte mirror and describes the shared contract, while these are host-specific stop reasons. No mirrored byte changed. There is no fixture self-check that would force the vocabulary to grow.",
+      "tests": [
+        "tests/domain/portable-semantics.test.ts",
+        "tests/domain/v051-dsh015-adaptation.test.ts"
+      ]
     }
   ]
 }