dsh-completion-guard 0.6.2 → 0.7.0

package/CHANGELOG.md

@@ -2,6 +2,95 @@
 
 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.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
+record eligibility. For publication status and same-artifact native evidence, use
+[the versioned release](https://github.com/GreenLv/dsh-completion-guard/releases/tag/v0.6.3).
+[Local acceptance](docs/LOCAL_ACCEPTANCE.md) records the source checks.
+
+### Changes
+
+- **Execution requires an independently recognized instruction.** Questions,
+  explanations, reported or quoted commands cannot grant execution authority.
+  Mixed requests whose action remains inside that scope stay unresolved and
+  cannot be closed by an ordinary answer. Write an independent instruction as
+  another sentence or semicolon-separated clause. Stored execution qualification
+  is inherited without promotion and consumed by both prepare and execution.
+  See the [contract revision](docs/CONTRACT_REVISION_0_6_3.md) for the intentional
+  compatibility change.
+- **The session working directory is no longer a target selection.** An
+  obligation's target now carries its provenance: an explicit name or path, a
+  phrase that selects the current repository, a trusted host selection, or a
+  unique selection inherited from another obligation of the same work unit. A
+  git action whose clause names no repository keeps that directory as
+  environment context only, so it stays a target clarification instead of
+  authorizing a mutation the root never chose. Several equally sourced
+  candidates stay ambiguous; a different repository is still refused.
+- **Preparation and execution answer the same compatibility question.**
+  `context_guard_prepare` evaluates the current item, action, revision and
+  target through the judgement the mutation gate enforces, reports
+  `incompatible` with the item's own action when the assumption is not what the
+  obligation records, and only ever returns a caller-named recipe labelled
+  `recipe_only`. A caller-supplied target that differs from the item's is
+  reported as a proposal, not as authority.
+- **Records captured under earlier rules are not inherited as passes.** An
+  upgrade eligibility check runs before any terminal filtering and covers
+  records the open-closure computation skips, including ones already
+  `answered`. A record whose own text still orders work, or whose git target has
+  no auditable source, is marked `needs_review`: its historical status is
+  preserved, nothing is re-executed, and the record blocks new certificates and
+  Goal completion instead of producing a warning. Unknown state versions are
+  reported rather than assumed compatible.
+- Codex alignment is restated honestly. A new recording executes the installed
+  Codex module's own reply-only delivery judge on twelve shared inputs
+  (`tests/fixtures/cross-end/codex-0.13.9.shape.json`), and the cross-end ledger
+  records each family's measured disposition. On this batch Codex refuses to
+  close all twelve, so the mixed-request and pure-question families are
+  `not-aligned` in the direction that matters, and the
+  `trusted-answer-delivery` claim is downgraded from `aligned`.
+- **Target uniqueness includes every identity field.** Candidate lists preserve
+  case where identity is case-sensitive, and package specs contribute both name
+  and version. Ordinary capture, restatements and every action-plan entry reject
+  conflicting choices. Restatements bind the new action and target together;
+  only omitted fields with unique sources can be inherited.
+
+### Upgrade and validation
+
+Write an intended action as an independent instruction when it shares a question
+or explanation's scope. Legacy records without execution qualification require
+review; no historical action is replayed. The exact supported DSH versions remain
+`0.1.5-rc.2 || 0.1.5-rc.1`.
+
+The final source suite passed 2140 tests with one skip. Historical repair rounds,
+contract changes and evidence limits are retained in
+[local acceptance](docs/LOCAL_ACCEPTANCE.md). These checks do not replace the
+exact-artifact native annexes attached to the versioned Release.
+
 ## 0.6.2 - 2026-09-16
 
 ### Changes

package/CHANGELOG.zh-CN.md

@@ -2,6 +2,49 @@
 
 本项目的重要变化记录在这里。项目仍处于 1.0 之前；版本号跟踪插件生命周期，不代表 API 已稳定。
 
+## 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) 保留源码检查。
+
+### 变更
+
+- **只有独立识别出的指令才能获得执行资格。** 疑问、解释、转述与引用命令不授予执行权限；动作仍处于这些范围内的混合请求保持未决，普通回答不能将其关闭。需要执行时，请另起一句或用分号分隔独立指令。资格持久保存，子项只能继承而不能提升，prepare 与执行共用它。此项有意收窄自动授权范围，详见[合同修订说明](docs/CONTRACT_REVISION_0_6_3.md)。
+- **会话工作目录不再等于用户选择的目标。** 义务的目标现在带有来源：显式名称或路径、明确选择当前仓库的表达、受信宿主选择，或来自同一工作单元内另一义务的唯一可审计选择。子句未指明仓库的 Git 动作只把该目录作为环境上下文保留，因此仍是目标待澄清，而不是为根用户未选择的变更放行。多个同源候选保持歧义；指向另一仓库仍被拒绝。
+- **prepare 与执行共用同一兼容判据。** `context_guard_prepare` 用变更门禁所执行的同一判据评估当前条目、动作、修订与目标：假设与义务记载不符时返回 `incompatible` 并指出条目自身的动作，只返回标注 `recipe_only` 的调用者假设手册；调用者提供的目标与条目自身目标不同时按“提议”报告，不作为授权。
+- **按旧规则捕获的记录不再被继承为通过。** 升级资格检查在任何终态过滤之前执行，覆盖开闭包计算会跳过的记录，包括已 `answered` 的记录。自身文本仍包含执行要求、或 Git 目标缺少可审计来源的记录被标记 `needs_review`：历史状态原样保留，不重放任何动作，并阻断新证书与 Goal 完成结论，而不是只给旁路警告。未知状态版本会被报告，不再假定兼容。
+- 如实重述 Codex 对齐范围。新增实测记录执行已安装 Codex 模块自身的纯回答交付判据（12 条共享输入，`tests/fixtures/cross-end/codex-0.13.9.shape.json`），跨端台账逐族记录实测结论。本批 12 条 Codex 全部拒绝以此方式关闭，故混合请求与纯问句两族记为关键方向上的 `not-aligned`，`trusted-answer-delivery` 从 `aligned` 下调。
+- **目标唯一性覆盖全部身份字段。** 候选按各字段的身份规则处理大小写；包规格同时贡献包名和版本。普通捕获、重述及动作计划的每一项都拒绝冲突选择。重述把新动作与新目标一起绑定，仅从唯一来源继承省略的字段。
+
+### 升级与验证
+
+动作仍处于疑问或解释范围时，请将要执行的动作写成独立指令。缺少执行资格的旧记录需要复核，不重放历史动作。支持的 DSH 版本仍为 `0.1.5-rc.2 || 0.1.5-rc.1`。
+
+最终源码测试为 2140 项通过、1 项跳过。历轮修复、合同调整与证据边界保留在[本地验收记录](docs/LOCAL_ACCEPTANCE.md)；源码检查不能代替对应 Release 附带的精确制品原生验收附件。
+
 ## 0.6.2（2026-09-16）
 
 ### 变更

package/README.md

@@ -4,16 +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.0 release line (2026-09-21).** 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
 
-**0.6.2** is the current source candidate; it is not published yet, so the
-registry command below still installs the newest published version. Candidate
-and platform results are recorded in [LOCAL_ACCEPTANCE](docs/LOCAL_ACCEPTANCE.md):
+After confirming that npm serves `0.7.0` 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.1
+dsh plugin --profile web add dsh-completion-guard@0.7.0
 ```
 
 **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.
@@ -39,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.0
+
+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
 
@@ -51,9 +57,9 @@ Activation is opt-in by default. `status` shows whether the Guard is on, its sta
 
 ## Status and compatibility
 
-Version 0.6.2 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.0 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.
 
@@ -104,108 +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.0, 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.0, `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.
 
 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.2 changes for ordinary work
-
-Three things you will notice, and one thing you will not.
-
-**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.0
+
+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.0, 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`:
 
@@ -219,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.
@@ -233,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
 
@@ -256,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.0, 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.0 发布线（2026-09-21）。** 安装前请读回[已发布 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.2** 是当前源码候选，尚未发布；下面的命令仍会安装注册表中最新已发布版本。候选与平台结果见[验收记录](docs/LOCAL_ACCEPTANCE.md)：
+确认 npm 已提供 `0.7.0`、且 GitHub Release 绑定同一已验收制品及平台附件后，再安装：
 
 ```sh
-dsh plugin --profile web add dsh-completion-guard@0.6.1
+dsh plugin --profile web add dsh-completion-guard@0.7.0
 ```
 
 **先升级并重启 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.0 中的普通工作
+
+照常让 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.2 仅支持 **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.0 继续仅支持 **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,47 +110,25 @@ DSH 有两种运行方式：**Web** 是在浏览器的网页界面里使用 DSH
 
 启用后，Guard 会保存用户直接给出的要求和验收条件。只有已保存的工具结果与指定命令、文件或其他目标一致时，才能作为证据。取得机器完成认证需要通过 Guard 检查；证据缺失、过期或对象不一致时，任务保持未认证。当前证据规则未覆盖的调查或解释仍可如实回答并结束，但不会取得完成证书。
 
-只读证据收集与修改包、文件、服务或 Git 状态的操作使用不同工具。查询成功不会自动产生变更权限。精确命令限制和平台证据见 [`docs/COMPATIBILITY.md`](docs/COMPATIBILITY.md)。
+只读观察与修改包、文件、服务或 Git 状态的操作保持分离。0.7.0 的普通动作由宿主工具执行；查询成功不会自动产生变更权限。精确命令限制和平台证据见 [`docs/COMPATIBILITY.md`](docs/COMPATIBILITY.md)。
 
 ### 要求一直未完成时
 
-“更新插件并检查 GUI”可能包含 Guard 尚不能认证的部分；而“是否有更新”这类提问属于调查：Guard 会保留原文和来源，但如实说明无法机器认证——完成调查并如实回答即可。checkpoint 会逐项给出原因和一个具体的下一步；`context_guard_prepare`（只读）可以在执行有状态动作之前，展示受支持的命令形状、所需的 resolution/effect/state 证据顺序以及精确缺失的目标字段。
+“更新插件并检查 GUI”可能包含 Guard 尚不能认证的部分；而“是否有更新”这类提问属于调查：Guard 会保留原文和来源，但如实说明无法机器认证——完成调查并如实回答即可。checkpoint 会逐项给出原因和一个具体的下一步。0.7.0 的 `context_guard_prepare` 用于诊断要求和缺失证据，不是普通宿主工作的执行配方。
 
 用 `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.2 为普通工作带来的变化
-
-你会注意到三件事，以及一件不会发生的事。
-
-**守护程序不再要求你改写它无法认证的请求。** 当一个任务写明了本构建没有认证适配器的具体动作（例如清理目录、重命名、移除）时，Guard 报告这一能力限制，并让该工作保持未认证。它不再向你索要输入，也不再建议重绑定，因为这两者都不会改变能认证的范围。Guard 无法认证的工作仍然是你的工作，只是被如实报告为未认证。重绑定保持原义：用真实的根指令替换已记录义务，并且该指令必须写明受支持的动作与目标。
-
-**工具调用成功不再被读成超出其本身的事实。** 每条 shell 结果现在分开表达：宿主返回了什么、控制台实际声明了什么退出状态、效果能否归属到本任务的操作、以及业务结果。如果没有读到退出状态，Guard 说 `unknown` 而不假定为 `0`；复合脚本最后一条命令成功，不构成前面命令也成功的证据。
-
-**清理结果保留其适用条件。** “已删除”只对已证明无依赖的对象成立。恢复指引会陈述该条件、保持未知依赖可见，并分别报告注册信息移除、内容移除与目录移除，而不是把部分结果总结为完成。本版本不新增删除执行器、不杀进程，也不承诺阻止宿主无法观察的条件。
-
-保持不变的部分：普通回答、调查与普通工具工作仍不需要 Guard 审批，Guard 也不会把自己的能力缺口说成你未授权。
-
-## 0.6.1 为普通工作带来的变化
+## 0.7.0 中的完成与恢复
 
-以下是你实际会注意到的行为。新协议边界之前的一切保持原有含义，不会被重新解释。
+Guard 按原始范围保留每项要求、禁止项和答复义务。宿主记录答复已交付后，问题才可关闭；文件修改、测试或回读仍需各自的真实结果。修改图片的要求要核验修改后的图片，不能只看工具是否成功。显式 proof 要求继续走 proof 契约；已采用的 Goal 完成路径仍核验必需结果。
 
-**提问不再留下永久待办。** 自动识别的疑问由宿主自身的记录关闭：正常完成 turn 的最后一条 assistant 消息。状态汇报、草稿、中间回复、其它 turn 的回答、子代理回答和被中断的 turn 都不会关闭它。"已交付"只说明回答到达了你，不说明它正确，也不说明有任何工作被执行。
+动作来源决定其范围。未来观察、尚未满足的时间或审批条件、证据不足和已就绪的具体动作是不同状态。后来的授权不会改写更早的 Stop 判断。有来源的暂停、取消或简短恢复只影响其范围内已经存在的工作；引用文字和旧 generic 待办不会在重载后变成当前授权。旧 v5 历史保留供复核，新 v6 工作使用当前合同。
 
-无法判定的解释或混合请求需要通过 `context_guard_interpret` 显式划分信息与未知跨度。只有信息部分可由解释 turn 的回答关闭；未知和未申报部分保持 pending。Guard 校验结构与重放身份，语义划分的正确性仍由模型负责。
+义务含糊时，`context_guard_rebind` 可以提出精确拆分，但只有根用户明确确认才会应用。无法支持的核验会如实报告证据不足，不授予动作，也不强迫再次编辑。用 `/context-guard diagnose` 和只读 checkpoint 查看缺失谓词，再通过宿主工具完成可支持的工作，并如实说明边界。
 
-**附带的截图或图片是要回答的问题，不是要执行的命令。** 每个附件保留自己的身份，其关闭需要两个事实：显式的解释记录（实际读取附件后用 `context_guard_interpret` 传入 item ID）加上记录解释的 turn 的回答。一张包含提交按钮的图片不构成提交授权；声称"尚未查看图片"的回答什么也关不了。附图与真实修改分开关闭，明确要求的视觉验证仍需要自己的回读事实。
-
-**文档"更新"由对象决定，而不是动词。** "更新文档"变成一次有界修改：具体文件由助手在你指令捕获到的目录与文件类型内决定。Guard 无法识别为文件的对象会保持诚实的"无法判定"状态，而不是被强行归为某个动作或被静默关闭。
-
-**回答一个问题不等于完成整句话。** "检查是否有更新，顺便创建 report.txt"会在回答交付时关闭问题部分，而文件创建保持未完成，直到它有独立证据。
-
-**任务按工作单元跟踪。** 把子任务委派给子代理会开启一个子单元，其未完成工作计入父单元，因此委派不会丢掉父任务自身的工作。子代理的回答记录为有界证据，绝不单独关闭父项。你此前声明的禁止项或等待，对后续任务中同一动作继续生效。
-
-**澄清原子替换其修正对象。** 后续指令逐字包含某条未决义务时会原子替换它，并保留新旧 revision。解释、禁止和等待绝不因相似措辞删除义务，也不会因为新句子看起来相似就删除任何东西。
-
-**宿主问答的可信回答会收窄目标。** 当助手询问文件放在哪里、你选择了某个目录，这个来自宿主问答工具、且 call 与 result 都在案的回答会收窄文件落点。粘贴进对话的文本不构成任何东西。沙箱审批单独记录，且从不用来授予目标。
+旧安装的 0.6.3 执行流程保留在[对应更新日志](CHANGELOG.zh-CN.md#0632026-09-18)中。0.7.0 的普通 `context_guard_action` 与 `context_guard_evidence` 调用只返回迁移说明。
 
 ## 策略档位
 
@@ -152,7 +138,7 @@ DSH 有两种运行方式：**Web** 是在浏览器的网页界面里使用 DSH
 | --- | --- |
 | `standard`（默认） | 工作必须有持久证据支撑；普通工具不会被额外的 Guard 审批拦在后面。 |
 | `strict` | 在 standard 之上，你明确要求的视觉或完整范围验证必须由真实回读事实兑现，而不是一次"只是成功"的工具调用。 |
-| `release` | 只有显式采用的发布契约才能授权发布操作。未采用之前，发布操作会被拒绝，而不是按 standard 规则执行。 |
+| `release` | 显式采用的发布契约按精确候选和一次性预约核验受覆盖的发布操作。契约本身不提供用户授权或宿主权限。 |
 
 在 `cordis.patch.yml` 的同一项里与 `activation` 一起设置：
 
@@ -166,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` 会报告精确覆盖范围。发布仍需用户授权和宿主检查；插件不能控制绕过其路由的进程内调用。
 
 ## 边界
 
@@ -188,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.0 的共享 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)。
 
 两个项目服务于不同运行时：