dsh-completion-guard 0.10.0 → 0.12.0

package/docs/ACTIVATION_MIGRATION.md

@@ -1,8 +1,20 @@
 # Session activation migration / 会话启用模式迁移
 
-This guide covers upgrades to **0.10.0**, including upgrades from **0.9.0**. Since 0.9.0, `always` has been the default for **new unseeded root sessions**. A write-once private binding preserves each old session's pre-upgrade effective mode. Mode is independent of `standard` policy, execution/publication authority and completion certificates. Empty old sessions belong in the inventory too. Recorded off/on continues to control enablement; neither configuration nor adoption re-signs history.
+A host already at DSH `0.2.1-rc.3` may follow this migration without first upgrading to rc.5, provided its own host graph passes qualification.
 
-本指南用于升级到 **0.10.0**，包括从 **0.9.0** 升级。自 0.9.0 起，**新建无继承根会话**的默认模式为 `always`，旧会话通过不可覆盖私有绑定保留升级前有效模式。模式独立于 `standard` 策略、执行与发布权限及完成证书。旧空会话也必须清点，已记录的 off/on 继续控制启用状态；配置及 adoption 都不重签历史。
+已使用 DSH `0.2.1-rc.3` 的宿主无需先升级到 rc.5，即可按本流程迁移；其宿主图仍须通过相应资格核验。
+
+This guide covers upgrades to **0.12.0**, including upgrades from **0.11.0**, 0.10.0 and earlier supported lines. Since 0.9.0, `always` has been the default for **new unseeded root sessions**. A write-once private binding preserves each old session's pre-upgrade effective mode. Mode is independent of `standard` policy, execution/publication authority and completion certificates. Empty old sessions belong in the inventory too. Recorded off/on continues to control enablement; neither configuration nor adoption re-signs history.
+
+本指南用于升级到 **0.12.0**，包括从 **0.11.0**、0.10.0 及更早支持线升级。自 0.9.0 起，**新建无继承根会话**的默认模式为 `always`，旧会话通过不可覆盖私有绑定保留升级前有效模式。模式独立于 `standard` 策略、执行与发布权限及完成证书。旧空会话也必须清点，已记录的 off/on 继续控制启用状态；配置及 adoption 都不重签历史。
+
+The CLI checks the physical JSONL inventory against the official reader before `inventory`, `inspect`, `adopt` and `verify`. It supports JSONL backends whose executable modules and loader shape match the reviewed rc.3/rc.5 implementation, including byte-equivalent version relabels, with `none` or `zstd` encoding. Changed or unreviewed implementations are refused. The proof binds the actual backend, resolved serialization inputs and Node compression version; it is not independent authentication of every dependency. The physical census streams complete session files to hash their bytes without parsing or emitting their bodies; the official read-only open may parse session data to verify it; runtime and I/O cost grow with total stored bytes. Keep writers stopped. Hidden or corrupt logs, future generations, links, unknown layouts and directories with multiple generations fail closed. A listed older format that the official `open` explicitly rejects can still be left pending in a selected scope; an item hidden by `list` cannot be assigned a fabricated identity.
+
+The proof binds the supplied physical root, compression, reviewed backend and file identities and contents. It does **not** establish that the supplied root is the active configuration: the operator or manager must verify that independently. An existing ordinary empty root can produce a zero-row inventory, but cannot produce a migration receipt. Missing roots fail. Backend, root, encoding or file changes require a fresh inventory and inspection. Receipts created before physical proofs existed are refused with `activation_inventory_proof_required`; preserve them and regenerate `inventory`, any selection, and `inspect` under the matching configuration.
+
+CLI 在 `inventory`、`inspect`、`adopt`、`verify` 前将物理 JSONL 库存与官方读取器逐项核对。目前支持可执行模块和加载结构与已审查 rc.3/rc.5 实现一致的 JSONL 后端（包括字节相同的版本重标）以及 `none`、`zstd` 编码；变化或未经审查的实现会被拒绝。证明绑定实际后端、解析到的序列化输入及 Node 压缩版本，不独立认证所有依赖。物理盘点流式读取完整会话文件计算摘要，不解析或输出正文；官方只读 open 可能解析会话数据以进行核验。耗时和 I/O 随库存总字节数增长。全程停止写者。隐藏或损坏日志、未来代际、链接、未知布局和同一目录多代并存均拒绝；官方 `list` 已列出且 `open` 明确拒绝的旧格式仍可在选择范围中保持 pending，不能为被 `list` 隐藏的项目伪造身份。
+
+证明绑定所传物理根、压缩方式、已审查后端以及文件身份和内容，**不证明所传目录就是当前配置**；操作者或管理器须独立核对。已存在的普通空根可产生零行库存，但不能生成迁移收据；缺失根拒绝。后端、根、编码或文件变化后须重新 inventory 和 inspect。没有物理证明的旧收据会以 `activation_inventory_proof_required` 拒绝；保留原记录，并在匹配配置下重新 inventory、按需选择和 inspect。
 
 ## Prepare before changing the installed version / 升级前准备
 
@@ -27,9 +39,9 @@ Prepare an operator-owned JSON file in the following format. `previousPackage.sh
 }
 ```
 
-The 0.10.0 toolkit accepts verified prior-mode records for predecessor versions `0.0.x`–`0.9.x`, including `0.9.0`. It refuses `0.10.0` as a prior package.
+The 0.12.0 toolkit accepts verified prior-mode records for predecessor versions `0.0.x`–`0.11.x`, including `0.11.0`. It refuses the current version and anything newer as a prior package.
 
-0.10.0 工具接受前驱版本 `0.0.x`–`0.9.x` 的已核验旧模式来源，包括 `0.9.0`；不能把 `0.10.0` 本身作为旧包。
+0.12.0 工具接受前驱版本 `0.0.x`–`0.11.x` 的已核验旧模式来源，包括 `0.11.0`；当前版本及更新的版本不能冒充旧包。
 
 ## Official old-format refusals and an explicit readable subset / 官方旧格式拒绝与显式可读子集
 
@@ -95,16 +107,16 @@ When a later official host supports the pending format, use its **read-only** pe
 
 ### Copyable migration prompts / 可复制迁移提示词
 
-> Help me migrate session activation to DSH Completion Guard 0.10.0. Lifecycle constraint: [fill in which writers may be stopped and whether restart is allowed]. Reuse scope, write and lifecycle authorization already supplied in this conversation; ask only for missing or materially changed decisions. First report the current host/persistence/compression settings, preserved predecessor package identity (for example 0.9.0) and sanitized pre-upgrade effective-mode sources. If they cannot be verified, keep affected sessions pending. Do not replace packages, stop/restart processes or write bindings before that lifecycle and mutation authority is established. Run the packaged read-only inventory command; show total/readable/official-format-refused counts and a local pending report. Use my existing explicit selection, or ask me to choose the included scope if none was supplied; do not silently expand it or treat readability alone as authorization. Bind that explicit selection through inspect/adopt/verify, detect all inventory changes, preserve raw logs and old sources, and never infer modes/origin/cuts from paths, dates or event counts. No log bodies, credentials or private IDs leave my machine. Once the scope and writes are covered by my authorization, adopt, repeat to check no-op, and verify; report selected completion and remaining pending separately. For unsupported rows, give the future official-reader/re-inventory/source-validation route; without a recoverable source, keep pending or use a new session. Do not treat old certificates as new authority.
+> Help me migrate session activation to DSH Completion Guard 0.12.0. Lifecycle constraint: [fill in which writers may be stopped and whether restart is allowed]. Reuse scope, write and lifecycle authorization already supplied in this conversation; ask only for missing or materially changed decisions. First report the current host/persistence/compression settings, preserved predecessor package identity (for example 0.9.0) and sanitized pre-upgrade effective-mode sources. If they cannot be verified, keep affected sessions pending. Do not replace packages, stop/restart processes or write bindings before that lifecycle and mutation authority is established. Run the packaged read-only inventory command; show total/readable/official-format-refused counts and a local pending report. Use my existing explicit selection, or ask me to choose the included scope if none was supplied; do not silently expand it or treat readability alone as authorization. Bind that explicit selection through inspect/adopt/verify, detect all inventory changes, preserve raw logs and old sources, and never infer modes/origin/cuts from paths, dates or event counts. No log bodies, credentials or private IDs leave my machine. Once the scope and writes are covered by my authorization, adopt, repeat to check no-op, and verify; report selected completion and remaining pending separately. For unsupported rows, give the future official-reader/re-inventory/source-validation route; without a recoverable source, keep pending or use a new session. Do not treat old certificates as new authority.
 
-> 帮我迁移到 DSH Completion Guard 0.10.0 的会话启用模式。生命周期约束：[填写允许停止的写者及是否允许重启]。沿用本会话已给出的范围、写入及生命周期授权，仅询问缺失或实质变化的决定。先报告现有宿主、持久化目录/压缩配置、保留的前驱包（如 0.9.0）身份及脱敏的升级前有效模式来源；不能核验就将受影响会话保持 pending。取得明确生命周期和写入权限前，不替换包、不停/重启进程、不写绑定。运行打包工具的只读 inventory，报告总数/可读/官方格式拒绝数量并保存本地 pending 报告；沿用我已明确选择的范围，尚未选择时再请我决定；不静默扩大范围，也不把可读性本身当作授权。让显式 selection 贯穿 inspect/adopt/verify，检测全部库存变化，保留原日志和旧来源，不按路径、日期、事件数猜模式/origin/cut。正文、凭据、私有 ID 不离开本机。范围和写入已有授权覆盖后 adopt、重复检查 no-op，再 verify，分别报告选中行完成及剩余 pending。被拒绝项给出未来官方读取器支持后重盘点、核验身份/旧来源的方案；没有可恢复来源就保留 pending 或改用新会话。旧证书不当作新权限。
+> 帮我迁移到 DSH Completion Guard 0.12.0 的会话启用模式。生命周期约束：[填写允许停止的写者及是否允许重启]。沿用本会话已给出的范围、写入及生命周期授权，仅询问缺失或实质变化的决定。先报告现有宿主、持久化目录/压缩配置、保留的前驱包（如 0.9.0）身份及脱敏的升级前有效模式来源；不能核验就将受影响会话保持 pending。取得明确生命周期和写入权限前，不替换包、不停/重启进程、不写绑定。运行打包工具的只读 inventory，报告总数/可读/官方格式拒绝数量并保存本地 pending 报告；沿用我已明确选择的范围，尚未选择时再请我决定；不静默扩大范围，也不把可读性本身当作授权。让显式 selection 贯穿 inspect/adopt/verify，检测全部库存变化，保留原日志和旧来源，不按路径、日期、事件数猜模式/origin/cut。正文、凭据、私有 ID 不离开本机。范围和写入已有授权覆盖后 adopt、重复检查 no-op，再 verify，分别报告选中行完成及剩余 pending。被拒绝项给出未来官方读取器支持后重盘点、核验身份/旧来源的方案；没有可恢复来源就保留 pending 或改用新会话。旧证书不当作新权限。
 
 
 ## Full-inventory inspect, adopt, verify / 整库清点、采纳、核验
 
-The entry `node /absolute/prepared-package/bin/dsh-completion-guard-activation.mjs` below uses the independently prepared 0.10.0 toolkit; it does not assume a new command is installed on PATH while the old Guard remains installed. The tool mounts only the official JSONL persistence service, without starting the agent loop, UI or model. `--runtime-anchor` is a file in the physical official runtime; the tool resolves its real path before loading dependencies. `--persistence-root` and optional `--compression none|zstd` must match the active persistence configuration. No storage path or encoding is guessed. Inspection uses public `list`, read-only `open`, exact header/inherited-cut metadata and revision readback; it outputs no event bodies. Keep writers stopped through the sequence.
+The entry `node /absolute/prepared-package/bin/dsh-completion-guard-activation.mjs` below uses the independently prepared 0.12.0 toolkit; it does not assume a new command is installed on PATH while the old Guard remains installed. The tool mounts only the official JSONL persistence service, without starting the agent loop, UI or model. `--runtime-anchor` is a file in the physical official runtime; the tool resolves its real path before loading dependencies. `--persistence-root` and optional `--compression none|zstd` must match the active persistence configuration. No storage path or encoding is guessed. Inspection uses public `list`, read-only `open`, exact header/inherited-cut metadata and revision readback; it outputs no event bodies. Keep writers stopped through the sequence.
 
-下方使用独立准备的 0.10.0 工具入口 `node /absolute/prepared-package/bin/dsh-completion-guard-activation.mjs`，不假定旧 Guard 仍安装时新命令已在 PATH。工具只挂载官方 JSONL persistence 服务，不启动 agent loop、界面或模型。runtime anchor 必须是官方 runtime 中的文件，加载依赖前先解析物理路径。持久目录及可选压缩格式必须匹配实际配置，不推测目录或编码。清点使用公开 list、只读 open、精确 header/cut 元数据及 revision 回读，不输出事件正文。整个操作期间保持写者停止。
+下方使用独立准备的 0.12.0 工具入口 `node /absolute/prepared-package/bin/dsh-completion-guard-activation.mjs`，不假定旧 Guard 仍安装时新命令已在 PATH。工具只挂载官方 JSONL persistence 服务，不启动 agent loop、界面或模型。runtime anchor 必须是官方 runtime 中的文件，加载依赖前先解析物理路径。持久目录及可选压缩格式必须匹配实际配置，不推测目录或编码。清点使用公开 list、只读 open、精确 header/cut 元数据及 revision 回读，不输出事件正文。整个操作期间保持写者停止。
 
 The following example is for a POSIX shell. Run `inspect` before replacement; run `adopt` and `verify` before starting the upgraded host. Keep the prepared toolkit path explicit throughout.
 
@@ -144,9 +156,13 @@ Missing/corrupt/changed records invalidate cached projections and certification.
 
 缺失、损坏或变化的记录使缓存投影和认证失效。根据具名原因诊断，再使用保留且已核验的收据采纳同一缺失旧身份与模式。损坏或冲突的 final 拒绝自动修复，请保留诊断；无可信旧来源时保持 unknown，在新合格会话中建立新工作。不删除历史，也不触发无穷纠正。fork 需核验父绑定并继承父模式；精确 cut 由官方 Session/persistence 合同提供及验证，不由前缀长度推断模式。
 
-A fresh creation that leaves `.pending`, including a fresh 0.10.0 session, has no general recovery command in this toolkit. `inspect` accepts verified pre-upgrade predecessor sources (`0.0.x`–`0.9.x`, including `0.9.0`), but `adopt` still requires a verified migration receipt for the same old session identity and mode. Predecessor support does not authorize treating a failed fresh creation as a legacy migration or inventing a receipt to repair it. Without an existing trusted legacy receipt, keep the mode unknown, diagnose the retained state, or continue new work in another qualified fresh session. The exported same-value writer is a programmatic controlled recovery primitive, not an operator CLI. Do not delete `.pending` merely to make the final readable.
+A qualified fresh creation that lost a brief writer-lock race now retries itself: the runtime re-attempts the SAME creation, while the startup intent is still provable, for a bounded budget (at most 8 attempts within 60 seconds of attach), and then reports the explicit `activation_writer_unavailable` status. The retry is idempotent (same-value) and never applies to a session that was ever successfully created, to resume/late attach, or to a deleted binding — those keep the unknown/diagnosis rules below. This automatic retry is not a recovery command and does not need one.
+
+A fresh creation that leaves `.pending`, including a fresh 0.12.0 session, has no general recovery command in this toolkit. `inspect` accepts verified pre-upgrade predecessor sources (`0.0.x`–`0.11.x`, including `0.11.0`), but `adopt` still requires a verified migration receipt for the same old session identity and mode. Predecessor support does not authorize treating a failed fresh creation as a legacy migration or inventing a receipt to repair it. Without an existing trusted legacy receipt, keep the mode unknown, diagnose the retained state, or continue new work in another qualified fresh session. The exported same-value writer is a programmatic controlled recovery primitive, not an operator CLI. Do not delete `.pending` merely to make the final readable.
+
+合格新会话因短暂写锁竞争而失败的首次创建会自行重试：运行时在首创意图仍可证明时，按有界预算（attach 后 60 秒内至多 8 次）重试同一创建，随后返回明确的 `activation_writer_unavailable` 状态。重试是同值幂等的，绝不适用于曾成功创建的会话、resume/迟挂载或被删除的绑定——那些仍按下面的 unknown/诊断规则处理。该自动重试不是恢复命令，也不需要恢复命令。
 
-新建会话（包括 0.10.0 新会话）留下 .pending 时，本工具仍没有通用恢复命令。inspect 可使用已核验的旧版本模式来源（`0.0.x`–`0.9.x`，包括 `0.9.0`），但 adopt 仍需针对同一旧会话身份与模式的已核验迁移收据。支持这些前驱版本不意味着可以把失败的新建会话当作旧会话迁移，或编造收据来修复它。没有既有可信旧收据时，保持模式 unknown、诊断保留状态，或在另一合格新会话中继续新工作。导出的同值 writer 是程序受控恢复原语，不是操作者 CLI；不能为了让 final 可读而删除 .pending。
+新建会话（包括 0.12.0 新会话）留下 .pending 时，本工具仍没有通用恢复命令。inspect 可使用已核验的旧版本模式来源（`0.0.x`–`0.11.x`，包括 `0.11.0`），但 adopt 仍需针对同一旧会话身份与模式的已核验迁移收据。支持这些前驱版本不意味着可以把失败的新建会话当作旧会话迁移，或编造收据来修复它。没有既有可信旧收据时，保持模式 unknown、诊断保留状态，或在另一合格新会话中继续新工作。导出的同值 writer 是程序受控恢复原语，不是操作者 CLI；不能为了让 final 可读而删除 .pending。
 
 For rollback, stop writers, retain the receipt and bindings, and select the previous mode explicitly in each old profile before reinstalling the old Guard. A pre-0.9.0 Guard does not read these bindings; mixed-mode inventories need separate correctly mapped profiles or remain unsuitable for rollback. Keep host-lock and certificate identities separate: re-inspect the actual installed host as required, and never re-sign old certificates merely to change mode. Cross-machine transfer includes only verified bindings/receipts, with owner permissions restored; it transfers no host lock, credentials or native authority.
 

package/docs/COMPATIBILITY.md

@@ -2,18 +2,58 @@
 
 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.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 baseline is DSH `0.2.1-rc.2` / Cordis `4.0.5`, with 47 package identities and published implementation digests in `manifests/rc021-rc2-byte-audit.json`, regenerated from the published `0.2.1-rc.2` tarballs (the audited cohort id is `dsh-0.2.1-rc.2-core-v1`). Native acceptance of the final Guard artifact on each platform remains a separate gate; no native validation of a future host is claimed.
+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、生命周期或真实模型验收通过。
@@ -30,7 +70,7 @@ Desktop 平铺安装索引只接受已观察的 pnpm `11.7.0`、`11.28.5` JSON
 
 ### 升级、临时禁用与恢复（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` / Cordis `4.0.5`（cohort `dsh-0.2.1-rc.2-core-v1`，47 包，见 `manifests/rc021-rc2-byte-audit.json`，上游提交 `687f282e8625c6b8d11ff58211a90524be2e4317`）。
+最低宿主为 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 等待与计划审阅的结束等待不算完成。
 

package/docs/DEPENDENCY_SCAN.md

@@ -0,0 +1,143 @@
+# Dependency advisory gate / 依赖告警门禁
+
+The repository runs a fail-closed dependency advisory gate (`scripts/audit_dependencies.py`,
+required CI job `dependency-scan`). This page is the maintenance contract for that gate.
+
+本仓库通过失败关闭的依赖告警门禁（`scripts/audit_dependencies.py`，必需 CI job
+`dependency-scan`）检查依赖公告。本文是该门禁的维护说明。
+
+## Policy / 策略
+
+- Any `high` or `critical` advisory — production or development chain — fails the gate.
+  A test-chain finding is still an unaccepted high/critical finding.
+- `moderate` and `low` advisories are printed by the gate but do not block. They stay
+  visible in CI logs; fixing them is encouraged, not gated.
+- The scan must complete: a network failure, registry outage, or malformed `pnpm audit`
+  output fails the gate (`exit 2`). A missing scan never reads as "zero vulnerabilities".
+
+- 任何 `high`/`critical` 公告（无论生产链还是开发链）都会使门禁失败。
+  开发链的 high/critical 同样是未接受的高危发现。
+- `moderate`/`low` 公告会被打印但不阻断；修复值得鼓励，但不作为门禁条件。
+- 扫描必须完成：网络失败、registry 不可用或 `pnpm audit` 输出不可解析时门禁失败
+  （退出码 2）。扫描缺失绝不会被解读为“零漏洞”。
+
+## Classification and reachability / 分类与可达性
+
+`pnpm audit` reports scanner severity, not product severity. This package ships no
+runtime dependencies beyond the audited DSH host cohort; advisories historically land in
+the development chain (vitest/vite/tinypool/source-map-js and their transitive graphs).
+Before acting on a finding, check where the module sits (`pnpm why <module>`) and whether
+the advisory's precondition is reachable in this repository's usage — for example, the
+tinypool advisories require attacker-controlled worker options, and the vitest mocker
+advisories require untrusted mock inputs. Reachability decides priority; it never
+converts a blocking advisory into a silent pass.
+
+`pnpm audit` 报告的是扫描器严重性，不是产品严重性。本包除受审计的 DSH 宿主队列外
+没有运行时依赖；历史告警均落在开发链（vitest/vite/tinypool/source-map-js 及其传递
+依赖）。处理发现前先确认模块位置（`pnpm why <module>`）及其前置条件在本仓库用法中
+是否可达——例如 tinypool 公告需要攻击者可控的 worker 选项，vitest mocker 公告需要
+不可信的 mock 输入。可达性决定优先级，但绝不把阻断级公告变成静默通过。
+
+## Fixing and upgrading / 修复与升级
+
+1. Prefer a coordinated upgrade of the affected chain that stays inside the dependents'
+   declared ranges (`pnpm update`, then `pnpm-workspace.yaml` `overrides` floors only when
+   the fixed version is otherwise unreachable). Verify `pnpm install`, the full local
+   matrix, and record the mapping advisory → version in the change log.
+2. Never hide an incompatibility behind a blind force, and never delete lockfile entries
+   to silence a scanner.
+3. Dropping an override floor requires the dependents' own minimums to cover the fixed
+   version.
+
+1. 优先协调升级受影响链条，并保持在依赖方声明范围内（先 `pnpm update`；只有当修复
+   版本无法通过范围解析时才在 `pnpm-workspace.yaml` 用 `overrides` 设下限）。验证
+   `pnpm install` 与完整本地矩阵，并在变更日志记录“公告 → 版本”映射。
+2. 不得用盲目 force 掩盖不兼容，也不得删除 lockfile 条目让扫描器闭嘴。
+3. 只有当依赖方自身的最低版本覆盖修复版本后，才可移除 override 下限。
+
+## Exceptions / 例外
+
+Accepting a blocking advisory requires a matching entry in the machine-readable table
+`scripts/dependency-scan-exceptions.json` (validated by the gate: expired, mismatched or
+malformed entries leave the advisory blocking) plus the summary record below: advisory id,
+affected module and version, why the advisory's precondition is unreachable here, the
+owner, and an expiry date after which the exception must be re-justified or the chain
+upgraded.
+
+接受阻断级公告必须同时在机器可读表 `scripts/dependency-scan-exceptions.json` 登记
+（由门禁校验：过期、不匹配或损坏的条目仍保持阻断）并在下表登记摘要：公告 ID、受影
+响模块与版本、前置条件在本仓库不可达的原因、责任方、到期日；到期后必须重新论证或
+完成升级。
+
+### Historical temporary risk acceptance for 0.11.0 / 0.11.0 历史临时风险接受
+
+For the three Undici 8.11.2 findings added below, the maintainer explicitly accepted the disclosed residual risk and waived the ordinary unreachability eligibility requirement for this 0.11.0 validation. This is a specific exception to eligibility, not a finding that the whole host is unreachable or safe. The signed host remains unfixed, and a TLS 1.2 process-crash denial of service cannot be excluded. The cache and TLS-callback inspections narrow particular paths only; they do not establish whole-host isolation. Changing a development override would not repair signed-host bytes.
+
+这次 0.11.0 验收新增的三条 Undici 8.11.2 例外，由维护者明确接受已披露的剩余风险，并对通常要求“前置条件不可达”的例外准入作一次特批。这不是“整个宿主不可达”或“已经安全”的结论。签名宿主仍未修复，TLS 1.2 导致进程崩溃的拒绝服务风险不能排除；cache 和 TLS callback 的静态检查只缩小部分路径，不能证明整个宿主隔离。修改开发依赖 override 也不会修复签名宿主中的代码。
+
+The original 0.11.0 acceptance covered only scanner IDs 1243472, 1243474 and 1243477 with the exact advisory IDs and Undici version below. Its expiry was **2026-11-05 inclusive**: the exception table shipped in that release would block from **2026-11-06** if left unchanged. The separate current 0.12.0 acceptance and expiry are recorded below. Other findings, versions and release checks are not waived. The two older exceptions retain their original scope and expiry. Expiry blocks CI qualification and subsequent acceptance checks; it does not fix upstream code, disable an installed 0.11.0 instance, or withdraw a published package.
+
+原 0.11.0 接受范围仅限 scanner ID 1243472、1243474、1243477 与下列精确公告 ID、Undici 版本的组合。原有效期**包含 2026-11-05 当日**；该发布所带的例外表若保持不变，将从 **2026-11-06** 起恢复阻断。下节单独登记本次 0.12.0 的新授权和期限。其他发现、版本及发布检查不在豁免范围内；原有两条例外的范围和到期日保持不变。到期阻断的是 CI 资格和后续验收，不会自动修复上游、禁用已安装的 0.11.0 实例或撤回已发布的包。
+
+The advisory id in the exception table is the scanner's numeric id; the GitHub
+advisory it resolves to is recorded alongside it. Earlier drafts of this page
+mistakenly wrote the numeric id as a GHSA code — the real identifiers are:
+
+| Advisory (GitHub) | Scanner id | Module@version | Severity | Rationale (summary) | Owner | Expires |
+| --- | --- | --- | --- | --- | --- | --- |
+| [GHSA-mrhx-c7xc-m3w5](https://github.com/advisories/GHSA-mrhx-c7xc-m3w5) | 1243066 | zod@4.4.3 | high | Dev-chain only: exact-pinned transitive dep of the pinned `@deepseek-ai` host devDependencies (test replica of the audited cohort). Nothing ships in the npm package; the advisory needs attacker-controlled oversized schema input, which offline deterministic tests never provide. The verified rc.3 and rc.5 host manifests still exact-pin zod 4.4.3, so upgrading the host does not lift this. Re-evaluate at the next host cohort bump that carries zod ≥4.6.6. | GreenLv | 2027-01-31 |
+| [GHSA-xjj6-f33q-929c](https://github.com/advisories/GHSA-xjj6-f33q-929c) | 1243112 | undici@8.11.2 | high | Dev-chain only: exact-pinned transitive dep of `@deepseek-ai/dsh-http-proxy` under the pinned host devDependencies. Nothing ships in the npm package; the advisory needs an attacker-controlled server sending crafted Content-Encoding stacks, which offline tests never contact. The verified rc.3 and rc.5 host manifests still exact-pin undici 8.11.2, so upgrading the host does not lift this. Re-evaluate at the next host cohort bump that carries undici ≥8.12.2. | GreenLv | 2027-01-31 |
+| [GHSA-4w7w-5xrc-9h26](https://github.com/nodejs/undici/security/advisories/GHSA-4w7w-5xrc-9h26) | 1243472 | undici@8.11.2 | high | Explicit temporary risk acceptance, 0.11.0 validation ONLY: cache/redirect composition was not found in the inspected factory; whole-host/plugin configurations remain unknown. 明确临时接受 cache/redirect 剩余风险，仅限 0.11.0 验收，不声称全宿主不可达。 | GreenLv | 2026-11-05 (inclusive) |
+| [GHSA-2m5v-pch6-74hx](https://github.com/nodejs/undici/security/advisories/GHSA-2m5v-pch6-74hx) | 1243474 | undici@8.11.2 | high | Explicit temporary risk acceptance, 0.11.0 validation ONLY: application-specific TLS callbacks may be lost; the inspected factory lacks that callback, but other configurations are unknown. 明确临时接受 TLS callback 检查绕过风险，仅限 0.11.0 验收，其他配置仍未知。 | GreenLv | 2026-11-05 (inclusive) |
+| [GHSA-qrxm-fqhp-jwvm](https://github.com/nodejs/undici/security/advisories/GHSA-qrxm-fqhp-jwvm) | 1243477 | undici@8.11.2 | high | Explicit temporary risk acceptance, 0.11.0 validation ONLY: TLS 1.2 renegotiation can crash the client; reachability cannot be excluded and the signed host is unfixed. 明确临时接受可能可达的进程崩溃风险，仅限 0.11.0 验收，签名宿主未修复。 | GreenLv | 2026-11-05 (inclusive) |
+
+### Status for the 0.12.0 candidate / 0.12.0 候选的现状
+
+The reviewed rc.3 host also pins the same Undici and zod versions, so retaining rc.3 admission does not close the disclosed gaps.
+
+The rc.5 cohort bump does not change this picture. The verified `0.2.1-rc.5` registry manifests and the regenerated 0.12.0 lockfile still exact-pin `undici` 8.11.2 (via `@deepseek-ai/dsh-http-proxy`) and `zod` 4.4.3 (via `@deepseek-ai/dsh-commands`), and the upstream default branch still pins the same Undici, so no gap is closed by adopting rc.5. On 2026-11-02 the maintainer explicitly and separately accepted the same three exact Undici 8.11.2 findings for 0.12.0 validation, including the disclosed residual risk and ordinary-unreachability eligibility waiver, and extended their expiry to **2026-11-30 inclusive**. Only scanner IDs 1243472, 1243474 and 1243477 with their recorded GHSA identities are covered. From **2026-12-01** the gate blocks them again unless re-justified. The signed host remains unfixed; whole-host unreachability is not established and the TLS 1.2 process-crash risk cannot be excluded. The table above preserves the first 0.11.0 authorization; the current table below and machine-readable rationales record the separately authorized 0.12.0 scope. Other findings, versions and release gates are not waived. Expiry affects later qualification; it does not automatically disable an installed instance or withdraw a published package. The two older exceptions remain within their original scope and expiry, with their rationale updated to reference the rc.5 cohort.
+
+已审查的 rc.3 宿主也锁定相同版本的 Undici 和 zod，因此保留 rc.3 准入不会关闭已披露缺口。
+
+rc.5 队列升级不改变上述结论：已核验的 `0.2.1-rc.5` registry manifest 与再生的 0.12.0 lockfile 仍精确锁定 `undici` 8.11.2（经 `@deepseek-ai/dsh-http-proxy`）与 `zod` 4.4.3（经 `@deepseek-ai/dsh-commands`），上游默认分支同样保留旧 Undici，因此本版没有关闭任何缺口。维护者于 2026-11-02 明确、单独接受本次 0.12.0 验收中相同三条 Undici 8.11.2 发现的已披露剩余风险，并特批通常要求前置条件不可达的例外资格，期限延至 **2026-11-30（含）**。仅覆盖 scanner ID 1243472、1243474、1243477 及其已登记 GHSA 身份。自 **2026-12-01** 起，未经重新论证的例外恢复阻断。签名宿主未修复，不能证明整个宿主不可达，也不能排除 TLS 1.2 进程崩溃风险。上表保留首次 0.11.0 授权历史，下表及机器可读 rationale 记录单独授权的当前 0.12.0 范围；其他发现、版本和发布核验不在豁免范围内。到期影响后续资格核验，不会自动禁用已安装实例或撤回已发布的包。原有两条例外保持原范围与到期日，仅将依据更新为 rc.5 队列口径。
+
+| Current accepted advisory / 当前接受公告 | Scanner id | Module@version | Owner | Expires (inclusive) |
+| --- | --- | --- | --- | --- |
+| GHSA-4w7w-5xrc-9h26 | 1243472 | undici@8.11.2 | GreenLv | 2026-11-30 |
+| GHSA-2m5v-pch6-74hx | 1243474 | undici@8.11.2 | GreenLv | 2026-11-30 |
+| GHSA-qrxm-fqhp-jwvm | 1243477 | undici@8.11.2 | GreenLv | 2026-11-30 |
+
+`pnpm audit` on the 0.12.0 lockfile additionally reports four moderate Undici findings (scanner IDs 1243077, 1243080, 1243480, 1243483 — EventSource unbounded memory, SRI token case bypass, WebSocket PONG buffering, decompress-interceptor exception) and four `fast-uri` moderate/low findings (1243098, 1243104, 1243101, 1243107) in the development chain. Per the policy above these are printed, non-blocking, and recorded here; they are additional signals on the same unfixed host pin, not evidence that the risk shrank.
+
+0.12.0 lockfile 的 `pnpm audit` 另报告四条 moderate Undici 公告（scanner ID 1243077、1243080、1243480、1243483）与四条 `fast-uri` moderate/low 公告（1243098、1243104、1243101、1243107），均在开发链。按上述策略它们仅打印、不阻断，并在此记录；它们是同一未修复宿主 pin 上的新增信号，不代表风险下降。
+
+## Recorded upgrades / 已记录的升级
+
+The advisory state is whatever the gate prints for the lockfile under review; the
+exception table above is the only durable record of accepted findings. Upgrades this
+gate has already carried: the vitest 3.2.7 mocker path-traversal and tinypool 1.1.1
+prototype-pollution/RCE chains were closed by moving to vitest 4.1.12 (which drops the
+vulnerable tinypool 1.x pool) with `vite >=7.3.7 <8` and `source-map-js ^1.2.2` floors
+inside the dependents' declared ranges. The vitest 4 migration seams for this repository
+(manifest wrapper modules, the clean-startup test setup file, mock placement) are
+described in the 0.11.0 change log.
+
+门禁打印的告警状态始终针对被检查的 lockfile；上表是已接受发现的唯一持久记录。该
+门禁已承载的升级：vitest 3.2.7 mocker 路径穿越与 tinypool 1.1.1 原型污染/RCE 链
+通过迁移到 vitest 4.1.12（随之移除带漏洞的 tinypool 1.x pool）并设定
+`vite >=7.3.7 <8`、`source-map-js ^1.2.2` 范围内下限关闭。本仓库 vitest 4 迁移的
+接缝（manifest 包装模块、清空启动参数的测试 setup 文件、mock 摆放位置）见
+0.11.0 变更日志。本仓库的 vitest 4 迁移注意事项（manifest 包装
+模块、清空启动参数的测试 setup 文件、mock 摆放位置）见 0.11.0 变更日志。
+
+## Upstream references and follow-up / 上游参考与后续更新
+
+- [DSH public dependency discussion](https://github.com/deepseek-ai/deepseek-harness/discussions/10847) records concerns about exact-pinned vulnerable dependencies. It does not establish that DSH maintainers have responded or scheduled a repair.
+- [Undici 8.12.2 release](https://github.com/nodejs/undici/releases/tag/v8.12.2) lists the upstream fixes for these three advisories. That release does not replace code in an already signed DSH app. The reviewed rc.3, rc.4, rc.5 and alpha.2 host manifests still pin Undici 8.11.2.
+
+- [DSH 公开依赖讨论](https://github.com/deepseek-ai/deepseek-harness/discussions/10847)记录了精确锁定受影响依赖的担忧；不能据此声称 DSH 维护者已回应或已排期修复。
+- [Undici 8.12.2 发布记录](https://github.com/nodejs/undici/releases/tag/v8.12.2)列出了这三条公告的上游修复，但该发布不会替换已有签名 DSH 应用内的代码。本次核对的 rc.3、rc.4、rc.5 和 alpha.2 宿主 manifest 仍锁定 Undici 8.11.2。
+
+Once an official compatible host carries the fixed dependency chain, recheck its actual signed/installed bytes and advisory result, validate the changed inputs, then update this disclosure and remove or reassess only the matching exceptions. Until then, the residual risk remains accepted only within the recorded scope and expiry; other acceptance gates stay in force.
+
+后续官方兼容宿主带入修复链后，应重新核对实际签名及安装字节、公告扫描结果和受影响输入，再更新披露，并仅移除或重新评估相符的例外。在此之前，剩余风险只在已记录的范围和期限内被接受，其他验收门禁继续有效。

package/docs/GETTING_STARTED.md

@@ -4,15 +4,15 @@
 
 ## Before installation
 
-Use the profile you actually run: Web, Headless or Desktop. Stop the relevant host/session writers first. If this installation has old Guard sessions, preserve the old package and effective mode sources, then prepare a frozen inventory and migration receipt using [the migration guide](ACTIVATION_MIGRATION.md) **before replacing DSH or Guard**. Empty old sessions count too. The 0.10.0 migration toolkit can run from a separately prepared package directory while the old package stays installed.
+Use the profile you actually run: Web, Headless or Desktop. Stop the relevant host/session writers first. If this installation has old Guard sessions, preserve the old package and effective mode sources, then prepare a frozen inventory and migration receipt using [the migration guide](ACTIVATION_MIGRATION.md) **before replacing DSH or Guard**. Empty old sessions count too. The 0.12.0 migration toolkit can run from a separately prepared package directory while the old package stays installed.
 
-With no old Guard sessions, there is no old-mode adoption step. Upgrade the host to DSH `>=0.2.1-rc.2` if necessary, install Guard, and complete the installation checks before startup. Requires Node.js `>=22`, pnpm `>=11` and a qualified Cordis `>=4.0.4` installation. Do not load both `dsh-context-guard` and `dsh-completion-guard` in one profile; the internal entry ID remains `context-guard`.
+With no old Guard sessions, there is no old-mode adoption step. Upgrade the host to DSH `>=0.2.1-rc.3` if necessary, install Guard, and complete the installation checks before startup. Requires Node.js `>=22`, pnpm `>=11` and a qualified Cordis `>=4.0.4` installation. Do not load both `dsh-context-guard` and `dsh-completion-guard` in one profile; the internal entry ID remains `context-guard`.
 
 ## 安装前
 
-先确认实际使用的 Web、Headless 或 Desktop profile，并停止相应宿主与会话写者。如果已有旧 Guard 会话，替换 DSH 或 Guard **之前**，按[迁移指南](ACTIVATION_MIGRATION.md)保留旧包、核验有效模式来源，冻结会话库存并准备迁移收据。旧空会话也需要清点。0.10.0 迁移工具可以从另行准备的包目录运行，旧包此时仍留在原安装位置。
+先确认实际使用的 Web、Headless 或 Desktop profile，并停止相应宿主与会话写者。如果已有旧 Guard 会话，替换 DSH 或 Guard **之前**，按[迁移指南](ACTIVATION_MIGRATION.md)保留旧包、核验有效模式来源，冻结会话库存并准备迁移收据。旧空会话也需要清点。0.12.0 迁移工具可以从另行准备的包目录运行，旧包此时仍留在原安装位置。
 
-没有旧 Guard 会话时，不需要旧模式 adoption。先按需将 DSH 升级到 `>=0.2.1-rc.2`，再安装 Guard，完成安装核验后启动。需要 Node.js `>=22`、pnpm `>=11` 及通过资格验证的 Cordis `>=4.0.4`。同一 profile 不要同时加载 `dsh-context-guard` 和 `dsh-completion-guard`，内部条目 ID 仍是 `context-guard`。
+没有旧 Guard 会话时，不需要旧模式 adoption。先按需将 DSH 升级到 `>=0.2.1-rc.3`，再安装 Guard，完成安装核验后启动。需要 Node.js `>=22`、pnpm `>=11` 及通过资格验证的 Cordis `>=4.0.4`。同一 profile 不要同时加载 `dsh-context-guard` 和 `dsh-completion-guard`，内部条目 ID 仍是 `context-guard`。
 
 ## Web installation / Web 安装
 
@@ -21,7 +21,7 @@ Keep the host stopped through these steps. Substitute the actual absolute runtim
 以下步骤期间保持宿主停止，将目录替换为实际绝对路径。`inject` 会把锁写入 profile 的 `cordis.patch.yml`，执行前先备份。`inspect`、`inject` 和 `verify-dump` 三条宿主锁检查都须返回 `status: "supported"`；非零退出或其他状态都不能继续启动。该状态要求不适用于 `dsh plugin add`。
 
 ```sh
-dsh plugin --profile web add dsh-completion-guard@0.10.0
+dsh plugin --profile web add dsh-completion-guard@0.12.0
 
 DSH_RUNTIME_ROOT=/absolute/path/to/.dsh-runtime
 DSH_PROFILE_ROOT=/absolute/path/to/.dsh/profiles/web
@@ -32,9 +32,9 @@ GUARD_HOST_LOCK="$DSH_PROFILE_ROOT/node_modules/.bin/dsh-completion-guard-host-l
 dsh --profile web --dump-config | "$GUARD_HOST_LOCK" verify-dump --runtime-root "$DSH_RUNTIME_ROOT" --profile-root "$DSH_PROFILE_ROOT" --dump-config -
 ```
 
-The reviewed baseline is DSH `0.2.1-rc.2` / Cordis `4.0.5`. A later compatible host requires `--rebind-registry` on the three lock commands; it checks official archives and qualifies changed programs before rebuilding the lock. See [compatible-version rebinding](HOST_LOCK_UPGRADE.md#rebinding-compatible-package-versions). Changes to DSH, Guard or the profile location require fresh checks. An ordinary market-only update does not require reinjection; installing or removing the Desktop market does.
+The default reviewed baseline is DSH `0.2.1-rc.5` / Cordis `4.0.5`; rc.3 uses its own reviewed cohort. A later compatible host requires `--rebind-registry` on the three lock commands; it checks official archives and qualifies changed programs before rebuilding the lock. See [compatible-version rebinding](HOST_LOCK_UPGRADE.md#rebinding-compatible-package-versions). Changes to DSH, Guard or the profile location require fresh checks. An ordinary market-only update does not require reinjection; installing or removing the Desktop market does.
 
-已审查基线为 DSH `0.2.1-rc.2` / Cordis `4.0.5`。更新的兼容宿主需要在三条锁命令中添加 `--rebind-registry`，核对官方归档并验证变化的程序后重建锁，见[兼容版本重绑定](HOST_LOCK_UPGRADE.md#rebinding-compatible-package-versions)。DSH、Guard 或 profile 路径变化后需要重新检查。仅 market 的普通更新不需重新注入，Desktop 市场的安装或移除则需要。
+默认审查基线为 DSH `0.2.1-rc.5` / Cordis `4.0.5`；rc.3 使用自己的审查队列。更新的兼容宿主需要在三条锁命令中添加 `--rebind-registry`，核对官方归档并验证变化的程序后重建锁，见[兼容版本重绑定](HOST_LOCK_UPGRADE.md#rebinding-compatible-package-versions)。DSH、Guard 或 profile 路径变化后需要重新检查。仅 market 的普通更新不需重新注入，Desktop 市场的安装或移除则需要。
 
 ### Windows, Headless and Desktop / 其他入口
 
@@ -105,6 +105,6 @@ Use a custom `DSH_HOME` instead of the default `.dsh` directory when configured.
 
 Copyable configuration prompt / 可复制配置提示词：
 
-> Use dsh-completion-guard 0.10.0's default always mode for future new root sessions while preserving old modes. Find the cordis.patch.yml for the Web, Headless or Desktop profile I actually use. First verify that old-session mode migration is complete for the authorized scope; keep exclusions and unknown sources pending. Back up the file, then remove only the activation field from the existing context-guard config, or leave it absent. Preserve bindings, all other settings and host-lock fields. Do not rewrite bindings or restart DSH. Show the path and exact diff, and report any lock or migration checks remaining before restart.
+> Use dsh-completion-guard 0.12.0's default always mode for future new root sessions while preserving old modes. Find the cordis.patch.yml for the Web, Headless or Desktop profile I actually use. First verify that old-session mode migration is complete for the authorized scope; keep exclusions and unknown sources pending. Back up the file, then remove only the activation field from the existing context-guard config, or leave it absent. Preserve bindings, all other settings and host-lock fields. Do not rewrite bindings or restart DSH. Show the path and exact diff, and report any lock or migration checks remaining before restart.
 
-> 让后续新根会话使用 dsh-completion-guard 0.10.0 的默认 always，保留旧模式。找到我实际使用的 Web、Headless 或 Desktop profile 的 cordis.patch.yml；先确认授权范围内的旧会话模式迁移已通过，排除项和来源未知项继续待处理。备份配置后，仅删除原 context-guard config 下的 activation 字段；原本没有该字段则保留不填。保留绑定、其他配置和宿主锁字段，不重写绑定，不重启 DSH。报告文件路径、精确差异，以及重启前尚缺的锁或迁移核验。
+> 让后续新根会话使用 dsh-completion-guard 0.12.0 的默认 always，保留旧模式。找到我实际使用的 Web、Headless 或 Desktop profile 的 cordis.patch.yml；先确认授权范围内的旧会话模式迁移已通过，排除项和来源未知项继续待处理。备份配置后，仅删除原 context-guard config 下的 activation 字段；原本没有该字段则保留不填。保留绑定、其他配置和宿主锁字段，不重写绑定，不重启 DSH。报告文件路径、精确差异，以及重启前尚缺的锁或迁移核验。

package/docs/HISTORICAL_INCIDENT_COVERAGE.md

@@ -1,5 +1,12 @@
 # Historical incident coverage
 
+> Scope note (0.12.0): this document is the frozen historical record of the
+> PUBLIC fixture subset as of its own date — it is not the current release's
+> historical-library gate. Current candidates derive their complete inventory
+> from the private maintained library's case registry and run the full
+> case-by-case gate before publication; the sanitized outcome summaries live
+> in the matching release acceptance materials, not in this file.
+
 Verification date: 2026-09-28 (two evidence rounds). The adjudication round
 ran its working tree on the `1e88176` lineage and the four adaptation cases it
 introduced were first committed in `f4a9497`; the review-repair round added the

package/docs/HOST_LOCK_UPGRADE.md

@@ -1,23 +1,23 @@
 # Upgrading the core host lock
 
-Version 0.10.0 requires DSH `>=0.2.1-rc.2` and qualified Cordis `>=4.0.4`. Fresh installations have no old-mode inventory to adopt; existing installations must preserve their old mode sources before any replacement. Follow this order:
+Version 0.12.0 requires DSH `>=0.2.1-rc.3` and qualified Cordis `>=4.0.4`. Fresh installations have no old-mode inventory to adopt; existing installations must preserve their old mode sources before any replacement. Follow this order:
 
 1. Stop the relevant host/session writers. For an **existing installation**, preserve the old installed package and sanitized effective-mode sources, then prepare the public persistence inventory and frozen receipt with the [prepared-candidate migration toolkit](ACTIVATION_MIGRATION.md), **before replacing DSH or Guard**. Unresolved old provenance stays pending. A **fresh installation with no old Guard sessions** skips this old-mode preparation.
-2. Upgrade DSH to `0.2.1-rc.2` or a later version, then install this Guard version, keeping writers stopped.
+2. Upgrade DSH to at least `0.2.1-rc.3` if necessary, then install this Guard version, keeping writers stopped.
 3. Rebuild the host lock for each profile with `inspect`, `inject` and `verify-dump` from the accepted package or matching prepared source. For a POSIX shell, the entry is `node /absolute/prepared-package/bin/dsh-completion-guard-host-lock.mjs`; pass the actual runtime/profile roots. A successful rebuild reads back `supported` with `audit_provenance` stating how the graph was established.
 4. For an **existing installation**, run mode `adopt` and `verify` with its frozen old receipt while writers remain stopped, **before starting any host**. Host-lock rebuilding does not perform adoption. For a fresh installation there is no old receipt to adopt.
 5. Start each Web/Headless/Desktop profile only after the applicable mode and host-lock checks pass. These checks do not require a running host.
 
-0.10.0 的全新安装没有旧模式需要采纳；已有安装必须在替换前保留旧来源。顺序为：先停相关写者，保存旧安装包和脱敏有效模式来源，以独立准备的候选工具冻结公开库存及旧收据；再升级 DSH、安装 Guard、重建宿主锁；保持写者停止，在启动任何宿主前完成旧收据 `adopt` 和 `verify`；最后按需启动。全新安装跳过旧模式准备与 adoption，未知旧来源仍保持 pending，宿主锁不替代模式核验。
+0.12.0 的全新安装没有旧模式需要采纳；已有安装必须在替换前保留旧来源。顺序为：先停相关写者，保存旧安装包和脱敏有效模式来源，以独立准备的候选工具冻结公开库存及旧收据；再按需升级低于下限的 DSH、安装 Guard、重建宿主锁；保持写者停止，在启动任何宿主前完成旧收据 `adopt` 和 `verify`；最后按需启动。全新安装跳过旧模式准备与 adoption，未知旧来源仍保持 pending，宿主锁不替代模式核验。
 
 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.1-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_version_below_minimum`: DSH is older than `0.2.1-rc.3`. Upgrade DSH first.
+- `host_lock_version_mismatch`: the installed graph differs from the reviewed baseline in version or integrity. For a compatible version outside the reviewed cohorts, use `--rebind-registry` to acquire and qualify the published graph. For rc.3 or rc.5, check the recorded identities for the actual launcher.
 - `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.1-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.
+The floor is `>=0.2.1-rc.3` 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.
 
@@ -52,12 +52,20 @@ graph it finds there, and each session mount validates those same roots once,
 with every security-sensitive entry validating them again at its own decision.
 Injecting against the old runtime therefore writes a lock that describes a graph
 the new runtime no longer has, and it will fail at the next mount or the next
-protected entry. Order: stop the host, upgrade DSH and install Guard, inspect/inject/verify each profile, then start it when needed.
+protected entry. Order: stop the host, upgrade DSH if below the floor and install Guard, inspect/inject/verify each profile, then start it when needed.
 
 `inject` **writes to `<profile>/cordis.patch.yml`** — it replaces or adds Guard's
 managed block in that file. Back the file up first. The same file is the one
 `docs/LOCAL_ACCEPTANCE.md` tells you to preserve.
 
+The patch must be one YAML array of mapping entries. `inject` preserves user entries in ordinary block YAML (including inline flow values) and JSON-shaped flow sequences. For a JSON sequence, the managed entry is inserted inside the closing bracket with YAML comment markers; the result remains a `.yml` flow sequence, not a strict JSON document. User entries are not reserialized. The reserved begin/end markers must each occupy their own line and occur only once.
+
+Before writing a temporary file, `inject` parses the original, unmanaged base and proposed output, then checks that the output preserves the base entries and adds exactly its managed entry. Invalid syntax, duplicate mapping keys, ambiguous Guard configurations, mismatched names, malformed markers and boundaries that prevent safe insertion are refused without changing the profile or an existing temporary file. Parsing uses the SDK's non-executing YAML dialect: `!!js` scalars remain expression data and are never evaluated by `inject`. This is syntax and injection-safety validation; plugin configuration, full composition and actual host loading still require the later checks below.
+
+配置文件须为由 mapping 条目组成的单个 YAML 数组。`inject` 保留普通 block YAML（包括字段内的 flow 对象和数组）及 JSON 形式的 flow 序列。输入为 JSON 序列时，受管条目连同 YAML 注释标记插入右方括号内；输出仍是 `.yml` flow 序列，不再是严格 JSON 文档。用户条目不会重新序列化。保留的起止标记须独占一行，且各出现一次。
+
+`inject` 在创建临时文件前解析原文件、移除受管区后的内容和拟写入结果，并核对结果只在原有条目后加入受管条目。语法错误、重复 mapping key、歧义 Guard 配置、包名不符、标记损坏或无法安全插入的文档边界都会在写入前拒绝；profile 和已有临时文件均保持不变。解析沿用 SDK 的非执行 YAML 方言，`!!js` 标量只保留为表达式数据，`inject` 不执行它。该步骤只核验语法与注入安全，插件配置、完整组合配置和真实宿主载入仍须经过下述检查。
+
 **Check both the JSON verdict and the exit status.** Accepted commands print `status: "supported"`. A missing graph, drift, incompatible implementation or untrusted registry description reports a specific `reason_code` on stderr and exits 1. `inspect-graph` is a pre-install graph check; it does not grant runtime authority.
 
 For Headless, use its profile path for the host-lock commands and `dsh --profile headless --dump-config` for the dump. On Windows, use the
@@ -84,7 +92,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.10.0 registers `dsh-0.2.1-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.
+Version 0.12.0 uses `dsh-0.2.1-rc.5-core-v1` as the default audited baseline and selects the rc.3 cohort for the rc.3 launcher; it derives graph cohorts for other 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.
 
@@ -103,14 +111,14 @@ 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.10.0.
+Historical requirements and session records are retained; old certificates do not become certificates for the new lock. The rc.3 graph is admitted under its own reviewed cohort; rc.2 remains below the 0.12.0 floor. Prior artifact acceptance remains bound to its original subject.
 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.
 
-For an existing installation, first preserve the old package/effective modes and freeze the inventory/receipt before replacing the carrier or Guard; after replacement, complete adoption/verification before Desktop startup. For a fresh installation there is no old-mode adoption. Install Guard through that carrier with `plugin --profile desktop add dsh-completion-guard@0.10.0`. 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:
+For an existing installation, first preserve the old package/effective modes and freeze the inventory/receipt before replacing the carrier or Guard; after replacement, complete adoption/verification before Desktop startup. For a fresh installation there is no old-mode adoption. Install Guard through that carrier with `plugin --profile desktop add dsh-completion-guard@0.12.0`. 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
@@ -124,11 +132,13 @@ GUARD_DESKTOP_LOCK="$DSH_DESKTOP_PROFILE/node_modules/.bin/dsh-completion-guard-
 
 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.
 
+`verify-dump` checks the injected Guard host-lock fields against the active graph (`verification_scope: guard_host_lock_fields`); it does not parse or validate every other entry in the composed configuration (`configuration_syntax: not_checked`). A supported lock readback cannot certify that the entire YAML is complete or that the host can load it. Keep the composed output private and require the official complete configuration parser and actual host loading as subsequent checks.
+
 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.
 
 The official plugin market (`dshmarket`) can be installed into the same Desktop profile through the official management entry; its package name neither conflicts with the Desktop bundle tuple nor grants any trust. Installing or removing the market changes the profile's importer, so the previous Desktop lock stops matching (`host_lock_installed_graph_drift`) and must be rebuilt with the full four-step flow: `inspect`, then `inject`, then generate a NEW composed dump with `dump-desktop`, then verify that new dump with `verify-dump --dump-config <new file>`. `dump-desktop` only composes a configuration for readback; it never substitutes for `verify-dump`. Verify the dump generated after this rebuild — a dump captured before the market change no longer matches and must be discarded. Rebuild the lock on this machine; a lock or digest copied from another profile or machine is not valid evidence. Desktop restart stays unsupported regardless of coexistence.
 
-Desktop 升级顺序相同：先停止应用并升级宿主，再用应用附带的 CLI 安装 Guard。普通外部 CLI 无法管理保留的 Desktop profile。以应用的 `app.asar` 和实际 Desktop profile 路径执行 `inspect`、`inject`、`dump-desktop`、`verify-dump`，确认三项 JSON 回读均为 `supported` 后再打开应用。`dump-desktop` 不启动宿主；配置输出可能包含私人信息，请留在本机。Guard 不修改应用归档，也不负责应用重启。官方插件市场（`dshmarket`）可以通过官方管理入口安装到同一 Desktop profile；其包名既不与 Desktop bundle 元组冲突，也不授予任何信任。安装或移除市场会改变 profile 的 importer，旧 Desktop 锁因此不再匹配（`host_lock_installed_graph_drift`），需要用完整四步流程重建：先 `inspect`，再 `inject`，然后用 `dump-desktop` 生成新的组合配置，最后用 `verify-dump --dump-config <新文件>` 校验这份新配置。`dump-desktop` 只负责生成配置供回读，不能替代 `verify-dump`。请校验本次重建后新生成的 dump——市场变化前捕获的旧 dump 已不匹配，应当丢弃。请在本机重建锁；从其他 profile 或其他机器复制的锁或摘要不构成有效证据。无论是否共存，Desktop 重启仍不受支持。
+Desktop 升级顺序相同：先停止应用，必要时将宿主升级至最低要求，再用应用附带的 CLI 安装 Guard。普通外部 CLI 无法管理保留的 Desktop profile。以应用的 `app.asar` 和实际 Desktop profile 路径执行 `inspect`、`inject`、`dump-desktop`、`verify-dump`，确认三项 JSON 回读均为 `supported` 后再打开应用。`dump-desktop` 不启动宿主；配置输出可能包含私人信息，请留在本机。Guard 不修改应用归档，也不负责应用重启。官方插件市场（`dshmarket`）可以通过官方管理入口安装到同一 Desktop profile；其包名既不与 Desktop bundle 元组冲突，也不授予任何信任。安装或移除市场会改变 profile 的 importer，旧 Desktop 锁因此不再匹配（`host_lock_installed_graph_drift`），需要用完整四步流程重建：先 `inspect`，再 `inject`，然后用 `dump-desktop` 生成新的组合配置，最后用 `verify-dump --dump-config <新文件>` 校验这份新配置。`dump-desktop` 只负责生成配置供回读，不能替代 `verify-dump`。请校验本次重建后新生成的 dump——市场变化前捕获的旧 dump 已不匹配，应当丢弃。请在本机重建锁；从其他 profile 或其他机器复制的锁或摘要不构成有效证据。无论是否共存，Desktop 重启仍不受支持。
 
 ## Market and restart
 

package/docs/LOCAL_ACCEPTANCE.md

@@ -1,5 +1,13 @@
 # Local Acceptance
 
+## 0.12.0 / DSH 0.2.1-rc.5 candidate contract
+
+The current source requires DSH `>=0.2.1-rc.3`, with rc.5 as its default audited host graph; rc.3 uses its own reviewed cohort. The task, certificate and data protocols and the existing Web/Headless and Desktop gate sets remain in force. Use `--desktop-cohort 0.2.1-rc.5` for this candidate's Desktop entry. Follow the [host-lock upgrade](HOST_LOCK_UPGRADE.md) and [old-session migration](ACTIVATION_MIGRATION.md) instructions before replacing an installation.
+
+The rc.5 qualification and packaged metadata updates create a new package identity. Source, CI, exact tgz identity, each platform's native installation/lifecycle, real-model and GUI/performance results must name that new subject; earlier rc.2 observations remain attached to their original source and artifact. This section states the contract, not a passing execution or publication. The versioned sections below retain their historical scope, including 0.10.0's rc.2 floor and original command examples.
+
+当前源码的 DSH 下限为 `0.2.1-rc.3`，默认审查基线为 rc.5；rc.3 使用自己的审查队列。旧会话及数据协议保持兼容，Web/Headless 与 Desktop 原有门禁不变；本候选的 Desktop 入口使用 `--desktop-cohort 0.2.1-rc.5`。候选变更产生新的包字节，源码、CI、制品、双平台原生、模型及 UI/性能证据必须分别绑定新身份。下文旧版本记录保留原范围，不改标为本候选通过。
+
 ## 0.10.0 / DSH 0.2.1-rc.2 acceptance contract
 
 Guard 0.10.0 retains the existing task, certificate and data protocols. This section defines the current acceptance contract; it does not report a passing native, model or GUI run. Its host floor is DSH `0.2.1-rc.2`; use the [upgrade guide](HOST_LOCK_UPGRADE.md) before establishing a new lock. The historical [RC.2/Desktop development plan](https://github.com/GreenLv/dsh-completion-guard/blob/563f144bf8568793da5017b9ff71395a33dcd265/docs/DEVELOPMENT_PLAN_DSH_0_2_0_RC2_DESKTOP.md) records the original adaptation scope; the current source, portability, exact-package, native, model and reader gates are defined below and in the repository instructions.

package/docs/PRIVACY.md

@@ -17,12 +17,26 @@ Context Guard stores only bounded, deterministic facts. It does not persist prom
 ## Never stored
 
 - Complete prompts, stdout, stderr, or file contents.
-- Authorization headers, URL query values, credentials, or API keys.
+- Authorization headers, URL query and fragment values, URL `user:password`
+  userinfo, credentials, or API keys.
 - Image bytes or binary contents.
 - Authenticated session state or raw transcripts.
 - Raw Session IDs, local paths, prompts, command output, or credential values in
   the private ledger; those bindings are stored only as SHA-256 values.
 
+## Redaction scope
+
+Before normalized text or URL evidence subjects are stored, the sanitizer
+removes, by structure: `Authorization`-style header values, quoted and bare
+`key=value` secret fields (including unclosed quotes), bearer tokens, the
+`sk-`/`pk-`/`ak-` key family, the GitHub token spellings (`ghp_`/`gho_`/`ghu_`/
+`ghs_`/`ghr_`/`github_pat_`), and URL userinfo plus query/fragment. This is a
+bounded, documented pattern set, NOT a guarantee that every secret format is
+recognized: credentials embedded in ordinary prose, non-listed token families,
+or URL path segments are outside what structural redaction can see. The
+sanitization is deterministic and idempotent; evidence recorded by older
+versions keeps its recorded digests and is not silently recomputed.
+
 ## Failure behavior
 
 - Unknown, failed, or object-mismatched evidence cannot certify completion.

package/docs/README.md

@@ -2,7 +2,7 @@
 
 For installation and upgrades, start with [host-lock upgrades](HOST_LOCK_UPGRADE.md) and [compatibility](COMPATIBILITY.md). [Distribution](distribution.md) lists package channels. [Local acceptance](LOCAL_ACCEPTANCE.md) distinguishes source checks, installed-artifact results and their limits.
 
-For maintenance, use [architecture](ARCHITECTURE.md), [privacy](PRIVACY.md), the [writer-lock protocol](WRITER_LOCK_PROTOCOL.md), and [historical incident coverage](HISTORICAL_INCIDENT_COVERAGE.md). The [core alignment contract](CORE_ALIGNMENT_CONTRACT_V2.md), [semantic compatibility](SEMANTIC_COMPATIBILITY.md), [upstream base](UPSTREAM_BASE.md), and [porting notes](PORTING_NOTES.md) explain shared semantics and product boundaries. [Third-party licenses](THIRD_PARTY_LICENSES.md) records attribution.
+For maintenance, use [architecture](ARCHITECTURE.md), [privacy](PRIVACY.md), the [writer-lock protocol](WRITER_LOCK_PROTOCOL.md), [historical incident coverage](HISTORICAL_INCIDENT_COVERAGE.md), and the [dependency advisory gate](DEPENDENCY_SCAN.md). The [core alignment contract](CORE_ALIGNMENT_CONTRACT_V2.md), [semantic compatibility](SEMANTIC_COMPATIBILITY.md), [upstream base](UPSTREAM_BASE.md), and [porting notes](PORTING_NOTES.md) explain shared semantics and product boundaries. [Third-party licenses](THIRD_PARTY_LICENSES.md) records attribution.
 
 ## Historical development material