dsh-completion-guard 0.8.4 → 0.10.0

package/README.md

@@ -2,115 +2,77 @@
 
 [简体中文](README.zh-CN.md)
 
-An add-on for DeepSeek Harness (DSH) that keeps a task's requirements and checks them before the task is marked complete. It restores the same checklist after a resumed session and accepts only matching saved tool results as evidence.
+DSH Completion Guard is a DeepSeek Harness plugin that keeps your task requirements and checks saved results before certifying completion. Use it when a long or resumed task must still account for requested edits, tests, prohibitions and later corrections.
 
-> **0.8.4 requires DSH `>=0.2.0-rc.2` and supports the official Desktop app.** Stop the host, upgrade DSH and install Guard, then run the host-lock tool's `inspect`, `inject` and `verify-dump` commands for each profile before starting it when needed. For the Desktop app, pass `--profile desktop` with the app archive as the runtime root. These commands bind the installed packages and their verified routes; installing Guard does not rebuild the lock. The tested host baseline is DSH `0.2.0-rc.2` with Cordis `4.0.4`; later versions must pass the same identity and adapter checks. See [compatibility](docs/COMPATIBILITY.md) for version admission, rebinding and native-evidence limits.
+**Opening or restoring a session with history can take time.** DSH loads the saved history and Guard rebuilds its state; you may see “载入历史” (loading history). Wait for loading to finish before continuing. `always` starts protection with the first real input in a new root session; it does not make history loading instant, and reopening a session can still require a wait.
 
-![Task-contract clauses and bounded evidence pass through a checkpoint before a completion certificate is issued](assets/social/completion-guard-hero.png)
+![Task requirements and matching evidence are checked before completion is certified](assets/social/completion-guard-hero.png)
 
-## Quick start
+## Install or upgrade
 
-Stop the host, upgrade to DSH `0.2.0-rc.2` or later, then install Guard in the profile you want to protect:
+Requires DSH `>=0.2.1-rc.2`, Cordis `>=4.0.4`, Node.js `>=22` and pnpm `>=11`. Web, Headless and the official Desktop app have separate profiles. The reviewed host baseline is DSH `0.2.1-rc.2` / Cordis `4.0.5`; a later host must pass the same compatibility checks.
 
-```sh
-dsh plugin --profile web add dsh-completion-guard@0.8.4
-```
+Choose your path before replacing any package:
 
-**Keep the host stopped while upgrading and checking the installed graph below.** The lock records the package versions and installation directories DSH actually uses. A lock generated before an upgrade describes the old packages and will fail against the new runtime. `inject` writes to `<profile>/cordis.patch.yml`, so back up that file first.
+1. **First installation, no old Guard sessions:** stop the host, install Guard in the intended profile, then check and bind that installation before starting it.
+2. **Upgrading with old sessions:** stop the relevant writers and preserve the old installed package and its effective mode sources. Prepare a frozen session inventory and migration receipt **before upgrading**. After installation, rebuild the host lock and complete mode `adopt` and `verify` while writers remain stopped. Do not start the upgraded host until those checks pass for the intended scope. Unknown old modes stay pending.
 
-Check that each command's JSON output says `status: "supported"`. A failure reports a specific reason and exits nonzero. For a later compatible host, add `--rebind-registry` to all three commands; it verifies the official archives and qualifies changed programs in an isolated Node probe before rebuilding the lock. See the [upgrade guide](docs/HOST_LOCK_UPGRADE.md#rebinding-compatible-package-versions).
+For Web, after the applicable preparation:
 
 ```sh
-DSH_RUNTIME_ROOT=/absolute/path/to/.dsh-runtime
-DSH_PROFILE_ROOT=/absolute/path/to/.dsh/profiles/web
-GUARD_HOST_LOCK="$DSH_PROFILE_ROOT/node_modules/.bin/dsh-completion-guard-host-lock"
-
-"$GUARD_HOST_LOCK" inspect --runtime-root "$DSH_RUNTIME_ROOT" --profile-root "$DSH_PROFILE_ROOT"
-"$GUARD_HOST_LOCK" inject --runtime-root "$DSH_RUNTIME_ROOT" --profile-root "$DSH_PROFILE_ROOT"
-dsh --profile web --dump-config | "$GUARD_HOST_LOCK" verify-dump --runtime-root "$DSH_RUNTIME_ROOT" --profile-root "$DSH_PROFILE_ROOT" --dump-config -
+dsh plugin --profile web add dsh-completion-guard@0.10.0
 ```
 
-On Windows, run the same three subcommands through `dsh-completion-guard-host-lock.cmd` in the Web settings directory's `node_modules\.bin` directory and use Windows absolute paths. Native acceptance and publication evidence is recorded per version, bound to that version's exact bytes, in the [acceptance record](docs/LOCAL_ACCEPTANCE.md); a version's source and deterministic evidence never substitutes for its own installed-artifact claim. Other host versions and artifacts need their own native evidence. Repeat this check after changing DSH, Guard or the profile location; an ordinary market-only update does not require reinjection. The Guard stays unavailable if the active package set is missing, duplicated, untrusted, or different from the bound setup.
+Installation alone is not enough. The **host lock** records the actual packages and directories this profile loads; check it with `inspect`, write it with `inject`, then check the composed configuration with `verify-dump`. Back up `cordis.patch.yml` before injection. [Installation and first load](docs/GETTING_STARTED.md) provides the Web commands, Windows and Desktop routes, and the final checks before startup. [Old-session migration](docs/ACTIVATION_MIGRATION.md) provides the preparation, commands and copyable AI prompts for an upgrade.
 
-For Desktop, install through the app's bundled CLI and bind `--profile desktop` to its `app.asar` and actual profile directory. Its CLI does not offer `--dump-config`; use Guard's `dump-desktop` to compose the configuration before readback. Follow the [Desktop upgrade steps](docs/HOST_LOCK_UPGRADE.md#official-desktop-profile). The official plugin market (`dshmarket`) can be installed alongside Guard in the Desktop profile; after installing or removing it, rebuild the Desktop lock with the full four-step flow (`inspect`, `inject`, a newly generated `dump-desktop` output, and `verify-dump` on that new output).
+## What to expect after startup
 
-When ready to use Guard, start DSH Web, open a session, and enable it:
+For an existing session, let history loading and state reconstruction finish. Then check:
 
 ```text
-/context-guard on
 /context-guard status
 ```
 
-Activation is opt-in by default. `status` shows whether the Guard is on, its startup phase (`armed` means waiting for your first message), the active policy tier, how many checks remain, and a summary of why the rest are open. `off` stops protection for the current session without deleting its history. `clear` closes the current checklist while keeping prohibitions. `diagnose` explains why a completion check passed or failed. `migration` reports which rule set the session is under and what an upgrade or rollback would mean. `release` reports an explicitly adopted release contract, its coverage, and anything in flight.
-
-### Ordinary work
-
-Ask DSH to edit a file or run a test as usual. The assistant performs that work with the DSH host tools. Guard records the request, observes the host's persisted call and result, and checks independent readback when the requested outcome needs it. For example, after a host edit changes a configuration file, a separate exact file read can establish the new bytes; a named test needs its own observed result. A successful tool return or the assistant's claim alone does not prove an unrelated condition or a forbidden-file constraint. `context_guard_prepare` explains what evidence is missing, and `context_guard_checkpoint` checks only the predicate that evidence establishes.
-
-The ordinary `context_guard_action` and `context_guard_evidence` tools from 0.6.x no longer perform edits, tests, or Git effects; they return migration guidance. A new file still needs trustworthy evidence that it was absent before creation. A package-script readiness observation can identify an existing test or assessment input without forcing another edit, but it does not prove the script ran or certify arbitrary numeric output. A later request to observe long-term benefits remains future work until its own time or approval condition is met; a short “continue” advances only a concrete ready action.
-
-## What it protects
-
-- Saves requirements, acceptance checks, prohibitions, and later corrections without overwriting history.
-- Uses only tool calls and results that DSH has saved, and stores a redacted summary rather than full output.
-- Accepts evidence only when the action and result match the requested command, file, or other target.
-- Rechecks completion after a session is rebuilt or resumed, and refuses to certify damaged state.
-- Stops the Guard-owned Goal completion path when the current checklist has not passed. DSH internals can still bypass this path, so the plugin reports those cases rather than claiming to block every possible write.
-
-## Status and compatibility
+A **new empty root session**, with the default configuration, uses `always` and shows `armed`: Guard is ready, waiting for the first real message. It appends no Guard events before that message, so you can still choose the DSH session preset. DSH may write its own initialization events. The first real input starts protection in the same step, before its first file changes; an image or attachment counts too, while a blank message does not. An explicit `activation: opt-in` remains opt-in: run `/context-guard on` to begin protection.
 
-Version 0.8.4 admits **DSH `>=0.2.0-rc.2`** without an upper version limit, and supports the official Desktop app as an independent profile (`desktop`): the app-owned `dsh-profile-desktop` profile is identified by its own name, its bundled graph is read in place from the signed `app.asar`, and its installed bytes are verified against the published tarballs. Cordis has an independent `>=4.0.4` peer range and must pass its adapter qualification. The published `0.2.0-rc.2` 46-package graph is the reviewed baseline (the rc.1 graph remains historical evidence); a newer mixed-version graph can receive its own registry-backed lock when the consumed implementations qualify. Changed Session/API implementations run a finite contract probe; incompatible behavior reports a qualification failure, and an old certificate cannot transfer to the new lock. Exact-artifact macOS/Windows native acceptance and future-version native evidence remain separate; Desktop backend, graphical-shell and real-model results are recorded separately for each exact artifact.
+An **old session** keeps its verified pre-upgrade mode, including an empty old session. The new default does not replace an old binding. A contradictory explicit `activation` setting reports `activation_mode_conflict`; follow the [configuration instructions](docs/GETTING_STARTED.md#choose-the-default-for-new-sessions) to use the new default while preserving old modes. Missing, damaged or conflicting bindings prevent certification; Guard reports the problem rather than guessing an identity or mode. Forks inherit their parent's bound initial mode.
 
-After upgrading, inspect, inject and verify the new host lock, then start the profile when needed; follow the [host-lock upgrade guide](docs/HOST_LOCK_UPGRADE.md). DSH migrates old sessions to V4. Guard retains old ledgers and certificates without re-signing them or promoting their old identity to current authority. Goal remains optional; installing the host does not imply it is enabled.
+Ask DSH to edit a file or run a test as usual. DSH executes the tools; Guard records the request and checks the saved result and any required readback. For example, “edit the configuration and make the tests pass” needs evidence of the changed file and a passing test, not just the assistant saying it is done. `context_guard_prepare` explains missing evidence; `context_guard_checkpoint` checks completion.
 
-Host checks verify package identities, implementation bytes and the dependency paths that load them. Native and model acceptance belong to the exact release artifact; consult its Release attachments and the [compatibility guide](docs/COMPATIBILITY.md).
+The default policy is still `standard`. Automatic protection grants no extra editing, execution or publication permission, and does not issue a certificate automatically.
 
-Restart is a separate capability. Current DSH does not supply independently verified bindings for market's loaded instance, so the Guard market restart adapter is unavailable. A requested restart remains pending; core protection and unrelated operations continue. Installing or applying a package on disk does not prove that a running process or UI has adopted it.
+## Mode and everyday commands
 
-Upgrading the core lock requires fresh inspection and injection from the actual runtime and profile. Old certificates are not relabelled as evidence for the new lock. See the [upgrade guide](docs/HOST_LOCK_UPGRADE.md) and [compatibility guide](docs/COMPATIBILITY.md).
-
-Choose a published version from [npm](https://www.npmjs.com/package/dsh-completion-guard) and verify its commit, checksum and native annexes on the [GitHub Release](https://github.com/GreenLv/dsh-completion-guard/releases/latest). The historical 0.4.2 release targets DSH `0.1.2-rc.1` with market 1.41 and does not contain this decoupling. A source version, CI, same-byte native acceptance and publication are separate states; see [acceptance scope](docs/LOCAL_ACCEPTANCE.md).
-
-The project was renamed from `dsh-context-guard` on 2026-08-29; its internal bundle id is still `context-guard`. Migration preserves sessions, activation and disabled settings. Do not load both package names in one profile. Node.js `>=22` and pnpm `>=11` are required.
-
-## Activation modes
-
-Context Guard has two activation modes:
-
-- `opt-in` (default): protection is off when a session starts. Run `/context-guard on` in that session to turn it on, and `/context-guard off` to turn it off again. This changes only the current session.
-- `always`: DSH sessions are protected automatically from the first real message. A brand-new session stays completely empty — the Guard writes nothing into it — so you can still pick the DSH session mode (standard, minimal, or a custom preset) before sending anything. The moment your first real message enters a step, protection begins in that same step and ahead of your message: the first task, including its first file changes, is covered. A first message that only carries an image or an attachment starts protection too and leaves an unresolved asset item until its meaning is clarified; a blank message starts nothing. Running `/context-guard off` turns protection off for that session until you run `on` again.
+| Command or mode | Result |
+| --- | --- |
+| `always` | New root sessions start protection with their first real input. |
+| `opt-in` | Protection starts when you run `/context-guard on` in that session. |
+| `/context-guard status` | Shows activation, remaining checks and reasons they remain open. |
+| `/context-guard off` / `on` | Disables or enables protection for this session; saved history remains. |
+| `/context-guard diagnose` | Explains a completion verdict. |
+| `/context-guard clear` | Supersedes the current checklist while keeping prohibitions; it does not prove the work was done. |
+| `/context-guard migration` | Shows the session's rules and upgrade/rollback implications. |
+| `/context-guard release` | Shows an explicitly adopted release contract and remaining work. |
 
-These modes only control Guard protection. They are not the DSH session mode (for example, the standard or minimal mode) that a session starts with. Because the Guard no longer writes into sessions before the first message, a session's DSH mode can be selected while the session is still new. `/context-guard on` and `/context-guard off` turn Guard protection on or off; they never change the DSH session mode.
+Guard activation is separate from DSH's standard/minimal/custom session preset. Saved `off` and `on` continue to apply. To change the initial default for future root sessions, see the [configuration instructions](docs/GETTING_STARTED.md#choose-the-default-for-new-sessions). Keep existing host-lock fields and session bindings.
 
-To make DSH sessions start with protection on, set `activation: always` on the existing `context-guard` entry in your profile’s `cordis.patch.yml`. Preserve its injected host-lock fields; the snippet below shows the field to change, not a replacement for the complete configuration:
+## History loading and 0.9.0 caching
 
-```yaml
-- id: context-guard
-  name: dsh-completion-guard
-  config:
-    activation: always
-```
+The first opening or restoration of an existing session loads its history and rebuilds Guard state. A later visit may also wait. This is different from a new empty session's `armed` state, which waits for your input.
 
-DSH Web in a browser, Headless in a terminal, and the Desktop app use separate settings files. Edit the profile you use; check each one separately when you use more than one:
+0.9.0 reuses completed checks of old history only when it can verify that the history is unchanged and the results are safe to reuse. Within one Desktop installation check, it also reuses application files already read and verified. Each operation still checks the current mode and performs the required fresh checks of Goal state, private records and the host environment. **This release does not change the official host's history-view lifecycle or decode cache, and does not promise to remove all UI loading waits.** See the [performance scope](CHANGELOG.md#090) and [acceptance record](docs/LOCAL_ACCEPTANCE.md).
 
-| System | How you use DSH | Default path |
-| --- | --- | --- |
-| macOS / Linux | Web | `$HOME/.dsh/profiles/web/cordis.patch.yml` |
-| macOS / Linux | Headless | `$HOME/.dsh/profiles/headless/cordis.patch.yml` |
-| macOS | Desktop | `$HOME/.dsh/profiles/desktop/cordis.patch.yml` |
-| Windows | Desktop | `%USERPROFILE%\.dsh\profiles\desktop\cordis.patch.yml` |
-| Windows | Web | `%USERPROFILE%\.dsh\profiles\web\cordis.patch.yml` |
-| Windows | Headless | `%USERPROFILE%\.dsh\profiles\headless\cordis.patch.yml` |
+If the official reader refuses an old format, preserve the original log and old-mode source. You can explicitly migrate selected readable sessions using `inventory`, `select` and the same `--selection` on `inspect/adopt/verify`. Excluded sessions remain pending: `selected_complete` means only the chosen rows completed, not the whole inventory. Corruption, permission errors and other failures are not silently skipped. The [migration guide](docs/ACTIVATION_MIGRATION.md) includes commands, recovery and AI prompts.
 
-If you set a custom `DSH_HOME`, use that directory instead of `$HOME/.dsh` or `%USERPROFILE%\.dsh`.
+## Limits and privacy
 
-You can also paste this prompt into DSH and let it make the change:
+Guard saves requirements, checks matching persisted results and rechecks them on resume. It refuses to certify damaged or insufficient evidence. It can block the Goal completion path it guards, but does not control every internal DSH write or replace DSH permissions, tools, Goal or compaction. Ordinary investigations can end with an honest answer without a machine completion certificate.
 
-> Set `dsh-completion-guard` to `always` mode. Find the `cordis.patch.yml` used by the way I am currently running DSH (Web, Headless or Desktop), back it up first, and only set `activation: always` on the entry with `id: context-guard`. Do not change any other settings or restart DSH. When finished, show me the file path and the exact diff.
+Guard stores bounded, redacted evidence summaries rather than full prompts, stdout, files, credentials, images or raw transcripts. See [privacy](docs/PRIVACY.md). A package installed on disk does not prove a running process or UI loaded it; Guard's market restart adapter remains unavailable. [Compatibility](docs/COMPATIBILITY.md) documents supported commands and platform limits.
 
-After the change, restart DSH.
+<details>
+<summary>Advanced completion, recovery and upstream behavior</summary>
 
-## How completion is checked
 
 Once enabled, the Guard saves direct user requirements and acceptance checks. A saved tool result counts only when it matches the requested command, file, or other target. A machine-certified completion requires the Guard's checkpoint; missing, stale, or mismatched evidence leaves the task uncertified. Investigations and explanations outside the supported evidence rules can still end with an honest answer, without a completion certificate.
 
@@ -144,14 +106,10 @@ Three tiers change how much proof is required at completion. They are separate f
 | `strict` | On top of standard, a visual or complete-scope verification you explicitly asked for must be discharged by a real readback fact, not by a tool that merely succeeded. |
 | `release` | An explicitly adopted release contract checks the covered publication operation against an exact candidate and one-use reservation. The contract does not supply user authorization or host permission. |
 
-Set the tier in the same `cordis.patch.yml` entry as `activation`:
+To choose `strict`, back up `cordis.patch.yml`, then add or change only `policy` under the existing `context-guard` entry's `config`. Preserve its activation setting, injected host-lock fields and other settings. This field illustration is not a replacement entry:
 
 ```yaml
-- id: context-guard
-  name: dsh-completion-guard
-  config:
-    activation: always
-    policy: strict
+policy: strict
 ```
 
 ### Explicit release contracts
@@ -188,6 +146,8 @@ The two repositories serve different runtimes:
 
 They do not share runtime state, installers, caches, or release histories. Fixes are contributed to the repository that owns the affected runtime and are ported deliberately when the same behavior belongs in both products. See [`docs/UPSTREAM_BASE.md`](docs/UPSTREAM_BASE.md) and [`docs/PORTING_NOTES.md`](docs/PORTING_NOTES.md) for the exact reused and replaced boundaries.
 
+</details>
+
 ## npm download history
 
 ![Combined cumulative npm download growth across dsh-context-guard and dsh-completion-guard](https://raw.githubusercontent.com/GreenLv/dsh-completion-guard/stats/npm-downloads.svg)
@@ -196,10 +156,11 @@ The cumulative chart keeps the old and new npm package totals visibly separate,
 
 History starts on the first public npm release day, 2026-08-26; its real first-day count is retained even when nonzero. The vertical axis starts at zero. Date labels share one fixed day interval and centered anchors; the caption always gives the exact coverage end.
 
-The daily workflow publishes through the last day whose counts are unchanged in checks at least 12 hours apart and at least two UTC calendar days old. The API availability date is shown separately; this observation rule is not an npm guarantee that counts will never change. See the [source data](https://raw.githubusercontent.com/GreenLv/dsh-completion-guard/stats/npm-downloads.json).
+The workflow is scheduled to collect twice daily. It publishes through the last day whose counts are unchanged in checks at least 12 hours apart and at least two UTC calendar days old. The chart shows the history cutoff, API availability date and latest check time separately. When npm data is delayed or revised, the previously checked curve remains visible with a pending status; a collection failure leaves the last chart intact. This observation rule is not an npm guarantee that counts will never change. See the [source data](https://raw.githubusercontent.com/GreenLv/dsh-completion-guard/stats/npm-downloads.json) and [latest collection status](https://raw.githubusercontent.com/GreenLv/dsh-completion-guard/stats/refresh-status.json).
 
 ## Documentation
 
+- [Installation and first load](docs/GETTING_STARTED.md) — safe setup, first loading wait and session modes.
 - [`CHANGELOG.md`](CHANGELOG.md) — versioned user-visible changes.
 - [`docs/ARCHITECTURE.md`](docs/ARCHITECTURE.md) — ownership, durable state, and certification pipeline.
 - [`docs/COMPATIBILITY.md`](docs/COMPATIBILITY.md) — supported DSH versions and certifiable command subset.

package/README.zh-CN.md

@@ -2,115 +2,77 @@
 
 [English](README.md)
 
-面向 DeepSeek Harness（DSH）的任务保护插件。它保存任务要求，并在任务标记完成前逐项核对；会话恢复后仍使用同一份检查表，只有匹配的已保存工具结果才能作为证据。
+DSH Completion Guard 是 DeepSeek Harness 插件，负责保存任务要求，并在认证完成前核对已保存的结果。长任务或恢复后的会话中，它帮助助手继续核对文件修改、测试、禁止事项和你后来补充的要求。
 
-> **0.8.4 要求 DSH `>=0.2.0-rc.2`，并支持官方 Desktop 应用。** 请先停止宿主、升级 DSH 并安装 Guard，再为每个 Profile 执行宿主锁工具的 `inspect`、`inject` 和 `verify-dump`，最后按需启动该 Profile。对 Desktop 应用请传入 `--profile desktop`，并以应用归档作为 runtime root。这些命令绑定实际安装包及其经过验证的路由；安装 Guard 本身不会重建锁。已测试的宿主基线是 DSH `0.2.0-rc.2`、Cordis `4.0.4`；较新版本仍需通过身份和适配契约检查。版本准入、重绑及原生证据范围见[兼容性指南](docs/COMPATIBILITY.md)。
+**首次打开或恢复已有历史的会话，需要等待载入。** DSH 载入历史，Guard 重建会话状态，界面可能显示“载入历史”；请等加载结束再继续。`always` 让新建根会话从首条真实输入开始受到保护，不会让历史载入立即完成；再次打开也不能保证没有等待。
 
-![任务合同条款与有界证据通过 checkpoint 匹配后签发完成证书](assets/social/completion-guard-hero.png)
+![核对任务要求及对应证据后，再认证完成](assets/social/completion-guard-hero.png)
 
-## 快速开始
+## 安装或升级
 
-先停止宿主并升级到 DSH `0.2.0-rc.2` 或更高版本，再把 Guard 安装到需要保护的 Profile：
+需要 DSH `>=0.2.1-rc.2`、Cordis `>=4.0.4`、Node.js `>=22` 和 pnpm `>=11`。Web、Headless 和官方 Desktop 应用使用各自的配置目录。已审查的宿主基线是 DSH `0.2.1-rc.2` / Cordis `4.0.5`，更新版本仍须通过兼容性核验。
 
-```sh
-dsh plugin --profile web add dsh-completion-guard@0.8.4
-```
+先选好路径，再替换任何包：
 
-**升级和执行下面的安装图检查时，保持宿主停止。** 宿主锁记录 DSH 实际使用的包版本和安装目录；如果升级前就生成锁，新运行时会因包版本不匹配而拒绝它。`inject` 会修改 `<profile>/cordis.patch.yml`，请先备份该文件。
+1. **首次安装，没有旧 Guard 会话**：停止宿主，在使用的 profile 中安装 Guard，核验并绑定本次安装后再启动。
+2. **已有旧会话，需要升级**：先停止相关写者，保留旧安装包及其有效模式来源。**升级前**冻结会话库存并准备迁移收据。安装后重建宿主锁，保持写者停止，完成旧模式的 `adopt` 和 `verify`；目标范围核验通过前不能启动升级后的宿主。无法核实的旧模式保持待处理。
 
-查看每条命令 JSON 输出中的 `status`，确认它为 `supported`。失败会报告具体原因并以非零退出码结束。较新兼容宿主需给三条命令都加上 `--rebind-registry`，先验证官方包归档，并在隔离 Node 进程中检查变化程序的兼容契约，再重建锁；步骤见[升级指南](docs/HOST_LOCK_UPGRADE.md#rebinding-compatible-package-versions)。
+Web 在完成相应准备后安装：
 
 ```sh
-DSH_RUNTIME_ROOT=/absolute/path/to/.dsh-runtime
-DSH_PROFILE_ROOT=/absolute/path/to/.dsh/profiles/web
-GUARD_HOST_LOCK="$DSH_PROFILE_ROOT/node_modules/.bin/dsh-completion-guard-host-lock"
-
-"$GUARD_HOST_LOCK" inspect --runtime-root "$DSH_RUNTIME_ROOT" --profile-root "$DSH_PROFILE_ROOT"
-"$GUARD_HOST_LOCK" inject --runtime-root "$DSH_RUNTIME_ROOT" --profile-root "$DSH_PROFILE_ROOT"
-dsh --profile web --dump-config | "$GUARD_HOST_LOCK" verify-dump --runtime-root "$DSH_RUNTIME_ROOT" --profile-root "$DSH_PROFILE_ROOT" --dump-config -
+dsh plugin --profile web add dsh-completion-guard@0.10.0
 ```
 
-Windows 请通过 Web 配置目录下的 `node_modules\.bin\dsh-completion-guard-host-lock.cmd` 运行相同的三个子命令，并使用 Windows 绝对路径。各版本的原生验收与发布证据在[验收记录](docs/LOCAL_ACCEPTANCE.md)中按版本绑定其精确制品字节单独记录；任何版本的源码与确定性证据都不能等同于该版本已安装制品的结论。其他宿主版本和制品仍需各自的原生证据。DSH、Guard 或 profile 路径变化后需要重新检查；仅 market 普通升级不需要重新注入。如果当前包集合缺失、重复、不可信或不同于已绑定环境，Guard 会保持不可用。
+装好插件还需核验环境。**宿主锁**记录这个 profile 实际加载的包和目录：先用 `inspect` 检查，再用 `inject` 写入，最后以 `verify-dump` 核对组合配置；注入前备份 `cordis.patch.yml`。[安装与首次载入](docs/GETTING_STARTED.md)给出 Web 命令、Windows 和 Desktop 路径及启动前的最后核验。[旧会话迁移指南](docs/ACTIVATION_MIGRATION.md)提供升级准备、完整命令和可复制的 AI 提示词。
 
-Desktop 请使用应用附带的 CLI 安装，再以 `--profile desktop`、应用 `app.asar` 和实际 profile 路径建立宿主锁。它的 CLI 不提供 `--dump-config`，请用 Guard 的 `dump-desktop` 生成组合配置再回读；见[Desktop 升级步骤](docs/HOST_LOCK_UPGRADE.md#official-desktop-profile)。官方插件市场（`dshmarket`）现在可以在 Desktop profile 中与 Guard 共存；安装或移除市场后，请按完整四步流程重建 Desktop 锁（`inspect`、`inject`、用 `dump-desktop` 新生成的组合配置、以及对新配置执行的 `verify-dump`）。
+## 启动后会看到什么
 
-需要使用时，再启动 DSH Web，打开会话并启用 Guard：
+已有会话请先等历史载入和状态重建结束，再查看：
 
 ```text
-/context-guard on
 /context-guard status
 ```
 
-默认采用 opt-in。`status` 显示 Guard 是否开启、启动阶段（`armed` 表示已就绪、等待你的第一条消息）以及还有多少检查项。`off` 停止保护当前会话，但不删除历史。`clear` 关闭当前待办，同时保留禁止项。`diagnose` 说明完成检查为什么通过或失败；`migration` 报告当前会话适用哪套规则、升级与回滚分别意味着什么；`release` 报告显式发布契约、其覆盖范围以及仍在执行中的操作。
-
-### 普通工作
-
-照常让 DSH 修改文件或运行测试，助手通过 DSH 宿主工具执行。Guard 保存要求，观察宿主已持久化的调用与结果；要求的结果需要独立核验时，再使用只读回读。例如，宿主修改配置文件后，另一次精确文件回读可证明新内容；具名测试需要自己的真实运行结果。工具返回成功或助手自述，不能证明无关条件，也不能抹去对禁改文件的真实修改。`context_guard_prepare` 说明缺少什么证据，`context_guard_checkpoint` 只核对证据实际证明的谓词。
-
-0.6.x 的普通 `context_guard_action` 与 `context_guard_evidence` 不再执行编辑、测试或 Git 效果，而是返回迁移说明。新建文件还需可信的写入前不存在证据。包脚本就绪观察可以选择已有测试或评估输入，不强迫再次编辑，但它不证明脚本已经运行，也不认证任意数值输出。后续观察长期收益的要求，要到其时间或审批条件满足后才成为当前工作；简短“继续”只推进有来源且已就绪的具体动作。
-
-## 它保护什么
-
-- 保存需求、验收条件、禁止项和后续修正，不覆盖旧记录。
-- 只使用 DSH 已保存的工具调用和结果，并保存脱敏摘要而不是完整输出。
-- 只有动作和结果对应指定命令、文件或其他目标时，证据才有效。
-- 会话重建或恢复后重新检查完成状态；记录损坏时拒绝签发证书。
-- 当前检查表尚未通过时，阻止 Guard 自己守卫的 Goal 完成路径。DSH 内部仍可能绕过这条路径，因此插件会报告这些情况，不声称能阻止所有写入。
-
-## 状态与兼容性
+**使用默认配置的新建空根会话**采用 `always`，显示 `armed`，表示 Guard 已就绪、等待你的首条真实消息。此前 Guard 不追加会话事件，你仍可选择 DSH 会话 preset；DSH 可能记录自身的初始化事件。首条真实输入进入执行步骤时，保护就在同一步骤内开始，覆盖任务的第一次文件修改。图片或附件也能启动保护，纯空白消息不会。显式配置的 `activation: opt-in` 继续有效，需要执行 `/context-guard on` 才开始保护。
 
-0.8.4 的版本准入范围是 **DSH `>=0.2.0-rc.2`**，没有版本上限，并支持官方 Desktop 应用的独立 profile（`desktop`）：应用自有的 `dsh-profile-desktop` 按名称识别，其内置依赖图从已签名的 `app.asar` 原位读取，安装字节按发布 tarball 逐文件核验。Cordis 使用独立的 `>=4.0.4` peer 范围，仍须通过适配器资格验证。已发布的 `0.2.0-rc.2` 46 包依赖图为已审查基线（rc.1 图保留为历史证据）；较新混合版本图在所消费实现具备资格后，可建立自己的 registry 来源锁。变化的 Session/API 实现须通过有限行为探针，不兼容行为会报告具体资格缺口，旧证书不能转移到新锁。最终制品的 macOS/Windows 原生验收、未来版本原生证据与 Desktop 原生验收仍须分别建立。
+**旧会话**保留已核验的升级前模式，旧空会话也一样。新默认值不会覆盖旧绑定。显式 `activation` 与绑定矛盾时会报告 `activation_mode_conflict`；要采用新默认值并保留旧模式，请按[配置步骤](docs/GETTING_STARTED.md#新会话默认模式)操作。绑定缺失、损坏或冲突时，Guard 报告原因并拒绝认证，不猜测身份或模式。分叉会话继承父会话绑定的初始模式。
 
-升级后重新检查、注入并验证 host-lock，再按需启动对应 Profile，步骤见[宿主锁升级](docs/HOST_LOCK_UPGRADE.md)。旧会话由 DSH 迁移为 V4；Guard 保留旧 ledger 和证书，但不会重签或把旧身份升级为当前权限。Goal 为可选能力，宿主安装不代表它已启用。
+照常让 DSH 改文件、跑测试即可。DSH 执行工具，Guard 保存要求，并核对已记录的结果和必要的回读。例如，“修改配置并让测试通过”需要修改后的文件证据和通过的测试结果，助手说“已完成”还不够。`context_guard_prepare` 说明缺什么证据，`context_guard_checkpoint` 检查能否认证完成。
 
-宿主检查核对包身份、实现字节及实际加载它们的依赖路径。原生与模型验收绑定到每个版本的精确制品；请查看对应 Release 的附件和[兼容性说明](docs/COMPATIBILITY.md)。
+默认策略仍是 `standard`。自动参与保护不会增加修改、执行或发布权限，也不会自动签发完成证书。
 
-重启属于单独能力。当前 DSH 没有提供可独立验证的 market 已加载实例绑定，因此 Guard 的 market 重启适配器返回不可用；已有重启要求仍保持未完成。核心保护和不依赖该接口的操作继续工作。磁盘上的插件安装/应用不等于运行进程或 UI 已生效。
+## 模式和常用命令
 
-升级到新核心锁时，需要从实际运行时与 profile 重新生成并验证锁；旧证书不会被重新标记为新锁证据。详见[升级说明](docs/HOST_LOCK_UPGRADE.md)和[兼容性](docs/COMPATIBILITY.md)。
-
-从 [npm](https://www.npmjs.com/package/dsh-completion-guard) 选择已发布版本，并用 [GitHub Release](https://github.com/GreenLv/dsh-completion-guard/releases/latest) 的提交、校验和和原生 annex 核对制品。0.4.2 的历史发布面向 DSH `0.1.2-rc.1` 与 market 1.41；它不包含上述解耦。源码版本号、CI、同包原生验收和公开发布是不同状态，验收范围见[记录](docs/LOCAL_ACCEPTANCE.md)。
-
-项目在 2026-08-29 从 `dsh-context-guard` 更名为 `dsh-completion-guard`，内部 bundle id 仍为 `context-guard`。迁移保留会话、激活方式和禁用设置；不要在同一 profile 同时加载新旧包。需要 Node.js `>=22` 和 pnpm `>=11`。
-
-## 启用模式
-
-Context Guard 有两种启用模式：
-
-- `opt-in`（默认）：打开会话时不会自动保护。你需要在这个会话中执行 `/context-guard on` 才会启用；执行 `/context-guard off` 可以再次关闭。开关只影响当前会话。
-- `always`：DSH 会话从第一条真实消息开始自动保护。全新会话保持完全空白——Guard 不写入任何内容——因此你仍然可以在发送任何内容之前选择 DSH 会话模式（standard、minimal 或自定义 preset）。第一条真实消息进入执行步骤的那一刻，保护在同一步骤内、且位于该消息之前开始：第一个任务连同它的第一次文件修改都在覆盖范围内。首条消息只有图片或附件时同样开始保护，并保留待解释的资产项；纯空白消息不启动任何内容。在某个会话中执行 `/context-guard off` 后，该会话关闭保护，直到再次执行 `on`。
+| 命令或模式 | 作用 |
+| --- | --- |
+| `always` | 新建根会话从首条真实输入开始自动保护。 |
+| `opt-in` | 在会话中执行 `/context-guard on` 后开始保护。 |
+| `/context-guard status` | 查看启用状态、未完成检查及其原因。 |
+| `/context-guard off` / `on` | 关闭或开启当前会话的保护，保留历史。 |
+| `/context-guard diagnose` | 解释完成检查的结论。 |
+| `/context-guard clear` | 撤下当前检查表，保留禁止项；不表示其中的工作已执行完成。 |
+| `/context-guard migration` | 查看会话适用规则及升级、回退的影响。 |
+| `/context-guard release` | 查看显式采用的发布合同及剩余工作。 |
 
-启用模式只控制 Guard 是否保护会话，不是 DSH 的会话模式（例如会话开始时所选的标准模式、极简模式）。Guard 不再在第一条消息之前写入任何内容，因此 DSH 会话模式可以在会话尚为新会话时选择。`/context-guard on` 和 `/context-guard off` 只负责开启或关闭 Guard 保护，不会改变 DSH 会话模式。
+Guard 启用模式与 DSH 的标准、极简或自定义会话 preset 分开。已保存的 `off`、`on` 继续有效。如需修改后续新根会话的初始默认值，按[配置步骤](docs/GETTING_STARTED.md#新会话默认模式)操作，保留已有宿主锁字段和旧会话绑定。
 
-如果希望 DSH 会话自动启用保护，请把实际 profile 的 `cordis.patch.yml` 中已有 `context-guard` 项设为 `activation: always`，保留已注入的宿主锁字段。下面的片段只显示要修改的字段，不用于替换整份配置：
+## 历史载入与 0.9.0 缓存
 
-```yaml
-- id: context-guard
-  name: dsh-completion-guard
-  config:
-    activation: always
-```
+首次打开或恢复已有会话时，需要载入历史并重建 Guard 状态；再次进入也可能等待。这与新空会话的 `armed` 不同，后者是在等待你输入。
 
-DSH 的 Web 网页、Headless 终端和 Desktop 桌面应用使用独立配置。请修改实际使用的 profile；多种方式都用时分别修改：
+0.9.0 只在确认历史未变、检查结果可安全复用时，复用旧历史已经通过的检查。同一次 Desktop 安装检查中，也会复用已读取并核验的应用文件。每次操作仍核对当前模式，并按需要重新核验 Goal 状态、私有记录和宿主环境。**本版没有修改官方宿主的历史视图生命周期或解码缓存，不能保证消除所有界面载入等待**。详见[本版性能边界](CHANGELOG.zh-CN.md#090)和[验收记录](docs/LOCAL_ACCEPTANCE.md)。
 
-| 系统 | 你怎么使用 DSH | 默认路径 |
-| --- | --- | --- |
-| macOS / Linux | Web | `$HOME/.dsh/profiles/web/cordis.patch.yml` |
-| macOS / Linux | Headless | `$HOME/.dsh/profiles/headless/cordis.patch.yml` |
-| macOS | Desktop | `$HOME/.dsh/profiles/desktop/cordis.patch.yml` |
-| Windows | Desktop | `%USERPROFILE%\.dsh\profiles\desktop\cordis.patch.yml` |
-| Windows | Web | `%USERPROFILE%\.dsh\profiles\web\cordis.patch.yml` |
-| Windows | Headless | `%USERPROFILE%\.dsh\profiles\headless\cordis.patch.yml` |
+官方读取器若拒绝旧格式，先保留原日志和旧模式来源。可以用 `inventory`、`select` 明确选择可读会话，并在 `inspect/adopt/verify` 三步使用同一 `--selection`。排除的会话继续待处理：`selected_complete` 只表示选中行完成，不等于整库完成。损坏、权限问题及其他异常不会自动跳过。[迁移指南](docs/ACTIVATION_MIGRATION.md)提供命令、恢复方案及 AI 提示词。
 
-如果你设置过自定义 `DSH_HOME`，请用该目录替换路径开头的 `$HOME/.dsh` 或 `%USERPROFILE%\.dsh`。
+## 限制与隐私
 
-不想手动改文件，也可以把下面这段话直接发给 DSH：
+Guard 保存要求、核对相符的已持久化结果，并在恢复时重新检查。证据不足或状态损坏时，它拒绝认证完成。它能守卫自身接入的 Goal 完成路径，不能控制 DSH 所有内部写入，也不替代 DSH 的权限、工具、Goal 或压缩机制。普通调查可以如实回答，并不总能获得机器完成证书。
 
-> 请把 `dsh-completion-guard` 设为 `always` 模式。根据我当前使用 DSH 的方式（Web、Headless 或 Desktop），自动找到对应的 `cordis.patch.yml`，先备份该文件，只把 `id: context-guard` 这一项的 `activation` 设为 `always`，不要修改其他配置，也不要替我重启 DSH。完成后告诉我文件的绝对路径，并显示准确的修改内容。
+Guard 保存有界、脱敏的证据摘要，不保存完整提示词、stdout、文件、凭据、图片或原始会话正文，详见[隐私说明](docs/PRIVACY.md)。磁盘安装不证明运行进程或界面已经加载；Guard 的市场重启适配器仍不可用。[兼容性说明](docs/COMPATIBILITY.md)列出可认证命令和平台边界。
 
-修改完成后，重启 DSH。
+<details>
+<summary>高级完成检查、恢复行为与上游关系</summary>
 
-## 如何检查完成状态
 
 启用后，Guard 会保存用户直接给出的要求和验收条件。只有已保存的工具结果与指定命令、文件或其他目标一致时，才能作为证据。取得机器完成认证需要通过 Guard 检查；证据缺失、过期或对象不一致时，任务保持未认证。当前证据规则未覆盖的调查或解释仍可如实回答并结束，但不会取得完成证书。
 
@@ -144,14 +106,10 @@ Guard 按原始范围保留每项要求、禁止项和答复义务。宿主记
 | `strict` | 在 standard 之上，你明确要求的视觉或完整范围验证必须由真实回读事实兑现，而不是一次"只是成功"的工具调用。 |
 | `release` | 显式采用的发布契约按精确候选和一次性预约核验受覆盖的发布操作。契约本身不提供用户授权或宿主权限。 |
 
-在 `cordis.patch.yml` 的同一项里与 `activation` 一起设置：
+若要使用 `strict`，先备份 `cordis.patch.yml`，再仅修改或添加原 `context-guard` 条目 `config` 下的 `policy`。保留启用模式、注入的宿主锁字段和其他配置。下方只展示要改的字段，不能替换完整条目：
 
 ```yaml
-- id: context-guard
-  name: dsh-completion-guard
-  config:
-    activation: always
-    policy: strict
+policy: strict
 ```
 
 ### 显式发布契约
@@ -183,6 +141,8 @@ Context Guard 负责完成认证；Goal、Todo、Compaction、continuation、权
 
 两个项目不共享运行时状态、安装器、缓存或发布历史。修复应先进入拥有对应运行时的仓库；只有同一行为确实适用于两侧时，才显式迁移。具体复用与替换边界见 [`docs/UPSTREAM_BASE.md`](docs/UPSTREAM_BASE.md) 和 [`docs/PORTING_NOTES.md`](docs/PORTING_NOTES.md)。
 
+</details>
+
 ## npm 下载量历史
 
 ![dsh-context-guard 与 dsh-completion-guard 的 npm 累计下载增长](https://raw.githubusercontent.com/GreenLv/dsh-completion-guard/stats/npm-downloads.zh-CN.svg)
@@ -191,10 +151,11 @@ Context Guard 负责完成认证；Goal、Todo、Compaction、continuation、权
 
 历史从首次公开发布 npm 的 2026-08-26 开始，保留首日真实下载数，不强行归零；纵轴从零起算。日期标签统一居中，按固定天数间隔显示，图注始终保留精确截止日。
 
-每日工作流仅发布至少相隔 12 小时复查一致、且距离当日已有两个 UTC 日历日的数据，另行标明 API 数据可用日期。这是项目的观测规则，不代表 npm 保证数值永不修订。详见[源数据](https://raw.githubusercontent.com/GreenLv/dsh-completion-guard/stats/npm-downloads.json)。
+工作流每天计划采集两次，仅发布至少相隔 12 小时复查一致、且距离当日已有两个 UTC 日历日的数据。图中分别显示历史截止日、API 数据可用日期和最近检查时间。npm 数据延迟或数值变化时，保留此前已复查的曲线，并显示等待复查；采集失败时保留上一份图。这是项目的观测规则，不代表 npm 保证数值永不修订。详见[源数据](https://raw.githubusercontent.com/GreenLv/dsh-completion-guard/stats/npm-downloads.json)和[最近采集状态](https://raw.githubusercontent.com/GreenLv/dsh-completion-guard/stats/refresh-status.json)。
 
 ## 文档
 
+- [安装与首次载入](docs/GETTING_STARTED.md) — 安全安装、首次等待及会话模式。
 - [`CHANGELOG.zh-CN.md`](CHANGELOG.zh-CN.md) — 面向使用者的版本变化。
 - [`docs/ARCHITECTURE.md`](docs/ARCHITECTURE.md) — 所有权、持久状态和认证管线。
 - [`docs/COMPATIBILITY.md`](docs/COMPATIBILITY.md) — 支持的 DSH 版本和可认证命令子集。

package/bin/dsh-completion-guard-activation.mjs

@@ -0,0 +1,95 @@
+#!/usr/bin/env node
+import { readFileSync, writeFileSync, realpathSync } from 'node:fs'
+import { createRequire } from 'node:module'
+import { pathToFileURL } from 'node:url'
+import { resolve } from 'node:path'
+import { homedir } from 'node:os'
+import { activationJson, activationCanonical, inspectActivationInventory, prepareActivationMigration,
+  readActivationMigrationReceipt, verifyMigrationInventory, adoptActivationReceipt, resolveActivationBindingsRoot,
+  scanActivationInventory, createActivationSelection, validateActivationSelection, activationSelectionPending,
+  prepareSelectedActivationMigration, verifySelectedMigrationInventory, isSelectedActivationReceipt } from '../dist/domain/index.js'
+
+const operation = process.argv[2]
+const common = ['--runtime-anchor', '--persistence-root', '--compression']
+const allowed = {
+  inventory: [...common, '--output'],
+  select: ['--inventory', '--include-file', '--output'],
+  inspect: [...common, '--prior-modes', '--output', '--selection'],
+  adopt: [...common, '--receipt', '--dsh-home', '--selection'],
+  verify: [...common, '--receipt', '--dsh-home', '--selection'],
+}
+const options = new Map()
+function option(name, optional = false) {
+  if (!options.has(name) && !optional) throw new Error(`missing ${name}`)
+  return options.get(name)
+}
+const readJson = path => activationJson(readFileSync(resolve(path), 'utf8'))
+function save(path, value) {
+  try { writeFileSync(resolve(path), activationCanonical(value) + '\n', { flag: 'wx', mode: 0o600 }) }
+  catch (error) { if (error?.code === 'EEXIST') throw new Error('activation_output_exists'); throw error }
+}
+const print = value => process.stdout.write(JSON.stringify(value) + '\n')
+async function main() {
+  if (!Object.hasOwn(allowed, operation)) throw new Error('activation_cli_usage')
+  for (let i = 3; i < process.argv.length; i += 2) {
+    const key = process.argv[i], value = process.argv[i + 1]
+    if (!allowed[operation].includes(key) || options.has(key) || !value || value.startsWith('--')) throw new Error('activation_cli_options_invalid')
+    options.set(key, value)
+  }
+  if (operation === 'select') {
+    const selection = createActivationSelection(readJson(option('--inventory')), readJson(option('--include-file')))
+    save(option('--output'), selection)
+    print({ status: 'selection_ready', includedCount: selection.include.length, selectionSha256: selection.sha256 })
+    return
+  }
+  const selection = option('--selection', true) ? validateActivationSelection(readJson(option('--selection'))) : undefined
+  const receipt = ['adopt', 'verify'].includes(operation) ? readActivationMigrationReceipt(resolve(option('--receipt'))) : undefined
+  if (receipt && !selection && isSelectedActivationReceipt(receipt)) throw new Error('activation_selection_required')
+  const anchor = realpathSync(option('--runtime-anchor'))
+  const require = createRequire(anchor)
+  const { Context } = await import(pathToFileURL(require.resolve('@deepseek-ai/cordis')).href)
+  const backendPath = require.resolve('@deepseek-ai/dsh-session-persistence-jsonl')
+  const { default: Jsonl } = await import(pathToFileURL(backendPath).href)
+  // Resolve the same dependency instance used by this physical JSONL backend.
+  const { SessionFormatUnsupportedError } = await import(pathToFileURL(createRequire(backendPath).resolve('@deepseek-ai/dsh-session-persistence')).href)
+  const ctx = new Context()
+  const compression = option('--compression', true)
+  if (compression && !['none', 'zstd'].includes(compression)) throw new Error('invalid compression')
+  const backend = ctx.plugin(Jsonl, { root: resolve(option('--persistence-root')), ...(compression ? { compression } : {}) })
+  try {
+    await backend.await()
+    const snapshot = operation === 'inventory' || selection
+      ? await scanActivationInventory(ctx.sessionPersistence, error => error instanceof SessionFormatUnsupportedError) : undefined
+    if (operation === 'inventory') {
+      save(option('--output'), snapshot)
+      print({ status: 'inventory_scanned', totalCount: snapshot.rows.length,
+        readableCount: snapshot.rows.filter(row => row.status === 'readable').length,
+        unsupportedCount: snapshot.rows.filter(row => row.status === 'unsupported').length, inventorySha256: snapshot.sha256 })
+      return
+    }
+    const inventory = selection ? undefined : await inspectActivationInventory(ctx.sessionPersistence)
+    const scope = selection ? { scope: 'receipt_selected', wholeInventoryStatus: 'not_claimed',
+      includedCount: selection.include.length, inventoryCount: snapshot.rows.length,
+      pending: activationSelectionPending(snapshot, selection) } : {}
+    if (operation === 'inspect') {
+      const prior = readJson(option('--prior-modes'))
+      const result = selection ? prepareSelectedActivationMigration(snapshot, selection, prior) : prepareActivationMigration(inventory, prior)
+      if (result.receipt) save(option('--output'), result.receipt)
+      print({ ...result, receipt: undefined, ...scope, count: selection ? selection.include.length : inventory.length,
+        ...(result.receipt ? { receiptSha256: result.receipt.sha256 } : {}) })
+      if (result.status !== 'ready') process.exitCode = 2
+    } else {
+      if (selection) verifySelectedMigrationInventory(receipt, snapshot, selection)
+      else verifyMigrationInventory(receipt, inventory)
+      const root = resolveActivationBindingsRoot(option('--dsh-home', true) ?? process.env.DSH_HOME, homedir())
+      const result = adoptActivationReceipt(root, receipt, operation === 'verify')
+      print({ ...result, ...scope, status: selection ? (result.status === 'complete' ? 'selected_complete' : 'selected_partial') : result.status })
+      if (result.status !== 'complete') process.exitCode = 2
+    }
+  } finally { await ctx.fiber.dispose() }
+}
+main().catch(error => {
+  const message = error instanceof Error && /^(?:activation_[a-z_]+|missing --[a-z-]+|invalid compression)$/u.test(error.message)
+    ? error.message : 'activation_cli_failed'
+  process.stderr.write(JSON.stringify({ status: 'unavailable', reason_code: message }) + '\n'); process.exitCode = 1
+})