dsh-completion-guard 0.9.0 → 0.11.0

package/CHANGELOG.zh-CN.md

@@ -2,14 +2,60 @@
 
 本项目的重要变化记录在这里。项目仍处于 1.0 之前；版本号跟踪插件生命周期，不代表 API 已稳定。
 
-## 0.9.0
+各条目描述对应版本。历史宿主范围、默认值、后续计划和候选验证结果，不是当前安装指引，也不能证明后续版本已通过验收。当前配置请看[安装与首次载入](docs/GETTING_STARTED.md)，各版本证据请看[验收记录](docs/LOCAL_ACCEPTANCE.md)。
+
+<details>
+<summary>版本索引</summary>
+
+[0.11.0](#0110) · [0.10.0](#0100) · [0.9.0](#090) · [0.8.4](#084) · [0.8.3](#083) · [0.8.2](#082) · [0.8.1](#081) · [0.8.0](#080) · [0.7.1](#0712026-09-22) · [0.7.0](#0702026-09-21) · [0.6.3](#0632026-09-18) · [0.6.2](#0622026-09-16) · [0.6.1](#0612026-09-15) · [0.6.0](#060---2026-09-14) · [0.5.3](#053---2026-09-14) · [0.5.2](#052---2026-09-11) · [0.5.1](#051---2026-09-10) · [0.5.0](#050---2026-09-10) · [0.4.3](#043---2026-09-08) · [0.4.2](#042---2026-09-07) · [0.4.1-rc.1](#041-rc1---2026-09-04) · [0.4.0](#040---2026-09-02) · [0.3.2](#032---2026-09-01) · [0.3.1](#031---2026-08-31) · [0.3.0](#030---2026-08-31) · [0.2.1](#021---2026-08-28) · [0.2.0](#020---2026-08-28) · [0.1.2](#012---2026-08-27) · [0.1.1](#011---2026-08-27) · [0.1.0](#010---2026-08-27)
+
+</details>
+
+## 0.11.0
+
+- **安装 Guard 0.11.0 前，请先将 DSH 升级到 `0.2.1-rc.3` 或更高版本。** 包声明、运行时准入和默认审查基线统一以 rc.3 为下限。旧会话及 Guard 数据协议保持兼容；rc.2 身份记录作为历史证据保留。
+
+- **宿主锁注入不再损坏 JSON 形式的 patch 序列。** 受管条目写入序列内部，用户条目保持原样；原有 block YAML、字段内的 flow 值、activation 和仅 disabled 的覆盖继续受支持。语法错误、重复 key、歧义 Guard 字段及损坏的受管标记会在修改 profile 前拒绝；内置 YAML reader 不执行 `!!js` 表达式。完整配置组合与原生载入仍须分别验收。
 
-- 新增显式可读子集迁移：只读 inventory 区分官方旧格式拒绝与其他异常，select 冻结用户选择的 ID。子集 inspect/adopt/verify 核对全库变化，保留原日志/旧模式来源，分别报告选中行完成及排除行 pending。整库默认仍 fail-closed；中英说明提供命令、恢复方案和 AI 提示词。
+- **上游已知风险：**维护者为本次 0.11.0 明确临时接受三条 Undici 8.11.2 高危发现，期限**包含 2026-11-05 当日**。签名宿主仍未修复，详见[风险范围与到期规则](docs/DEPENDENCY_SCAN.md)；上游修复链通过核验后再继续更新。
 
-- **重大默认模式变化：**新建根会话默认 `always`，首条真实输入前 Guard 不追加事件，从该输入开始保护。旧会话通过核验后的不可覆盖绑定保留升级前有效模式。升级前准备旧模式清点，再使用随包提供的 inspect/adopt/verify 迁移入口；混合来源需要精确会话映射。未知、损坏或冲突的绑定不能认证。显式配置选择新建根会话的初始模式，持久化 off/on 继续有效。策略仍为 `standard`，不自动授予权限或签发证书。
-- 逐会话 adoption 保留旧重放 epoch 和有效证书，不改写历史或重签。每次 sync 新鲜读取绑定；删除或替换使缓存认证失效。fork 保留核验过的父模式及官方宿主提供的精确继承 cut。[迁移与回退说明](docs/ACTIVATION_MIGRATION.md)列出部分恢复及存储能力边界。
-- 重复同步会话时复用已完整证明冻结的事件子树，追加事件后不再递归检查未变的旧历史。可变、访问器、循环及未完成证明的图仍不能复用；Goal、私有账本和宿主敏感决策继续读取所需的新鲜状态。Desktop 审计只在单次操作内共享 ASAR 索引和已验证字节。这些改动减少组件工作量，尚不能证明历史窗口打开更快或界面端到端延迟下降。
-- 新增只读本地历史测量脚本，以匿名会话报告读取、解压、JSON 解析和纯 Guard 重放耗时。历史日志代际只做清点，不迁移或认证；计时不含运行时迁移、私有账本、宿主审计、IPC 或界面渲染。
+- 默认宿主审计核对声明文件和依赖路由，跳过无关目录扫描；使用资格回执的审计仍核对完整文件清单。
+
+- **“请分别执行”“依次分别执行”等已核对句式不再产生误读的禁止。** 这些句式中的“分别”等词保持完整；“这个别推送”“完成前别”等真正的禁止仍然有效。
+
+- **较长的宿主锁配置现在能完整输出到管道。** `verify-dump` 明确报告只核验 Guard 锁字段；完整配置解析和宿主载入仍须分别检查。
+
+- **激活 CLI 兼容官方 rc.3 持久化导出。** 清点与显式模式接纳支持 default 和 namespace 两种有效插件形态，无效模块在访问持久化数据前拒绝。
+
+- **发布 tgz 的包身份现在经由同一套可审计 tar 子集读取。** Guard、npm 与发布各阶段对"这些字节编码的是哪个 package.json"达成一致：resolution、执行前最终复核与发布后回读共用一个严格读取器——校验 header 校验和、理解 ustar prefix 与 npm 路径规范化，拒绝链接、PAX/GNU 扩展、规范化后重名及 `package/` 之外的路径。两个 manifest 互相矛盾的伪造档案（prefix 遮蔽加 `./` 别名）会在任何授权前被拒绝，发布授权不再可能绑定一个包名而 npm 实际安装另一个。读取在所有维度有预算——实际读取的压缩字节、解压输出、单成员大小、成员数量与 manifest 大小——高压缩比档案无法再在授权完成前拖垮宿主。
+- **registry 回读拥有自己的总时限与响应体预算。** 发布后的对账在插件自有总期限（与调用方取消组合）内读取精确版本的 registry 文档，按硬性字节预算流式接收响应体，并在每条退出路径释放 reader。缓慢、挂起或超量的 registry 都会在记录的预算内以稳定拒绝结束：尝试保持 in-flight，被拒绝的回读不写任何结算，也绝不重发 publish。
+- **私有存储保护跟随官方工作目录参数。** Bash/Pwsh 防护现在读取官方 `workdir` 参数（绝对、相对或符号链接别名），而不是宿主根本不发送的字段；相对文件目标按调用方可信的有效目录（最近一次提交的工作目录纪元）解析，相对目标无可证明基底时失败关闭。同一矩阵通过生产注册 guard 强制，而不只是 helper。
+- **文件回读绑定调用当时的目录。** 已提交 `working-directory/change` 之后，独立文件观察器按调用自身序号的 cwd 纪元解析相对目标，而不是不可变 header 目录，也不是当前日志末尾目录。后来的目录变化不能再把已完成 effect 重绑定到另一个同名文件；不可读时间线拒绝相对目标，绝对目标仍可观察。
+- **脱敏现在清除 URL 凭据与已记录的令牌族。** URL 中的 `user:password@` 按结构移除，有边界的 GitHub 令牌拼写（`ghp_`/`gho_`/`ghu_`/`ghs_`/`ghr_`/`github_pat_`）在归一化文本、URL 主体或恢复提示被存储前脱敏。[隐私说明](docs/PRIVACY.md)写明精确模式集及其边界；capture→replay 摘要保持确定性，历史摘要绝不静默重算。
+- **一次中断的 anchor 写入不再影响其他会话。** 共享 session-anchors 文件末尾被撕裂的一行按未提交追加处理：每条完整行对其会话保持权威，下一位持锁写者在追加前修复尾字节；中间坏行与冲突 anchor 仍对所有会话拒绝。
+- **合格首次创建可以在短暂写锁竞争后恢复。** 新 startup 会话的激活写入因短暂锁竞争失败时，运行时在其首创意图仍可证明期间按有界预算重试同一创建，随后返回明确的 `activation_writer_unavailable` 状态。重试同值幂等，绝不适用于 resume、迟挂载或已被删除的绑定。
+- **普通 fork 重新成为根会话。** `parentSession` 是分叉谱系而非委派：首次边界与指导、工作单元和确认语义现在适用于普通及恢复的 fork，宿主的显式子代理标记（`origin=subagent`、正 `delegationDepth`）继续保留委派限制。矛盾标记按委派处理。
+- rc.3 核心图已登记经 registry 核验的包身份与实现摘要；macOS arm64、Windows x64 官方 Desktop 分发行分别登记厂商签名及签名绑定的归档身份。安装、生命周期、真实模型和 UI 性能仍须分别验收。
+- **发布 tgz 身份在文件增长后仍然成立。** 可审计 tar 读取器按有界分块读到确认的 EOF，把身份绑定到实际读取的完整字节——元数据检查之后增长的制品不再可能按旧前缀摘要被接受。私有存储防护在默认目录不可证明（无可信工作目录）时拒绝 shell/文件调用；URL 凭据剥离按 URL authority 语义处理任意 scheme、大小写不敏感，合法 authority 引号不再被当作终结符。任何写者写入的激活绑定一旦被观察到，新会话首次创建重试即永久终止，删除后绝不重建文件。registry 对账在组合 deadline 下释放每一条响应体——包括错误响应与停滞的 body。依赖公告门禁现在遵守扫描器退出协议（失败的扫描绝不读作干净）、对每个安装版本逐一匹配例外，并记录真实 GitHub 公告编号。anchor 写入在回归套件中注入真实边界故障（部分写、fsync 失败、尾修复失败）：已提交同伴保持可读，下一位写者修复未提交尾。
+- **迁移库存接受 `0.10.x` 作为旧包版本**，从 0.10.0 升级沿用既有启用模式迁移路径；更早版本的规则不变。
+- **失败关闭的依赖公告门禁成为必需 CI 的一部分。** 新 `dependency-scan` job 对任何未接受的高危/严重公告阻断，扫描本身无法完成时同样失败；已接受例外保存在带校验、带到期日的表中，见[依赖公告门禁](docs/DEPENDENCY_SCAN.md)。开发链升级至 vitest 4.1.12（随之移除带漏洞的 tinypool 1.x pool），并设定兼容的 vite 与 source-map-js 下限。
+
+## 0.10.0
+
+- **安装 Guard 0.10.0 前先升级 DSH。** 最低宿主为 `0.2.1-rc.2`，没有隐式上限。保留旧会话模式和配置，升级宿主、安装 Guard，再为各 profile 重建并回读宿主锁，核验后恢复启用。旧锁和完成证书不能转移到变化后的包图。[兼容性说明](docs/COMPATIBILITY.md#0100-dsh-021-rc2)保留已审查宿主身份，以及市场卡片、插件加载和 Guard 准入各自的边界。
+- **job 生命周期事件细化外部等待，但永不代替完成。** 本会话所有、身份核验一致的持久化 `job/registered`/`job/settled` 配对记录可结束对应等待，合法孤立结算仅保留为审计事实：`completed` 结算只有在 producer 自己报告完成时才算完成；killed 与 failed 是显式失败，未报告的 completed 保持未确认。结算不证明资源清理、文件读回或用户义务完成——验证仍需照做。记录的 owner 不转移到 fork 或恢复的历史副本。
+- **工作目录切换不再重新解释已捕获的证据。** 每条已提交的 `working-directory/change` 开启新的 cwd 纪元：目标、路径与回执保留捕获当时的含义，会话原始项目目录在 header 中保持不变。shell 工作目录回执核验 cwd 服务身份，并新增绑定纪元的 v2 形态。调用未返回时若目录变化，依赖该目录的执行保持未确认，不能在重放时转归新目录。没有目录变更事件的日志在同一宿主绑定下保留 0.9.0 冻结投影，并保留其证据字段与摘要，包括显式相对 workdir；后来事件不能改写已完成的旧证据。
+- **实验性 `plugin:` 记录一律保留并跳过。** 它们不触发捕获、不授予任何权限、不破坏工具配对；Guard 自有私有账本不迁移到该机制。Guard 从未引用上游已移除的 invariant 伴随插件；同步 `snapshotEvents()` 读取在锁定宿主上继续有效。
+- **单独核验官方 Desktop 分发中保留的文件。** 固定发行包/header 和独立源码编译字节 pin 覆盖八个保留的 invariant 伴随文件，不将它们混入 registry 清单；官方签名、原模块字节及实际路由核验仍为必需。平铺 pnpm `11.7.0`、`11.28.5` profile 必须与 carrier 版本一致，v2 两步 no-op 合同不变。native fixture 在创建临时目录时即绑定物理路径，再派生证据目标，保留严格 readback 断言。见[Desktop 分发资格说明](docs/COMPATIBILITY.md#official-desktop-distribution-bytes)。
+- **子代理、Team Inbox 与 Goal 等待语义保持不变。** `subagent` 工具结果仍是有界证据，不能关闭父义务；直接 Inbox 投递记录的是接收成功而非执行完成；等待子任务、计划审阅结束或暂停的 Goal 都不会伪造或消耗完成。
+- **迁移库存现在接受 `0.9.x` 作为旧包版本**，从 0.9.0 升级沿用既有启用模式迁移路径；更早版本的规则不变。开发依赖固定 DSH `0.2.1-rc.2`，发布 floor 以官方 app-boot 消费者的真实准入决策核对。
+
+## 0.9.0
+
+- **未填写 `activation` 时，新建根会话默认采用 `always`。** 显式 `opt-in` 仍受支持。Guard 从首条真实输入开始保护，此前不追加会话事件。旧会话（包括旧空会话）保留已核验的升级前模式，已保存的 `off`、`on` 继续有效。显式配置与绑定模式矛盾时会被拒绝；要采用新默认值并保留旧模式，请[在迁移后省略覆盖字段](docs/GETTING_STARTED.md#新会话默认模式)。默认策略仍为 `standard`，自动启用不授予执行、发布权限，也不会自动认证完成。
+- **已有安装升级后，先核验再打开会话。** 替换包前停止相关写者，保留旧包及有效模式来源，冻结旧会话库存。安装后重建宿主锁，完成旧模式 adoption 和 verify，再启动宿主。绑定缺失、冲突或损坏时不能认证；原历史和有效旧证书保留，不重写、不重签。步骤及回退见[迁移指南](docs/ACTIVATION_MIGRATION.md)。
+- **历史载入仍需要等待。** 首次打开或恢复已有历史的会话时，宿主载入历史，Guard 重建状态，界面可能显示“载入历史”；再次打开也可能等待。本版只在确认历史未变、检查结果可安全复用时，复用已经通过的历史检查；同一次 Desktop 安装检查中也会复用已读取并核验的应用文件。每次操作仍核对当前模式，并按需要重新核验 Goal 状态、私有记录和宿主环境。官方宿主的历史视图生命周期及解码缓存未变，不能保证消除界面等待。新增只读测量脚本，分别报告本地读取、解压、JSON 解析和纯 Guard 重放耗时，不包含运行时迁移、IPC 和渲染。
+- **官方宿主拒绝旧格式时，可明确迁移选中的可读会话。** `inventory` 清点全库，`select` 冻结选中 ID，inspect/adopt/verify 全程使用同一 `--selection`。排除项保留原日志和旧模式来源，继续待处理；`selected_complete` 不代表整库完成。其他异常仍会中止。[指南](docs/ACTIVATION_MIGRATION.md)包含命令、恢复方案和可复制 AI 提示词。
 
 ## 0.8.4
 
@@ -128,7 +174,7 @@
 
 ### 验证范围
 
-当前为源码发布候选。本地结果与尚缺的 CI、T06 原生、精确制品和发布门槛见[验收记录](docs/LOCAL_ACCEPTANCE.md)及[发版计划](https://github.com/GreenLv/dsh-completion-guard/blob/784b5452b0da366a351dff6490fa46eeed2839a9/docs/RELEASE_PLAN_0_6_2.md)。
+准备时，本条目记录的是源码发布候选。本地结果与当时尚缺的 CI、T06 原生、精确制品和发布门槛见[验收记录](docs/LOCAL_ACCEPTANCE.md)及[发版计划](https://github.com/GreenLv/dsh-completion-guard/blob/784b5452b0da366a351dff6490fa46eeed2839a9/docs/RELEASE_PLAN_0_6_2.md)。
 
 ## 0.6.1（2026-09-15）
 
@@ -144,7 +190,54 @@
 
 解释记录和原因码为增量。附件捕获文本保持 0.6.0 字节；旧日志没有解释记录时，附件继续 pending。源码检查、CI、冻结制品和原生 Web/Headless 验收分别记录在[验收记录](docs/LOCAL_ACCEPTANCE.md)。测试宿主清理现在显式释放持久化宿主，避免 FileHandle 被垃圾回收时报错。本节不代表任何平台验收或发布已经完成。
 
-## 0.6.0 定向复核后的第三轮修复（2026-09-14）
+## 0.6.0 - 2026-09-14
+
+本版统一普通 DSH 任务在进入、执行、交付与恢复时的规则，并新增部分共享 Context Guard 行为。本版本尚未建立跨语言 parity 或正式 v2 镜像。新协议边界之前的一切保持原有含义，既不重解释也不重新贴标签。
+
+下方各轮修复都属于同一个 0.6.0，不是额外版本。原始缺陷、范围裁定和测试证据保留在折叠记录中；初始候选的行为说明应与这些修正一同阅读。
+
+### 新增
+
+- **回答交付与执行认证分开记录。** 问答或讲解只由宿主的自身事实关闭：同一 turn 最大 step 的 `assistant/message`、无 interrupted 标记，且其后存在 `reason.kind: "completed"` 的 `turn/end`。状态汇报、草稿、中间回复、其它 turn 的回答、子代理回答和中止的 turn 都不会关闭任何条目。`answered` 只表示"回答已交付"，不表示正确、完整或已执行。
+- **工作单元与必需后代闭包。** 任务被归入派生的单元。带委派标记的指令会开启一个子单元，其未完成义务进入父单元闭包，因此委派子任务绝不会丢掉父任务自身的工作；普通任务切换开启的是同级单元，不阻塞更新的任务。子代理结果是**有界证据**：记录并可见，但永远不能关闭父项。
+- **祖先约束持续生效。** 根用户在前一单元声明的禁止项或未满足条件，对后续单元中同一动作与目标的义务继续生效；认证器在检查证据之前就拒绝这类绑定。
+- **证明 v2 与真实能力矩阵。** 新增输入资产检查、生成结果视觉回读、对象/URL 回读、执行事实、外部事实五类证明，每类都绑定当前主体、声明的来源和真实操作。工具调用成功只构成执行事实：一次仅仅返回的浏览器调用不能证明看过图，输入资产检查必须是前置状态事实，子代理结果不能作为证明来源。已安装宿主没有对应生产者时结论是 `unavailable`，绝不静默通过。原有三类 manifest 及其摘要域不变，仍可读取。
+- **显式发布票据。** 发布契约只能由用户显式根命令采用。采用后每个操作消耗一次预约记录：效果前写入，效果后依据可信回读结算。错候选 SHA、错 ref、错制品摘要或版本、过期或无法评估的有效期、已消费票据、重放、已在执行中的操作、未解析目标和不透明 runner 都在任何副作用之前被拒绝。"release" 关键词、加载 Skill 或安装不会采用契约。
+- **strict 证明档位。** 在默认 `standard` 之上，用户明确要求的视觉或完整范围验证必须由真实回读事实兑现。strict 不为普通动作新增审批，安装也绝不隐式进入 `release` 档。
+- **统一诊断语言。** 每个未完成条目在精确原因码之外，还会给出七类标签之一：参数缺失、来源不足、条件未满足、生产者能力缺失、历史缺口、完整性失败、策略边界。`/context-guard migration` 报告当前生效的规则集、仍按 0.6.0 之前规则保留的义务，以及回滚所需的动作。
+- **宿主中立的 v2 一致性 fixture**，覆盖 S01–S12，且全部经过真实 derive/交付/闭包/Goal 链路。每条期望都只与"由事件和生产投影独立算出"的实际值比较；runner 绝不读取期望来决定实际值。
+
+### 变化
+
+- 文档"更新/修改"由对象决定，而不由动词决定：可识别的文档名词变成 `modify`，助手可在捕获的范围与类型内解析到具体文件；无法识别的对象保持诚实的未决读法，而不是被强行归为某个动作。
+- 宿主自身问答工具返回的可信答案现在会收窄有界文件选择的落点，并与沙箱审批分开记录。转贴或复述的回答文本不构成任何东西。
+- 后续根指令逐字包含某条未决通用义务时，会原子替换它并保留新旧 revision；解释、禁止和等待绝不因相似措辞删除义务。
+- `/context-guard status` 报告当前策略档、原因类直方图、迁移事实与发布状态。
+
+### 修复
+
+- 会话首步现在能看到同步持久化的输入；flush 失败会明确报告不可用，而不是返回陈旧投影。
+- v2 一致性 runner 的 `interpreted`、`closure`、`delivery`、`turn_bound` 与纠正判断改为从生产状态计算，不再取自 fixture 自身的期望。
+- 损坏的发布记录只产生一条有界诊断，不再把整个会话标为 corrupt，因此损坏的发布状态不会阻塞无关的普通工作。
+
+### 迁移与回滚
+
+- 0.6.0 语义从新的 `Context Guard protocol boundary: v5.0.0` notice 开始，写在新会话首个真实根输入步之前。旧二进制会忽略该 notice，因此回滚方向是 fail-closed，而不是误读新记录。
+- 从未写过该边界的会话继续沿用整会话契约、版本 1 证书与旧摘要域。
+- 写过该边界的会话中，边界之前的义务保留出生规则，新工作使用工作单元、交付与版本 2 证书。
+- 回滚到 0.5.x 必须恢复 0.5.x 的状态快照。用 0.5.x 重放 0.6.0 日志会以 `certificate_replay_mismatch` fail-closed；切勿手工把新 schema 数据降级。
+
+### 尚未成立
+
+- **跨语言 parity 与正式镜像尚未完成。** 上游 `codex-context-guard` 尚未落地冻结的 v2 fixture，因此本仓库的 v2 文件明确是 DSH 产出的**候选**（`2.0.0-candidate.1`、`status: "dsh-candidate"`）。`UPSTREAM_PIN.json` 仍绑定未变的 v1 镜像，本次发布不刷新它。
+- `release` 档只保护 Guard 自身路由的表面：经 Guard 自有动作工具发布 npm 制品受保护；`git tag`、GitHub Release 各操作和复合 runner 在本宿主没有拦截点，会在效果前拒绝，而不是假装已覆盖。完全绕过 Guard 的可信进程内调用属于宿主信任边界，只能披露，不能否认。
+- 发布后若 registry 回读生产者没有回应，结算保持 `unconfirmed`；未确认的操作绝不重发。
+- 确定性测试、CI、macOS/Windows 原生验收、发布与安装是相互独立的证据范围。本次记录源码与确定性证据；原生验收与发布另行进行。
+
+<details>
+<summary>0.6.0 发布前的复核与修复细节</summary>
+
+### 0.6.0 定向复核后的第三轮修复（2026-09-14）
 
 针对 `fcc3813` 定向复核的两项发现，均已修复。
 
@@ -153,11 +246,13 @@
 
 新增回归：采用后签发 → 拒绝（投影仍 valid）；采用时已存在的证书按身份冻结，且后续新增义务不会使其失效；无效/错字段 adopt 输入不影响有效契约可用。
 
-## 0.6.0 跟进复核后的第二轮修复（2026-09-14）
+### 0.6.0 跟进复核后的第二轮修复（2026-09-14）
 
 对修复提交的跟进复核在新接线中发现 5 个残留缺陷，全部复现并已修复。复核者的反例按归属保留为常驻回归用例。
 
-### 修复
+下方变化还包括配套新增的可信恢复入口，各条目并非与五个反例一一对应。
+
+#### 修复
 
 - **追加 v5 边界不再回答 v5 之前的问题。** 交付此前只受自身 turn 水位约束；在 v4 日志末尾追加边界，会让旧 turn 的回答追溯性关闭旧规则下仍开放的义务。现在只有 turn 在边界**之后**结束的交付才算数，且只有边界之后捕获的义务才可能被交付关闭。
 - **真实发布生产者补齐合同声明的全部身份。** 可信读取器现在从规范化后的 resolution 填充 registry（此前完全缺失，凡声明 registry 的合同都无法被授权）；ref 改由运行时依据**已采用契约**用审计过的 git 可执行程序解析——这是一条闭合且可达的路径，而不是发布 manifest schema 会拒绝的 command-manifest 字段。解析出的提交与制品内嵌 `gitHead` 不一致时拒绝。
@@ -166,21 +261,21 @@
 - **新增可调用的可信恢复入口。** `context_guard_release` 读取发布状态；`reconcile` 通过与发布路径相同的审计 registry 适配器读取外部身份，并且只在回读指向合同（或预约记录中的 SRI）所冻结的字节时才结算。它绝不重发发布，且在重启后、以及对**已撤销但仍在执行中**的尝试都可用——撤销收回的是后续授权，而不是对可能已发生效果的核对义务。仅冻结字节 SHA-256 的合同仍可被核对，并且仍能**检测**回读不一致。
 - **递交的证明现在属于持久合同。** checkpoint 调用会记录其 `proof` manifest，重放在该调用自身水位处重新绑定，并要求记录中的证明状态与日志蕴含的一致。被篡改或被省略、而结果仍声称已绑定的证明，现在以 `proof_replay_mismatch` fail-closed，而不是恢复出一张有效证书。签发、落盘与重放使用同一份调用参数，Goal 门也只消费证明仍能绑定的证书。
 
-### 验证
+#### 验证
 
 - 复核者的 5 个跟进反例全部通过，并按归属保留为回归用例：pre-v5 交付、只读 status、冻结的候选闭包、观测到的 registry、持久证明篡改。
 - 新增 `tests/tools/v060-release-chain.test.ts`——复核要求的验收：同一个测试串起真实 root 发布指令、真实已认证准备闭包、真实契约采用、经注册取证工具产生的真实 tgz 与 resolution，随后由注册的动作工具调用**运行时自身的发布门**：写入预约、执行一次、保持 in-flight、经注册恢复工具结算，并把重放作为已消费票据拒绝。只替换 npm 执行器与 registry HTTP 客户端；授权门、记录、生产者与重放都是生产代码。另有两例覆盖"已撤销但在执行中"的重启恢复与回读不一致。
 - 证明套件新增遗漏证明、Goal 消费，以及准确的证据边界说明。
 
-### 证据边界
+#### 证据边界
 
 发布链路测试通过显式的 `RuntimeExecutorSeams.hostLock` 验收接缝固定审计队列，因为宿主锁迁移复核会读取真实文件系统根。该接缝**只**替换宿主锁求值；发布门、预约与结算记录、证据生产者与重放仍是生产代码，宿主锁也有自己的套件与原生验收。
 
-## 0.6.0 集中复核后的修复（2026-09-14）
+### 0.6.0 集中复核后的修复（2026-09-14）
 
 针对 `0dce898` 候选的集中复核给出 15 个定向反例，15 个全部复现出真实缺陷。本节记录修复。编号（`F01`–`F08`、`R1`–`R15`）沿用复核者原编号。
 
-### 修复
+#### 修复
 
 - **F01 证书重放依赖时间点。** 交付原本在整个日志重放后统一应用，因此后续 turn 记录下来的证书在重放时，已交付的回答仍显示为未决；v5 规则也按整段日志生效，而不是从边界开始。现在交付在其所属 turn 的结束水位处应用，规则档在边界事件处切换，投影因此等于自身前缀的投影。证书比较改为按字段语义：字段顺序不同的同一证书重放结果一致，而多字段、少字段或被篡改仍然失败。
 - **F02 交付接纳迟到与中间回答。** 最终回答必须出现在该 turn 自己的 `turn/end` 之前、位于宿主实际进入的最高 step，且该 turn 只能有一个 completed 结束并有 start 记录。迟到文本、中间 step、重复或异常结束、被中止的 turn 都不产生交付。
@@ -191,7 +286,7 @@
 - **F07 证明可能被错误主体满足。** 绑定改为完整链路：条目自身冻结的主体与范围、事实按普通证据资格规则校验、声明的来源、每一类声明的操作、输入检查相对效果的先后、以及范围摘要背后真实的覆盖集合。manifest 与事实互相自洽但与用户义务不符时一律拒绝。
 - **F08 证明入口未接入生产。** v2 绑定器已接入 `context_guard_checkpoint`（可选 `proof` manifest 在签发任何证书之前绑定并报告状态）；v2 fixture 在每个 release 探针自己的时间点求值、铸造真实闭包证书、为 S09 携带真实读事实；并新增专职生产链路测试：producer → 持久日志 → derive → checkpoint → 重放。
 
-### 范围裁定（协调者，2026-09-14）
+#### 范围裁定（协调者，2026-09-14）
 
 两项范围事实一次裁定，均按事实记录，而不是作为整体 parity 声明：
 
@@ -200,51 +295,11 @@
 
 因此本插件不宣称与 Codex Context Guard "C01–C12 核心对齐"，也不宣称完整的发布覆盖面。
 
-### 验证
+#### 验证
 
 复核者的 15 个反例保留为 `tests/domain/review-counterexamples.test.ts`，现已全部通过；本次修复刻意改动的期望在原位标注了原因。新增覆盖：`tests/domain/v060-proof-production-chain.test.ts`（经真实工具注册的证明入口）、重写的发布/迁移套件（26 例，含真实已认证闭包与逐项身份拒绝）、以及扩展后的 v2 fixture（S09 证明绑定、逐时间点 release 探针、范围归因表）。
 
-## 0.6.0 - 2026-09-14
-
-本版让普通 DSH 任务在进入、执行、交付与恢复时遵循同一套规则，并补齐与共享 Context Guard 语义之间的实质差距。新协议边界之前的一切保持原有含义，既不重解释也不重新贴标签。
-
-### 新增
-
-- **回答交付与执行认证分开记录。** 问答或讲解只由宿主的自身事实关闭：同一 turn 最大 step 的 `assistant/message`、无 interrupted 标记，且其后存在 `reason.kind: "completed"` 的 `turn/end`。状态汇报、草稿、中间回复、其它 turn 的回答、子代理回答和中止的 turn 都不会关闭任何条目。`answered` 只表示"回答已交付"，不表示正确、完整或已执行。
-- **工作单元与必需后代闭包。** 任务被归入派生的单元。带委派标记的指令会开启一个子单元，其未完成义务进入父单元闭包，因此委派子任务绝不会丢掉父任务自身的工作；普通任务切换开启的是同级单元，不阻塞更新的任务。子代理结果是**有界证据**：记录并可见，但永远不能关闭父项。
-- **祖先约束持续生效。** 根用户在前一单元声明的禁止项或未满足条件，对后续单元中同一动作与目标的义务继续生效；认证器在检查证据之前就拒绝这类绑定。
-- **证明 v2 与真实能力矩阵。** 新增输入资产检查、生成结果视觉回读、对象/URL 回读、执行事实、外部事实五类证明，每类都绑定当前主体、声明的来源和真实操作。工具调用成功只构成执行事实：一次仅仅返回的浏览器调用不能证明看过图，输入资产检查必须是前置状态事实，子代理结果不能作为证明来源。已安装宿主没有对应生产者时结论是 `unavailable`，绝不静默通过。原有三类 manifest 及其摘要域不变，仍可读取。
-- **显式发布票据。** 发布契约只能由用户显式根命令采用。采用后每个操作消耗一次预约记录：效果前写入，效果后依据可信回读结算。错候选 SHA、错 ref、错制品摘要或版本、过期或无法评估的有效期、已消费票据、重放、已在执行中的操作、未解析目标和不透明 runner 都在任何副作用之前被拒绝。"release" 关键词、加载 Skill 或安装不会采用契约。
-- **strict 证明档位。** 在默认 `standard` 之上，用户明确要求的视觉或完整范围验证必须由真实回读事实兑现。strict 不为普通动作新增审批，安装也绝不隐式进入 `release` 档。
-- **统一诊断语言。** 每个未完成条目在精确原因码之外，还会给出七类标签之一：参数缺失、来源不足、条件未满足、生产者能力缺失、历史缺口、完整性失败、策略边界。`/context-guard migration` 报告当前生效的规则集、仍按 0.6.0 之前规则保留的义务，以及回滚所需的动作。
-- **宿主中立的 v2 一致性 fixture**，覆盖 S01–S12，且全部经过真实 derive/交付/闭包/Goal 链路。每条期望都只与"由事件和生产投影独立算出"的实际值比较；runner 绝不读取期望来决定实际值。
-
-### 变化
-
-- 文档"更新/修改"由对象决定，而不由动词决定：可识别的文档名词变成 `modify`，助手可在捕获的范围与类型内解析到具体文件；无法识别的对象保持诚实的未决读法，而不是被强行归为某个动作。
-- 宿主自身问答工具返回的可信答案现在会收窄有界文件选择的落点，并与沙箱审批分开记录。转贴或复述的回答文本不构成任何东西。
-- 后续根指令逐字包含某条未决通用义务时，会原子替换它并保留新旧 revision；解释、禁止和等待绝不因相似措辞删除义务。
-- `/context-guard status` 报告当前策略档、原因类直方图、迁移事实与发布状态。
-
-### 修复
-
-- 会话首步现在能看到同步持久化的输入；flush 失败会明确报告不可用，而不是返回陈旧投影。
-- v2 一致性 runner 的 `interpreted`、`closure`、`delivery`、`turn_bound` 与纠正判断改为从生产状态计算，不再取自 fixture 自身的期望。
-- 损坏的发布记录只产生一条有界诊断，不再把整个会话标为 corrupt，因此损坏的发布状态不会阻塞无关的普通工作。
-
-### 迁移与回滚
-
-- 0.6.0 语义从新的 `Context Guard protocol boundary: v5.0.0` notice 开始，写在新会话首个真实根输入步之前。旧二进制会忽略该 notice，因此回滚方向是 fail-closed，而不是误读新记录。
-- 从未写过该边界的会话继续沿用整会话契约、版本 1 证书与旧摘要域。
-- 写过该边界的会话中，边界之前的义务保留出生规则，新工作使用工作单元、交付与版本 2 证书。
-- 回滚到 0.5.x 必须恢复 0.5.x 的状态快照。用 0.5.x 重放 0.6.0 日志会以 `certificate_replay_mismatch` fail-closed；切勿手工把新 schema 数据降级。
-
-### 尚未成立
-
-- **跨语言 parity 与正式镜像尚未完成。** 上游 `codex-context-guard` 尚未落地冻结的 v2 fixture，因此本仓库的 v2 文件明确是 DSH 产出的**候选**（`2.0.0-candidate.1`、`status: "dsh-candidate"`）。`UPSTREAM_PIN.json` 仍绑定未变的 v1 镜像，本次发布不刷新它。
-- `release` 档只保护 Guard 自身路由的表面：经 Guard 自有动作工具发布 npm 制品受保护；`git tag`、GitHub Release 各操作和复合 runner 在本宿主没有拦截点，会在效果前拒绝，而不是假装已覆盖。完全绕过 Guard 的可信进程内调用属于宿主信任边界，只能披露，不能否认。
-- 发布后若 registry 回读生产者没有回应，结算保持 `unconfirmed`；未确认的操作绝不重发。
-- 确定性测试、CI、macOS/Windows 原生验收、发布与安装是相互独立的证据范围。本次记录源码与确定性证据；原生验收与发布另行进行。
+</details>
 
 ## 0.5.3 - 2026-09-14
 

package/README.md

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