dsh-completion-guard 0.5.0 → 0.5.1

package/docs/COMPATIBILITY.md

@@ -2,9 +2,44 @@
 
 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.1 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.1 supports **DSH >= 0.1.5-rc.1** and nothing older. There is no
+backward compatibility: the previous Session V2 API, the V2 event vocabulary,
+and every older host cohort were removed rather than kept behind a fallback.
+`0.1.5-rc.1` is the version this release was implemented and tested against; it
+is the baseline, not a ceiling.
+
+Two separate judgments decide whether a host is usable, and neither replaces the
+other:
+
+1. **Version policy** — `src/domain/host-version.ts` orders host versions with
+   the SemVer prerelease rules. `peerDependencies` publish the range
+   `>=0.1.5-rc.1`; because a range cannot express "every future prerelease at
+   any base", the range is the conservative install-time statement and the
+   module is the explicit decision path. `0.1.4` and `0.1.5-alpha.9` are
+   refused. `0.1.6-rc.1` and `0.2.0-rc.1` order above the bound but do not
+   resolve from the published range and are not registered cohorts.
+2. **Host identity** — the exact 33-row DSH core graph must match one registered
+   cohort row for row. A newer host that has not been registered is reported as
+   unverified, never as supported: the version range alone never admits a graph.
+
+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 +67,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.1 targets DSH >= `0.1.5-rc.1` with `0.1.5-rc.1` 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 +83,15 @@ 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.1 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 **active** 0.5.1 cohort, with no dshmarket row.
 
 ## Rejection rules
 
@@ -106,7 +147,20 @@ 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.1 publishes one range per DSH package: `>=0.1.5-rc.1`, with Cordis `^4.0.2` (Cordis is versioned independently and unchanged at `4.0.2`). The range is the floor of the support policy, never a claim that any graph above it works: runtime acceptance still requires an exact injected host lock and atomic selection of one complete registered cohort.
+
+Two npm facts are worth stating plainly, because a bare `>=` reads stronger than it is:
+
+- A version carrying a prerelease resolves from `>=0.1.5-rc.1` only when its
+  `major.minor.patch` tuple is `0.1.5`. So `0.1.5-rc.2` and `0.1.5` resolve,
+  while `0.1.6-rc.1` and `0.2.0-rc.1` do not. Later `x.y.z` releases resolve
+  normally.
+- The development dependencies pin the exact `0.1.5-rc.1` packages this release
+  actually verified, so the tested baseline is recorded even though the peer
+  range is wider.
+
+Historical peer declarations belong to their own release sections above and are
+not part of the 0.5.1 contract.
 
 ## Terminal outcome contract
 
@@ -117,6 +171,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,36 @@ 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. **Windows is accepted for
+evaluation but has not been natively audited for this cohort**, so treat a
+Windows result as unverified until the native gate runs. 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 +71,35 @@ 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's active cohort is the DSH `0.1.5-rc.1` core graph, and its rows
+are the exact published npm tarball identities rather than a graph read off a
+running host. The cohort therefore records
+`auditProvenance: registry-derived-pending-native-audit` with an empty
+`auditedPlatforms` list, and that provenance is part of the digest. A lock
+generated from it can certify the bytes, but no certificate may describe it as
+a native pass. Reading the native gate as "not run" is the accurate reading.
+Every successful `inspect`, `inspect-graph`, `inject` and `verify-dump` readback
+prints the same value as `audit_provenance`, next to the cohort id and the
+digest, so you can tell which of the two you are holding without decoding the
+digest. (A failing command prints only a status and a reason code: no cohort was
+resolved, so there is no provenance to report.)
+
+**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,21 @@
 
 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 candidate scope
+
+The candidate 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 +32,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.1)
+
+Version 0.5.1 ports Guard onto DSH >= 0.1.5-rc.1 and keeps no path back to the
+older 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 active 0.1.5-rc.1
+cohort is registry-derived with its native audit still pending, 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/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"
+      ]
     }
   ]
 }