dsh-completion-guard 0.6.3 → 0.7.1

package/CHANGELOG.md

@@ -2,6 +2,43 @@
 
 All notable changes to this project are documented here. The project is pre-1.0; release versions track the plugin lifecycle, not stabilised API promises.
 
+## 0.7.1 - 2026-09-22
+
+### Changes
+
+- Recovery now reports the same current results as prepare and checkpoint. A completed test is not presented as missing evidence, and ordinary work is not sent through target clarification or rebinding merely because it cannot be certified.
+- Recovery retains verifiable current prohibitions and unreleased user waits when current results are unavailable, prioritizes them in short messages, and reports omitted rows. Long boundaries link to read-only details that retain their full text; historical sibling tasks do not become current restrictions.
+- Recovery preserves the dependency-free cleanup condition. A partial deletion or unknown dependency cannot be presented as complete cleanup. Contract updates are identified as updates instead of being mislabeled as compaction or resume.
+- Prepare distinguishes a recorded wait from a currently applicable wait and checks the requested item revision even when the completion state is unknown. Prepare and checkpoint preserve a prohibition's meaning when its compliance state cannot be verified.
+
+### Upgrade and limits
+
+The supported DSH versions remain `0.1.5-rc.2 || 0.1.5-rc.1`. Restart DSH after updating the plugin. Existing history is retained; explicit proof, adopted Goal and release checks remain separate. Some combined natural-language wait clauses remain unrecognized, and this patch does not establish that a model will continue correctly after answering a side question during compaction. See the [acceptance record](docs/LOCAL_ACCEPTANCE.md) for source checks and exact-artifact evidence boundaries.
+
+## 0.7.0 - 2026-09-21
+
+### Highlights
+
+- Ordinary edits, tests and Git operations use the host’s tools. Guard keeps the requirement, observes persisted results and exact readback, and certifies only the matching completed predicate.
+- Stop distinguishes a ready current action from a future observation or insufficient evidence. A short resume can advance a ready action once; an older generic task or prose-derived wait is not promoted during recovery.
+- Goal completion protection requires explicit `/context-guard on` adoption in new v6 sessions; a later failed required outcome prevents an older certificate from completing the current Goal. Adopted release contracts and explicit proof requirements retain their independent checks.
+
+### Changes
+
+- The core/v2 consumer mirrors the exact shared source and conformance files pinned to Codex Context Guard commit `cb415cbe374d452e4a0c71e9e292d20e31f23b0e`. The old v1 pin and v5 history stay intact; the mirror is a shared-source identity, not full product equivalence.
+- Ordinary `context_guard_action` and `context_guard_evidence` calls now return migration guidance. DSH Host tools perform file, test and Git effects; read-only file, Git and package-script observations supply only facts needed for the named completion predicate. A ready input is not proof that the test ran or that a user-set time or approval condition has passed.
+- A relative file request retains its root-time Session location; exact filesystem readback identifies the file. A real Host edit of a forbidden file remains a violation even when an allowed edit also succeeded. A trustworthy pre-effect absence is still required before claiming creation.
+- Separate edits, tests, readbacks and delivered answers remain separate obligations. A short resume or cancellation changes only work in its sourced scope, while future observation and old generic entries cannot become current authority on reload. Default feedback reports an already satisfied ordinary result without asking for a legacy binding again.
+- A present request to explain a future observation can close on its own trusted answer. Its source and condition remain attached across clause splitting and recovery; a quoted or conditional explanation does not become a new present instruction, and a separately requested test still needs its own result.
+- Supported foreground `npm test` or `pnpm test` results can satisfy an ordinary run-and-report request after exact Host renderer and terminal checks. A request to make tests pass still needs a pass; other package-script numeric results and unknown exit status remain uncertified. Explicit proof, adopted Goal completion and applicable release contracts retain their own checks.
+- Foreground renderer auditing now recognizes the official Windows DSH rc.2 hoisted package-map layout as well as pnpm's versioned layout. It still requires one reachable package, an exact supported version, a contained physical module and matching implementation bytes; this source fix does not itself establish Windows native acceptance.
+
+- Host observation notices are delivered after the full tool-result batch, so they do not interrupt pending calls. Adopted release and restart control records use a separate private durable ledger; keep that ledger with its session when preserving state. Missing or damaged records leave protected operations unresolved instead of making a consumed operation available again.
+
+### Validation
+
+Candidate `583035bd90b8ee589d01b12487a057b655d43e41` passed the complete local deterministic matrix, candidate CI and 34 macOS native gates with cleanup on its exact clean-source tgz. That native run skipped real-model requests; Windows exact-artifact and complete model acceptance were not performed for those tgz bytes. These are historical results for those bytes once packaged documentation or source changes. Publication requires deterministic, CI, native-platform and model acceptance for the final exact tgz. Tag, npm package and GitHub Release publication follow that acceptance; public readback and daily installation are separate later steps; see the [acceptance record](docs/LOCAL_ACCEPTANCE.md).
+
 ## 0.6.3 - 2026-09-18
 
 Repairs execution authority, target identity, preparation consistency and legacy
@@ -94,7 +131,7 @@ exact-artifact native annexes attached to the versioned Release.
 This is a source release candidate. Local checks and remaining CI,
 native T06, exact-artifact and publication gates are recorded in
 [local acceptance](docs/LOCAL_ACCEPTANCE.md) and the
-[release plan](docs/RELEASE_PLAN_0_6_2.md).
+[release plan](https://github.com/GreenLv/dsh-completion-guard/blob/784b5452b0da366a351dff6490fa46eeed2839a9/docs/RELEASE_PLAN_0_6_2.md).
 
 ## 0.6.1 (2026-09-15)
 

package/CHANGELOG.zh-CN.md

@@ -2,6 +2,43 @@
 
 本项目的重要变化记录在这里。项目仍处于 1.0 之前；版本号跟踪插件生命周期，不代表 API 已稳定。
 
+## 0.7.1（2026-09-22）
+
+### 变更
+
+- 恢复提示与 prepare、checkpoint 使用一致的当前结果。已完成的测试不再被提示缺少证据；普通任务也不会仅因无法认证而被引向补充目标、重新绑定等操作。
+- 当前结果不可用时，仍保留来源可核验的当前禁止事项及用户等待；短消息优先展示这些边界，并报告折叠数量。过长的边界可通过只读详情查看完整原文；历史兄弟任务不会重新成为当前限制。
+- 恢复提示保留“仅清理已证明无依赖的对象”的条件，不能把部分删除或依赖未知说成清理完成。要求发生变化时，提示明确说明更新，不再误称发生了压缩或恢复。
+- prepare 区分历史记录中的等待与当前适用的等待，并在完成状态未知时继续核验条目版本。禁止项的遵守状态无法核验时，prepare 和 checkpoint 仍明确保留禁止含义。
+
+### 升级与限制
+
+受支持的 DSH 版本仍为 `0.1.5-rc.2 || 0.1.5-rc.1`。更新插件后请重启 DSH。已有历史记录保留，显式 proof、已采用的 Goal 和 release 检查仍分别生效。部分复合自然语言等待句仍无法识别；本补丁也不证明模型在压缩前回答插问后一定会正确续接主任务。源码检查及精确制品证据边界见[验收记录](docs/LOCAL_ACCEPTANCE.md)。
+
+## 0.7.0（2026-09-21）
+
+### 要点
+
+- 普通编辑、测试和 Git 操作由宿主工具完成。Guard 保存要求、观察已持久化的结果与精确回读，只认证相符的完成谓词。
+- Stop 区分已就绪的当前动作、未来观察与证据不足。简短继续指令仅在具体动作就绪时允许一次继续；恢复时不把旧 generic 项或文本推导的等待升级为可信事实。
+- 新 v6 会话的 Goal 完成保护需要显式 `/context-guard on` 采用；后来失败的必需结果会阻止旧证书完成当前 Goal。已采用的 release 合同和显式 proof 要求仍独立保护。
+
+### 变更
+
+- core/v2 消费端按 Codex Context Guard 提交 `cb415cbe374d452e4a0c71e9e292d20e31f23b0e` 精确镜像共享源码与一致性夹具。旧 v1 pin 和 v5 历史保持原状；源码身份不等于两个产品完全等价。
+- 普通 `context_guard_action` 与 `context_guard_evidence` 调用改为返回迁移说明。文件、测试和 Git 效果由 DSH 宿主工具执行；只读文件、Git 与包脚本观察仅为具名完成谓词提供事实。输入就绪不证明测试已运行，也不证明用户要求的时间或审批条件已满足。
+- 相对文件要求保留根时 Session 位置，精确文件系统回读确认目标。宿主确实修改禁改文件时，即使允许的编辑成功也仍属违例。宣称新建文件前仍需可信的写入前不存在证据。
+- 编辑、测试、回读与答复交付各保留独立义务。简短恢复或取消只改变有源范围内的工作；未来观察及旧 generic 项不会在重载时变成当前授权。普通结果已经满足时，默认反馈不再索要旧绑定。
+- 本轮要求解释未来观察时，该解释可由本轮可信答复完成。分句和恢复仍保留其来源与条件；引用或带条件的解释不会变成新的当前指令，独立要求的测试仍需自己的实际结果。
+- 具名的前台 `npm test` 或 `pnpm test` 经精确宿主渲染器和终态核验，可满足“运行并报告”。“使测试通过”仍需实际通过；其他包脚本的数值和未知退出状态不予认证。显式 proof、已采用的 Goal 完成和适用的 release 合同各自保留检查。
+- 前台渲染器审计现在同时识别官方 Windows DSH rc.2 的提升式 package-map 布局与 pnpm 带版本的布局。它仍要求唯一可达包、受支持的精确版本、位于受控目录内的物理模块及匹配的实现字节；这项源码修复本身不代表 Windows 原生验收通过。
+
+- 宿主观察通知在整批工具结果之后交付，不再插入尚未结束的工具调用。已采用的 release 与 restart 控制记录使用独立的私有持久账本；保留会话状态时应同时保留该账本。记录缺失或损坏时，受保护操作保持未决，不会把已消费操作重新视为可用。
+
+### 验证
+
+候选 `583035bd90b8ee589d01b12487a057b655d43e41` 通过完整本地确定性矩阵、候选 CI，以及同一干净源码 tgz 的 macOS 原生 34 项门禁和清理。该原生运行跳过真实模型请求；该 tgz 字节没有执行 Windows 同一制品及完整模型验收。若打包文档或源码改变，这些结果只属于原字节。正式发布以最终精确 tgz 通过其自身的确定性、CI、原生平台和模型验收为前提。tag、npm 包与 GitHub Release 在验收后发布；公开读回和日常安装属于随后分别核验的步骤；详见[验收记录](docs/LOCAL_ACCEPTANCE.md)。
+
 ## 0.6.3（2026-09-18）
 
 修复执行授权、目标身份、准备/执行判据与旧记录资格。发布状态及同一制品的原生验收证据见[对应 Release](https://github.com/GreenLv/dsh-completion-guard/releases/tag/v0.6.3)；[本地验收记录](docs/LOCAL_ACCEPTANCE.md) 保留源码检查。
@@ -33,7 +70,7 @@
 
 ### 验证范围
 
-当前为源码发布候选。本地结果与尚缺的 CI、T06 原生、精确制品和发布门槛见[验收记录](docs/LOCAL_ACCEPTANCE.md)及[发版计划](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）
 

package/README.md

@@ -4,17 +4,16 @@
 
 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.
 
+> **0.7.1 release line (2026-09-22).** Verify the [published Releases](https://github.com/GreenLv/dsh-completion-guard/releases) and [npm version](https://www.npmjs.com/package/dsh-completion-guard) before installation. This release line’s shared core/v2 source mirror is pinned to an exact Codex Context Guard commit; the two products have separate runtimes and release identities. See [compatibility](docs/COMPATIBILITY.md) and [acceptance record](docs/LOCAL_ACCEPTANCE.md) for its verified scope and open gates.
+
 ![Task-contract clauses and bounded evidence pass through a checkpoint before a completion certificate is issued](assets/social/completion-guard-hero.png)
 
 ## Quick start
 
-For version **0.6.3**, use the command below after confirming that its
-[GitHub Release](https://github.com/GreenLv/dsh-completion-guard/releases/tag/v0.6.3)
-is published. The release contains the exact artifact identity and platform evidence;
-[source acceptance](docs/LOCAL_ACCEPTANCE.md) records the development checks.
+After confirming that npm serves `0.7.1` and the GitHub Release identifies the same accepted artifact and platform annexes, install this version:
 
 ```sh
-dsh plugin --profile web add dsh-completion-guard@0.6.3
+dsh plugin --profile web add dsh-completion-guard@0.7.1
 ```
 
 **Upgrade and restart DSH before running the host-lock checks 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.
@@ -40,7 +39,13 @@ Restart DSH Web, open a session, and enable the Guard:
 /context-guard status
 ```
 
-Activation is opt-in by default. `status` shows whether the Guard is on, its startup phase (`armed` means waiting for your first message), the active policy tier, how many checks remain, and a summary of why the rest are open. `off` stops protection for the current session without deleting its history. `clear` closes the current checklist while keeping prohibitions. `diagnose` explains why a completion check passed or failed. `migration` reports which rule set the session is under and what an upgrade or rollback would mean. `release` reports the explicit release contract, its coverage, and anything in flight.
+Activation is opt-in by default. `status` shows whether the Guard is on, its startup phase (`armed` means waiting for your first message), the active policy tier, how many checks remain, and a summary of why the rest are open. `off` stops protection for the current session without deleting its history. `clear` closes the current checklist while keeping prohibitions. `diagnose` explains why a completion check passed or failed. `migration` reports which rule set the session is under and what an upgrade or rollback would mean. `release` reports an explicitly adopted release contract, its coverage, and anything in flight.
+
+### Ordinary work in 0.7.1
+
+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
 
@@ -52,9 +57,9 @@ Activation is opt-in by default. `status` shows whether the Guard is on, its sta
 
 ## Status and compatibility
 
-Version 0.6.3 supports exactly **DSH `0.1.5-rc.2` or `0.1.5-rc.1`** with Cordis `4.0.2`. These are the latest registered release and the verified minimum. The previous Session API, V2 event vocabulary, and every older host package set remain removed. If you are upgrading from DSH `0.1.2-rc.1`, **start a new session**: Guard does not migrate old logs, proposals or certificates, and it never deletes or reinterprets your old data.
+Version 0.7.1 retains support for exactly **DSH `0.1.5-rc.2` or `0.1.5-rc.1`** with Cordis `4.0.2`. These are the latest registered release and the verified minimum. The previous Session API, V2 event vocabulary, and every older host package set remain removed. If you are upgrading from DSH `0.1.2-rc.1`, **start a new session**: Guard does not migrate old logs, proposals or certificates, and it never deletes or reinterprets your old data.
 
-Package discovery and npm installation now publish the same newest-first exact union, `0.1.5-rc.2 || 0.1.5-rc.1`. Older versions, unregistered stable `0.1.5`, and future versions are not advertised as supported. Every admitted version must still match its complete 33-package DSH core graph; missing, mixed, or unknown graphs fail closed.
+Package discovery and npm metadata use the same newest-first exact union, `0.1.5-rc.2 || 0.1.5-rc.1`. Older versions, unregistered stable `0.1.5`, and future versions are not advertised as supported. Every admitted version must still match its complete 33-package DSH core graph; missing, mixed, or unknown graphs fail closed.
 
 The registered host sets are **DSH `0.1.5-rc.1` and `0.1.5-rc.2`**, each with its own exact 33-package graph. Their identities come from published npm tarballs; mixed versions fail the host check. Registry identity and native acceptance are separate: use the annex for the exact Guard artifact, host version and platform to establish a native pass. See the [compatibility guide](docs/COMPATIBILITY.md) for version rules and host-lock provenance.
 
@@ -105,151 +110,35 @@ After the change, restart DSH.
 
 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.
 
-Read-only evidence collection and actions that change packages, files, services, or Git state use separate tools. A successful lookup never grants permission to make a change. Exact command limits and platform evidence are documented in [`docs/COMPATIBILITY.md`](docs/COMPATIBILITY.md).
+Read-only observation and actions that change packages, files, services, or Git state remain separate. In 0.7.1, ordinary actions use Host tools; a successful lookup never grants permission to make a change. Exact command limits and platform evidence are documented in [`docs/COMPATIBILITY.md`](docs/COMPATIBILITY.md).
 
 ### When a requirement stays incomplete
 
-“Update the plugin and check the GUI” can contain work the Guard cannot certify, and questions such as “是否有更新” are inquiries: they stay recorded with their source, but no checkpoint or rebind can machine-certify an answer — complete the investigation and report the result. The checkpoint reports a reason and one concrete next action per item, and `context_guard_prepare` (read-only) shows, before a stateful action, the supported command shape, the required resolution/effect/state evidence order, and the exact missing target fields.
+“Update the plugin and check the GUI” can contain work the Guard cannot certify, and questions such as “是否有更新” are inquiries: they stay recorded with their source, but no checkpoint or rebind can machine-certify an answer — complete the investigation and report the result. The checkpoint reports a reason and one concrete next action per item. In 0.7.1, `context_guard_prepare` diagnoses the requirement and missing evidence; it is not an execution recipe for ordinary Host work.
 
-Use `context_guard_rebind` to propose an exact, complete split of the old text. If the action or target needs clarification, first ask the root user for an explicit instruction that includes the original clause; the proposal can reference that new item's ID. The tool returns a proposal ID and a comparison. The user applies it with the confirmation line `确认重绑定 <proposal ID>` as the first line of a reply; an explanation request or a new task after a blank line keeps its own meaning, and a new task is captured normally. A confirmation buried in a sentence, quotes, or a code block, or followed by a reversal, does nothing. Splitting a requirement into equally uncertifiable pieces returns “no certification gain” instead of asking for a pointless confirmation. Unsupported parts remain pending, and a qualified safe end does not mean all work is complete.
+Only use `context_guard_rebind` when the root requirement itself needs an exact, complete split. Ordinary work that lacks certification support does not need rebinding. If the action or target needs clarification, first ask the root user for an explicit instruction that includes the original clause; the proposal can reference that new item's ID. The tool returns a proposal ID and a comparison. The user applies it with the confirmation line `确认重绑定 <proposal ID>` as the first line of a reply; an explanation request or a new task after a blank line keeps its own meaning, and a new task is captured normally. A confirmation buried in a sentence, quotes, or a code block, or followed by a reversal, does nothing. Splitting a requirement into equally uncertifiable pieces returns “no certification gain” instead of asking for a pointless confirmation. Unsupported parts remain pending, and a qualified safe end does not mean all work is complete.
 
 The default `context_guard_checkpoint` call uses `bindings: []` for diagnosis. It shows at most eight current items/constraints and ten evidence rows, within 12 KiB of plugin JSON. `pagination` reports totals and a separate `next_cursor` for each list; the first page is not the whole contract. Use `item_ids` or `evidence_ids` to focus a query, or `evidence_scope: "history"` for the complete evidence history, including rows marked unavailable. Keep the query unchanged when following a cursor; a changed contract or evidence snapshot requires a fresh query. Large rows expose `detail_id`; retrieve chunks with `detail_offset` and return the first response's `snapshot` as `detail_snapshot` on later chunks. All queries remain read-only and never shrink the certification set.
 
-## What 0.6.3 changes for ordinary work
-
-Four things you will notice, and the one that matters most.
-
-**A question never deletes work beside it — and a mixed clause is no longer
-auto-authorized.** Separate clauses keep their own readings, so
-"更新插件，检查是否存在更新，安装新主题，记录变更。" is still an update, a
-question, an install and a record: the answer closes the question and the other
-three stay open. But when a question, an explanation, an investigation and an
-action share ONE clause, the Guard no longer guesses that the action is a
-separate instruction. It keeps the whole clause as one **undecided** obligation,
-which stays visible, cannot be closed by an ordinary answer, cannot take a
-completion certificate, and authorizes nothing — write the action as its own
-sentence to authorize it ("Check whether the cache is valid. Then install the
-package."). This is the deliberate narrowing recorded in
-[docs/CONTRACT_REVISION_0_6_3.md](docs/CONTRACT_REVISION_0_6_3.md): the earlier
-build tried to prove that such an action had left the question's scope, and every
-proof turned out to be a guess about vocabulary or word position. A purely
-informational request still closes with the answer it receives.
-
-**Where work happens is no longer assumed from where the session started.** When
-an instruction says which repository to change, the Guard records that choice
-and its source. When it does not, the session's working directory is kept as
-context only: a commit or push that never named a repository stays an explicit
-open question instead of being authorized against whichever directory the
-session happened to start in. A short follow-up such as "提交并推送" inherits the
-repository only when the current work unit holds exactly one repository the user
-already named; two candidates stay an explicit choice for you, and a repository
-called `/repo-a.js` is still a repository — a file extension is part of the name
-you gave, not proof of what kind of thing it is.
-
-**`context_guard_prepare` answers about the item you actually asked about.** It
-now reports whether your intended action, revision and target match the current
-obligation, using the same judgement the execution gate applies. If you assume a
-different action, it says so and names the item's own action instead of handing
-you a recipe the gate would refuse; an action manual is labelled `recipe_only`,
-and a target you supply that the obligation did not select is reported as a
-proposal, never as authority.
-
-**An obligation recorded by an earlier version is never inherited as a pass.**
-Upgrading to 0.6.3 re-reads the records that can still affect the current
-conclusion — including ones already marked answered — and flags any whose own
-text still orders work, or whose git target has no auditable source, as needing
-review. Their history is preserved byte for byte and nothing is re-executed, but
-they block a new certificate and a Goal completion until you resolve them, so a
-misreading an earlier version published cannot quietly become current truth.
-
-**The Guard no longer asks you to re-word a request it cannot certify.** When a
-task names a concrete action this build has no certification adapter for — a
-directory cleanup, a rename, a removal — the Guard reports that capability
-limit and leaves the work uncertified. It does not ask you for more input and it
-does not propose a rebind, because neither would change what can be certified.
-Work that the Guard cannot certify is still your work; it is simply reported as
-such. A rebind stays what it always was: a way to replace a recorded obligation
-with a real root instruction that names a supported action and target.
-
-**A successful tool call is no longer read as more than it says.** Every shell
-result now separates what the host returned, what the console actually declared
-about the exit status, whether the effect could be attributed to your task's own
-operation, and the business outcome. If no exit status was read, the Guard says
-`unknown` rather than assuming `0`; a compound script whose last command
-succeeded is not evidence that its earlier commands did.
-
-**A cleanup result keeps its condition.** "Remove it" is only satisfied for the
-objects proven to have no dependants. The recovery guidance states that
-condition, keeps unknown dependants visible, and reports registry removal,
-content removal and directory removal separately instead of summarising a
-partial result as done. This version does not add a remover, kill a process, or
-promise to block a condition the host cannot see.
-
-What does not change: ordinary answers, investigations and ordinary tool work
-still need no Guard approval, and the Guard never turns its own missing
-capability into a claim that you did not authorize the work.
-
-## What 0.6.1 changes for ordinary work
-
-The following behaviours are what you will actually notice. Everything before
-the new protocol boundary keeps its old meaning; nothing is re-read.
-
-**Asking a question no longer leaves a permanent to-do.** An automatically recognized question is closed by the host's own record: the final assistant message of a
-turn that completed normally. A status summary, a draft, an intermediate reply,
-another turn's answer, a subagent's answer, or an interrupted turn never closes
-it. "Answered" means the answer reached you — it says nothing about whether it
-was correct or whether any work was done.
-
-Unresolved explanation or mixed requests need an explicit span partition through `context_guard_interpret`. The caller identifies information and unknown spans; only information spans can close with the interpreting turn's answer. Unknown and undeclared spans stay pending. The guard checks structure and replay identity, while the model remains responsible for the semantic classification.
-
-**An attached screenshot or image is a question to answer, not a command to
-run.** Each attachment keeps its own identity and closes only through two
-facts: an explicit interpretation record (`context_guard_interpret` with the
-item ID, after actually reading the attachment) and the answer of the turn
-that recorded the interpretation. A picture of a commit button never authorizes a commit; an
-answer that says the images were not viewed closes nothing. Images plus real
-modifications close separately, and an explicitly requested visual
-verification still needs its own readback.
-
-**A document "update" is decided by the object, not the verb.** "Update the
-docs" becomes a bounded modification whose exact file you leave to the
-assistant, inside the directory and file type your instruction captured.
-Something the Guard cannot recognize as a file keeps an honest "I could not
-determine this" state instead of being forced into an action or silently closed.
-
-**Answering a question does not complete the rest of the sentence.**
-"Check for updates and also create report.txt" closes the question when the
-answer is delivered and leaves the file creation open until it has its own
-evidence.
-
-**Tasks are tracked as units.** Delegating a sub-task to a subagent opens a
-child unit whose open work counts towards the parent, so delegating never drops
-the parent's own work. A subagent's answer is recorded as bounded evidence and
-never closes the parent on its own. A prohibition or a wait you declared earlier
-continues to govern the same action in later tasks.
-
-**Corrections replace what they refine.** A later instruction that contains a
-pending obligation verbatim supersedes it atomically and keeps both revisions.
-Explanations, prohibitions and waits never delete an obligation by similar
-wording, and nothing is removed just because a new sentence looks alike.
-
-**A trusted answer to the host's own question narrows a target.** When the
-assistant asks you where a file should go and you pick a directory, that answer —
-from the host's own question tool, with its call and result both on record —
-narrows where the file may land. Text pasted into the conversation does not.
-Sandbox approvals are recorded separately and never grant a target.
+## Completion and recovery in 0.7.1
+
+The Guard keeps each requirement, prohibition and answer obligation in its original scope. A question closes when the host records delivery of its answer; a file edit, test or readback needs its own observed result. A request to change an image needs evidence about the changed image, not just a successful tool return. An explicit proof request still uses the proof contract, and an adopted Goal-completion path still checks its required results.
+
+The source of an action matters. A future observation, an unmet time or approval condition, insufficient evidence and a concrete ready action remain different states. A later authorization never changes an earlier Stop decision. A sourced pause, cancellation or short resume changes only the work that existed in its scope; quoted or old generic text does not become current authority on reload. Existing v5 history remains available for review, while new v6 work uses the current contract.
+
+If an obligation is ambiguous, `context_guard_rebind` can propose an exact split, but only an explicit root-user confirmation applies it. Unsupported verification is reported as insufficient; it does not grant an action or force an edit. Use `/context-guard diagnose` and the read-only checkpoint to see the missing predicate, then complete supported work with host tools and report limitations honestly.
+
+The 0.6.3 execution-era behavior is retained in the [0.6.3 changelog](CHANGELOG.md#063---2026-09-18) for existing installations. On 0.7.1, ordinary `context_guard_action` and `context_guard_evidence` calls only return migration guidance.
 
 ## Policy tiers
 
-Three tiers change how much proof is required at completion. They are separate
-from the `opt-in` / `always` activation modes, and installing never enters the
-release tier.
+Three tiers change how much proof is required at completion. They are separate from the `opt-in` / `always` activation modes, and installing never enters the release tier.
 
 | Tier | What it demands |
 | --- | --- |
 | `standard` (default) | Work must be supported by durable evidence; ordinary tools are not gated behind extra Guard approval. |
 | `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` | Only an explicitly adopted release contract authorizes a release operation. Until you adopt one, release operations are refused rather than performed under the standard rules. |
+| `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`:
 
@@ -263,12 +152,7 @@ Set the tier in the same `cordis.patch.yml` entry as `activation`:
 
 ### Explicit release contracts
 
-A release is never implicit. A "release" keyword in a message, a loaded Skill,
-or an installation does not adopt anything; only this command does:
-
-```text
-/context-guard release adopt {"operations":["npm_publish"],"candidate":{"ref":"refs/heads/main","fullSha40":"<40 hex characters>","version":"0.6.1","artifactDigest":"<64 hex characters>"}}
-```
+A release contract is never adopted by a keyword, loaded Skill or installation. When the user has separately authorized publication, an explicit `/context-guard release adopt` call names the covered operations and exact candidate ref, full commit, version and artifact digest. `/context-guard release` then shows its coverage and any unfinished operation. Do not reuse a historical candidate identity for a new release.
 
 After adoption, `/context-guard release` reports the contract, its candidate, its
 per-operation coverage, what has been consumed, and anything still in flight.
@@ -277,16 +161,7 @@ settled afterwards from a trusted readback. A wrong candidate SHA, ref, artifact
 digest or version, an expired ticket, a consumed ticket, a retry of a request
 that is still in flight, and an opaque runner are all refused before any effect.
 
-**Coverage is stated honestly, and the gap is attributed.** This release
-protects only the surface Guard itself routes: publishing an npm artifact
-through `context_guard_action`. `git tag` and the GitHub Release operations have
-no Guard-owned route yet, so a contract requiring them is refused before any
-effect and reported as `release_operation_unrouted` — a scope reduction this
-release explicitly took, not a claim that the host makes them impossible. A
-composite runner is refused as an opaque host boundary. `/context-guard release`
-prints this table in machine-readable form. A trusted in-process caller that
-bypasses the Guard entirely is a host trust boundary; the plugin reports what it
-can see and does not claim to stop what it cannot see.
+The retained controlled npm publication route is separate from the retired ordinary action/evidence path. Coverage is limited to operations Guard actually routes. `git tag` and GitHub Release have no Guard-owned route; a contract requiring them reports `release_operation_unrouted` rather than pretending that a host command was protected. A composite runner is opaque. `/context-guard release` reports the exact coverage. Publication still needs the user's authorization and host checks; Guard cannot control an in-process caller that bypasses its route.
 
 ## Boundaries
 
@@ -300,9 +175,7 @@ This project began as a DSH port of deterministic behavior from [`GreenLv/codex-
 
 Version 0.4.0 was deliberately aligned with the shared evidence rules in Codex Context Guard 0.10.0: proof must belong to work that is still open and must show the operation, target, and result the user actually requested. This is a limited behavior-level alignment, not a claim that the two products have the same features.
 
-The 0.6.x line implements the C01–C12 shared contract that pairs this release with a planned Codex Context Guard 0.14.0: source spans and coverage, one interpretation view, trusted answer delivery, work units with a required-descendant closure, per-action conditions, responsibility tiers, bounded target resolution, atomic clarification, the proof capability matrix, explicit release tickets, fresh projections, and unified migration diagnostics. The plain-language comparison, the implementation status per contract, and the dated delta ledger are in [`docs/SEMANTIC_COMPATIBILITY.md`](docs/SEMANTIC_COMPATIBILITY.md).
-
-Two shared artifacts are deliberately incomplete, and calling them done would be false. The upstream repository had not landed a frozen v2 conformance fixture at the time of this release, so the v2 fixture here is a **DSH-authored candidate** rather than a byte mirror, and `UPSTREAM_PIN.json` still pins only the unchanged v1 fixtures. Cross-language parity and the canonical mirror therefore remain open; the delta ledger records them as such.
+For 0.7.1, the shared core/v2 source files and conformance fixtures are byte-mirrored from the exact Codex Context Guard commit in `tests/fixtures/conformance/core_v2/UPSTREAM_PIN.json`. This proves source identity for those files, not complete feature or runtime parity; each product's host evidence and release remain independent. The earlier 0.6.x C01–C12 contract and DSH-authored v2 candidate are historical. The current comparison and its limits are in [`docs/SEMANTIC_COMPATIBILITY.md`](docs/SEMANTIC_COMPATIBILITY.md).
 
 The two repositories serve different runtimes:
 

package/README.zh-CN.md

@@ -4,14 +4,16 @@
 
 面向 DeepSeek Harness（DSH）的任务保护插件。它保存任务要求，并在任务标记完成前逐项核对；会话恢复后仍使用同一份检查表，只有匹配的已保存工具结果才能作为证据。
 
+> **0.7.1 发布线（2026-09-22）。** 安装前请读回[已发布 Release](https://github.com/GreenLv/dsh-completion-guard/releases)和 [npm 版本](https://www.npmjs.com/package/dsh-completion-guard)。本发布线的共享 core/v2 源码镜像绑定 Codex Context Guard 的精确提交；两个产品的运行时和发布身份分别管理。已验证范围和未完成门禁见[兼容性](docs/COMPATIBILITY.md)及[验收记录](docs/LOCAL_ACCEPTANCE.md)。
+
 ![任务合同条款与有界证据通过 checkpoint 匹配后签发完成证书](assets/social/completion-guard-hero.png)
 
 ## 快速开始
 
-安装 **0.6.3** 前，请先确认对应的 [GitHub Release](https://github.com/GreenLv/dsh-completion-guard/releases/tag/v0.6.3) 已发布。Release 提供精确制品身份与平台验收结果；[源码验收记录](docs/LOCAL_ACCEPTANCE.md) 保留开发阶段的检查。
+确认 npm 已提供 `0.7.1`、且 GitHub Release 绑定同一已验收制品及平台附件后，再安装：
 
 ```sh
-dsh plugin --profile web add dsh-completion-guard@0.6.3
+dsh plugin --profile web add dsh-completion-guard@0.7.1
 ```
 
 **先升级并重启 DSH，再执行下面的宿主锁检查。** 宿主锁记录 DSH 实际使用的包版本和安装目录；如果升级前就生成锁，新运行时会因包版本不匹配而拒绝它。`inject` 会修改 `<profile>/cordis.patch.yml`，请先备份该文件。
@@ -39,6 +41,12 @@ Windows 请通过 Web 配置目录下的 `node_modules\.bin\dsh-completion-guard
 
 默认采用 opt-in。`status` 显示 Guard 是否开启、启动阶段（`armed` 表示已就绪、等待你的第一条消息）以及还有多少检查项。`off` 停止保护当前会话，但不删除历史。`clear` 关闭当前待办，同时保留禁止项。`diagnose` 说明完成检查为什么通过或失败；`migration` 报告当前会话适用哪套规则、升级与回滚分别意味着什么；`release` 报告显式发布契约、其覆盖范围以及仍在执行中的操作。
 
+### 0.7.1 中的普通工作
+
+照常让 DSH 修改文件或运行测试，助手通过 DSH 宿主工具执行。Guard 保存要求，观察宿主已持久化的调用与结果；要求的结果需要独立核验时，再使用只读回读。例如，宿主修改配置文件后，另一次精确文件回读可证明新内容；具名测试需要自己的真实运行结果。工具返回成功或助手自述，不能证明无关条件，也不能抹去对禁改文件的真实修改。`context_guard_prepare` 说明缺少什么证据，`context_guard_checkpoint` 只核对证据实际证明的谓词。
+
+0.6.x 的普通 `context_guard_action` 与 `context_guard_evidence` 不再执行编辑、测试或 Git 效果，而是返回迁移说明。新建文件还需可信的写入前不存在证据。包脚本就绪观察可以选择已有测试或评估输入，不强迫再次编辑，但它不证明脚本已经运行，也不认证任意数值输出。后续观察长期收益的要求，要到其时间或审批条件满足后才成为当前工作；简短“继续”只推进有来源且已就绪的具体动作。
+
 ## 它保护什么
 
 - 保存需求、验收条件、禁止项和后续修正，不覆盖旧记录。
@@ -49,9 +57,9 @@ Windows 请通过 Web 配置目录下的 `node_modules\.bin\dsh-completion-guard
 
 ## 状态与兼容性
 
-0.6.3 仅支持 **DSH `0.1.5-rc.2` 或 `0.1.5-rc.1`**（配合 Cordis `4.0.2`），两者分别是当前已注册的最新版本和验证过的最低版本。旧 Session API、V2 事件词表和所有更早的宿主包组合仍已删除。如果你从 DSH `0.1.2-rc.1` 升级，请**新建会话**：Guard 不迁移旧日志、提案或证书，也不会删除或重新解释你的旧数据。
+0.7.1 继续仅支持 **DSH `0.1.5-rc.2` 或 `0.1.5-rc.1`**（配合 Cordis `4.0.2`），两者分别是当前已注册的最新版本和验证过的最低版本。旧 Session API、V2 事件词表和所有更早的宿主包组合仍已删除。如果你从 DSH `0.1.2-rc.1` 升级，请**新建会话**：Guard 不迁移旧日志、提案或证书，也不会删除或重新解释你的旧数据。
 
-插件市场与 npm 安装现在统一发布按新到旧排列的精确并集 `0.1.5-rc.2 || 0.1.5-rc.1`。更早版本、未注册的稳定版 `0.1.5` 以及未来版本都不会被宣称为受支持。进入版本集合后仍必须匹配完整的 33 包 DSH 核心图；缺失、混装或未知图会 fail closed。
+插件市场与 npm 元数据使用同一个按新到旧排列的精确并集 `0.1.5-rc.2 || 0.1.5-rc.1`。更早版本、未注册的稳定版 `0.1.5` 以及未来版本都不会被宣称为受支持。进入版本集合后仍必须匹配完整的 33 包 DSH 核心图；缺失、混装或未知图会 fail closed。
 
 已注册的宿主组合是 **DSH `0.1.5-rc.1` 和 `0.1.5-rc.2`**，各自绑定完整的 33 个核心包。包身份取自已发布的 npm tarball；两个版本混装会被拒绝。注册表身份和原生验收是不同证据：原生通过需要匹配 Guard 制品、宿主版本和平台的验收附件。版本规则和宿主锁来源详见[兼容性说明](docs/COMPATIBILITY.md)。
 
@@ -102,55 +110,25 @@ DSH 有两种运行方式：**Web** 是在浏览器的网页界面里使用 DSH
 
 启用后，Guard 会保存用户直接给出的要求和验收条件。只有已保存的工具结果与指定命令、文件或其他目标一致时，才能作为证据。取得机器完成认证需要通过 Guard 检查；证据缺失、过期或对象不一致时，任务保持未认证。当前证据规则未覆盖的调查或解释仍可如实回答并结束，但不会取得完成证书。
 
-只读证据收集与修改包、文件、服务或 Git 状态的操作使用不同工具。查询成功不会自动产生变更权限。精确命令限制和平台证据见 [`docs/COMPATIBILITY.md`](docs/COMPATIBILITY.md)。
+只读观察与修改包、文件、服务或 Git 状态的操作保持分离。0.7.1 的普通动作由宿主工具执行；查询成功不会自动产生变更权限。精确命令限制和平台证据见 [`docs/COMPATIBILITY.md`](docs/COMPATIBILITY.md)。
 
 ### 要求一直未完成时
 
-“更新插件并检查 GUI”可能包含 Guard 尚不能认证的部分；而“是否有更新”这类提问属于调查：Guard 会保留原文和来源，但如实说明无法机器认证——完成调查并如实回答即可。checkpoint 会逐项给出原因和一个具体的下一步；`context_guard_prepare`（只读）可以在执行有状态动作之前，展示受支持的命令形状、所需的 resolution/effect/state 证据顺序以及精确缺失的目标字段。
+“更新插件并检查 GUI”可能包含 Guard 尚不能认证的部分；而“是否有更新”这类提问属于调查：Guard 会保留原文和来源，但如实说明无法机器认证——完成调查并如实回答即可。checkpoint 会逐项给出原因和一个具体的下一步。0.7.1 的 `context_guard_prepare` 用于诊断要求和缺失证据，不是普通宿主工作的执行配方。
 
-用 `context_guard_rebind` 提出完整的原文拆分方案。动作或对象不明确时，先请根用户给出包含原条款的明确澄清要求，再在提案中引用新要求的 ID。工具会返回提案 ID 和原项/替代项对照；用户把确认行 `确认重绑定 <proposal ID>` 作为回复的第一行即可应用，空行之后的解释请求或新任务保留各自含义，新任务照常采集。嵌在句子、引号或代码块里的确认，以及后面跟反转表述的确认，都无效。把要求拆成同样不可认证的片段会得到“无认证收益”，而不是要求一次无意义的确认。未支持的部分继续保留 pending；按结构化边界安全结束也不表示全部完成。
+只有根要求本身需要拆分时，才用 `context_guard_rebind` 提出完整的原文拆分方案。普通工作缺少认证支持，不构成重新绑定的理由。动作或对象不明确时，先请根用户给出包含原条款的明确澄清要求，再在提案中引用新要求的 ID。工具会返回提案 ID 和原项/替代项对照；用户把确认行 `确认重绑定 <proposal ID>` 作为回复的第一行即可应用，空行之后的解释请求或新任务保留各自含义，新任务照常采集。嵌在句子、引号或代码块里的确认，以及后面跟反转表述的确认，都无效。把要求拆成同样不可认证的片段会得到“无认证收益”，而不是要求一次无意义的确认。未支持的部分继续保留 pending；按结构化边界安全结束也不表示全部完成。
 
 用 `bindings: []` 调用 `context_guard_checkpoint` 可查询诊断。默认最多展示八个当前要求/限制和十条证据，插件 JSON 不超过 12 KiB。`pagination` 给出总数及各列表独立的 `next_cursor`，首页不代表完整合同。`item_ids`、`evidence_ids` 可按 ID 查询；`evidence_scope: "history"` 可查看完整证据历史，其中不可引用项会明确标记。翻页时保持查询条件不变，合同或证据快照变化后需重新查询。超长行提供 `detail_id`，用 `detail_offset` 取分片；后续分片需把首次返回的 `snapshot` 作为 `detail_snapshot` 传回。分页只改变展示，不会减少认证时检查的要求。
 
-## 0.6.3 为普通工作带来的变化
-
-你会注意到四件事，以及最重要的那一件。
-
-**疑问不会删掉旁边的指令，但同一子句内的混排不再自动授权。** 分开的子句各自保有自己的判读，因此“更新插件，检查是否存在更新，安装新主题，记录变更。”仍是一次更新、一个问句、一次安装、一次记录：回答只关闭问句，其余三项保持未完成。但当疑问、解释、调查与动作同处**一个子句**时，Guard 不再猜测该动作是独立指令，而是把整句保留为一条**未决**义务：它可见、不能被普通回答关闭、不能取得完成证书、不授予任何执行权限——想授权就把动作另写成一句（“确认缓存是否有效。然后安装依赖。”）。这是[合同修订说明](docs/CONTRACT_REVISION_0_6_3.md)记录的**有意收窄**：此前版本试图证明这类动作已经脱离疑问范围，而每一版证明都只是关于词表或词位的猜测。纯信息请求仍由收到的回答关闭。
-
-**执行位置不再从会话启动目录推断。** 指令写明要改哪个仓库时，Guard 记录该选择及其来源；没有写明时，会话工作目录只作为上下文保留：未指明仓库的提交或推送保持为明确的待澄清问题，而不是按会话碰巧启动的目录放行。简短后续（“提交并推送”）只在当前工作单元中恰有一个用户已指定的仓库时继承它；出现两个候选时保持明确的选择留给用户；名为 `/repo-a.js` 的仓库仍是仓库——扩展名是你给的名字的一部分，不是它是何类文件的证据。
-
-**`context_guard_prepare` 回答的是你真正问的那一项。** 它现在用执行门禁所用的同一判据，报告你打算执行的动作、修订与目标是否与当前义务一致。假设了不同动作时，它会说明并给出条目自身的动作，而不是给出一份门禁会拒绝的手册；动作手册标注为 `recipe_only`；你提供而义务并未选择的目标按“提议”报告，不作为授权。
-
-**旧版本记录的义务不再被继承为通过。** 升级到 0.6.3 会重新检查仍会影响当前结论的记录（包括已标记 answered 的记录），凡自身文本仍包含执行要求、或其 Git 目标缺少可审计来源的，都标记为需要复核。历史按字节保留，不重放任何动作；但在你处理之前，它们会阻断新证书与 Goal 完成结论，使旧版本发布的误读不会悄然成为当前事实。
-
-**守护程序不再要求你改写它无法认证的请求。** 当一个任务写明了本构建没有认证适配器的具体动作（例如清理目录、重命名、移除）时，Guard 报告这一能力限制，并让该工作保持未认证。它不再向你索要输入，也不再建议重绑定，因为这两者都不会改变能认证的范围。Guard 无法认证的工作仍然是你的工作，只是被如实报告为未认证。重绑定保持原义：用真实的根指令替换已记录义务，并且该指令必须写明受支持的动作与目标。
-
-**工具调用成功不再被读成超出其本身的事实。** 每条 shell 结果现在分开表达：宿主返回了什么、控制台实际声明了什么退出状态、效果能否归属到本任务的操作、以及业务结果。如果没有读到退出状态，Guard 说 `unknown` 而不假定为 `0`；复合脚本最后一条命令成功，不构成前面命令也成功的证据。
-
-**清理结果保留其适用条件。** “已删除”只对已证明无依赖的对象成立。恢复指引会陈述该条件、保持未知依赖可见，并分别报告注册信息移除、内容移除与目录移除，而不是把部分结果总结为完成。本版本不新增删除执行器、不杀进程，也不承诺阻止宿主无法观察的条件。
+## 0.7.1 中的完成与恢复
 
-保持不变的部分：普通回答、调查与普通工具工作仍不需要 Guard 审批，Guard 也不会把自己的能力缺口说成你未授权。
+Guard 按原始范围保留每项要求、禁止项和答复义务。宿主记录答复已交付后，问题才可关闭；文件修改、测试或回读仍需各自的真实结果。修改图片的要求要核验修改后的图片，不能只看工具是否成功。显式 proof 要求继续走 proof 契约；已采用的 Goal 完成路径仍核验必需结果。
 
-## 0.6.1 为普通工作带来的变化
+动作来源决定其范围。未来观察、尚未满足的时间或审批条件、证据不足和已就绪的具体动作是不同状态。后来的授权不会改写更早的 Stop 判断。有来源的暂停、取消或简短恢复只影响其范围内已经存在的工作；引用文字和旧 generic 待办不会在重载后变成当前授权。旧 v5 历史保留供复核，新 v6 工作使用当前合同。
 
-以下是你实际会注意到的行为。新协议边界之前的一切保持原有含义，不会被重新解释。
+义务含糊时，`context_guard_rebind` 可以提出精确拆分，但只有根用户明确确认才会应用。无法支持的核验会如实报告证据不足，不授予动作，也不强迫再次编辑。用 `/context-guard diagnose` 和只读 checkpoint 查看缺失谓词，再通过宿主工具完成可支持的工作，并如实说明边界。
 
-**提问不再留下永久待办。** 自动识别的疑问由宿主自身的记录关闭：正常完成 turn 的最后一条 assistant 消息。状态汇报、草稿、中间回复、其它 turn 的回答、子代理回答和被中断的 turn 都不会关闭它。"已交付"只说明回答到达了你，不说明它正确，也不说明有任何工作被执行。
-
-无法判定的解释或混合请求需要通过 `context_guard_interpret` 显式划分信息与未知跨度。只有信息部分可由解释 turn 的回答关闭；未知和未申报部分保持 pending。Guard 校验结构与重放身份，语义划分的正确性仍由模型负责。
-
-**附带的截图或图片是要回答的问题，不是要执行的命令。** 每个附件保留自己的身份，其关闭需要两个事实：显式的解释记录（实际读取附件后用 `context_guard_interpret` 传入 item ID）加上记录解释的 turn 的回答。一张包含提交按钮的图片不构成提交授权；声称"尚未查看图片"的回答什么也关不了。附图与真实修改分开关闭，明确要求的视觉验证仍需要自己的回读事实。
-
-**文档"更新"由对象决定，而不是动词。** "更新文档"变成一次有界修改：具体文件由助手在你指令捕获到的目录与文件类型内决定。Guard 无法识别为文件的对象会保持诚实的"无法判定"状态，而不是被强行归为某个动作或被静默关闭。
-
-**回答一个问题不等于完成整句话。** "检查是否有更新，顺便创建 report.txt"会在回答交付时关闭问题部分，而文件创建保持未完成，直到它有独立证据。
-
-**任务按工作单元跟踪。** 把子任务委派给子代理会开启一个子单元，其未完成工作计入父单元，因此委派不会丢掉父任务自身的工作。子代理的回答记录为有界证据，绝不单独关闭父项。你此前声明的禁止项或等待，对后续任务中同一动作继续生效。
-
-**澄清原子替换其修正对象。** 后续指令逐字包含某条未决义务时会原子替换它，并保留新旧 revision。解释、禁止和等待绝不因相似措辞删除义务，也不会因为新句子看起来相似就删除任何东西。
-
-**宿主问答的可信回答会收窄目标。** 当助手询问文件放在哪里、你选择了某个目录，这个来自宿主问答工具、且 call 与 result 都在案的回答会收窄文件落点。粘贴进对话的文本不构成任何东西。沙箱审批单独记录，且从不用来授予目标。
+旧安装的 0.6.3 执行流程保留在[对应更新日志](CHANGELOG.zh-CN.md#0632026-09-18)中。0.7.1 的普通 `context_guard_action` 与 `context_guard_evidence` 调用只返回迁移说明。
 
 ## 策略档位
 
@@ -160,7 +138,7 @@ DSH 有两种运行方式：**Web** 是在浏览器的网页界面里使用 DSH
 | --- | --- |
 | `standard`（默认） | 工作必须有持久证据支撑；普通工具不会被额外的 Guard 审批拦在后面。 |
 | `strict` | 在 standard 之上，你明确要求的视觉或完整范围验证必须由真实回读事实兑现，而不是一次"只是成功"的工具调用。 |
-| `release` | 只有显式采用的发布契约才能授权发布操作。未采用之前，发布操作会被拒绝，而不是按 standard 规则执行。 |
+| `release` | 显式采用的发布契约按精确候选和一次性预约核验受覆盖的发布操作。契约本身不提供用户授权或宿主权限。 |
 
 在 `cordis.patch.yml` 的同一项里与 `activation` 一起设置：
 
@@ -174,15 +152,11 @@ DSH 有两种运行方式：**Web** 是在浏览器的网页界面里使用 DSH
 
 ### 显式发布契约
 
-发布绝不隐式发生。消息里的 "release" 关键词、加载的 Skill 或一次安装都不会采用任何东西；只有这条命令会：
-
-```text
-/context-guard release adopt {"operations":["npm_publish"],"candidate":{"ref":"refs/heads/main","fullSha40":"<40 位十六进制>","version":"0.6.1","artifactDigest":"<64 位十六进制>"}}
-```
+消息中的“发布”关键词、加载的 Skill 或安装都不会自动采用发布契约。用户另外授权发布后，可通过 `/context-guard release adopt` 显式给出所覆盖的操作、候选 ref、完整提交、版本和制品摘要。`/context-guard release` 随后显示覆盖范围与未结算操作。新版本不能复用历史候选身份。
 
 采用之后，`/context-guard release` 报告契约、候选、逐操作覆盖范围、已消费内容和仍在执行中的操作。每个操作只消耗一次预约记录：效果前写入，效果后依据可信回读结算。错候选 SHA、错 ref、错制品摘要或版本、过期票据、已消费票据、仍在执行中的请求重试和不透明 runner 都会在任何副作用之前被拒绝。
 
-**覆盖面如实声明，并说明缺口归属。** 本版只保护 Guard 自己路由的表面：经 `context_guard_action` 发布 npm 制品。`git tag` 与 GitHub Release 各操作尚无 Guard 自有路由，因此要求它们的契约会在效果前被拒绝并报告为 `release_operation_unrouted`——这是本版明确采取的**范围缩减**，不是"宿主做不到"。复合 runner 作为不透明宿主边界被拒绝。`/context-guard release` 以机器可读形式打印该表。完全绕过 Guard 的可信进程内调用属于宿主信任边界；插件只报告它能看到的，不宣称能阻止它看不到的。
+保留的受控 npm 发布路径与已退役的普通 action/evidence 路径分开。Guard 只保护它实际路由的发布操作。`git tag` 与 GitHub Release 没有 Guard 自有路由；要求它们的契约会报告 `release_operation_unrouted`，不会假装宿主命令已受保护。复合 runner 是不透明边界，`/context-guard release` 会报告精确覆盖范围。发布仍需用户授权和宿主检查；插件不能控制绕过其路由的进程内调用。
 
 ## 边界
 
@@ -196,9 +170,7 @@ Context Guard 负责完成认证；Goal、Todo、Compaction、continuation、权
 
 0.4.0 明确对齐了 Codex Context Guard 0.10.0 的共享证据规则：证据必须对应仍未完成的工作，并证明用户实际要求的操作、目标和结果。这只是有边界的行为对齐，不表示两个产品拥有相同功能。
 
-0.6.x 实现了与本版配套的 Codex Context Guard 0.14.0 计划共享的 C01–C12 契约：来源跨度与覆盖、统一解释视图、可信回答交付、带必需后代闭包的工作单元、逐动作条件、责任分档、有界目标解析、原子澄清、证明能力矩阵、显式发布票据、新鲜投影和统一迁移诊断。逐条实现状态、通俗对照与注明日期的差异台账见 [`docs/SEMANTIC_COMPATIBILITY.md`](docs/SEMANTIC_COMPATIBILITY.md)。
-
-有两项共享资产是刻意未完成的，写成已完成就是失实：上游仓库在本版发布时尚未落地冻结的 v2 一致性 fixture，因此这里的 v2 文件是 **DSH 产出的候选**而非字节镜像，`UPSTREAM_PIN.json` 仍只绑定未变的 v1 镜像。跨语言 parity 与正式镜像因此仍待完成，差异台账按此记录。
+0.7.1 的共享 core/v2 源码和一致性夹具，按 `tests/fixtures/conformance/core_v2/UPSTREAM_PIN.json` 记录的 Codex Context Guard 精确提交进行字节镜像。这只证明所列文件的源码身份，不证明两个产品功能或运行时完全等价；宿主证据与发布仍分别核验。0.6.x 的 C01–C12 契约和 DSH 自行编写的 v2 候选属于历史阶段。当前对照和限制见 [`docs/SEMANTIC_COMPATIBILITY.md`](docs/SEMANTIC_COMPATIBILITY.md)。
 
 两个项目服务于不同运行时：