dsh-completion-guard 0.8.1 → 0.8.2

package/docs/COMPATIBILITY.md

@@ -2,6 +2,46 @@
 
 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.8.2: DSH >=0.2.0-rc.2 and official Desktop
+
+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 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.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 不会回退到平铺目录路径。
+
+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.

package/docs/DEVELOPMENT_PLAN_DSH_0_2_0_RC2_DESKTOP.md

@@ -0,0 +1,85 @@
+# Completion Guard：DSH RC.2 与 Desktop 开发任务
+
+本任务在 `dsh-context-guard` 仓库内独立完成。公开仓库及 npm 产品名是 `dsh-completion-guard`，Cordis entry id 仍为 `context-guard`。目标是把最低支持版本提高到 DSH `0.2.0-rc.2`，支持官方 Desktop，并在本次适配中完成全仓审阅、修复已复现的功能、性能和安全问题。实现完成后交给另一个 Codex 线程独立验收；本文件不是已经通过的实现或发布证明。
+
+## 1. 基线与工作边界
+
+2026-09-30 的调查基线是 `b18d31dda7fdecae5c6496446f33238ea945a93a`、插件 `0.8.1`，调查开始时工作区干净。启动开发时重新读取 HEAD、分支、dirty paths、AGENTS 和工具链，保留非本任务改动。基线变化不自动改变本文件的功能要求。
+
+最低版本是固定策略 `>=0.2.0-rc.2`，最新实际测试宿主暂定 RC.2；构建依赖和测试 runtime 则使用精确 RC.2。三者分别记录。未来升级不自动追随 registry `latest` 提高下限；高于下限的宿主不能因为未列入测试清单而被拒绝。实际 API、完整性或行为不合格仍必须拒绝相应能力。
+
+本轮准备已把本机 Web runtime 升至 RC.2，官方 Desktop 也为 RC.2。现有 Guard 保留安装但暂时禁用；旧 RC.1 host lock 保留用于恢复，不能直接用于 RC.2。当前状态及私有回读在 codex-sync 的 RC.2 准备记录中，不能当成新插件验收。
+
+本仓库自行设计、实现、检查和交付，不依赖 Session Insights 的进度或发布。开发 harness 不修改另一个插件、codex-sync 的消费者 pins、日常 runtime 或 Desktop app bundle。需要消费者适配时返回明确的适配要求。不要发布 npm、创建 tag/Release、推送、迁移日常 profile 或启用日常插件；这些是后续独立操作。分支采用 `codex/` 前缀，按平台权限执行。
+
+## 2. 已核实的上游与源码事实
+
+- [官方 RC.2 发布页](https://github.com/deepseek-ai/deepseek-harness/releases/tag/dsh-v0.2.0-rc.2)，tag `dsh-v0.2.0-rc.2`，发布关联提交 `639ed01`。相关变化包括 Desktop 官方 dsh 命令、图形启动的登录 shell 环境、PowerShell 完成状态识别、定时消息语义及实验性异步问答。
+- RC.2 官方 `dsh-app-boot` 的 `evaluatePluginCompatibility()` 使用 `includePrerelease: true` 检查 DSH peers。必须用这个真实消费者及市场消费者验证范围，不能只测普通 node-semver。
+- 现有 `src/domain/host-version.ts` 已把最低版本与 `HOST_VALIDATED_VERSIONS` 分离；`host-lock.ts`、`host-trust.ts`、`host-resolver.ts` 和 `host-contract-program.ts` 已有 graph-derived registry rebind 路径。保留它，不能退回“每个新版本加一行才支持”的实现。
+- `HostProfileKind` 只有 `web | headless`；profile 识别、目标图、lock 注入和 native 工具均没有正式 Desktop 分支。`resolveActiveProfileHostLock()` 用 Web bundle/market 推断 profile，Desktop 也包含 Web app bundle，不能沿用该推断。
+- 现有源码测试基线（RC.1 测试依赖）：`pnpm test` 为 169 个文件通过、1 个文件跳过；2812 个测试通过、7 个跳过。只建立现有源码基线，不建立 RC.2、Desktop、新 tgz 或新模型行为证据。
+
+## 3. 本次问题登记
+
+| ID | 级别与状态 | 定位与影响 | 结案要求 |
+| --- | --- | --- | --- |
+| CG-RC2-001 | 必须实现；已确认 | package.json 的双层 engines/DSH peers，`host-version.ts`、RC.1 manifest/dev pins：下限仍为 RC.1 | 所有当前准入面统一 RC.2 下限；RC.1 拒绝，后续 RC/stable 接受版本准入；历史记录保持原事实 |
+| CG-RC2-002 | 必须实现；已确认 | `host-lock.ts`、`host-resolver.ts`、`config.ts`、bin、native scripts：Desktop 缺失且可被误识别为 Web | 显式 Desktop 身份、正确官方 CLI/Node/包图、独立 profile-bound lock 和生命周期证据 |
+| CG-RC2-003 | P2；强制测量后结案 | `runtime.ts` 的 `rebuild()`、`sync()`，`session-events.ts` 与 private-ledger：反复全日志投影；host audit 是同步 I/O | 测事件数/entry 次数/文件读取/耗时和峰值资源；可复现回退必须修复。不得凭猜测新增跨 entry 信任缓存 |
+| CG-RC2-004 | 语义适配；强制设计与复现 | RC.2 schedule 产生 `source.kind=schedule` 的 user message；`derive.ts` 对 root input 只接受 `kind=user` | 明确定时指令/用户授权继承策略，覆盖真实生产路径；不能简单把所有 schedule 或 role=user 都升级成 root authority |
+| CG-RC2-005 | 审阅风险；待复现 | RC.2 异步问答、late answer、取消、resume、子代理通知与 Stop/Goal/boundary 状态交互 | 无提前结案、重复 capture、错误暂停或旧证书复用；实验功能关闭/开启分别检查适用行为 |
+
+CG-RC2-004 的合成对照已在提交的 dist/domain 运行：相同 user-role 文本，`source.kind=user` 得到 `realRootInputSeen=true`，`kind=schedule` 得到 false。它证明现行来源分类差异，尚不证明新的授权策略应当如何实现。必须核对实际定时任务记录、用户授权与宿主投递关系，再决定适配或保留限制并给出理由。
+
+对于新增发现：先建立最小复现和稳定 ID，记录影响、共同原因、修复与回归。不能把猜测写成已确认漏洞，也不能以“这只是审阅”略过已复现的本次范围内问题。低价值重构和新产品功能可列 backlog，必须说明边界。
+
+## 4. 设计与实现要求
+
+### 版本准入与宿主资格
+
+1. 同步顶层 `engines.dsh`、`dsh.engines.dsh`、各 DSH peer 最低值、运行时 floor、支持 manifest、生成工具、当前 README/兼容性/迁移文档及 fixture identity。dev pins 和实际测试 runtime 精确绑定 RC.2；Cordis 单独验证，不因 DSH 版本一起随意放宽。
+2. 版本向量至少含：RC.1、RC.2、RC.3、0.2.0 stable、0.2.1-rc.1、0.3.0-rc.1、1.0.0、带 build metadata 的 RC.2、非法值。未来版本仅做消费者/生产准入合成测试，不谎称真实宿主验收。
+3. RC.2 关键包从官方 archive/SRI 重新研究，报告实际 API/程序/依赖与 RC.1 差异。保留旧 manifest 的历史用途；新的资格证明必须绑定所有实际选中 executable/JSON inventory、ESM/CJS 路由、Node conditions 和依赖身份。
+4. 验证“新但兼容的程序经生产 rebind 可以资格化”和“API/行为/字节/路由破坏被拒绝”。不能用测试 seam、复制已签信任、仅换版本字串或只扩 cohort 表来替代。
+5. 核对 Goal、jobs、shell、fs、session flush 的必要/可选能力边界；缺可选 Goal 时只按既定策略禁用 Goal，不把整套 core 误报支持或全部瘫痪。
+
+### Desktop
+
+1. 使用官方 app 的命令 carrier 与 bundled Node/pnpm。Web/Headless 仍使用显式管理的 CLI runtime。PATH 上同名 dsh、系统 Node、临时 npm CLI 均不是 Desktop 身份替代物。
+2. 读取 app/runtime/host/primary metadata、profile bundles、实际 import graph 和真实解析路由。app.asar/安装型图没有 pnpm `.package-map.json` 时设计真实适配器；不能伪造 map，也不能把 app bundle 解包后当作官方运行图。
+3. Desktop profile 身份独立进入 digest、trust receipt、lock、config schema 和 native annex。Web lock 或证书不得复制到 Desktop；app 或 profile 路径别名、同名包 shadow、混合图、错误 Node startup conditions 均需负例。
+4. 扩展 repository-owned host-lock/native 工具：显式选择 Desktop，不要求 CLI 启动桌面 UI；通过官方图形启动/退出处理生命周期，安装前检查主程序及 host children 已退出，尤其 Windows 原生模块占用。
+5. 升级与重装保留模型/MCP、bundles、禁用偏好、skins、日常数据和 account state；备份、atomic apply、失败恢复及第二次严格 no-op。不要改 app.asar 或绕过 Desktop 保留 profile 管理。
+
+### 全仓审阅与性能
+
+至少逐项覆盖：root capture/附件及引用授权、work units/supersession、evidence/target/locator/digest、checkpoint/closure/Stop、Goal、recovery/compaction/replay、private ledger/损坏恢复、external operations/jobs/用户暂停、release reservation/settlement、shell/pwsh/fs/native adapters、host version/graph/trust/rebind、CLI/安装/迁移、公开隐私、双语文档、pack inventory/CI。包含提交的 dist、manifests、tests、scripts、bin 和 npm 文件表；文档里的宣称也要对照实际执行入口。
+
+提交覆盖表：模块/阅读位置/生产入口/现有测试/新增复现/结案或残余风险。审阅不是给所有目录标一个“看过”。特别检查 RC.2 PowerShell 末尾空格/退出码、unknown tool outcome 不能成为成功或确定失败、late user answer 不能串 turn、历史工具文本不能创建 authority。
+
+性能至少对 0、100、1000、10000 个事件和短/长私有账本测量，包含长 tool output；同一宿主同一环境各 5 次，报告中位数与 p95、物理读取次数/字节、投影次数和峰值 RSS。性能 harness 的 synthetic/source/native 分类必须明确。修复重复解析/无界输入/泄漏时保留新鲜的 pre-effect host validation、durability 与 fail-closed；无可复现回退可用有依据的“无需变更”结案。
+
+## 5. 开发、打包与验收
+
+先关闭复现问题，再做完整 candidate gate。按 AGENTS 的完整矩阵：typecheck、lint、Vitest、release-pack tests、stats tests、build、pack dry run、文档 audit 及其测试、`git diff --check`；build 后核对 dist 无意外漂移。选择器和 repair-families 可用于修复阶段，不代替 freeze 矩阵。
+
+最终按仓库干净源码要求提交一个本任务候选 commit（若接收线程的实际权限允许）；不要混入 unrelated changes。使用 `scripts/release-pack.mjs` 生成唯一 tgz、SHA256SUMS 和 release-artifact。新版本原暂建议 0.9.0；独立复核确认未改变任务、证书或数据协议，按维护者的版本连续性要求采用 0.8.2；不占用已发布版本。不在不同平台重打包，不提前发布。
+
+| Gate | 独立验收要检查的事实 |
+| --- | --- |
+| G1 源码与准入 | RC.2 floor、真实 DSH/market 消费者、未来版本合成向量、Core/Goal 资格与拒绝路径；全仓问题登记结案 |
+| G2 portable/CI | repository-owned 实际生产入口、RC.2 契约、跨 OS/Node 矩阵；不将 fixture pass 报成原生通过 |
+| G3 制品 | 全 commit、tgz SHA256、嵌入 gitHead、安装文件 inventory、clean source、dist 同步 |
+| G4 macOS native | 同一 tgz 的 Web、Headless、官方 Desktop 安装、strict no-op、lock/字节/路由、启动/取消/重启/恢复、卸载/清理与状态还原 |
+| G5 Windows native | 独立执行同样三种宿主；Desktop 真 app、pwsh/shim/原生模块占用，不用 macOS 或 CI 代替 |
+| G6 行为与页面 | 非空真实生产路径的 capture→checkpoint→Stop，未满足拒绝、满足允许、暂停/等待/Goal/compaction；Desktop 实际设置和插件状态；必要的模型批次单独绑定来源和结果 |
+| G7 文档 | 中英文 README/CHANGELOG/兼容性/升级操作清晰且事实一致；最终字节 cold review，公开面无私有路径/真实会话 |
+
+初始开发验收至少完成 G1–G3 和可用平台的 G4/G5；缺少平台或模型能力必须保留 pending，不能整体标“支持 Desktop 已验收”。独立 Codex 验收最终关闭所需平台/模型/UI gates，输出逐项结果，不把发布或消费者 apply 混入开发结论。真实模型沿用现有登录，不因隔离 HOME 重做登录；未运行的部分明确给出 owner 和 resume event。
+
+## 6. 返回给独立验收线程
+
+交付一个聚合 handback：候选 commit/dirty 状态与任务 diff；稳定问题 ID、复现及修复解释；全仓审阅覆盖与性能数据；源码/CI/制品/native/模型/UI 各自的命令、结果和 subject identity；唯一 tgz 与 checksum/inventory；final reader-review；公开可用的迁移说明；仍待验收项、未执行外部操作和恢复方法。使用 `agent-handoff/v1`，不要返回真实会话或原始凭据日志。
+
+独立 Codex 线程先阅读这个 handback、检查 subject 和差异，再对缺失或失效的 gate 验收。修复回合只重跑受影响 gates，重复同类失败时审查共同原因及所有入口，不重复无关通过项。

package/docs/HOST_LOCK_UPGRADE.md

@@ -1,8 +1,8 @@
 # Upgrading the core host lock
 
-Version 0.8.1 requires DSH `>=0.2.0-rc.1` and qualified Cordis `>=4.0.4`. Upgrade order and what each step produces:
+Version 0.8.2 requires DSH `>=0.2.0-rc.2` and qualified Cordis `>=4.0.4`. Upgrade order and what each step produces:
 
-1. Stop the host, upgrade DSH to `0.2.0-rc.1` or a later version, then install this Guard version.
+1. Stop the host, upgrade DSH to `0.2.0-rc.2` or a later version, then install this Guard version.
 2. Rebuild the host lock for each Guard profile by running `inspect`, `inject` and `verify-dump` from an accepted package or matching source checkout:
    `node bin/dsh-completion-guard-host-lock.mjs inject --runtime-root <DSH runtime> --profile-root <profile>` — then verify with `... verify-dump --dump-config <file>`. A successful rebuild reads back `supported` with `audit_provenance` stating how the graph was established.
 3. Start each Web/Headless profile when needed so it reads the rebuilt lock. The checks above do not require a running host.
@@ -10,11 +10,11 @@ Version 0.8.1 requires DSH `>=0.2.0-rc.1` and qualified Cordis `>=4.0.4`. Upgrad
 Failure readbacks distinguish these cases:
 
 - `host_lock_migration_required`: the configuration lacks the policy or source roots. Supply `--runtime-root` and `--profile-root` when rebuilding the lock.
-- `host_lock_version_below_minimum`: DSH is older than `0.2.0-rc.1`. Upgrade DSH first.
+- `host_lock_version_below_minimum`: DSH is older than `0.2.0-rc.2`. Upgrade DSH first.
 - `host_lock_version_mismatch`: the installed graph differs from the reviewed baseline in version or integrity. For a later compatible version, use `--rebind-registry` to acquire and qualify the published graph. For the baseline, restore the recorded identities.
 - `host_lock_installed_graph_drift`: installed bytes or routes changed after the audit. Inspect the change before rebuilding the lock.
 
-The floor is `>=0.2.0-rc.1` with no upper bound. Passing the version check does not establish native validation; validated versions are recorded separately. Guard's exact DSH core is separate from optional market versions.
+The floor is `>=0.2.0-rc.2` with no upper bound. Passing the version check does not establish native validation; validated versions are recorded separately. Guard's exact DSH core is separate from optional market versions.
 A normal market update no longer changes the core digest. A plugin that changes
 which core packages actually resolve still invalidates the lock.
 
@@ -66,7 +66,7 @@ profile remains a separate user action.
 
 A DSH Headless profile can have no external dependencies and no private `node_modules` or lockfile. From an accepted package or matching source checkout, `node bin/dsh-completion-guard-host-lock.mjs inspect-graph --runtime-root <runtime> --profile-root <profile>` checks that state without initializing or launching the profile.
 
-This narrow case requires exactly the installation-owned `dsh-base` and `dsh-headless` bundles, a complete audited runtime core, and matching bundle versions, package-map origins and patch files. Declared but uninstalled dependencies, partial map/lock pairs, unexplained local modules and foreign parent-module fallbacks are rejected. Existing profiles with both graph files retain their active-importer checks; damaged files are not treated as an empty graph.
+This narrow case requires the installation-owned `dsh-base` and `dsh-headless` bundles, with the RC.2 `dsh-web-app` bundle allowed between them, a complete audited runtime core, and matching bundle versions, package-map origins and patch files. Declared but uninstalled dependencies, partial map/lock pairs, unexplained local modules and foreign parent-module fallbacks are rejected. Existing profiles with both graph files retain their active-importer checks; damaged files are not treated as an empty graph.
 
 The result labels `inspection_scope: pre_install_target` and `profile_graph.state: dependency_free_headless`, with the manifest hash and bundle identities. Its package rows describe the verified runtime core used for this installation target, not a private profile importer or a live boot. After installing Guard, the `inspect`, `inject` and runtime replay checks still require the profile's package map, lockfile and installed plugin binding. This pre-install result cannot replace those checks.
 
@@ -81,7 +81,7 @@ certificate authority — completion certificates, mutation authorization,
 release pre-effect decisions and Goal/Stop boundaries — validates the lock
 freshly at the moment of its own decision.
 
-Version 0.8.1 registers `dsh-0.2.0-rc.1-core-v1` as the audited baseline cohort and derives graph cohorts for compatible hosts above the version floor (see the compatibility guide). Runtime checks authenticate the mapped files and verify that each critical dependency resolves to the mapped instance. Installation imports use native Node resolution; Profile imports use the host's local-first routing and installation fallback only when no local package is selected. A nearer shadow, missing edge, wrong export target or escaped path is rejected even when the recorded versions match.
+Version 0.8.2 registers `dsh-0.2.0-rc.2-core-v1` as the audited baseline cohort and derives graph cohorts for compatible hosts above the version floor (see the compatibility guide). Runtime checks authenticate the mapped files and verify that each critical dependency resolves to the mapped instance. Installation imports use native Node resolution; Profile imports use the host's local-first routing and installation fallback only when no local package is selected. A nearer shadow, missing edge, wrong export target or escaped path is rejected even when the recorded versions match.
 
 The manifest's `registry-derived-pending-native-audit` provenance and empty `auditedPlatforms` list describe its immutable source audit, which is part of the lock digest. Native acceptance belongs to each exact artifact's separate Release annexes; it does not rewrite that digest. Inspection, injection and dump verification report `audit_provenance` alongside the cohort and digest.
 
@@ -100,9 +100,31 @@ that matters for deciding whether you are migrating or just drifting:
   a DSH upgrade, and both are cured by re-running inspect, inject and verify against
   the new runtime rather than by editing the lock.
 
-Historical requirements and session records are retained; old certificates do not become certificates for the new lock. Historical host cohorts are test data only and are not accepted by 0.8.1.
+Historical requirements and session records are retained; old certificates do not become certificates for the new lock. Historical host cohorts are test data only and are not accepted by 0.8.2.
 The shared digest-v3 encoder and its upstream fixtures are unchanged.
 
+## Official Desktop profile
+
+Stop the Desktop app before installing or rebuilding its lock. Use the CLI carrier shipped with that app: `Contents/Resources/runtime/cli/bin/dsh` on macOS, or `resources\runtime\cli\bin\dsh.cmd` in the Windows installation. A separately installed `dsh` CLI cannot manage the reserved Desktop profile.
+
+Install Guard through that carrier with `plugin --profile desktop add dsh-completion-guard@0.8.2`. Use the profile's own host-lock tool and the app's physical `app.asar` as `--runtime-root`. The default profile is `$DSH_HOME/profiles/desktop`, or `.dsh/profiles/desktop` under the user's home when `DSH_HOME` is unset. This POSIX example starts after installation:
+
+```sh
+DSH_DESKTOP_ASAR=/absolute/path/to/DeepSeek-Harness.app/Contents/Resources/app.asar
+DSH_DESKTOP_PROFILE=/absolute/path/to/.dsh/profiles/desktop
+GUARD_DESKTOP_LOCK="$DSH_DESKTOP_PROFILE/node_modules/.bin/dsh-completion-guard-host-lock"
+"$GUARD_DESKTOP_LOCK" inspect --profile desktop --runtime-root "$DSH_DESKTOP_ASAR" --profile-root "$DSH_DESKTOP_PROFILE"
+"$GUARD_DESKTOP_LOCK" inject --profile desktop --runtime-root "$DSH_DESKTOP_ASAR" --profile-root "$DSH_DESKTOP_PROFILE"
+"$GUARD_DESKTOP_LOCK" dump-desktop --profile desktop --runtime-root "$DSH_DESKTOP_ASAR" --profile-root "$DSH_DESKTOP_PROFILE" > desktop-composed.yml
+"$GUARD_DESKTOP_LOCK" verify-dump --profile desktop --runtime-root "$DSH_DESKTOP_ASAR" --profile-root "$DSH_DESKTOP_PROFILE" --dump-config desktop-composed.yml
+```
+
+On Windows use the `.cmd` host-lock launcher and the installation's `resources\app.asar` path. `dump-desktop` authenticates the carrier and uses the app's bundled configuration APIs to compose the same bundle/profile/home layers, without starting a host. It writes the profile's empty loader anchor as the official dump API does. Preserve any composed output privately because user configuration may contain secrets; it is not a Release attachment.
+
+Check `supported` on inspect, inject and verify-dump. Keep Desktop stopped until all checks pass, then open the app when needed. Guard never edits the app archive or restarts the graphical app.
+
+Desktop 升级顺序相同：先停止应用并升级宿主，再用应用附带的 CLI 安装 Guard。普通外部 CLI 无法管理保留的 Desktop profile。以应用的 `app.asar` 和实际 Desktop profile 路径执行 `inspect`、`inject`、`dump-desktop`、`verify-dump`，确认三项 JSON 回读均为 `supported` 后再打开应用。`dump-desktop` 不启动宿主；配置输出可能包含私人信息，请留在本机。Guard 不修改应用归档，也不负责应用重启。
+
 ## Market and restart
 
 Core compatibility does not certify the optional market restart adapter.
@@ -132,7 +154,7 @@ exact artifact and platform; publication is recorded on its GitHub Release.
 
 ## Historical 0.5.1 evidence
 
-Version 0.5.1 registered DSH `0.1.5-rc.1` and `0.1.5-rc.2` with 33 critical packages. Its macOS and Windows results belong only to that artifact and those hosts; see the [0.5.1 release annexes](https://github.com/GreenLv/dsh-completion-guard/releases/tag/v0.5.1). These are historical records, not installation targets for 0.8.1.
+Version 0.5.1 registered DSH `0.1.5-rc.1` and `0.1.5-rc.2` with 33 critical packages. Its macOS and Windows results belong only to that artifact and those hosts; see the [0.5.1 release annexes](https://github.com/GreenLv/dsh-completion-guard/releases/tag/v0.5.1). These are historical records, not installation targets for 0.8.2.
 
 ## Rebinding compatible package versions
 

package/docs/LOCAL_ACCEPTANCE.md

@@ -1,5 +1,15 @@
 # Local Acceptance
 
+## 0.8.2 RC.2 and Desktop acceptance
+
+The candidate keeps the 0.8.x task, certificate and data protocols. Its changed host floor is DSH `0.2.0-rc.2`; use the [upgrade guide](HOST_LOCK_UPGRADE.md) before establishing a new lock. The [development plan](DEVELOPMENT_PLAN_DSH_0_2_0_RC2_DESKTOP.md) defines the source, portability, exact-package, native, model and reader gates.
+
+Run the repository entrypoint twice for each native platform, always with the same frozen tgz and source commit. `host_bound_v070` covers Web/Headless. `desktop_bound` takes the physical app archive as `--runtime-root` and the exact DSH version as `--desktop-cohort`; it creates an isolated profile and uses the signed app's bundled CLI and actual Electron Node backend. Pass `--preflight` to each intended command before execution, with distinct unused external output and transfer-receipt paths.
+
+The Desktop backend annex uses `dsh-desktop-bound/v1`. It covers carrier/graph authentication, installation parity, strict second no-op, injection and real composed readback, loaded Guard behavior, graceful stop, uninstall and cleanup. It expressly skips `graphical_shell` and `real_model_request`. Those skips require separate GUI/model evidence before the complete Desktop release gate closes. Portable tests, source composition against a real archive and a backend annex cannot substitute for those observations.
+
+每个平台分别运行 Web/Headless 与 Desktop 原生入口，绑定同一份最终 tgz、源码提交及摘要。Desktop 使用 `--gate-profile desktop_bound --runtime-root <app.asar> --desktop-cohort 0.2.0-rc.2`，先加 `--preflight` 做同一次调用环境的能力预检，再去掉该参数执行。该入口在隔离 profile 中验证官方载体、安装字节、严格 no-op、组合配置、实际加载与卸载，并输出独立 annex；它不启动图形界面、不请求真实模型，二者须单独补齐。具体结果留在对应制品的外部回执和 Release 附件，避免文档自引用造成制品身份变化。
+
 ## 0.8.0 rc.2 source-stage snapshot
 
 The [A01–A16 source-stage snapshot](DSH_0_1_7_RC2_ACCEPTANCE.md) records development checks before exact-artifact acceptance. Final CI, platform and model results belong to the matching artifact receipts and Release attachments. This source snapshot neither predicts those results nor transfers earlier acceptance to the changed rc.2 adapter.

package/docs/RELEASE_NOTES_0_8_2.md

@@ -0,0 +1,21 @@
+# DSH Completion Guard 0.8.2
+
+## English
+
+This release adapts Guard to DSH RC.2 and adds an independent host lock for the official Desktop app. It keeps the 0.8.x task, certificate and data protocols. It also fixes shell evidence that could mistake an obscured failure marker for success.
+
+Upgrade DSH to `0.2.0-rc.2` or later before installing Guard. Keep the host stopped while installing, inspecting and injecting the new lock, and verifying the composed configuration. Each profile needs its own lock; existing certificates retain their historical identity. Follow the [upgrade guide](HOST_LOCK_UPGRADE.md).
+
+For Desktop, use the CLI shipped with the application to install plugins. Guard checks the vendor-signed carrier, archive bytes and actual dependency routes. Its `dump-desktop` command composes configuration through the bundled APIs without starting a host. The graphical app owns its restart lifecycle.
+
+The reviewed baseline is DSH `0.2.0-rc.2` with Cordis `4.0.4`. Later versions require implementation qualification. Source checks, portability CI, same-artifact native backend acceptance, GUI/model observations and public publication identity have separate evidence. Use the Release attachments for the exact commit, package checksum and platform scope; see [compatibility](COMPATIBILITY.md) and [acceptance](LOCAL_ACCEPTANCE.md).
+
+## 简体中文
+
+本版本适配 DSH RC.2，并为官方 Desktop 应用新增独立宿主锁；任务、证书与数据协议延续 0.8.x。同时修复 shell 失败退出标记被后续文字遮挡时可能误报成功的问题。
+
+请先将 DSH 升级到 `0.2.0-rc.2` 或更高版本，再安装 Guard。安装、检查、注入新锁及回读组合配置期间保持宿主停止；每个 profile 分别建立锁，旧证书保留历史身份。具体步骤见[升级指南](HOST_LOCK_UPGRADE.md)。
+
+Desktop 插件须通过应用附带的 CLI 安装。Guard 核验厂商签名载体、归档字节与实际依赖路由；`dump-desktop` 通过应用内 API 组合配置，不启动宿主。图形应用的重启仍由应用自行管理。
+
+已审查基线是 DSH `0.2.0-rc.2`、Cordis `4.0.4`；较新版本仍须通过实现资格验证。源码检查、跨平台 CI、同包原生后端、GUI/模型观察与公开发布身份分别建立证据。请用 Release 附件核对精确提交、包摘要和平台范围；详见[兼容性](COMPATIBILITY.md)及[验收记录](LOCAL_ACCEPTANCE.md)。