dsh-completion-guard 0.6.1 → 0.6.3

package/docs/RELEASE_PLAN_0_6_2.md

@@ -0,0 +1,41 @@
+# 0.6.2 发版计划 / Release plan
+
+更新：2026-09-16。目标包：`dsh-completion-guard@0.6.2`；拟用标签：`v0.6.2`。开发基线：`d11009d8f755ecee7d288cff18250c7b372cfd2a`。候选尚未提交或冻结；上述基线不是发布提交。
+
+This plan advances the reviewed implementation toward release. The candidate is uncommitted and no release artifact has been frozen. The development baseline above is not the release commit.
+
+## 当前证据 / Current evidence
+
+- D062-01–03 的已报告代码缺陷已修复，checkpoint 来源与冲突字段经真实工具入口验证。D062-04 有界函数级对照已补齐，详见 [跨端结果合同](CROSS_END_RESULT_CONTRACT.md)。
+- 2026-09-16 Codex/macOS、Node 25.1.0、Python 3.12.2：完整 Vitest 为 70 文件通过、1092 项通过、1 项跳过。单独运行 `host-target-preflight` 为 46 项通过。DSH 先前报告的 8 项失败在该环境未复现；这不证明其原因，也不代替 Node 22/24 或 Windows 验证。
+- The reported implementation defects are repaired. The full local Vitest run passed in the environment above. The earlier eight DSH failures were not reproduced here; their cause remains unconfirmed. D062-04 now has bounded lifecycle recordings; native acceptance remains separate.
+
+## 顺序与出口 / Sequence and exit criteria
+
+| 阶段 / Stage | 执行与验收 / Required result | 当前状态 / Status |
+| --- | --- | --- |
+| 1. 跨端补证 / Cross-end evidence | 同一混合结果分别进入 DSH 与 Codex 完整验证路径；隔离合成会话通过 Codex 自有入口建立可验证账本，覆盖 stop、纠正、pending、wait 与用户可见纠正。不得读取用户真实任务账本或伪造通过。 / Exercise equivalent mixed results and valid isolated-ledger lifecycle cases on both products. | 有界函数级对照通过 / Bounded function-level comparison passed |
+| 2. 文档及源码冻结 / Source freeze | 冻结版本、双语文档、包清单、manifest、dist；执行完整本地矩阵、两模式录制检查、文档审计与带文档哈希的 reader review。以确切 Git 提交作为候选身份。 / Freeze all shipped bytes and bind passing checks and reader review to the candidate. | 准备中 / Preparing |
+| 3. 候选 CI / Candidate CI | 提交并推送最终候选，确认同一提交的 Ubuntu/macOS/Windows × Node 22/24 六通道与 static 合同全部通过。 / Verify all six portability lanes and static contracts on the exact candidate. | 未执行 / Not run |
+| 4. 单一制品 / One artifact | 使用 CI static 阶段已有的 canonical pack 与托管制品，回读 tgz、SHA256SUMS.txt、release-artifact.json、嵌入 gitHead、文件清单。若不采用 CI 制品，另明确指定唯一冻结来源，不能混用或在主机重打包。 / Select and verify one canonical artifact set; never repack per host. | 未冻结 / Not frozen |
+| 5. 原生验收 / Native acceptance | 同一 tgz 的 Windows/macOS 安装、严格二次 no-op、包字节对齐、host-lock 回读、Web/Headless 生命周期、cleanup；另完成开发计划 T06 的 Windows 真实句柄部分删除和 macOS 原生结果检查。 / Run exact-artifact host acceptance and the additional T06 scenarios. | 未执行 / Not run |
+| 6. 发布前核对 / Publication readiness | 汇总 candidate-closure、reader review、CI、原生 annex、制品身份、双语 release notes、精确标题及发布动作；检查标签与 npm 版本空缺，完成认证预检。 / Validate readiness and the exact public action list. | 未就绪 / Not ready |
+| 7. 发布与回读 / Publish and read back | 仅发布已验收 tgz；验证注释标签目标、npm gitHead/integrity/下载字节、GitHub Release 目标与资产。 / Publish the accepted bytes and independently verify every public identity. | 未发布 / Not published |
+
+阶段 1 已由隔离合成账本补齐，不涉及用户私态。剩余原生门槛不能由此替代。
+
+Stage 1 is covered by disposable synthetic-ledger probes. This does not replace the remaining native gates.
+
+## 原生交接 / Native handoff
+
+跨主机执行者使用仓库已有 `scripts/native_acceptance.py`，先对拟运行命令加 `--preflight`。输出与 transfer receipt 使用仓库外不同的未占用路径。只有通过 CI 的确切候选与冻结制品才能进入正式原生验收；预检不证明宿主已加载该制品。
+
+Use the repository native entrypoint with `--preflight` before execution. Store annexes and transfer receipts at distinct unused paths outside the checkout. Preflight is not evidence that the host loaded the artifact.
+
+T06 仅使用执行者新建的隔离目录和自有句柄进程。分别记录 metadata/content/directory 与 dependency status；未知依赖不得进入删除集合。Windows 失败后先只读核对，不循环删除、不杀持有者或重启。原生入口使用 `--t06` 记录额外场景，Windows CI 也执行此门槛；宿主 Web/Headless 仍需独立验收。
+
+T06 uses only disposable directories and an owned handle process. Record removal layers separately from dependency status. Unknown dependencies prohibit removal. Pass `--t06` to bind the additional OS fixture to the artifact annex. Windows CI also runs this gate; Web/Headless acceptance remains independent.
+
+本计划不安排修改用户日常运行态。安装/重启日常 Web 或 Headless 配置与发布验收保持独立。
+
+This plan does not schedule changes to daily user profiles. Applying or restarting those profiles remains separate from release acceptance.

package/docs/REVIEW_0_6_2_CORE_ALIGNMENT.md

@@ -0,0 +1,87 @@
+# 0.6.2 真实会话：核心对齐与验收失效复核
+
+状态：已复现缺陷，未实施修复；不是下一版本已批准的开发或发布计划。
+基线：`63326f22d40407099baa70c8947c37029749588e`，package 0.6.2。
+比较对象：实际安装的 Codex Context Guard 0.13.9。
+
+## 结论
+
+这次是 macOS 会话，不能沿用 Windows 平台解释。存在三个相互作用的核心缺陷，其中混合请求的执行义务可被最终答复错误关闭，比用户看到的拒绝更严重。原会话有 119 次工具调用，其中 23 次为 Guard 调用；这个比例仅是数量，不证明全部属于浪费，也不代表有自动 Stop 自旋。
+
+此次复核以根用户文本、工具调用/结果、宿主 turn 事件和源码为证据，不采用会话模型的自我诊断为结论，不重放任何安装/提交/推送效果。原始会话及私有回放留在仓库外。
+
+## F062-01：问句标记吞并混合请求（P1）
+
+位置：`src/domain/semantics.ts` 的 QUESTION_SCOPE / classifyPositive，及 derive / delivery 接线。
+
+合成反例：
+
+> 更新插件，检查是否存在更新，安装新主题，记录变更。
+
+当前实现将整个片段赋予 informational。在完整的合成 turn 中不提供任何工具调用，只输出“已收到。”并结束 turn，条目仍转为 answered。原会话第一条混合要求同样在第一轮结束后变成 answered。这个结果不表示生成了完成证书，但确实使执行要求从 pending 中消失。
+
+英文变体 `Install the package, check whether an update exists, and write a report.` 中安装子段也被当成信息部分关闭。换成句号/分号可保留执行项，说明行为依赖断句。并非所有含问句的输入都失败：显式“然后安装”能够保留安装项，必须作为对照保留。
+
+机制：对尚未可靠分解的片段执行 QUESTION_SCOPE 的存在性匹配，遇到“是否”等标记立即返回 informational。源码注释将“含有疑问标记”误当成“整段是纯信息请求”。保留 source span 不能证明该 span 的解释正确。
+
+同样四条合成输入在 Codex 0.13.9 的 `_reply_only_request_shape` 中均返回 false，因此不会通过这条纯回答交付判据关闭。此比较证明具体判据差异，不是宣称 Codex 任意表达都正确或完成了原生对等验收。
+
+## F062-02：环境 cwd 被当成已确定的用户目标（P1）
+
+位置：`src/domain/capture.ts` 的 Git requested target 捕获；derive 将 scope cwd 传作 subject。
+
+合成 scope `/workspace/repo-a` 下输入“提交并推送。”，得到 repository=repo-a 且 targetCaptureStatus=resolved。真实会话的变更在另一个配置仓库，后续用户简短指代提交推送，Guard 仍锁定启动目录。
+
+必须区分用户指定目标、当前工作单元的可追溯目标、环境默认值和执行前解析结果。不能把任意模型提供的 selector 当授权，也不能无条件把 cwd 提升为根用户选择。唯一且有可信来源的上下文目标可复用；多义时保留目标未决，才请求必要澄清。
+
+后续 runtime 的 mutation_requested_target_mismatch 是正确保护。不能以放宽目标比较修复过早捕获，更不能要求模型到错误仓库做一次空提交来配合账本。
+
+## F062-03：准备配方与当前条目不相容（P2）
+
+位置：`src/tools/prepare.ts` 的 semantic_action override 与 runtime.authorizeMutationFromProjection。
+
+实际源工具探针：commit 条目传入 push 与另一仓库的 requested_target，prepare 仍返回 status=prepared 和 push 配方。runtime 后续会拒绝动作/目标不一致。真实会话也反复出现 prepare 给配方、action 才拒绝。
+
+prepare 是只读，不授予授权；因此不能称其已经放行错误动作。但它混合了“当前条目诊断”与“调用者假设动作的手册”，未明确区分 recipe_only 与 current-item readiness，容易把模型带入不可达路径。需要共用兼容判据，在副作用之前一次返回精确不匹配和可达下一步；不把任意准备参数写回用户要求。
+
+## 正确拒绝不能一起放宽
+
+- 使用普通 shell 的效果 call ID 代替 Guard 自有 producer 回执，被 persisted_effect_mismatch 拒绝，不证明 Git 适配器坏了。
+- 缺前置引用时 producer_reference_missing 正确；历史操作不得为了补证重复执行。
+- 没有真实等待/无进展资格的 boundary 被拒绝，不意味着不能普通结束。
+- 不透明复合 shell 不认证，不能据此直接判定所有 shell 工具不可用。
+- source、host、action capability 和 certification 表达不同维度，并非它们取值不同就一定矛盾；必须证明接口误导或状态错误。
+
+原会话模型把首项 answered 列为正常，复核否定这一点：纯问答交付可以关闭，但混合执行要求被误标为问答不是正常行为。不能再用“没有签发证书”概括全链路 fail-closed。
+
+## 为什么既有验证没有发现
+
+本次重跑：v061-conservative-interpretation、v051-target-identity、v062-codex-oracle 三组共 51 项全部通过；上述缺陷仍能稳定复现。通过数量不能证明测试 oracle 正确。
+
+1. 混合请求回归主要使用问号、特定连接词或明确句界；未覆盖逗号连续指令内嵌“是否”的语义等价族。v061 保守修复集中限制解释动词，留下问句存在性匹配作为快捷关闭入口。
+2. v051-target-identity 明确把 cwd fallback 固化为预期。已有测试验证显式路径优先，却未覆盖跨仓库工作后续指代；错误默认因此受到测试保护。
+3. prepare 回归验证 JSON 合法性和各配方字段，缺少“同一个 item/action/target/revision 在 prepare 与 execute 必须得到相容结论”的纵向一致性检查。
+4. 0.6.2 的跨端 oracle 确实执行了真实 Codex 入口，不应称伪造；但覆盖六个 contract 输入、四个 lifecycle 情景，偏重未知清理/缺证/等待/混合工具结果。没有覆盖此次混合语义、跨仓库指代和准备执行一致性。
+5. 原生安装、制品一致性、host-lock 和有限成功场景证明的是对应边界，不能补足上述语义覆盖缺失。
+
+协调与评审责任：前几轮分析识别了“混合请求”和“环境目标”的原则风险，却继续以局部反例和有限跨端验证作为充分交接，未形成覆盖整个缺陷家族的退出条件。0.6.2 计划聚焦诊断，没有修复仍存在的上游解释/目标错误。仅在文档注明“不是完全对齐”不足以防止真实使用再次失败。
+
+## 对齐声明的实际边界
+
+README 明确限定到共享证据规则，Semantic Compatibility 也不声称全产品对等；UPSTREAM_PIN 仍绑定旧的 v1/摘要输入。差异台账对 trusted-answer-delivery 标记 aligned，只能支持已有边界内的宿主交付机制，当前不能支撑“混合任务端到端保持相同义务”的结论。
+
+必须把“共享摘要字节相等”“单个机制类似”“端到端行为对等”分开。当前判断是**核心流程尚未对齐**。与上一事故不同，本次存在 Codex 与 DSH 对同一混合请求的明确判定差异，不能仅以 Codex 静默未认证解释用户感受到的区别。
+
+## 下一轮接受实现前必须满足的证据
+
+这不是新增一个版本号就能消除的风险。下一轮应先固定以下整体合同再实现：
+
+- 根来源→完整语义覆盖→目标来源→准备兼容性→执行→回读→当前闭包，所有阶段使用同一条目的身份和语义；不能分别推断后只在终点拒绝。
+- information 必须是完整信息范围。改变逗号/句号/连接词、中英同义或子句顺序，独立执行要求仍保留；未知尾部不能被吞并。
+- cwd 只提供环境上下文；显式当前仓库、另仓库工作后续指代、多个候选仓库、工具输出伪称目标、模型自行改目标均有正反例。
+- prepare 必须给出当前条目的真实兼容性，并与执行 gate 做同输入差分；拒绝时不可发出不加说明的可执行配方。标准普通工具与显式受控认证入口的责任要清晰，不能通过安装插件就要求所有业务改走认证链。
+- 用零工具最终回复、不相关成功工具、错误目标工具、部分执行完成四类反例验证闭包，不只测试合法链成功；未认证和错误 answered 都要统计。
+- 冻结未用于实现调参的同义留出集，经两端真实入口比较完整投影及用户可见结果。不能靠更多同型正例宣布对齐。
+- 保留正确的 producer/target/boundary 拒绝；修源头解释和准备路径，不能让执行校验迁就错误账本。
+
+当前只有复现与分析证据，未修改运行时、未重做用户安装或提交、未认证新的修复。后续具体实现范围、状态迁移和版本应基于这些合同确定，不先以新补丁版本替代根因修复。

package/docs/SEMANTIC_COMPATIBILITY.md

@@ -39,6 +39,33 @@ Authority rules:
   DSH v0.1.0 port. It is a historical fact, not the current alignment claim;
   current status lives in this document and the delta ledger.
 
+## 0.6.3 core-alignment delta
+
+The 0.6.2 core-alignment review reproduced three domain defects — a question
+marker swallowing a mixed request, the session directory promoted to a resolved
+request target, and preparation returning a recipe the execution gate refuses —
+and a fourth consequence: records an earlier version closed as answered were
+inherited as current passes. 0.6.3 repairs the source readings rather than the
+endpoint checks:
+
+| Capability | 0.6.3 disposition | Evidence |
+| --- | --- | --- |
+| information scope is complete and execution-free | implemented (DSH side) | `tests/domain/v063-core-alignment.test.ts`, `tests/domain/v063-holdout.test.ts` |
+| requested target has an auditable source | implemented (DSH side) | `tests/domain/v063-core-alignment.test.ts` (K2), `tests/domain/v051-target-identity.test.ts` |
+| prepare and execution share one compatibility judgement | implemented (DSH side) | `src/domain/compatibility.ts`, `tests/domain/v063-core-alignment.test.ts` (K3) |
+| earlier answered records are re-checked before terminal filtering | implemented (DSH side) | `tests/domain/v063-core-alignment.test.ts` (K4), `tests/domain/v063-holdout.test.ts` |
+| mixed-request obligation projection equals Codex | **not measured** | `tests/fixtures/cross-end/core_alignment_0_6_3.json` records it `not-applicable` |
+| cross-repository follow-up reference equals Codex | **not measured** | Codex exposes no equivalent target-source entry point |
+| prepare/execute consistency equals Codex | **not measured** | Codex has no equivalent prepare surface; recorded `not-applicable` |
+
+`docs/upstream-deltas.json` carries the same statements in the machine-readable
+ledger (refreshed 2026-09-16 for the 0.6.3 target; the Codex-side release
+comparison it names is unchanged), and
+`tests/fixtures/cross-end/core_alignment_0_6_3.json` is the case-level record. The `trusted-answer-delivery` entry was downgraded from `aligned` to
+`partial-equivalent`: the recorded Codex reply-only judgement returns false for
+the mixed inputs where DSH's delivery judgement would close the information
+range, so the two ends do not agree on that family.
+
 ## Digest v3
 
 Certificate, boundary, and evidence manifests bind to versioned canonical
@@ -152,7 +179,7 @@ Work-unit scope and correction attribution are also shared semantic gaps and sho
 
 ## 0.4.2 and 0.4.3 product boundaries
 
-The 0.4.2 release retained these exact mirrored fixtures and the recorded upstream pin. Its DSH-native rebinding, bounded checkpoint output, and recovery changes do not establish parity with later Codex releases. `upstream-deltas.json` is the dated 2026-09-03 comparison snapshot: its `currentRelease` fields name the releases compared then, not a live latest-version lookup. Refreshing that comparison requires a separate upstream audit; it does not happen merely because either product releases a newer version.
+The 0.4.2 release retained these exact mirrored fixtures and the recorded upstream pin. Its DSH-native rebinding, bounded checkpoint output, and recovery changes do not establish parity with later Codex releases. `upstream-deltas.json` is a dated comparison snapshot (refreshed 2026-09-16 for the 0.6.3 target; originally the 2026-09-03 audit): its `currentRelease` fields name the releases compared then, not a live latest-version lookup. Refreshing that comparison requires a separate upstream audit; it does not happen merely because either product releases a newer version.
 
 The 0.4.3 core policy changes DSH-specific manifest values, not the shared digest-v3 encoding or byte-mirrored fixtures. Core manifest version 2 and `dsh-core/v1` produce a fresh identity after actual-graph inspection. Legacy cohorts remain historical inputs. Market service adapter `context-guard.service.v2` uses version `2.0.0`; old restart credentials cannot become new-instance credentials. Package apply remains a disk-state operation, and unavailable restart work remains pending.
 
@@ -243,6 +270,21 @@ as done:
   digest-v3 vectors remain the only byte-level cross-language agreement
   evidence, and they are unchanged.
 
+0.6.2 adds one more explicitly incomplete shared artifact, and describes it the
+same way:
+
+- **D062-04 uses measured, bounded cross-end cases.** Contract and proof
+  recordings are supplemented by `codex-0.13.9.lifecycle.json`: the recorder
+  creates disposable synthetic prompt ledgers through Codex's own entrypoints,
+  then exercises silent pending, missing-proof correction, user wait and the
+  same opaque mixed-result command used by DSH. These are function-level
+  lifecycle checks, not native application acceptance or full product parity.
+  See [the result contract](CROSS_END_RESULT_CONTRACT.md). No upstream mirror,
+  digest domain or pin changes.
+- **Deferred capability:** an explicit distinction between action-event and
+  state-outcome obligations needs a separate public contract; it is not added
+  by 0.6.2. The existing v2 mirror and release-producer gaps above remain open.
+
 The consequence is stated plainly: this repository does not claim "C01–C12
 core alignment" with Codex Context Guard. It claims that its own C01–C12
 implementation is present and covered by production-chain tests, and that the
@@ -292,3 +334,24 @@ classes, release state, and migration facts.
 - The delta ledger separates source facts, plan status, implementation
   status, deterministic tests, native platform acceptance, and release
   readback; keep all six aligned when a capability moves.
+
+## 0.6.3 narrowed execution qualification (DSH-side)
+
+The DSH side now decides EXECUTION QUALIFICATION once per clause, before any
+partition: a clause whose own reading is a question, an explanation, an
+investigation, a reported question or a quoted scope is `restricted`, and one that
+asks nothing is `granted`. The qualification is stored on the item
+(`executionQualification`), inherited by every partition child, and consumed by
+both the mutation gate and `context_guard_prepare`; a record captured before the
+qualification exists is refused rather than read from its stored disposition and
+is flagged `legacy_missing_execution_qualification` by the upgrade check. The
+same-clause "prove the complement closed" rules of the earlier 0.6.3 revisions are
+removed, so there is exactly one authorization path.
+
+What this means for cross-end work: a question and a coordinated action in ONE
+clause is an UNDECIDED obligation on the DSH side, where earlier revisions recorded
+the action as an order. The machine-readable ledger
+`tests/fixtures/cross-end/core_alignment_0_6_3.json` records that reading at
+revision 4; the Codex side is unchanged, both ends still refuse to let an answer
+close the install, and no feature, runtime or release equivalence may be inferred
+from the shared fixture. See [CONTRACT_REVISION_0_6_3.md](CONTRACT_REVISION_0_6_3.md).

package/docs/upstream-deltas.json

@@ -1,7 +1,7 @@
 {
   "ledgerVersion": "2",
   "description": "Current, evidence-bounded delta ledger for behavior shared between codex-context-guard and dsh-completion-guard. It separates aligned behavior, partial host-native equivalents, missing shared behavior, and Codex-only lifecycle features.",
-  "updatedAt": "2026-09-14",
+  "updatedAt": "2026-09-16",
   "source": {
     "product": "codex-context-guard",
     "currentRelease": "v0.13.9",
@@ -17,12 +17,12 @@
   },
   "target": {
     "product": "dsh-completion-guard",
-    "currentRelease": "v0.6.0",
-    "currentReleaseHead": "not recorded here: the 0.6.0 source candidate is not yet frozen into an artifact, so no commit SHA is asserted in this ledger",
+    "currentRelease": "v0.6.3",
+    "currentReleaseHead": "not recorded here: the 0.6.3 source candidate is not yet frozen into an artifact, so no commit SHA is asserted in this ledger",
     "implementationBaseline": "ffc6fe9e1246a815f0bb630943c59d14b6505716",
-    "host": "DSH 0.1.5-rc.2 || 0.1.5-rc.1 / Cordis 4.0.2 (registry-derived cohort; native audit pending for 0.6.0)"
+    "host": "DSH 0.1.5-rc.2 || 0.1.5-rc.1 / Cordis 4.0.2 (registry-derived cohort; native audit pending for 0.6.3)"
   },
-  "alignmentClaim": "DSH 0.6.0 implements the C01-C12 shared contract of the paired 0.6.0/0.14.0 plans and covers it with production-chain tests. It does NOT claim core alignment with Codex Context Guard: the v2 conformance fixture exists only as a DSH-authored candidate because the upstream has not landed a frozen v2 specification, so the canonical mirror and the cross-language parity comparison remain open. The v1 fixtures, the digest-v3 vectors, and the frozen digest domains are unchanged.",
+  "alignmentClaim": "DSH 0.6.3 implements the C01-C12 shared contract of the paired 0.6.0/0.14.0 plans plus the K1-K4 core-alignment repairs, and covers it with production-chain tests. It does NOT claim core alignment with Codex Context Guard: the 0.6.2 review reproduced three domain defects and one inheritance defect that the recorded Codex behaviour does not share, the v2 conformance fixture still exists only as a DSH-authored candidate because the upstream has not landed a frozen v2 specification, and the mixed-request, cross-repository and prepare/execute families have no measured Codex counterpart. tests/fixtures/cross-end/core_alignment_0_6_3.json records each family's disposition case by case. The v1 fixtures, the digest-v3 vectors, and the frozen digest domains are unchanged.",
   "dispositions": [
     "aligned",
     "partial-equivalent",
@@ -149,14 +149,16 @@
     {
       "capability": "trusted-answer-delivery",
       "introducedBy": "shared C03 (0.6.0 / 0.14.0 plan)",
-      "disposition": "aligned",
-      "targetRelease": "dsh-completion-guard v0.6.0",
-      "plainLanguage": "A question or explanation is closed only by the host's own record of a normally completed turn whose final assistant message was not interrupted; delivery never implies correctness or execution.",
-      "implementation": "domain/delivery.ts derives the fact from assistant/message + turn/end; deriveProjection applies it to information-slot items of that turn's owning unit and its delegated sub-units.",
+      "disposition": "partial-equivalent",
+      "targetRelease": "dsh-completion-guard v0.6.3",
+      "plainLanguage": "A question or explanation is closed only by the host's own record of a normally completed turn whose final assistant message was not interrupted; delivery never implies correctness or execution. DSH bounds the closable range to a COMPLETE information range, which the recorded Codex reply-only judgement does not match on mixed inputs.",
+      "implementation": "domain/delivery.ts derives the fact from assistant/message + turn/end; deriveProjection applies it to information-slot items of that turn's owning unit and its delegated sub-units, after K1 has separated the execution obligations of the same clause.",
       "tests": [
         "tests/domain/v060-units-delivery.test.ts",
-        "tests/domain/v060-portable-v2.test.ts"
-      ]
+        "tests/domain/v060-portable-v2.test.ts",
+        "tests/domain/v063-core-alignment.test.ts"
+      ],
+      "note": "Downgraded from aligned in 0.6.3: the recorded Codex _reply_only_request_shape judgement returns false for the mixed comma-run inputs where 0.6.2 DSH would close the whole clause as answered. Alignment on this family is not established."
     },
     {
       "capability": "work-unit-required-descendant-closure",
@@ -220,6 +222,60 @@
         "tests/domain/v060-v2-runner-independence.test.ts"
       ],
       "dshOnlyReason": "Only the upstream repository can land the canonical v2 specification, schema and reference projection. Until it does, mirroring and parity cannot be established honestly."
+    },
+    {
+      "capability": "information-scope-preservation",
+      "introducedBy": "dsh-completion-guard v0.6.3 (K1; review F062-01)",
+      "disposition": "aligned",
+      "targetRelease": "dsh-completion-guard v0.6.3",
+      "plainLanguage": "A question inside an instruction is a question; the work beside it stays work. An answer closes the information range it answers and nothing else. This is a DSH-side implementation of the shared contract; the Codex counterpart for this family is not measured.",
+      "implementation": "domain/semantics.ts classifies a clause as information only when an interrogative opens or ends it, and partitions a mixed clause into an information range plus its directive clauses.",
+      "tests": [
+        "tests/domain/v063-core-alignment.test.ts",
+        "tests/domain/v063-holdout.test.ts"
+      ],
+      "note": "The 0.6.2 rule is retained as legacyQuestionReadingIsInformational so the fixed defect keeps a failing-before regression."
+    },
+    {
+      "capability": "requested-target-provenance",
+      "introducedBy": "dsh-completion-guard v0.6.3 (K2; review F062-02)",
+      "disposition": "aligned",
+      "targetRelease": "dsh-completion-guard v0.6.3",
+      "plainLanguage": "Work happens where you said it happens. The directory a session started in is context, not your choice. This is a DSH-side implementation of the shared contract; the Codex counterpart for this family is not measured.",
+      "implementation": "domain/capture.ts records TargetSource (explicit name/path, explicit current repository, host selection, unit inheritance, environment default); derive.ts resolves inheritance across the same work unit; runtime.ts refuses an environment-default target explicitly.",
+      "tests": [
+        "tests/domain/v063-core-alignment.test.ts",
+        "tests/domain/v063-holdout.test.ts",
+        "tests/domain/v051-target-identity.test.ts"
+      ],
+      "note": "Codex exposes no equivalent target-source entry point, so this family is recorded not-applicable rather than aligned."
+    },
+    {
+      "capability": "prepare-execute-shared-compatibility",
+      "introducedBy": "dsh-completion-guard v0.6.3 (K3; review F062-03)",
+      "disposition": "aligned",
+      "targetRelease": "dsh-completion-guard v0.6.3",
+      "plainLanguage": "Preparation tells you what the Guard will actually accept for the item you asked about, and it will not hand you a recipe the execution gate would refuse. This is a DSH-side implementation of the shared contract; the Codex counterpart for this family is not measured.",
+      "implementation": "domain/compatibility.ts is the single pure judgement used by tools/prepare.ts and runtime.authorizeMutationFromProjection; it separates semantic compatibility, target compatibility, execution readiness and adapter capability.",
+      "tests": [
+        "tests/domain/v063-core-alignment.test.ts",
+        "tests/domain/v063-holdout.test.ts",
+        "tests/tools/v063-host-materialization.test.ts"
+      ],
+      "note": "Codex has no equivalent prepare surface; recorded not-applicable in the cross-end ledger."
+    },
+    {
+      "capability": "legacy-record-eligibility",
+      "introducedBy": "dsh-completion-guard v0.6.3 (K4)",
+      "disposition": "aligned",
+      "targetRelease": "dsh-completion-guard v0.6.3",
+      "plainLanguage": "An obligation recorded by an earlier version is never inherited as a pass. If its own text still orders work, it blocks a new certificate until you resolve it, and its history is preserved. This is a DSH-side implementation of the shared contract; the Codex counterpart for this family is not measured.",
+      "implementation": "derive.ts runs the eligibility pass before any terminal filtering; closure.ts exposes the blocking set; checkpoint.ts and goal-gate.ts refuse certification and Goal completion; delivery.ts does not close a flagged record.",
+      "tests": [
+        "tests/domain/v063-core-alignment.test.ts",
+        "tests/domain/v063-holdout.test.ts"
+      ],
+      "note": "Codex has no equivalent eligibility layer for previously-closed information records."
     }
   ]
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-completion-guard",
-  "version": "0.6.1",
+  "version": "0.6.3",
   "description": "A task-contract and completion-certification layer for DeepSeek Harness.",
   "repository": {
     "type": "git",
@@ -113,5 +113,5 @@
     "hooks",
     "typescript"
   ],
-  "gitHead": "d11009d8f755ecee7d288cff18250c7b372cfd2a"
+  "gitHead": "4c26bee90a7b9e8b26ebbe91f335e356e7589fc3"
 }

package/docs/NEXT_VERSION_REPAIR_NOTES.md

@@ -1,97 +0,0 @@
-# 下个版本：准备工具、Git 取证与问答残留
-
-状态：局部修复已随 0.5.3 发布（2026-09-14）；本页记录的 0.6.0 语义设计已实现（2026-09-14），0.6.1 修复已实现（2026-09-15），实现状态与验收边界见下节与[语义兼容说明](SEMANTIC_COMPATIBILITY.md)。本页以 0.5.2 为事故修复基线；精确制品与平台结果见[验收记录](LOCAL_ACCEPTANCE.md)。
-
-## 0.6.1 修复（2026-09-15）
-
-对一次真实 Windows 0.6.0 会话的只读回放复核确认了五项缺陷（来源与根因见仓库内 `docs/WINDOWS_0_6_0_REPAIR_PLAN.md`；该计划是本批修复的规划依据，原始材料保留在仓库外）。五项均已从统一解释、能力合同与状态转换层修复，不依赖事故句子白名单，不通过删除未知项或放宽证据校验使测试通过：
-
-- **W060-01 附件解释死路**：非文本根输入按逐资产身份保留为信息义务，其关闭需要**逐资产解释记录**（新入口 `context_guard_interpret`）**加**记录所在 turn 的可信交付，两者缺一不可。记录绑定**调用与结果一致的 turn 对**（调用 turn 随 `tool/call` 记录，重放要求回执 turn 与之相等）；重放在事件自身水位把回执对照合同重新校验（调用 item ID、条目 revision、资产身份）：身份矛盾或 turn 对不一致（中断 turn 的调用、回执被移植进后来回答）记 `interpretation_receipt_mismatch` 完整性违规；身份有效但 turn 关联缺失则仅不产生记录、日志保持 valid。解释 turn 的交付也是旧附件的关闭通路（其根消息已不可能属于活 turn）；仅存在一条 final 不关闭任何未经解释记录的图片义务。在入口存在之前写入的日志重放时附件保持 `pending`（与 0.6.0 相同），只能由当前解释事件关闭。回答交付、视觉证明与执行认证保持分离。
-- **W060-02 默认执行语义**：遵循复核最终解释合同——**语法上的陈述句也可以表达任务要求**，任何表面句式都不能证明子句是可关闭的信息。无可解析动作且无**正面信息依据**的子句默认 `unresolved`（保留、可见、永不执行、不被交付关闭；经逐字具体澄清、确认重绑定或 clear 解决，澄清通路已接受 unresolved）。正面信息依据 = 可识别的信息请求形态：疑问句、引用动作、产出物请求、过去/完成体报告，且依据必须**独占整个子句**——信息跨度之后衔接新要求（"Figure out the issue and sanitize all inputs"、"Figure out the issue & sanitize all inputs"、"Explain the issue, sanitize all inputs"）、报告处于定语（"清理已经生成了的缓存"，无长度阈值）或从句（"Sanitize inputs that were supplied by users"）时整句不可判定、保持 unresolved 并保留其中的执行子项。解释/调查开头同样不自动进入可关闭通道。**结构化解释通路已实现，为跨度划分合同**：`context_guard_interpret` 泛化后同时服务资产义务与 unresolved 子句义务——调用方提交 information_spans/unknown_spans 划分，守护程序对照完整输入跨度校验覆盖与关联；**重放把回执绑定到持久化的调用参数并要求二者划分完全一致**，重画划分（把已提交的 unknown 跨度改成 information 声明）即 `interpretation_receipt_mismatch` 完整性违规，不产生记录、不取代任何条目；仅 information 子项由解释 turn 的交付关闭，unknown 与未申报子跨度保持 pending。整项确认回执不产生关闭资格。整句应答（"当然。"）属会话层不捕获。裸英文 wh-词只在子句开头算疑问标记，从句关系词不把真实指令降级。普通祈使句读法不变；仅提及动作的陈述不再释放等待保留。
-- **W060-03 发现结果截断**：prepare 的 discovery 改为固定页大小、稳定排序、绑定合同 revision 的 cursor 分页，revision 变化显式失效；`semantic_action` 为唯一声明筛选并随 cursor 携带；v5 会话下列表范围为当前单元闭包加必需后代加 pre-v5 义务。
-- **W060-04 只读证据角色不一致**：prepare、诊断与认证器共用同一义务合同——stateful 需要 resolution/effect/state，只读验证需要单条 effect 角色事实；historical-gap 判定仅限 stateful。
-- **W060-05 普通 Git 观察事实**：对动作与命令头锚定信号一致、且无可归属生产者证据的义务，诊断为 `execution_unattributable`——该命令是否执行了此动作**无法确立**：只读核实现状、保持未认证、不重做、不断言未发生。Guard 不扫描复合命令文本（引号数据与短路控制流会虚构观察，整体成功不证明分段执行）。受保护 git 链现在拒绝重放已成立的动作：push（远端已在本地 head）、pull（HEAD 已在 upstream）、fetch（tracking 已更新）在执行任何命令前以 `effect_already_applied` 拒绝，动作工具报告 `action_already_applied`——链外执行不能经空转重跑洗白为生产者证据。首次提示的条件化措辞取代对所有 stateful 动作的无条件 Guard 前置要求。
-
-本节初稿曾宣称上一版实现"附件按 turn 交付关闭"与"按段动作观察"；复核以反例否决后已按上述设计重做，反例保留为 `tests/domain/v061-*.test.ts` 常驻回归。
-
-有意排除的范围：action-event 与 state-outcome 义务的显式区分（需要新的公开义务类型与捕获合同，超出补丁版本兼容边界，列为后续独立能力）；`git_tag` 与 GitHub Release producer 路由缺口维持既有 backlog 状态。
-
-0.6.1 的确定性证据边界见[验收记录](LOCAL_ACCEPTANCE.md)的对应小节：它覆盖本地确定性矩阵，不包含也未宣称原生平台验收、精确制品冻结或发布读回。
-
-## 0.6.0 实现结论（2026-09-14）
-
-本页"待设计：问答交付与执行认证分离"一节列出的六项要求已全部落地，并且都在生产链路（derive / 交付 / 闭包 / Goal / 工具注册）上运行，而不是只测解析器：
-
-- 原文跨度按 UTF-8 字节半开区间绑定信息、执行、约束和未知部分；无法分类的部分进入 coverage 记录并保持可见，不由模型摘要替代原文。
-- 回答交付记录绑定当前根输入、宿主 turn 与最终回答；判据是宿主的 `assistant/message`（该 turn 最大 step、无 interrupted）+ 后继 `turn/end completed`，交付不代表内容正确或执行完成。
-- 混合请求按子项关闭：回答部分交付即关闭，修改/测试/发布仍需独立证据；子项交付不关闭父项全部工作（C04 必需后代闭包）。
-- 未知表达保持可解释的未决状态；未通过增加关键词或删除 pending 条目来掩盖问题。
-- 延迟回复、子代理回复、压缩摘要、引用历史和中止 turn 都不会绑定为当前回答；子代理结果标记为有界证据，且明确不是可用的证明来源。
-- 旧证书、旧投影与升级边界已明确：v5 边界之前的条目保留出生规则，v1 证明 manifest 与全部 v3 摘要域只读不变；新共享行为先以 DSH 侧 host-neutral 候选形式落地。
-
-### 跟进复核后的第二轮修复（2026-09-14）
-
-修复提交的跟进复核在新接线中发现 5 个残留缺陷，均属原家族，已全部修复并保留反例为回归：pre-v5 交付追溯关闭（F01）、真实生产者缺 registry 且 ref 路径不可达（F04）、闭包 revision 使发布依赖发布（F04）、只读 `release status` 永久毒化发布状态（F05/F06）、proof 签发时校验但重放时忽略（F08）。同时补齐了此前缺失的**可信恢复入口** `context_guard_release`（`status` 只读、`reconcile` 按审计 registry 回读结算，绝不重发；覆盖重启后与 revoked-but-in-flight 恢复，并为 SHA256-only 合同保留预约期记录的 SRI 以便核对与检测不一致）。
-
-### 集中复核后的修复（2026-09-14）
-
-对 0dce898 候选的集中复核给出 15 个反例，全部复现真实缺陷；F01–F08 已修复并各有生产链路正负例，反例套件保留为常驻回归（`tests/domain/review-counterexamples.test.ts`）。其中一项复核期望（R1）被有意修改：原探针要求"64 位 hex 契约 + SRI 请求"必须放行，这本身就是被判定为缺陷的身份混用；修复后同义要求由"真实制品绑定的合法发布必须可放行"与"错字节/错 gitHead/错 SRI/错目标/错回读必须拒绝"两组用例覆盖，理由写在测试原位。
-
-仍未完成、且本页不宣称完成的部分：
-
-- 上游尚未落地冻结的 v2 fixture，因此本仓库的 v2 文件是候选身份，跨语言 parity 与正式镜像待上游落地后按精确 commit 重镜像并刷新 `UPSTREAM_PIN.json`。**协调者已于 2026-09-14 裁定阶段性退出**：该项归上游所有，列为跨仓库待办，不作为 DSH 侧退出条件。
-- 发布档可保护表面仅 `npm_publish`。`git_tag` 与 GitHub Release 路由记为 `release_operation_unrouted` / `attribution: scope_reduction`（缺少 Guard 自有路由，属可实现缺口，并经协调者批准缩小本轮公开范围）；只有复合 runner 记为不透明宿主边界。补建这两条路由是后续版本的工作项。
-- 0.6.0 的发布事实已按阶段核对（2026-09-15）：annotated tag `v0.6.0` 指向 `cc5cbc6d408664172d9383de7c83c55ec6dfd602`，GitHub Release `v0.6.0` 绑定同一提交，npm 注册表存在 `dsh-completion-guard@0.6.0`（registry `dist.integrity` 已读回记录）。该版本的原生 macOS/Windows 验收与精确制品验收按[验收记录](LOCAL_ACCEPTANCE.md)的版本小节为准；发布回执冻结的制品字节比对属于发布档案，不在仓库内重写。
-
-## 已实施的局部修复
-
-### 准备工具返回合法 JSON
-
-宿主能力检查成功时可以不携带 reasonCode，但 prepare 将其写成 host_capability.reason_code: undefined。DSH 在渲染前检查返回值是否为无损 JSON，因此拒绝整个调用。不存在的条目和错误 revision 提前返回，不经过此字段。
-
-现在只有定义了 reasonCode 才输出 reason_code。注册期回归使用真实成功结果的形状，不再人为补一个成功原因来掩盖问题；覆盖 generic_run、commit、install、verify、push 和错误分支。该缺陷属于插件输出契约，跨操作系统，不应归因于 Windows 宿主拒绝合法数据。
-
-### Git 取证给出可执行的准备信息
-
-prepare 新增 evidence_input_contract：列出 selector、command_manifest、planned_arguments 的字段和完整调用顺序。Git 的 missing_target_fields 只列调用方需要提供的 selector 字段；前置 HEAD、暂存区摘要和源提交等由生产者读取，不要求用户伪造。
-
-resolution 缺少输入时，evidence 在探测可执行程序前返回 resolution_input_missing、missing_fields 和 next_step。effect/state 缺少前置调用引用时保留 producer_reference_missing，并明确缺少 resolution_call_id 或 effect_call_id。这些新增字段只解释失败，不改变证据事实、摘要或认证权限。
-
-正确顺序：
-
-1. 暂存需要提交的改动后，先请求 resolution。commit 的 selector 是 repository、branch；push/fetch/pull 是 repository、remote、refspec。
-2. Git command_manifest 只包含 planned_tool 和 planned_arguments；planned_tool 为 bash 或 pwsh，planned_arguments 只包含 command 和 workdir。命令必须匹配 prepare 给出的受支持形态；workdir 与 repository 一致。manifest_id 不是该输入的替代品。
-3. 用成功 resolution 的调用 ID、target_digest 和当前条目 ID/revision 调用 context_guard_action 执行一次。
-4. 分别请求 effect 和 state，均引用同一 resolution_call_id 和成功 action 的 effect_call_id。
-5. checkpoint 引用三种角色对应的 evidence ID。工具 call ID 与证据 evidence ID 不可混用。
-
-已有动作如果绕过这条链执行，普通回读仍能报告实际结果，但无法补造执行前证据。不要重复提交或推送来填补历史证据缺口。
-
-## 事故结论的修正
-
-两次 Windows 对话确实观察到 prepare 输出错误和 Git 取证失败。独立核对后，不能把缺参调用的失败推广为“Git 适配器完全不可达”：resolution 调用未提供计划工具清单，effect/state 调用未提供前置调用引用。adapter_id 标识尝试的适配路径，不代表本次产生了可用事实；selector 不接受 commit 字段也不表示缺少提交支持。
-
-现有真实临时仓库测试覆盖 commit/push/fetch/pull 的受控执行和独立回读。它们不能替代 Windows 日常宿主验收。Windows 中 Git 子进程创建 signal pipe 失败另属执行环境问题，不能由本次输出契约修复宣称解决。没有真实等待或延后资格时，boundary 拒绝仍是正常保护，不应为结束一次对话伪造资格。
-
-## 待设计：问答交付与执行认证分离
-
-本轮没有改变需求捕获、pending 状态、证书或恢复关闭规则。当前调查/问答可能已交付给用户，却仍以未认证条目保留；复杂表达又可能被识别为 generic_run。不能将这个已知缺口写成已修复。
-
-后续设计沿用上游 [Semantic Compatibility](https://github.com/GreenLv/codex-context-guard/blob/main/docs/SEMANTIC_COMPATIBILITY.md) 的边界：共享语义由上游拥有，DSH 保留独立宿主、持久化和运行时。当前镜像不意味着自动采用 Codex 0.13.x 的全部行为。既有分析还包括 effectiveness 仓库的 docs/SEMANTIC_BOUNDARIES.md，指出有限句型只能保证已覆盖语法，不能证明一般语义完备。
-
-下一批工作须定义：
-
-- 原文跨度对应信息交付、执行、约束和未知部分；未覆盖跨度保持可见，不由模型摘要替代原文。
-- 回答交付记录绑定当前根用户输入、宿主 turn 和最终回答；交付不等于内容正确或执行认证。
-- 混合请求的回答部分可以记录交付，修改、测试、发布等仍需独立证据；子项交付不能关闭父项全部工作。
-- 未知表达保持可解释的未决状态，禁止靠增加关键词或删除 pending 条目掩盖问题。观察模式先评估误关闭与误保留，再决定版本化切换。
-- 延迟回复、子代理回复、压缩摘要、引用历史和中止 turn 不能误绑定为当前回答；恢复保持已验证的交付与未完成执行。
-- 旧证书、旧投影和升级边界必须明确；新增共享行为先在上游形成中立合成用例，再按精确 pin 适配，不能静默改写冻结镜像。
-
-验收需分别覆盖纯问答、附流程图说明、长复合提问、解释后执行、未知尾句、条件/否定、双语、跨 turn、compact/resume 和旧状态。记录误保留、误关闭及额外轮次，不能仅用总测试通过率评价语义覆盖。
-
-## 验证边界
-
-本轮局部修复使用宿主注册、诊断和取证测试，以及仓库映射所要求的本地检查。更新 dist 只代表生成源码产物；旧 0.5.2 制品和已加载插件不变。0.5.3 的 CI、冻结制品、双平台隔离原生验收和公开发布已独立完成，具体范围见验收记录；日常环境安装不在这些结果之内。
-
-0.6.0 的确定性证据包括仓库完整矩阵（typecheck、lint、vitest、release-pack、stats、build、pack:check、文档 audit 及其单测、`git diff --check` 与 dist 一致性）。确定性证据永远不等于原生平台验收：任何版本是否已在 macOS/Windows 的 Web 与 Headless 上完成原生运行、是否冻结为精确制品，以[验收记录](LOCAL_ACCEPTANCE.md)按版本记录的事实为准。Codex 本轮仅新增问题与设计文档，不修改其运行时；上游没有新增可用于镜像的 v2 规范或 fixture。

package/docs/WINDOWS_0_6_0_REPAIR_PLAN.md

@@ -1,92 +0,0 @@
-# Windows 真实会话复核与 0.6.1 修复计划
-
-日期：2026-09-15。状态：W060-01–05 的实现与本地确定性验证已随 0.6.1 源候选完成（2026-09-15，见 CHANGELOG 与 LOCAL_ACCEPTANCE 对应小节）；本页保留复核结果与修复合同作为规划依据。跨主机/精确制品验收与发布属于后续独立阶段，本页不宣称其结果。
-
-## 结论与版本
-
-0.6.0 需要后续修复。主要缺陷不是准备工具再次返回非法 JSON，也不是全部问答交付失效，而是解释结果、附件义务与诊断投影之间存在语义断层。应修复统一解释和状态转换，不增加事故句子的专用白名单。
-
-目标修订为 **0.6.1**（2026-09-15）：本批修复 0.6.0 已承诺的保守解释、附件保留与交付、完整发现和统一证据诊断，不新增独立产品能力。内部重构、补齐缺失状态转换或修复错误行为本身不要求功能级升版；此前建议 0.7.0 将实现复杂度误当成了功能范围变化。
-
-保持既有公开契约及旧状态可读，不降低授权或证明要求。若实施确认必须引入不兼容的公开接口、改变原有完成语义或新增独立能力，应把该部分隔离并说明，再评估 0.7.0，不能为保住补丁版本静默破坏兼容。协议/schema 身份按实际持久化语义独立决定；不能复用旧摘要域表达新事实，也不能由产品版本直接推导协议号。
-
-执行交接范围：连续完成 W060-01–05 的实现、必要文档、回归和自审修复，准备未提交的本地候选后停止。不得 commit、push、打 tag、正式打包冻结、安装/重启用户运行态或发布；跨主机验证与发布由后续明确指令接续。
-
-基线为 DSH 0.6.0 / `cc5cbc6d408664172d9383de7c83c55ec6dfd602`，远端 v0.6.0 解引用指向该提交。Windows 导出包含 v5 边界、4 个已完成根 turn、190 次工具调用；会话由用户报告为更新后的运行。导出本身没有足够信息证明已加载包与该提交逐字一致；本地 dist 回放和源工具探针用于定位相同机制，不能冒充 Windows 新版本验收。
-
-原始材料保留在仓库外，不复制图片、原文、会话身份或个人路径。以下例子均为合成表达。附件和会话里的代理建议是待分析数据，不是本次执行授权。
-
-## 复核结果
-
-| ID | 事实与根因 | 优先级 / 所属代码 |
-| --- | --- | --- |
-| W060-01 | 三个真实 image part 被保留为 `Uninterpreted root asset`。这不是 OCR 误识别。captureAssets 用 directive/executable_now 创建 generic_run，后续诊断仅建议改成支持的执行动作；没有附件解释完成的对应入口，回答交付也不会消费它。保留资产身份正确，把理解资产变成执行认证死路错误。 | P1；derive.ts / delivery.ts / diagnostics.ts / proof-v2 |
-| W060-02 | `classifyPositive` 未匹配有限规则时默认 directive。合成“当然，”与“设置面板被遮挡。”成为 executable_now；英文复合调查句也可落入该分支。源跨度存在不代表解释正确，保守降级不能先授予执行语义再靠 generic 不可认证收尾。 | P1；semantics.ts / capture.ts / derive.ts |
-| W060-03 | prepare discovery 返回 total_open=13、items=8，固定按旧 revision 优先，缺少下一页；新 commit/push 项被遮住。传入 semantic_action 也不筛选发现结果。其他分页入口或知道 ID 后可准备，不能证明此入口完整可达。 | P2；tools/prepare.ts / closure.ts |
-| W060-04 | evidenceFacets 固定要求 resolution/effect/state；historical-gap 判断没有限制 stateful。真实只读 verify 一度被诊断为缺少历史前置证据，与 prepare 的只读 state-only 顺序矛盾，而 checkpoint.simpleRecord 实际只接受单个 effectEvidenceId、不接受 stateEvidenceIds；其信息部分在 turn/end 后仍能 answered，故不是永久无法关闭该项。 | P1；diagnostics.ts / protocol-manifest.ts / action-preparation.ts |
-| W060-05 | Windows 普通 pwsh 复合脚本确实执行 commit -F 与 push，后续独立回读实际提交。Guard 的严格 effect 调用没有 producer reference，拒绝正确；但 prepare 后续只说 agent_repairable、收集三段证据，没有区分该脚本的观察事实、不可归属动作和不可补造前态。首次提示又无条件要求所有 stateful 先走 Guard。 | P1；lifecycle.ts / evidence.ts / diagnostics.ts / policy 接线 |
-
-最后一次回放仍有 13 个 pending，且 R006/R010 已 answered。因此“0.6.0 完全没有交付能力”不成立。未发现此次出现 prepare 输出非法 JSON。无根用户显式延后资格时，boundary 返回空 available_qualifications 并拒绝 deferred 属正常保护，不应伪造资格、放宽验证或作为独立 bug 登记。
-
-会话仍属于同一相关任务链，不能仅因旧条目多就宣布工作单元实现错误，也不能把整段调查工具耗时算作 Guard 自旋。根问题是错误条目持续进入该闭包。普通 shell 的权限/凭据受限与插件语义问题分开处理；本次不重试现场修改、提交或推送。
-
-## 统一修复合同
-
-### P0：解释和能力合同先于工具补丁
-
-1. 原始输入与解释记录分离。输入保存完整跨度/资产身份；解释记录明确 information、execution、constraint、unresolved，以及来源、owner、条件和关联。连接成分与背景叙述作为 coverage 中的上下文片段，不自行生成执行义务。不能靠标点切成的单片段丢失支配关系。
-2. 未证明是指令的片段不得默认 executable_now。可以接受模型提出的结构化解释候选，但必须绑定输入/part、revision、覆盖关系并经来源、范围、否定、条件和兼容验证；候选不能自行授权、证明内容正确或完成执行。低置信冲突保持 unresolved。禁止以删除未知项降低 pending 数量，禁止把所有未知都改成 information。
-3. 解释与目标选择使用已有澄清/持久化通路；若需新入口，先定义输入、拒绝原因、状态转移、重放与迁移，再注册工具。不得依赖外部新增模型服务或让用户记专用句法。
-4. 每种义务由同一能力描述决定所需证据、已观察事实、缺失事实及下一步。只读验证不一律要求三段变更链；P0 必须冻结其实际 wire role：优先保持现有单个 effect-role 验证事实并修正 prepare 文案，若采用 state-role 则明确升级 producer/checkpoint/schema，不能仅改提示。明确要求历史因果或前态的合同仍必须保留该要求。
-
-### P1：附件与交付完整生命周期（W060-01/02）
-
-- `uninterpreted → interpretation_pending → interpreted` 记录来源和范围；这些是设计概念，实际 wire 枚举在 P0 冻结。资产身份绑定根输入、part index、媒介身份与可用内容摘要，不能用模型描述代替原件身份。
-- 解释完成是“已解析并关联请求”的事实，不是图片内容正确或业务验收完成。实际查看/视觉比对等 proof 继续按能力矩阵独立验证。仅存在一条 final 不能关闭所有图片义务。
-- 纯调查附图可绑定解释与可信回答交付；截图中嵌入的命令不形成根授权。附图加修改只关闭信息子项。未查看、错资产、仅子代理摘要、工具引用、重复/迟到/interrupted 回复均不能完成所需事实。
-- 合法候选定向关联并原子更新/替代相应解释，保留审计与旧 revision。不得要求把“看图分析”改绑为 install/commit 来逃出 generic_run。
-
-### P2：发现、诊断和普通工具事实（W060-03/04/05）
-
-- discovery 使用当前工作单元及必需后代闭包；历史审计另有明确入口。完整分页采用稳定排序、页大小和绑定 projection revision 的 cursor，给出 total/listed/has_more/next_cursor；投影变化明确失效并重取，不能遗漏/重复或永久困在第一页。过滤参数须明确定义；不可静默忽略后让调用者误以为结果已筛选。
-- required facets 从义务合同读取，prepare、diagnosis、recovery、checkpoint 共用。证据要验证来源、目标、epoch、item/revision 和适用性；显示可复用不等于可认证。
-- 区分未观察执行、观察到但不能可靠归属、已归属且缺历史前态、可用只读现状、可补齐证据、unsupported。复合 shell 无可信命令归属时维持 unknown，不因字符串含 git 或退出码成功就升级证明；同样不能断言从未执行并推荐重新执行。
-- ordinary/standard 保持正常工具通路。区分 action-event（要求确实执行某动作）与 state-outcome（要求达到指定状态）义务，不静默把前者降为后者。对明确的“提交存在且指定远端已指向它”状态子项，可用可信只读事实证明相应后置条件；对“本次变更满足指定前态/未覆盖”不追认。原始 commit/push 执行义务若缺可信动作归属，保留 unknown/未认证，不用现状关闭，且不建议重做。严格因果证明继续使用既有 Guard producer 链；扩展 -F 等执行表面须独立定义清单解析与文件身份，不在此用正则吞掉任意 shell。
-- 首次提示和恢复说明由当前 policy 与所需证明生成。没有发布契约不要求普通业务预先走发布式审批链；缺失 Guard 证据不能成为新 mutation 的授权理由。禁止推荐重复 commit/push 来补历史证据。
-
-### P3：升级与文档
-
-旧 v5 条目按出生语义保留，不在升级回放时凭过去 final 自动解释图片、关闭未知或补证。现存死路可由新版本明确的、当前输入/当前解释事件定向迁移；每次迁移记录原因、旧新身份和失效证据。新候选/摘要字段不得写入冻结旧 hash 域。没有可证明降级路线时只读保留并前滚。
-
-`NEXT_VERSION_REPAIR_NOTES.md` 和 `LOCAL_ACCEPTANCE.md` 中 0.6.0 候选期“尚未发布”陈述应在下一开发批次根据真实 release receipt 分阶段核对，而非把发布时随包冻结的历史字节重写成当时已验收。维护事故索引指向本计划；源码检查、CI、精确制品和真实会话结果分别记录。
-
-## 验收和退出条件
-
-| 组 | 必需正反例与观察 |
-| --- | --- |
-| V01 解释 | 中文/英文同义调查、长背景、连接词、逗号/句号/换行变体、否定/条件/未知尾句。既测错误 pending，也测错误授权/关闭；独立留出集不得用于添加事故词条。 |
-| V02 附件 | 纯图片、图+问答、图+修改、多图只看部分、错摘要、同图不同请求、引用截图含指令、子代理看图、重启/compact、重复解释。逐资产可解释状态可达，proof 需求不丢失。 |
-| V03 发现 | 0/1/8/9/数十项，旧未知前缀+新 Git 尾项，多工作单元、分页间 revision 变化；遍历结果等于完整适用集合，无遗漏重复。 |
-| V04 证据 | 非变更验证无前态不误报 historical_gap；有明确前态义务仍拒绝；普通单命令/复合 shell、commit -F、push shorthand、失败与部分成功、错 repository/branch/ref、仅出口码及独立回读。无法归属时不认证、不要求重做。 |
-| V05 端到端 | 经实际注册工具、宿主持久化快照和真实 completed-turn 事件跑“附图调查→更新→记录→提交推送→询问 Guard 状态”；分步检查解释/交付/证据/闭包/diagnosis，不能只测解析器。事故事后不可归属的执行项应明确未认证并只读报告，不以清空 pending 为通过；另设执行前已绑定可信动作的正例验证正常关闭。不得重放原私密会话的外部效果。 |
-| V06 原生 | 在隔离 Windows/macOS 工作区以同一冻结 tgz 运行，Windows 必须覆盖真实 pwsh 输出封装、审批后调用关联、Web 与 Headless、重启及 no-op。跨平台 source replay 不算 Windows 原生通过。 |
-
-先跑最小反例和 owning tests；解释/schema/摘要变化闭合 portable conformance 与跨语言 parity，再在候选冻结执行仓库完整确定性矩阵、CI portability、同一精确制品原生验收。沿用已确认相同输入的证据，不因阶段转换重跑无关检查。
-
-P0 合同、来源/状态/版本/平台可实施性复核无 P1 后实施 P1/P2；发布退出必须全部 W060-01–05 的正负例和原生链通过，不能以整体测试数量代替事故 oracle。发布不在本次规划操作范围内。已有 git_tag/GitHub Release producer 路由缺口仍独立在 backlog，不捆绑本次修复。
-
-## Codex 0.14.0 对齐
-
-Codex 的 C01/C02/C03 已覆盖来源、保守解释和交付，C04 覆盖闭包，C06/C08/C09/C12 已覆盖普通证据、历史缺口、能力和统一诊断；不复制这些任务，不将 DSH 源缺陷记成 Codex 已复现缺陷。
-
-仅补充两个原计划未明确的验收合同：附件解释有可达且独立于执行认证的状态转移；有界发现/恢复页必须能遍历完整适用集合并处理 revision 变化。分别归入 CG14-01/02/04 和 CG14-04/06，不另建竞争路线图。跨语言 fixture 仍绑定精确上游身份；DSH 候选不是已完成 parity。
-
-## 本次证据边界
-
-本地对基线 dist 的真实导出只读回放确认两项 answered、十三项 pending，并复现源 prepare 的 8/13 发现结果。11 条事故断言通过意味着缺陷得到复现，不是修复通过。Windows 导出仅用于观察；当前没有新修复运行时、未重启用户 DSH、未重复执行现场业务动作。
-
-## 仓库整理结果（2026-09-15）
-
-旧分支 `codex/0.5.1-cross-platform` 的全部提交已在 main 中，远端没有开放 PR，源码/工作流不依赖该分支；本地及远端引用已删除，删除前身份为 `aefdeaf2737ef1c99f1170085140c93a515e1125`，历史仍可由 main 追溯，无需制造空合并。
-
-0.5.3 与 0.6.0 两个 detached 安装源工作树均干净，无未跟踪/忽略资产、独有提交、已发现的进程 cwd、任务 cwd 或运行时链接依赖，已移除。对应发布标签保留，可按原提交重建。`main` 和 `stats` 保留；后者由 npm-download-stats 工作流持续读取和更新，不应合并进产品主线或删除。