# Compatibility

Guard binds each accepted installation to its exact package identities, implementation bytes and dependency routes. Version admission and implementation qualification are separate checks; a matching version alone does not establish compatibility.

## 0.12.1 and the 0.12.0 host cohort

Guard 0.12.1 retains the same DSH and Cordis admission ranges and the reviewed host cohorts below. The patch changes the activation migration toolkit to verify retained generations of a session before adopting its previous mode. New acceptance records must identify the 0.12.1 artifact.

Guard 0.12.1 沿用下文的 DSH、Cordis 准入范围和宿主审查队列。本次修复在采纳旧启用模式前逐代核验保留的会话日志。新验收记录须绑定 0.12.1 制品。

## 0.12.0: DSH >=0.2.1-rc.3

Before installing Guard 0.12.0, upgrade DSH if it is older than `0.2.1-rc.3`. The package declares the same minimum in `engines.dsh`, `dsh.engines.dsh` and its DSH peers; Guard enforces that floor independently at runtime. There is no upper version bound, but every later graph must still pass package, byte, route and contract qualification. Cordis keeps its separate `>=4.0.4` range.

The current reviewed baseline and default cohort are DSH `0.2.1-rc.5` / Cordis `4.0.5` (`dsh-0.2.1-rc.5-core-v1`). An rc.3 runtime uses its own reviewed `dsh-0.2.1-rc.3-core-v1` cohort; rc.2 is below the floor. Earlier acceptance records retain their original subjects and do not establish acceptance of this package. Existing session and Guard data protocols are preserved, while changed host locks require fresh checks. The official app-boot admission tests and [`semver-matrix-v120.json`](../benchmarks/incidents/acceptance/semver-matrix-v120.json) bind the declared floor; the 0.11.0 matrix remains unchanged for that release.

The rc.5 registry and Desktop implementation records below describe their own source qualification. A new Guard package still needs its own CI, exact-artifact native, model and UI/performance evidence; the version floor does not transfer an earlier package's acceptance.

安装 Guard 0.12.0 前，低于 `0.2.1-rc.3` 的 DSH 须先升级。包顶层、嵌套 DSH 声明和 DSH peer 范围使用同一下限，Guard 运行时也独立核对；没有版本上限，后续宿主仍须逐项核验包身份、实现字节、依赖路由和接口。Cordis 继续单独要求 `>=4.0.4`。

当前已审查基线及默认 cohort 为 DSH `0.2.1-rc.5` / Cordis `4.0.5`。rc.3 宿主使用自己的 `dsh-0.2.1-rc.3-core-v1` 审查队列；rc.2 仍低于下限。旧验收记录保留原有对象，不能代替本包的验收。旧会话及 Guard 数据协议保持兼容，宿主锁变化后仍须重新核验；新包的 CI、精确制品原生验收、模型及 UI/性能结果分别记录，不从旧包继承。

### The rc.3→rc.5 cumulative study

The rc.5 manifest was regenerated from the published `0.2.1-rc.5` tarballs (upstream `dsh-v0.2.1-rc.5`, commit `b830ec950faba0a46dda564be3e2d854afed94f1`). The cumulative `dsh-v0.2.1-rc.3..dsh-v0.2.1-rc.5` study covered all 13 upstream commits and 388 changed files: the only non-manifest changes are client-UI thinking-block rendering (`ui-chat`, `ui-conversation`, `client-ui-cot-translation`, the `cordis-client-runner` slot-catalog source lines) and two ACP stdout diagnostics reroutes (`dsh-mcp-client` resource gating, `dsh-llm-deepseek-account` info logging to stderr) — none of them Guard-consumed interfaces. Per-file digest comparison found ZERO executable-byte changes across the 47-name core cohort (only rewritten `package.json` manifests), and the registry manifests' dependency routing is structurally unchanged between rc.3 and rc.5; Cordis remains the shared 4.0.5 release. Host trust acquisition selects the equivalence baseline by the acquired graph's version (rc.2, rc.3 or rc.5) and accepts a loading/modules match only from ONE reviewed published state. Native acceptance of the final Guard artifact on each platform remains a separate gate; no native validation of rc.5 is claimed by this study.

rc.3→rc.5 累计研究覆盖全部 13 个上游提交与 388 个变更文件：非 manifest 变更只有客户端 UI 思考块渲染与两处 ACP stdout 诊断改道，均不属于 Guard 消费接口。47 包核心闭包可执行字节逐文件比对为零变化，依赖路由结构不变，Cordis 仍为共享的 4.0.5。宿主信任获取按已获取图的版本（rc.2/rc.3/rc.5）选择等价基线，且 loading 与 modules 必须来自同一已审查发布状态。最终制品的各平台原生验收仍是独立门槛。

### Official rc.5 Desktop distribution bytes

The official `0.2.1-rc.5` Desktop distributions have separately registered `darwin-arm64` and `win32-x64` identities. On macOS, the official CDN package SHA-512 was recorded, `codesign --verify --deep --strict` passed (TeamIdentifier `NAN929V4UM`, identifier `com.deepseek.dsh`), and the recomputed ASAR header matches the independently verified installed app. On Windows, both the installed carrier and retained installer have valid DeepSeek Authenticode signatures; the signed `ElectronAsar/Integrity` resource matches the measured ASAR header, and the retained installer size and SHA-512 match the separately acquired official distribution. Both desktop/runtime manifests report rc.5 with pnpm 11.28.5, and actual ASAR/runtime index scans found no invariant companions. The rc.3/rc.2 pins are not reused. Distribution registration does not establish Guard installation, lifecycle, real-model or UI performance acceptance; those remain separate gates. An unregistered distribution still fails closed.

`0.2.1-rc.5` 的官方 macOS arm64 与 Windows x64 分发行分别登记身份。macOS 侧核对官方 CDN 包 SHA-512，并通过厂商 `codesign --verify --deep --strict`（TeamIdentifier `NAN929V4UM`）；Windows 侧读取已安装载体和保留安装器的有效 DeepSeek Authenticode 签名。两端签名绑定的 ASAR header 均与实测值一致；Windows 安装器的大小、SHA-512 也与独立获取的官方分发包一致。两端 desktop/runtime manifest 均为 rc.5、pnpm 11.28.5，实际索引扫描未发现 invariant 伴随文件。rc.3/rc.2 pin 不复用。分发行登记不代表 Guard 安装、生命周期、真实模型或 UI 性能已验收；未登记的分发行仍按失败关闭拒绝。

## 0.11.0: DSH >=0.2.1-rc.3 (historical for this release)

Upgrade DSH to `0.2.1-rc.3` or later before installing Guard 0.11.0. The package declares the same minimum in `engines.dsh`, `dsh.engines.dsh` and its DSH peers; Guard enforces that floor independently at runtime. There is no upper version bound, but every later graph must still pass package, byte, route and contract qualification. Cordis keeps its separate `>=4.0.4` range.

The current reviewed baseline and default cohort are DSH `0.2.1-rc.3` / Cordis `4.0.5` (`dsh-0.2.1-rc.3-core-v1`). The rc.2 audit files, distribution pins and prior acceptance records remain historical evidence; they do not admit an rc.2 runtime into this release. Existing session and Guard data protocols are preserved, while changed host locks require fresh checks. The official app-boot admission tests and [`semver-matrix-v110.json`](../benchmarks/incidents/acceptance/semver-matrix-v110.json) bind the new floor; the older matrix remains unchanged for 0.10.0.

The rc.3 registry and Desktop implementation records below describe their own source qualification. A new Guard package still needs its own CI, exact-artifact native, model and UI/performance evidence; raising this floor does not transfer an earlier package's acceptance.

安装 Guard 0.11.0 前，请先将 DSH 升级到 `0.2.1-rc.3` 或更高版本。包顶层、嵌套 DSH 声明和 DSH peer 范围使用同一下限，Guard 运行时也独立核对；没有版本上限，后续宿主仍须逐项核验包身份、实现字节、依赖路由和接口。Cordis 继续单独要求 `>=4.0.4`。

当前已审查基线及默认 cohort 为 DSH `0.2.1-rc.3` / Cordis `4.0.5`。rc.2 的审计文件、分发行身份与旧验收记录原样保留，但不再作为本版运行准入。旧会话及 Guard 数据协议保持兼容，宿主锁变化后仍须重新核验；新包的 CI、精确制品原生验收、模型及 UI/性能结果分别记录，不从旧包继承。

## 0.10.0: DSH >=0.2.1-rc.2

0.10.0 raises the host floor to `0.2.1-rc.2` (upstream release `dsh-v0.2.1-rc.2`, commit `687f282e8625c6b8d11ff58211a90524be2e4317`, cumulative over `0.2.1-rc.1`). There is no upper bound: later RCs on any tuple, stable and future releases pass VERSION ADMISSION and must still pass the graph, byte, route and contract audits. `0.2.0-rc.2`, `0.2.0` and `0.2.1-rc.1` keep their recorded-evidence rows but are refused as below the floor. Cordis keeps a separate `>=4.0.4` peer range and qualification (the reviewed baseline moved to Cordis `4.0.5` with the same range).

The reviewed host baselines are DSH `0.2.1-rc.2` and DSH `0.2.1-rc.3` (both over Cordis `4.0.5`), with 47 package identities and published implementation digests in `manifests/rc021-rc2-byte-audit.json` and `manifests/rc021-rc3-byte-audit.json` (cohort ids `dsh-0.2.1-rc.2-core-v1` and `dsh-0.2.1-rc.3-core-v1`). The rc.3 manifest was regenerated from the published `0.2.1-rc.3` tarballs (upstream `dsh-v0.2.1-rc.3`, commit `1f81c047fc48fa190a683e469daa699857e9afe8`); the rc.2→rc.3 cohort study verified per-package registry SRI and found ZERO executable-byte changes across the 47-name core cohort — the rc.3 functional commits touch only UI/model-listing packages outside this cohort — with manifest diffs limited to version and dependency-field rewrites. Host trust acquisition selects the equivalence baseline by the acquired graph's version and accepts a loading/modules match from either reviewed state. Native acceptance of the final Guard artifact on each platform remains a separate gate; no native validation of rc.3 is claimed.

### Official Desktop distribution bytes

Official `0.2.1-rc.3` Desktop distributions for macOS arm64 and Windows x64 have independent registered identities, verified using vendor signatures, signed ASAR headers and official updater archive digests. The rc.2 pins are not reused. Distribution registration does not establish Guard installation, lifecycle, real-model or UI performance acceptance; those remain separate gates. An unregistered distribution still fails closed.

The official Desktop `0.2.1-rc.2` distribution retains generated `lib/types/invariant.js` companions that the npm packages no longer contain. Guard does not load these companions. Desktop qualification additionally checks the exact released archive identities and eight critical-package file tuples in [`desktop-distribution.v1.json`](../manifests/desktop-distribution.v1.json). Each program was independently reproduced from the fixed upstream source before its removal; the manifest keeps that public source pin separate from the application's declared build identity. The local ASAR hash table cannot authorize extra code. The carrier must pass vendor-signature verification, the authenticated ASAR header must match a registered platform distribution, and registry bytes and active dependency routes must still pass their existing audits. Unknown files, changed bytes, versions, headers or routes are refused. Ordinary registry runtime qualification is unchanged. A new Desktop build requires qualification of its own bytes even when its version string is unchanged.

Desktop's physical hoisted profile reader accepts the observed pnpm `11.7.0` and `11.28.5` JSON layouts only when the profile's manager agrees with the verified carrier. Duplicate keys, unsupported YAML, linked or escaped locations and invalid dependency routes are refused. The `dsh-desktop-bound/v2` contract is unchanged: Guard's second single-package add must preserve all tracked bytes and its complete package tree; only object-key order in `.modules.yaml` may differ in the later multi-package add. Qualification and read-only preflight do not establish installation, no-op, lifecycle or real-model acceptance.

`0.2.1-rc.3` 的 macOS arm64 与 Windows x64 官方 Desktop 分发行已分别登记厂商签名、签名绑定的 ASAR 头和官方更新源归档摘要，不复用 rc.2 pin。分发行登记不代表 Guard 安装、生命周期、真实模型或 UI 性能已验收；这些仍是独立门槛。未登记分发行继续按失败关闭拒绝。

官方 Desktop `0.2.1-rc.2` 分发包保留了 npm 包已移除的 `lib/types/invariant.js` 编译产物，Guard 不加载这些伴随插件。Desktop 另行核对固定发行包身份和八个关键包的精确文件清单；每份程序均由删除前的固定上游源码独立编译复现，公开源码 pin 与应用声明的构建标识分开记录。ASAR 自带哈希表不能授权额外代码：仍须通过官方签名、已登记平台的 archive header、registry 字节和实际依赖路由核验。未知文件、改字节、错版本、错 header 和错路由均被拒绝，普通 registry runtime 的闭合规则不变。同版本重新构建的 Desktop 也须重新核验其分发字节。

Desktop 平铺安装索引只接受已观察的 pnpm `11.7.0`、`11.28.5` JSON 布局，版本必须与已验证的 carrier 一致；重复 key、未知 YAML、链接或越界目录、错误依赖路由仍会被拒绝。v2 两步 no-op 合同不变：Guard 单包第二次 add 要求全部跟踪文件及包树字节不变；后续多包 add 仅容许 `.modules.yaml` 的对象 key 顺序变化。资格核验及只读 preflight 不等于安装、no-op、生命周期或真实模型验收通过。

### Host-surface changes Guard 0.10.0 actually handles

- **Session V4 catalog adds `job/registered`, `job/settled`, `working-directory/change`.** Job registrations and settlements are durable lifecycle facts, not completion evidence: a `job/settled` record with `status: "completed"` refines the external-wait view only when the producer itself reported fulfilment (`cause: "producer"`, `producerReported: true`); killed and failed settlements are explicit failures, and an unreported completion is unconfirmed. A settlement never certifies resource cleanup, file readback or the completion of a user obligation. Only a validated registration/settlement pair owned by the current session may refine its wait; supplied tool/root identities must match the original persisted invocation. The host writes lifecycle records best effort, so a well-formed orphan settlement remains audit-only. Missing or malformed identity, time or optional fields and conflicting repeats fail closed. A forked history never transfers the original owner.
- **Working directory is switchable inside a session.** The immutable Session header keeps the original project; each committed `working-directory/change` opens a new cwd epoch. Captured targets, paths and receipts keep the meaning of the epoch they were bound in — a later change never re-interprets an older relative path. A cwd-dependent call keeps its call-epoch target; a directory change before its result makes execution unconfirmed, including recovery by the host after dispatch. Absolute explicit execution targets remain independently bound. Drive-root and complete Windows UNC directories preserve their original spelling. Host default-workdir receipts gained a v2 shape that binds the governing epoch and the original project; receipts replayed next to different directory history are refused. Root-locator digests bind the epoch each root was captured in. Historical logs without `working-directory/change` preserve the 0.9.0 frozen projection under the same host binding, and preserve its evidence fields and digests, including the original spelling of explicit relative shell workdirs. The epoch reader applies only once a committed effective epoch is visible through that result; it resolves relative shell workdirs against the call epoch and keeps ambiguous Windows workdirs unconfirmed. Later events never reinterpret an already completed legacy fact.
- **Plugin records exist (`appendPluginRecord`/`pluginRecordOf`, `plugin:` namespace).** They are ignorable, never model-visible, and retained on a best-effort basis across format migrations; the upstream gate restricts production callers to its own experimental packages, so this API is not a stable third-party persistence interface. Guard does NOT migrate its private hash-chained ledger onto plugin records; the ledger keeps its own storage, writer lock and loss model. Foreign plugin records are retained-and-skipped: they never trigger capture, never authorize anything, and never break seq-driven call/result pairing.
- **Session append gained a publication-reentrancy check and per-listener exception isolation.** Guard's synchronous `snapshotEvents()` reads remain valid on the pinned local Session implementation; the existing flush-before-control and boundary durability flows are unchanged.
- **The invariant companion plugin and the `./invariant` exports were removed upstream.** Guard never imported them and adds no substitute. The official Desktop distribution's retained compiled files require the separate qualification above.
- **Subagents and Teams.** The subagent tool name `subagent` stays in Guard's delegation allowlist: a subagent result remains bounded evidence and never closes a parent obligation. Team delivery moved to direct inbox acceptance (the old outbox retry/dedupe path is gone upstream); `team/message/delivered` records reception only — reception is not execution, and neither is completion. Waiting for a subtask, a plan-review end turn, or a Goal pause does not consume or fabricate a completion.
- **Search/Fetch APIs and new models** are ordinary host tools: their success is non-authoritative evidence, never proof that a user task is complete.

### 升级、临时禁用与恢复（0.10.0 中文说明）

最低宿主为 DSH `>=0.2.1-rc.2`，没有隐式上限。升级顺序不变：先停写者、保留旧模式来源，升级宿主到 `0.2.1-rc.2` 或更高，安装 Guard，重新注入宿主锁并回读（见[宿主锁升级](HOST_LOCK_UPGRADE.md)）。已审查基线为 DSH `0.2.1-rc.2` 与 `0.2.1-rc.3`（Cordis 均为 `4.0.5`；cohort `dsh-0.2.1-rc.2-core-v1` / `dsh-0.2.1-rc.3-core-v1`，各 47 包，见 `manifests/rc021-rc2-byte-audit.json` 与 `manifests/rc021-rc3-byte-audit.json`，上游提交分别为 `687f282e8625c6b8d11ff58211a90524be2e4317` 与 `1f81c047fc48fa190a683e469daa699857e9afe8`；rc.3 核心图可执行字节经逐包比对与 rc.2 完全一致）。

新宿主事件语义：`job/settled` completed 不证明资源释放，只有本会话所有、注册与结算身份一致且工具根调用匹配的配对记录，在 producer 自己报告完成（`cause: "producer"` 且 `producerReported: true`）时才把外部等待标记为完成；合法孤立结算仅保留为审计事实，畸形或冲突记录拒绝；killed/failed 是显式失败，未报告的 completed 保持未确认。`working-directory/change` 开启新的 cwd 纪元：此前捕获的目标与证据保留原含义，不会随当前目录重新解释；调用与结果之间若发生目录变化（包括宿主自动恢复），默认或相对目录的执行保持未确认；显式绝对目标独立绑定。Windows 完整 UNC 和 drive-root 路径保留拼写，drive-relative/root-relative 拒绝。没有 `working-directory/change` 的日志在同一宿主绑定下保留 0.9.0 冻结投影，并保留其证据字段与摘要，包括显式相对 shell workdir 的原始拼写。新读法只在该结果之前已有实际生效的提交纪元时使用；后来追加的事件不能重新解释已经完成的旧证据。`plugin:` 记录一律忽略且不触发捕获；Guard 私有账本不迁移到 plugin records。子代理结果仍是有界证据；Team 直投 Inbox 的接收成功不等于执行完成；Goal 等待与计划审阅的结束等待不算完成。

临时禁用与恢复：升级窗口内可在 profile 配置中把 Guard 从 bundles 移除或保持不加载（临时禁用是独立状态，不影响 `activation=always` 与完整原有 config 的保留）。禁用期间会话事件不被捕获；重新启用时按既有规则恢复——新建无继承根会话回到默认模式，旧会话沿用 write-once 私有绑定的原模式。宿主锁在禁用期间不变质；重新启用后若宿主或 profile 图未变，原锁继续有效，若变化则按 `--rebind-registry` 流程重建。市场兼容卡片显示"兼容"不等于 Guard admission 已通过；插件加载成功也不等于审计通过。

### Consumer prerelease semantics

The plain npm/node-semver expression `>=0.2.1-rc.2` excludes later-tuple prereleases by default. The installed DSH plugin compatibility check (`dsh-app-boot`'s `evaluatePluginCompatibility`) reads the TOP-LEVEL `engines.dsh` first and ignores the DSH peers entirely when it exists; it uses `semver.satisfies(..., { includePrerelease: true })`, so the declaration admits `0.2.1-rc.3` and later RCs on any tuple, and refuses below-floor values. Both shipped layers (`engines.dsh` and `dsh.engines.dsh`) carry the same range so consumers reading either layer agree; peers keep the same range for peers-only consumers. `benchmarks/incidents/acceptance/semver-matrix.json` records the verified matrix for the new floor, and `tests/v100-app-boot-admission.test.ts` pins the real consumer's decisions. Package installation is not a version-admission proof — Guard's own floor check rejects a below-floor host independently.

The default-workdir shortcut additionally authenticates the published `dsh-working-directory` implementation, its dependency routes and the scoped `WorkingDirectoryService`. Missing, substituted or modified providers emit no trusted receipt. A v1 receipt is valid only before any directory-change event; v2 replay binds its origin to the actual Session header supplied by derivation, rather than trusting the receipt's own origin field. A pre-execute receipt is refused if directory history changes before the result; a pre-execute observation does not prove that `ensure()` later executed in that directory.

默认目录快捷证据还核验 `dsh-working-directory` 的发布字节、依赖路由和当前 scoped 服务身份。服务缺失、替换或修改时不发可信回执。v1 只能用于调用前没有目录变化的历史；v2 的 origin 必须绑定派生器从实际 Session header 取得的原始目录，不能只信回执自报。调用后目录发生变化时，执行前回执不再证明实际执行目录。

## 0.8.2–0.9.0: DSH >=0.2.0-rc.2 and official Desktop

0.9.0 retained the host admission introduced in 0.8.2 with the floor `0.2.0-rc.2`; 0.10.0 supersedes it. Historical description:

Version admission uses strict SemVer precedence, including later-tuple RCs and ignoring build metadata. The floor is `0.2.0-rc.2`, with no upper limit. `0.2.0-rc.1` keeps its recorded-evidence row but is refused as below the floor. Below-floor and malformed versions are refused. Cordis has a separate `>=4.0.4` peer range and qualification; a DSH version does not establish arbitrary Cordis compatibility.

The reviewed host baseline is DSH `0.2.0-rc.2` / Cordis `4.0.4`, with 46 package identities and published implementation digests in `manifests/rc020-rc2-byte-audit.json`, regenerated from the published `0.2.0-rc.2` tarballs (upstream commit `639ed015397290b3745d163aafe02ffee4aa3f84`). Compared with rc.1, only six cohort packages carry real `lib` changes in rc.2 (`dsh`, `dsh-commands`, `dsh-goal`, `dsh-llm` typert tables; `dsh-tool-bash`/`dsh-tool-pwsh` tool descriptions); every other package differs only in its `package.json` dependency pins. Native acceptance of the final Guard artifact on each platform remains a separate gate; no native validation of a future host is claimed.

### Official Desktop (CG-RC2-002)

The application owns the `desktop` profile (`dsh-profile-desktop`). Its CLI carrier permits plugin management for that profile but refuses CLI boot and `--dump-config`. Use the carrier installed with the app for installation, and Guard's `dump-desktop` command for boot-free composition. See the [Desktop upgrade steps](HOST_LOCK_UPGRADE.md#official-desktop-profile).

Guard identifies the profile by its manifest name. A Desktop profile contains the Web bundle, so bundle presence alone cannot identify the running surface. For macOS, Guard verifies the app's Developer ID signature and DeepSeek team/identifier; for Windows, it verifies the executable's Authenticode status and DeepSeek publisher. It then compares the ASAR header with the integrity value embedded in the signed carrier. A detached archive or a self-reported digest table cannot establish carrier identity.

Desktop's bundled pnpm 11.7 produces a physical hoisted plugin tree with a JSON `.modules.yaml` index and no package map. Guard verifies the index against the actual tree, then applies the same published-byte and dependency-route checks to local critical peers. Missing, unlisted, duplicate, escaped or changed critical packages are refused. A supported package-map layout remains accepted when present; malformed maps never fall back to the physical-tree path.

The official market (`dshmarket`) is an ordinary third-party profile plugin on a Desktop profile: its bundle presence neither conflicts with the official bundle tuple nor identifies the surface as Web, and its package name grants no trust. Installing or removing the market changes the profile's importer, so the previous Desktop lock stops matching and must be rebuilt through the formal flow. Real-market coexistence acceptance (`desktop-market-coexistence/v1`) is recorded separately from the layered no-op gate in the matching Release annex; graphical-shell and real-model observations remain separate gates.

The archive is read in place. The registry baseline closes the executable/JSON inventory of each critical package, including scripts outside `lib`. Its bytes must match the acquired official tarball digests. The signed archive metadata authenticates the packager's rewritten manifests; executable files have no rewrite exception. Nested critical packages, unlisted code and changed dependency routes are refused. The same fresh route and byte audit also checks critical peers selected from the physical profile.

The lock binds the canonical archive, signed header, runtime manifest and metadata, carrier bytes, installed Guard manifest, profile manifest, map and lockfile. Inject and runtime revalidation use one evaluation path, including foreground renderers and default-workdir providers. Changed inputs refuse the injected lock. Receipts stay under physical, contained profile directories; directory links cannot redirect them elsewhere.

`hostLockProfile: "desktop"` is preserved through composition and readback. Guard refuses Desktop restart with `host_capability_request_unsupported`; the graphical app owns its lifecycle. Exact-artifact backend acceptance, graphical-shell acceptance and real-model behavior are separate gates. Their results belong to the matching Release annexes.

### 0.8.2–0.9.0 中文说明

0.9.0 保留 0.8.2 的宿主准入范围与 Desktop 支持；各版本仍须独立核对制品验收结果。

0.8.2 延续 0.8.x 的任务、证书与数据协议，主要适配 DSH RC.2、增加 Desktop 宿主锁并修复退出证据判定。最低 DSH 版本升至 `0.2.0-rc.2`；请先升级宿主，再安装 Guard、重新注入锁并回读。版本准入没有上限，但版本号相符仍不足以证明实现兼容。Cordis 的独立要求为 `>=4.0.4`。

Desktop 按应用自有的 `dsh-profile-desktop` 名称识别。安装须使用应用附带的 CLI；该 CLI 允许管理 Desktop 插件，但拒绝通过 CLI 启动 Desktop 或执行 `--dump-config`。Guard 的 `dump-desktop` 使用应用内同一套配置组合 API，不启动宿主。具体操作见[Desktop 升级步骤](HOST_LOCK_UPGRADE.md#official-desktop-profile)。

Desktop 自带 pnpm 11.7 生成平铺插件目录，安装索引为 JSON 格式的 `.modules.yaml`，不含 package-map。Guard 核对索引与实际目录，再对本地关键 peer 执行相同的官方字节与依赖路由认证。关键包缺失、未登记、重复、越界或发生改写时均拒绝准入；若存在受支持的 package-map，则使用该布局，损坏的 map 不会回退到平铺目录路径。

官方插件市场（`dshmarket`）在 Desktop profile 上是普通第三方 profile 插件：它的 bundle 既不与官方 bundle 元组冲突，也不能把运行面识别成 Web，其包名本身不授予任何信任。安装或移除市场会改变 profile 的 importer，旧 Desktop 锁因此不再匹配，必须按正式流程重建。真实市场共存验收（`desktop-market-coexistence/v1`）在对应 Release annex 中与分层 no-op 门槛分开记录；图形界面与真实模型观察仍是独立门槛。

Guard 先核验 macOS 的 DeepSeek Developer ID 签名或 Windows 的 DeepSeek Authenticode 发布者，再将 ASAR 头与签名载体内的摘要比对。随后原位读取归档，按独立获取的官方 tarball 清单核验关键包内全部可执行/JSON 文件，包括 `lib` 外的脚本。签名归档的元数据只用于认证打包器改写的 manifest；新增代码、嵌套关键包、错误依赖路由及本地被改动的关键 peer 均拒绝。宿主锁同时绑定应用、载体、profile、安装映射与锁文件；注入和运行时复验采用同一链路，并核验 shell 渲染器及默认工作目录提供者。

Desktop 应用重启仍由应用自行管理，Guard 不提供该能力。最终制品的后端生命周期、图形界面和真实模型验收分别记录在对应 Release annex 中。定时提醒及超时问题的晚到答案仍不授予根指令权限；退出标记被后续 prose 遮挡时，结果保持 `unknown`，不再误判成功。

### RC.2 message sources (CG-RC2-004 / CG-RC2-005)

RC.2 delivers scheduled reminders as `user/message` events with `source.kind === 'schedule'` and late answers to timed questions as `source.kind === 'user-question-reply'`. Neither is root user input: neither activates Guard, counts as real root input, creates work units, or is scanned for instructions. The authority for a schedule is the real user turn that created it, recorded in the durable log; the framing of a scheduled message (rc.2 renders it as "from the user") does not change that classification. A late answer belongs to its question/answer contract, never to a new instruction. Only `source.kind === 'user'` carries root authority, and unknown future source kinds fail closed the same way.

### Consumer prerelease semantics

The plain npm/node-semver expression `>=0.2.0-rc.2` excludes later-tuple prereleases by default. The installed DSH plugin compatibility check (`dsh-app-boot`'s `evaluatePluginCompatibility`) uses `semver.satisfies(..., { includePrerelease: true })`, so a `>=0.2.0-rc.2` peer declaration admits `0.2.1-rc.1` and later RCs on the same tuple, and refuses below-floor values. `benchmarks/incidents/acceptance/semver-matrix.json` records the verified matrix for the new floor. pnpm's peer helper behaves the same way; package installation is not a version-admission proof — Guard's own floor check rejects a below-floor host independently.

## 0.8.1: DSH >=0.2.0-rc.1

Version admission uses strict SemVer precedence, including later-tuple RCs and ignoring build metadata. The floor is `0.2.0-rc.1`, with no upper limit. Below-floor and malformed versions are refused. Cordis has a separate `>=4.0.4` peer range and qualification; a DSH version does not establish arbitrary Cordis compatibility.

The reviewed host baseline is DSH `0.2.0-rc.1` / Cordis `4.0.4`, with 46 package identities and published implementation digests in `manifests/rc020-rc1-byte-audit.json`. Real installed-graph source entry measurements exist for that baseline. Native acceptance of the final Guard artifact on each platform remains a separate gate; no native validation of a future host is claimed.

A newer compatible installation can be rebound with `--rebind-registry`, without adding an internal version row. The generator checks exact official registry metadata, archive SRI, installed manifests/modules and both CJS/ESM routes.

Qualification binds ordered entry-selection fields (`exports`, `main`, `imports`, package type and dependency declarations) as well as the reviewed ECMAScript programs. A changed entry or dependency cannot inherit qualification merely because the old file remains unchanged. `guard-host-contract/v2` probes use actual bare package resolution in separate ESM and CJS processes, including the acquired dependencies. Critical adapter entries must resolve to the same authenticated target in both lanes; auxiliary libraries may have separate authenticated lane implementations. Changed compatible entries can qualify without a version row; incompatible API, Session or guarded-effect behavior fails the contract.

A deterministic per-profile receipt binds all qualified bytes, dependency identities and actual Node startup conditions. Old v1 receipts require rebinding. If Node cannot execute an ESM package through `require`, the receipt explicitly records resolution-only CJS coverage; it does not claim CJS behavior was executed. Runtime and pre-install inspection verify the binding and recheck loading routes; a verified download or self-reported compatibility cannot establish qualification.

An unqualified optional Goal implementation disables only Goal integration and reports `host_contract_goal_qualification_required`; independent core work stays available. Different dependency package versions are allowed when their individual identities and routes agree. New graph/module expectations create a new digest, so prior certificates cannot transfer. See [rebinding](HOST_LOCK_UPGRADE.md#rebinding-compatible-package-versions).

The plain npm/node-semver expression `>=0.2.0-rc.1` excludes later-tuple prereleases by default. The installed DSH `0.2.0-rc.1` plugin manager and market discovery explicitly include prereleases: input probes accept `0.2.1-rc.1` and `0.3.0-rc.1`, and reject below-floor values without exemptions. pnpm 11.22.0's peer helper uses `includePrerelease: true`, and isolated version-form registry fixtures resolve those RCs. In the tested install mode it also resolved a below-floor peer despite strict-peer flags; package installation is therefore not a version-admission proof. The DSH and Guard floor checks independently reject that version. Other consumers must opt into equivalent semantics; plain npm matching is not the runtime version rule.

## 0.8.0: DSH 0.1.7-rc.2 (historical fact, unchanged)

0.8.0 metadata and its production selector accepted exactly `0.1.7-rc.2`, with Cordis `4.0.4`, cohort `dsh-0.1.7-rc.2-core-v1`, manifest `manifests/rc017-rc2-byte-audit.json`. That historical support scope is a property of the released 0.8.0 and is not rewritten by the 0.8.1 adaptation.

Missing, duplicated, mixed, escaped or modified critical packages fail closed. A matching version or `allow-version` cannot bypass host identity. `auditedPlatforms: []` remains empty: local graph/module verification is separate from native acceptance of a frozen Guard tgz. See the [A01–A16 record](https://github.com/GreenLv/dsh-completion-guard/blob/563f144bf8568793da5017b9ff71395a33dcd265/docs/DSH_0_1_7_RC2_ACCEPTANCE.md).

Upgrade DSH first, install an accepted Guard artifact, rebuild the host lock and restart each profile. Goal is optional; neither Goal nor Inspector nor scheduling is assumed to be enabled. The 0.7.1 recovery fixes and independent proof, Goal and release gates remain in force.

Foreground shell evidence requires the audited renderer and a trusted terminal result. Promotion, truncation or unknown ownership cannot certify completion from partial stdout. The promoted job-to-target completion chain remains unavailable; do not rerun business merely to obtain evidence. Old ledger and certificate context remains historical after host/session identity changes, with no automatic re-signing or deletion.

## Historical 0.7.0 release-line boundary (2026-09-21)

Public availability of 0.7.0 depends on npm, tag and GitHub Release readback. Historical commit `583035bd90b8ee589d01b12487a057b655d43e41` passed candidate CI and a 34-gate macOS native run with cleanup on its exact canonical tgz; that result skipped real-model requests. That historical tgz has no Windows exact-artifact native or complete fixed-model acceptance. Final release identity, installation and publication require separately bound evidence. Later packaged-document or source changes require a new exact artifact and native acceptance. The existing exact DSH host-lock cohorts remain the test targets. Ordinary file edits, tests and Git operations run through host tools; Guard observes persisted results and uses read-only file/Git/readiness adapters where the named completion predicate needs independent evidence. A package-script readiness observation may select a current test or assessment input; it proves neither that the test ran nor that a root time or approval condition was released. An existing change can be assessed without requiring a new edit. A missing pre-effect state cannot prove create/no-overwrite, and a Git parent object is not an observed pre-effect HEAD. Unsupported predicates remain insufficient rather than being inferred from successful tool return.

The core/v2 JSON and conformance fixture mirrors are bound to the exact Codex Context Guard source commit `cb415cbe374d452e4a0c71e9e292d20e31f23b0e` and per-file hashes in `tests/fixtures/conformance/core_v2/UPSTREAM_PIN.json`. The historical v1/digest pin at `tests/fixtures/conformance/UPSTREAM_PIN.json` retains its prior bytes. This source-mirror identity does not establish product runtime equivalence, publication, or installed behavior. Source and cross-end checks, CI, native acceptance, and exact-artifact acceptance remain separate evidence.

## Historical 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

- Plugin: `dsh-completion-guard` `0.4.0`
- DeepSeek Harness: `0.1.2-alpha.3`
- dshmarket: `1.39.0`
- Cordis: `4.0.2`
- Node: `>= 22`
- pnpm: `>= 11`

DSH is still a developer preview and may make breaking changes. Version 0.4.0 therefore makes no floating alpha compatibility claim.

## Published 0.4.1-rc.1 prerelease (`next`)

- Plugin: `dsh-completion-guard` `0.4.1-rc.1` prerelease
- DeepSeek Harness: `0.1.2-rc.1`
- dshmarket: `1.41.0`
- Cordis: `4.0.2`
- 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 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.

## Historical 0.5.2 adaptation policy

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

- **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 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.

## Historical compatibility cohorts

These are verification records, not support entries. An installed runtime built
from any of them fails closed under the 0.8.0–0.8.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 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

The reviewed baseline core graph is recorded in [`../manifests/supported-host.v1.json`](../manifests/supported-host.v1.json); older graphs remain only in historical test fixtures. For the baseline lock all core rows must match that graph. For a registry rebind, exact individual identities and qualified module expectations bind the new graph. Mixed dependency versions are allowed; missing required, duplicate, untrusted or integrity-drifted identities and wrong critical routes reject certification.

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

- Candidate and historical-artifact evidence: [`LOCAL_ACCEPTANCE.md`](LOCAL_ACCEPTANCE.md)
- Shared Codex/DSH semantic scope: [`SEMANTIC_COMPATIBILITY.md`](SEMANTIC_COMPATIBILITY.md)
- Exact host identities: [`../manifests/supported-host.v1.json`](../manifests/supported-host.v1.json)

## Loader contract

The package exposes a named `apply(ctx)` function and a named `inject` array (`['sessions', 'commands', 'fs']`) with no default export. Its `dsh.bundle.patch` points at `cordis.patch.yml`, which inserts the `context-guard` bundle row.

The plugin accepts explicit `opt-in` or `always`, preserving omitted configuration through the real Cordis schema. Since 0.9.0 only newly created, unseeded root sessions default to `always`. Old sessions retain the pre-upgrade effective mode through [verified migration bindings](ACTIVATION_MIGRATION.md), including empty sessions. Existing bindings override a profile default; contradictory explicit configuration refuses with `activation_mode_conflict`. Persisted off/on controls replay enablement. Mode selection does not grant authority, certify work or change the default `standard` policy. Invalid values refuse configuration.

A qualified official `agent/created` startup path may bind fresh roots. Resume, clear, compact and late attach only read existing bindings; missing or corrupt records refuse certification. Qualification checks public live Agent/Session identity and the supported host composition. This trusts the audited host call chain; the public API provides no factory issuer token and does not defend against arbitrary hostile in-process plugins. Fork/seed mode comes from a verified parent binding; exact inherited-cut validation belongs to the official Session/persistence contract, not a guessed event count. At T0 the Guard may write its private sidecar but writes no Session log messages, preserving the blank preset picker. First real input receives the boundary and guidance in the same entered step. Blank input does not activate; attachments do.

旧会话通过升级前模式清点及核验收据保留有效模式和重放 epoch，不重新解释旧证书。缺省变化只影响新建无继承根会话。恢复、清空、压缩及迟挂载不补建缺失记录；显式模式冲突拒绝认证。官方宿主公开身份与调用链是来源边界，不声称有逐调用 issuer token 或防御任意同进程伪造。父模式绑定和官方 persistence 的精确 cut 分别核验；未知来源保持诊断，不清历史、不重签。见[迁移说明](ACTIVATION_MIGRATION.md)。

### 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.

Since 0.4.3, the generator injects `hostLockPolicy: dsh-core/v1`, the runtime/profile source roots, `hostLockPackages`, `hostLockPlatform`, and `hostLockProfile` together. Mount and protected entries recheck those actual graph sources; ordinary replay uses the mount result; 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 reachable instances, untrusted, or drifted rows fail closed. The audited identities are defined in [`../manifests/supported-host.v1.json`](../manifests/supported-host.v1.json).

### Capability groups

The host lock evaluates these groups independently:

- base and Goal;
- agent loop;
- POSIX or Windows terminal;
- filesystem tools;
- DSH CLI;
- plugin inventory;
- Web control; and
- jobs.

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 core row keeps the core lock unavailable.

## Peer dependencies

The ordinary runtime packages are host-provided peers:

- `@deepseek-ai/cordis`;
- `@deepseek-ai/dsh-agent`;
- `@deepseek-ai/dsh-commands`;
- `@deepseek-ai/dsh-llm`;
- `@deepseek-ai/dsh-session`; and
- `@deepseek-ai/dsh-tools`.

Goal support uses two identity-bound 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.

The historical 0.5.2 artifact 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.

That historical artifact retained exact `0.1.5-rc.1` development pins. The current 0.9.0 build pins DSH `0.2.0-rc.2` while public DSH peers declare the floor range. Historical peer declarations belong to their own release sections
above and are not part of the 0.5.2 contract.

## Terminal outcome contract

The pinned DSH `bash` and `pwsh` renderers append terminal markers for sandbox
denial, timeout, signal termination, and non-zero exit. A completed foreground
result with none of those markers is the renderer's representation of a clean
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
marker because no pinned host renderer contract has been verified for it.
Outcome classification also remains separate from command certification:
unsupported or malformed syntax produces no executable or operation facts and
no certifying subject/capability combination, so it cannot close a contract even
when the host execution itself succeeded.

Replay also binds the ordinary tool name to the active host surface: `bash`
requires the exact POSIX terminal group and `pwsh` the exact Windows group.
The opposite-platform name is `adapter_unavailable`, not a portable alias.
Likewise, ordinary `read`, `write`, and `edit` results require the exact
filesystem capability group. Base-lock support alone is insufficient; the
bounded fact retains an explicit host-capability reason code, carries no
certifying capability, and has unknown outcome.

## Verified surfaces

### 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.
- The slash command appears in the Web command directory. Its `on`, `off`, `clear`, `status`, and `diagnose` subcommands produce the expected `command/run` and `command/done` events.

`inspect` reports whether the active package graph matches a supported cohort, so it can correctly return `supported` before injection. Pre-injection failure is established by reading the composed configuration and by `verify-dump`, which rejects missing or mismatched injected host-lock data.

Evidence and certificates are session-scoped. A later DSH session cannot import or certify evidence IDs from an earlier session. Any workflow that needs a certificate must therefore produce its evidence and checkpoint in the same session.

### Historical 0.3.x evidence

- **0.3.0 runtime baseline:** 20 files exercise 360 deterministic tests, including all 37 mirrored portable semantic cases and all 29 digest vectors. macOS passed 359 tests with one Windows-only shim test capability-skipped; native Windows passed all 352 tests in the earlier 19-file baseline with no skips.
- **0.3.0 native and CI evidence:** the same canonical pre-release tgz passed isolated Web and Headless installation, host-lock inspect/inject/dump/verify, real dshmarket restart readback, HTTP recovery, and cleanup on native macOS and Windows. Headless reached the intentional missing-credential boundary. CI covered Ubuntu, macOS, and Windows on Node.js 22 and 24.
- **0.3.0 model-session evidence:** a credentialed session verified one accepted evidence binding and persisted typed-boundary/disarm path. A deliberately over-broad prompt remained incomplete and received no false certificate.
- **0.3.1 provenance repair:** 0.3.1 preserves the 0.3.0 runtime bytes and repairs only the frozen-package provenance path after the 0.3.0 registry entry omitted `gitHead`. Its final tgz is separately bound to native-platform and public-registry readback.
- **0.3.2 completed release:** the frozen package from commit `22cde610` passed the same-byte isolated lifecycle on native macOS and Windows. Its tag, npm publication, GitHub Release, and public downloads resolve to the same commit and bytes.

Exact commands, artifact identities, and platform limits for these releases are recorded in [`LOCAL_ACCEPTANCE.md`](LOCAL_ACCEPTANCE.md). The published 0.1.x and 0.2.x lines retain their own historical evidence there. The fail-closed invariants below remain covered as regressions.

## Session-layer capture filter and goal completion (v0.2.1)

Not every direct user message becomes a contract item. Informational reports
(receipts, pasted summaries) were already excluded; v0.2.1 additionally drops
session-layer utterances: bare progression/acknowledgement phrases (`继续`,
`好的`, `continue`), meta questions (`这个收尾具体要做什么`, `是不是bug`),
and meta comments or objections without a task feature. The filter also runs
per clause, so a conversational opener inside an otherwise actionable message
(`好的。请修改 src/a.ts`) no longer adds a phantom scope requirement. The
classifier fails closed: an artifact path, an explicit method, or a
non-negated operation verb always keeps the message captured, and uncertain
phrasing stays a captured requirement. Old sessions replay unchanged — a
contract already polluted by such messages remains historical state and is
remediated explicitly (below), not by re-derivation.

`update_goal(action=complete)` stays denied while the guard is enabled without
a current completion certificate. The remediation routes are explicit:
`/context-guard off` disables gating (use only after the user confirms the
work is actually done), `/context-guard clear` supersedes pending
requirements/acceptances under a `CLEAR:<revision>` sentinel (prohibitions are
retained) so an empty-binding checkpoint can certify while the guard stays
enabled, and `update_goal(action=blocked)` records the blocker truthfully.
Recovery packet injection is content-deduplicated: an unchanged packet is
injected once per re-arm, while resume, compaction, an enablement transition,
relevant evidence, or a new contract revision triggers reevaluation. In 0.4.2, unrelated historical success does not repeat unchanged refusal guidance; every actual recovery still receives a current summary.

## v0.3 semantic action and binding contract

[`../manifests/action-manifest.v1.json`](../manifests/action-manifest.v1.json) freezes the action vocabulary, compatibility matrix, required target/state keys, expected-transition predicates, and accepted structured evidence adapter versions. `generic_run` is not a wildcard and cannot certify another semantic action.

The full `STATEFUL_ACTIONS` set is `install | apply | create | modify | restart | commit | push | publish | pull | fetch`. Each requires distinct resolution/effect/state evidence IDs, exact same-target closure, independent state readback, and a versioned expected-transition payload. An effect-only success is incomplete. Old v0.2 scope-run certificates are retained as `legacy_generic_run` audit facts and do not become current v0.3 authority; unprovable legacy authority is also non-certifiable.

### Read-only resolution and explicit mutation

`context_guard_evidence` is read-only. It resolves the current target, checks a persisted effect, and reads the resulting state. `context_guard_action` is the explicitly mutating surface for exact-tgz install, apply, and publish; two-phase dshmarket restart; and exact Git commit, push, pull, and fetch.

The normal flow is: resolve the current target, match that resolution to one authorized pending requirement, perform the exact action, and independently read the state back. A successful effect without matching state evidence remains incomplete.

### Authorization and early rejection

Before mutation, `context_guard_action` flushes and replays the resolution and contract chain. It then requires the exact target digest plus the id and revision of one current pending `root_instruction` or `root_adoption` requirement. The requirement's action and complete requested identity must match the resolution.

A matching pending root prohibition denies the mutation regardless of message order. Prohibitions and acceptance clauses never grant authority.

The action is rejected before executable inspection, command execution, HTTP, or intent persistence when the requirement is disabled, integrity-unknown, stale-host, missing, already passed, superseded, clarification-required, incomplete-target, action-swapped, target-swapped, or an unrebound legacy item. Unknown selector, command-manifest, or Git argument keys are also rejected.

### 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. 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.

The resolution and effect bind the same canonical executable realpath and version.

### Git operations

Push, pull, and fetch require the exact repository, remote, and canonical explicit full ref or refspec. Git aliases, implicit refs, deletion refs, wildcards, force refs, target substitution, and prestate drift are rejected.

Commit certification additionally rejects root commits, merge commits, and substituted parents. Fetch certification requires its resolved pre-HEAD, post-HEAD readback, and predicate parameter to be equal.

### File creation and modification

Create and modify bind to the frozen target and expected transition described below. For modify, the Guard re-hashes the source bytes against the frozen pre-digest before deriving the unique UTF-8 replacement post-digest.

### Restart

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

Windows `.cmd` and `.bat` actions also bind the canonical `SystemRoot\\System32\\cmd.exe` realpath and version. Arguments containing shell control, expansion, quotes, NUL, or newline characters are unsupported. Execution never performs a second `PATH` search or trusts a changed `ComSpec`.

### Concurrency limit

Pre-execute revalidation is a correctness check, not isolation from another process running as the same user. Any divergent post-action readback is not certified.

### Expected transitions and readback

Every stateful resolution freezes its expected transition before the effect and binds a stable digest of that payload. Checkpoint diagnostics copy the immutable payload from the resolution fact. Callers cannot construct create or modify predicates from post-effect state.

- **Create:** hash the exact UTF-8 content from the closed write manifest.
- **Modify:** read the original bytes, require valid UTF-8 and exactly one `old_string` match, apply the pinned single replacement in memory, and hash the resulting bytes.
- **Restart:** freeze `health=healthy` as a manifest constant.

After the action, independent state readback must match the frozen transition. A successful effect with different state remains incomplete.

## Legacy v0.2 command parsing subset

Context Guard v0.2 is **not** a general Bash or PowerShell static analyzer. Only
the small, auditable grammar below can produce `executable`, `operation` and
`subject`; any other command parses as `unsupported` (unterminated quotes parse
as `malformed`) with EMPTY executables and operations, so unrecognized syntax
can never certify an operation. False negatives are preferred over false
positives: an uncertain command keeps its item incomplete.

The enumerations that define this surface (tools, executables, clause verbs)
are declared once in `src/domain/manifest.ts`; the parsers and the contract
capture read from that single data source, which test-time validation keeps
non-empty and duplicate-free with the documented verb priority order. The
manifest ships with the package and is not runtime-writable: widening the
surface lowers the evidence bar, so it changes only through a release.

### Supported POSIX shell (single foreground simple command)

- `printf … > literal-path`
- `echo … > literal-path`
- `touch literal-path`
- read-only inspection tools (`cat`, `grep`, `rg`, `head`, `tail`, `wc`,
  `sed` without in-place flags): every pathish argument counts as a read effect
  (v0.2)
- one whitelisted executable run directly, e.g. `node script.js`,
  `python tool.py`, `pnpm test`, `git pull`,
  `dsh plugin --profile web add dsh-dream-skin@0.3.1`
- a leading simple environment-assignment prefix, e.g. `CI=1 pnpm test`
  (wrappers such as `env`, `nohup`, `time`, `command` are not supported)
- diagnostic stream duplication (`2>&1`, `1>&2`, `N>&M`) in any position
  (v0.2); it is a pure fd copy with no filesystem effect

Literal paths only: no variables, globs, `~` expansion or command substitution.

### Unsupported → fail-closed (whole command, no partial results)

- unquoted LF/CRLF command boundaries, `;`, `&&`, `||`, pipelines (`|`), background (`&`), parentheses/subshells
- `$(…)`, backtick command substitution, heredoc/here-string (`<<`, `<<<`)
- unterminated quotes, dynamic `eval`/`source`/`.`-sourcing
- non-literal (variable/glob) redirect targets or arguments
- `>>`, `<`, file-target fd redirects (`2>`, `2>>`) and all other redirections
  beyond a single `>` or an `N>&M` stream copy
- in-place `sed -i`/`sed --in-place` editing
- executables outside the v0.2 whitelist

### Supported PowerShell (single directly invoked command)

- the v0.1 cmdlet set: `Set-Content`, `Add-Content`, `New-Item`, `Out-File`,
  `Get-Content` with the exact documented parameters
- v0.2: a whitelisted external executable (`git`, `pnpm`, `npm`, `node`,
  `python`, `tsc`, `vitest`, `pytest`, … – the same run-executable set as the
  POSIX side) invoked directly with all-literal arguments, e.g.
  `git push origin main`, `pnpm add pkg@1.0.0`; its run effect carries the
  first pathish argument
- v0.2: unquoted `N>&M` stream duplication is stripped everywhere (a quoted
  `"2>&1"` remains an ordinary value)

Requirements: the command must be unquoted at the command position; the path
must come from the explicit named path parameter (cmdlets) or be a literal
argument (external executables); a quoted path is one token (spaces allowed);
permitted value parameters (`-Value`, `-Encoding`, and `-ItemType`
where listed above) never contribute subjects;
`-WhatIf` and `-Confirm` are unsupported because they can avoid or defer the
claimed effect; positional paths, variables, expressions, `Join-Path`,
subexpressions, pipelines, `;`, script blocks, `&`, dot sourcing, `Copy-Item`,
`Move-Item`, `Rename-Item` and `.NET WriteAllText` are unsupported and fail the
WHOLE command.

### Subject resolution (v0.2)

Evidence artifact subjects are resolved against the call's `workdir`; when the
shell tool carries none (the macOS persistent bash/pwsh tools expose only
`command`), the session scope cwd is used as the default, so relative paths and
scope-run attribution match the contract subject derived from the same cwd. A
pathless `run` operation of a whitelisted executable is attributed to that cwd,
which is what closes a scope `run` contract; builtins (`echo`, `cat`, …) never
become a subject-carrying run.

### Binding invariants

- `run`: the successful method evidence (method + operation + subject) alone
  closes the contract; no extra read or unrelated deterministic-check is needed.
- `create`/`write`/`modify`: require one successful effect evidence matching
  operation and subject, plus an independent successful state-verification
  evidence on the same subject. When an explicit method is present, that method
  identity must be carried by the effect evidence itself; without an explicit
  method, any compatible effect evidence may satisfy the effect facet.
- `read`: a successful read evidence matching method, read operation and
  subject satisfies the method side and the object side at once.
- `verify`: one evidence must simultaneously provide success, an explicit
  read/verify/deterministic-check capability, the canonical subject and surface,
  and any required method identity; separate method and verification evidence
  cannot be spliced together.
- an explicit method whose operation cannot be parsed fails closed.
- prohibitions keep their existing semantics.