dsh-completion-guard 0.6.1 → 0.6.2

package/docs/CROSS_END_RESULT_CONTRACT.md

@@ -0,0 +1,60 @@
+# Cross-end result contract (0.6.2 D062-04)
+
+The planned bounded function-level comparison is now measured. Native T06 and
+exact-artifact host acceptance remain separate release gates. This is not full
+product parity, and no upstream fixture or digest pin changes.
+
+## Inputs and measured paths
+
+Codex Context Guard 0.13.9 is loaded from the installed module. Each recording
+binds its `moduleSha256`. Only synthetic inputs are used; the lifecycle mode
+creates and removes its own temporary ledger through `new_state` and
+`handle_user_prompt`. It never reads a user's session or exports raw ledgers,
+control tokens, timestamps or temporary paths.
+
+| Recording | Executed paths | Evidence boundary |
+| --- | --- | --- |
+| `codex-0.13.9.facts.json` | `clause_metadata`, `verification_contract` | Six exact contract inputs; no generalization to every phrase |
+| `codex-0.13.9.behaviour.json` | `derive_ordinary_proofs`, `_auto_complete_checkpoint`, corrupt-state `handle_stop` | Negative proof and checkpoint cases; its in-memory-only stop gap remains recorded honestly |
+| `codex-0.13.9.lifecycle.json` | Prompt ingestion, verified durable prompt readback, optional `handle_post_tool`, proof derivation, checkpoint and `handle_stop` | Four fresh disposable-ledger cases close the previous lifecycle gap |
+
+The earlier assumption that lifecycle checks required an existing real user
+session was too restrictive. A product-created synthetic ledger satisfies the
+same prompt-integrity check without touching private user state.
+
+## Cross-end assertions
+
+`tests/domain/v062-codex-oracle.test.ts` reads the recorded prompt and command
+bytes and passes them to DSH derivation, checkpoint and boundary entrypoints.
+The host-specific result wrappers remain distinct.
+
+| Case | Codex observation | DSH observation |
+| --- | --- | --- |
+| Ordinary cleanup, honestly uncertified | Silent end, pending retained, zero proofs | Safe end, pending retained, incomplete checkpoint |
+| Missing readback, false whole-completion reply | Visible Stop correction, pending retained | Explicit checkpoint refuses completion; DSH does not parse the same reply at Stop |
+| Wait for user confirmation | Silent user boundary, pending retained | Root wait remains unreleased, incomplete checkpoint |
+| Identical opaque command with intermediate failure and final success | One tool evidence, zero proofs, no automatic checkpoint, pending retained | Unknown operation attribution, no certificate, pending retained |
+
+The mixed-result case replays observations; it does not execute the destructive
+command. A structured per-operation subset is separately tested on DSH and is
+never promoted to a certifying producer. Zero proof and refusal cases establish
+those negative boundaries, not positive certification coverage.
+
+## Reproduce
+
+From the repository root, with Python 3.11+ and the installed 0.13.9 module:
+
+```sh
+python scripts/record_cross_end_oracle.py --check
+python scripts/record_cross_end_oracle.py --mode behaviour --check
+python scripts/record_cross_end_oracle.py --mode lifecycle --check
+python -m unittest tests/record_cross_end_oracle_test.py
+pnpm exec vitest run tests/domain/v062-codex-oracle.test.ts
+```
+
+`--check` compares without replacing the recording. Lifecycle mode may create
+and remove temporary synthetic state even in check mode. Missing entrypoints or
+prompt-integrity failure must fail the lifecycle run; never replace those facts
+with hand-written successful observations. Matching reason strings, equivalent
+obligation models, native Windows behaviour and application loading are not
+claimed by these recordings.

package/docs/DEVELOPMENT_PLAN_0_6_2.md

@@ -0,0 +1,86 @@
+# 0.6.2：普通任务能力诊断与部分失败的事实边界
+
+日期：2026-09-16。状态：D062-01–03 已实施并经本地复核；D062-04 的有界函数级对照已补齐（不等于原生验收）；进入发版准备，尚未冻结候选或发布。后续门槛见 [0.6.2 发版计划](RELEASE_PLAN_0_6_2.md)。
+
+## 结论
+
+本次不能归为单一 Windows 插件故障。Windows 原生文件系统报告目录被另一进程占用；执行代理在尚未证明“无依赖”的条件下清空工作树、反复尝试删除，随后过度描述“无功能影响”；DSH Guard 则把明确但没有专用认证适配器的清理任务表示为 generic_run，并给出不适用的用户补输入/rebind 建议。三者必须分开修复和计量。
+
+目标为 **0.6.2**：纠正既有普通任务责任边界、能力诊断、结果表达和验收覆盖；不通过新增通用删除执行器或自动认证任意 shell 来扩大产品能力。不重做 0.6.1 已通过的附件/分页修复，也不将所有 pending 清空作为成功标准。
+
+## 基线与证据
+
+DSH 本地干净 main 为 `d11009d8f755ecee7d288cff18250c7b372cfd2a`，package 0.6.1。Windows 导出的仓库 HEAD 与之相同；这只证明被操作仓库身份，不单独证明已加载插件字节。日志包含一次根任务、19 次工具调用、两次成功 prepare，无 Guard 异常抛出、无 checkpoint 认证调用，也没有 Guard 阻止删除的证据。
+
+原始日志、会话身份、路径和私有回放保留在仓库外。以下为脱敏归纳，不将附件里的清理请求当成本次授权，不继续删除 Windows 文件或运行原始脚本。
+
+| ID | 观察与源代码定位 | 判定 |
+| --- | --- | --- |
+| W061-01 | discovery 已有 total/listed/has_more，单项清理为 generic_run；`diagnostics.ts` generic 分支仍是 user_input_required，映射到 source_insufficient，建议改成受支持动作并确认。`checkpoint.ts` 明确拒绝 generic 认证。 | 认证能力有限本身不是故障；把能力缺口归给用户且推荐不能保持原义的 rebind 是诊断缺陷。跨平台。 |
+| W061-02 | 多个 worktree remove 同处一个 pwsh 脚本，中间一项退出 255，后续命令继续。宿主 tool/result isError=false，无终止非零 marker。给回放显式提供仓库审计的 Windows rc.2 host-lock fixture 后，`evidence.ts` 得到 outcome=success、parseStatus=unsupported_statement_operator。 | success 在此是宿主工具调用返回且未标错误的旧分类，没有独立结构化退出码，不证明每个删除成功；现有 parse/generic 拒绝保留，不能称 Guard 错签成功证书。诊断/展示必须明确两层事实。 |
+| W061-03 | 删除前检查了 clean/HEAD/无 Git lock，未充分排查 task/process cwd 与运行时依赖；删除后才搜索进程命令行，随后反复 Remove-Item/rename，出现被另一进程占用错误。最后目录仍存在但为空、Git 注册已移除。 | 原生占用是环境事实，依赖检查不足及恢复次序属于执行流程缺陷。命令行不含路径不证明无 cwd/handle，具体持有者和“pending delete”精确状态未被证明。 |
+| W061-04 | 最终同时说清理完成、无功能影响，又承认可能有任务仍依赖已清空目录。分支提交仍可按 SHA 读取被描述为可回滚。 | 部分完成与依赖未知不应表达为全部满足“无依赖”；悬空对象当前可读不是持久备份或无限期恢复保证。属于结果报告/证据边界问题。 |
+
+0.6.1 的首次 guidance 已将 Guard 执行链改成有条件使用，不再无条件审批普通工具；本次不把旧版本的 guidance 缺陷重复登记。没有充分证据认定日志泄露了私有控制令牌；最后那段泛化的认证说明仅属无关实现细节，不应夸大成敏感信息泄漏。
+
+## 为什么 Codex 通常不出现同样提示
+
+比较对象是实际安装的 Codex Context Guard 0.13.9，不从 Skill 文案推断实现。读取其 `scripts/context_guard.py`：
+
+- `verification_contract` 对两条中英文合成的普通分支/工作树清理请求返回 legacy_fallback/no_deterministic_contract，不生成确定性义务。这是函数级探针，不是完整原生任务验收，也不能推广为所有清理表达都会落在同一分支。
+- `derive_ordinary_proofs` 只自动推导其支持且唯一绑定的 artifact readback / scope coverage；`_auto_complete_checkpoint` 不把任意成功工具提升成完成。
+- `handle_stop` 在无确定性未完成义务、无其他续跑门槛且无法唯一认证时，可以静默结束，保留 completion_claim_uncertified_pending_items。故“没看到报错”可能只是静默未认证；若存在强制证明、完整性失败或当前可执行工作，仍可能纠正。
+- DSH 的 `decideTurnBoundary` 普通情形同样可 safe-yield/preserve pending；此次可见错误码来自模型主动调用 prepare 并在最终答复中复述，而非 Stop 强制中断。
+
+因此二者不是“一个成功认证，一个认证失败”的对照实验；它们的可见诊断入口、义务推导和认证模型不同。DSH 的有限 semanticAction + action producer/三角色模型与 Codex 的 obligation/proof 模型尚未完全对齐。共享 digest/v1 fixtures 不证明全功能等价：本仓库 UPSTREAM_PIN 仍绑定 `b59fcfe1aaf8ead3f0438bc67dc7f725c869a473`，Semantic Compatibility 也明确否认完全功能对等。
+
+Windows 占用错误换成 Codex 在同一目录执行也可能遇到；没有证据表明 Codex 能绕过它。两个执行代理是否事先保护活跃工作树，取决于执行流程和可观察宿主事实，不由使用哪个 Guard 自动保证。不能为了对齐让 DSH 隐藏真实业务失败，也不能让 Codex 的静默结束被当成成功证明。
+
+## 开发工作包
+
+### D062-01：能力、输入与修复建议统一
+
+在共享能力投影中区分：解释未知、目标/参数真正缺失、明确动作但没有认证适配器、历史前态缺失、部分/不可归属执行、已验证完成。不要仅以 generic_run 一个枚举推断根因，也不要只针对“清理”增加词表。
+
+对没有保持原义的可达认证路径，repairability 应是 unsupported（或兼容的能力不可用表达），不能要求用户改说 install/modify。建议应为继续已授权普通工作、保留可观察结果、不得宣称证书；有真实歧义或目标选择才请求补充输入。rebind 仅用于能保持原范围且有真实状态转换的澄清，不将产品适配器缺口转成用户授权缺口。
+
+统一 prepare/recovery/status/checkpoint 的 reason 与指引。默认回复不要求代理向用户复述认证内部术语；业务失败、未完成范围和用户需要的操作仍必须清楚报告。只有用户询问 Guard 状态或明确要求证书时才展开认证能力说明。
+
+### D062-02：shell 完成与业务结果分层
+
+保留宿主终止契约：宿主工具返回、明确的进程退出码与可归属单操作成功分开；未能解析的复合 runner 的操作层为 unknown，不从 output 中任意 error/exit 文本猜测业务事实，更不因最后命令成功覆盖中间失败。
+
+只读派生诊断可以新增明确的 process outcome / operation attribution / applicable evidence 字段；无明确退出码事实时新的 process exit status 保持 unknown，不把旧 outcome=success 改称已经读取到 exit 0；不能静默更改旧 evidence.outcome、旧摘要域或重解释已冻结历史证书。所有认证消费者继续校验 parseStatus、目标、来源与所需事实，不能单独消费 success。若持久化新字段会改变语义，先分配版本和迁移边界。
+
+有可信结构化逐操作结果时才表达 partial_failure 及确切子集；只有不透明 shell 输出时给出 unknown 和只读复核建议。当前事故中 Windows 报错是人可读观察证据，不等于插件已获得标准逐操作生产者。不得通过 stderr 关键词白名单自动认证或回溯构造前态。
+
+### D062-03：保留限定条件与安全失败恢复
+
+将“无用/无依赖”保留为清理结果的适用约束，而不是从 clean 或 ancestor 推断完成。为维护流程增加清理前后清单：Git 独有内容、dirty/untracked/ignored、任务 cwd、进程/句柄、运行时链接、外部消费者和恢复依据；这些由执行者与宿主适配层负责，不增加普通工具审批 gate。
+
+对候选逐项记录 dependency_free / in_use / unknown：unknown 不参与要求“无依赖”的自动删除集合；报告保留原因即可，不反复让用户重述原授权。Windows 没有可靠 cwd/handle 读取能力时明确未知，不能用命令行搜索替代。发生部分删除后先只读核对目录内容、Git 元数据及受影响任务；不可自动强删、杀进程、重启或在占用目录里反复写入探针。
+
+将 metadata_removed、content_removed、directory_removed、dependency_status 分开报告。只列 git worktree list 为空不证明目录消失或任务无影响。保留分支若只是悬空 SHA，明确恢复期限未知；需要持久归档时使用已有授权范围内的稳定引用/备份并验证，不能把可读对象当备份。
+
+本版本用合成场景、恢复说明和现有证据/约束接口约束这些行为，不构建万能 Git 清理执行器。对宿主不可观察条件保持未认证，不能承诺插件自动阻止所有危险清理。
+
+### D062-04：与 Codex 做结果合同对照
+
+将同一合成任务和等价事实分别送入两端真实入口，比较 obligation/coverage、operation attribution、completion、pending、wait 和用户可见纠正；保留各宿主事件编码差异。期望对齐的是来源、事实强度及不伪造完成，不是 reason_code 字符串或“都不报错”。
+
+Codex 原 C04/C06/C08/C09/C12 已覆盖大部分原则，只补跨端静默未认证/显式能力诊断的对照 oracle，以及混合结果与无依赖限定条件；不把 DSH 事故登记成 Codex 已发生同类 native bug。上游共享 fixture 未落地前，DSH 用版本明确的本地回归，不覆盖旧 pin、不宣称 parity 完成。
+
+## 验收与阶段出口
+
+| 测试组 | 必须证明 |
+| --- | --- |
+| T01 能力诊断 | 中英同义清理、归档/重命名等未知动作与真缺参数分开；无适配器不要求用户改成另一动作；不虚构 authorized/answered/certified。 |
+| T02 输出层次 | 单命令成功/失败、非零被 catch、循环中间失败后成功、输出含示例 error、宿主超时/中断、只有最后退出码；不透明复合操作保持 unknown，不签发证书。 |
+| T03 条件和子集 | 干净但活跃、ignored 文件、外部链接、未知占用者、部分注销/部分删除；只完成已证明适用子集，不将“无依赖”从闭包删除。 |
+| T04 普通结束 | 默认普通任务不被新增审批链阻断；保留 pending 可静默结束；显式强制证明仍拒绝缺证；用户主动诊断时说明能力限制，失败不能被静默掩盖。 |
+| T05 迁移/回放 | 0.6.1 旧证据和证书不被重新认证，新增诊断不变旧 hash；相同输入重放结果稳定。 |
+| T06 原生 | Windows 隔离目录真实持有句柄并产生部分删除，核对实际状态；macOS 用各自原生行为，不能要求同一错误码；均禁止碰用户活跃任务。共享合成回放不算 native 通过。 |
+
+先最小反例和 owning tests，再按改变的语义/consumer 扩展。候选冻结才跑完整本地矩阵、CI 和同一 tgz 跨主机验收；未提交工作树不产生正式冻结制品。计划实施后自审来源、能力、部分失败、约束遗漏和兼容性，交付未提交候选；提交、跨主机验收、安装/重启及发布另按用户后续指令执行。
+
+当前四条本地断言只复现 generic/diagnosis 及宿主输出层次，Windows 平台上下文来自明确注入的审计 fixture，不能证明现场 host-lock 已加载。首次缺平台的回放为 unknown；修正测试上下文后观察到旧工具级 outcome=success，但 parse 仍 unsupported。没有以调宽 host-lock 或降低 parse gate 获得认证。

package/docs/LOCAL_ACCEPTANCE.md

@@ -1,5 +1,43 @@
 # Local Acceptance
 
+## 0.6.2 lifecycle and documentation consolidation (2026-09-16)
+
+The coordinator added a third Codex recording (`--mode lifecycle`) using
+product-owned prompt ingestion and disposable synthetic ledgers. Its four
+cases measure silent pending, missing-proof correction, user wait and one
+opaque mixed-result command. DSH receives the same recorded prompt/command
+bytes; its checkpoints remain incomplete and its boundary decisions preserve
+pending/wait. See [the result contract](CROSS_END_RESULT_CONTRACT.md).
+
+The earlier in-memory-only probes remain historical evidence, including their
+unexecuted ledger-dependent branch. That limitation is resolved by the later
+lifecycle recording, not by rewriting the old result. T06 now has an owned
+held-handle OS fixture behind `native_acceptance.py --t06`; the source probe
+passed on macOS. Windows and exact-artifact results are not yet claimed.
+
+Duplicate repair notes and the superseded 0.6.1 plan were removed. Historical
+references point to their exact Git snapshot; current semantic and release
+limitations remain in maintained documents.
+
+## 0.6.2 release-preparation recheck (2026-09-16)
+
+The coordinating Codex run on macOS (Node 25.1.0, Python 3.12.2) independently
+passed the full local Vitest suite: 70 files, 1092 tests passed, one skipped.
+The previously reported eight `host-target-preflight` failures did not reproduce;
+that file separately passed all 46 tests. This establishes the result in this
+execution environment, not the root cause of the earlier DSH failures or
+Node 22/24 and Windows portability.
+
+Typecheck passed; lint reported 27 warnings and no errors. Release-pack tests
+passed 2/2; stats tests passed 10/10; build and pack dry-run passed. Rebuilt
+`dist` matched the staged runtime bytes. Documentation audit reported zero
+errors/warnings, 81 Python tests passed, and both Codex recording checks were
+current. The recorder tests are now included in candidate CI's static job.
+
+The uncommitted candidate is not frozen, installed, or published. D062-04 was partial at that checkpoint; subsequent disposable-ledger probes above close its bounded lifecycle gap. T06/exact-artifact native acceptance and candidate CI remain pending. See the
+[0.6.2 release plan](RELEASE_PLAN_0_6_2.md) for the remaining ordered gates.
+
+
 Each section names its evidence boundary. Deterministic checks, isolated DSH_HOME composition, native-platform lifecycle runs, model sessions, CI, and public release readback are separate claims; none substitutes for another.
 
 ### Third repair round after targeted review (2026-09-14)
@@ -79,6 +117,23 @@ the same day it was performed. The historical section text is kept as written.
   receipt's frozen tgz belongs to the release archive and is not re-derived
   here.
 
+## 0.6.2 source candidate (2026-09-16)
+
+Development baseline: `d11009d8f755ecee7d288cff18250c7b372cfd2a`. The
+capability, process-layer and recovery fixes are covered by
+`v062-capability-and-layers.test.ts`; the seven review findings were repaired,
+including frozen-outcome preservation and checkpoint source/conflict output.
+The later lifecycle recording and source probe are described above.
+
+Earlier DSH runs reported eight `host-target-preflight` failures. The Codex
+full run passed those cases; the environment-dependent cause is unconfirmed.
+Do not carry the earlier speculative realpath/module-shadow diagnosis forward
+as an established production defect.
+
+Current source tests do not establish candidate CI, native Web/Headless or a
+frozen tgz. The ordered remaining gates are in the release plan. Historical
+release bytes and their native results below do not certify this candidate.
+
 ## 0.6.1 source candidate (2026-09-15)
 
 This section records a **source and deterministic** claim only. It is not a
@@ -89,7 +144,7 @@ own frozen-artifact identity.
 Established at this point:
 
 - The five W060-01–05 repairs from the Windows 0.6.0 session review
-  (`docs/WINDOWS_0_6_0_REPAIR_PLAN.md`) are implemented and covered by
+  ([historical plan](https://github.com/GreenLv/dsh-completion-guard/blob/d11009d8f755ecee7d288cff18250c7b372cfd2a/docs/WINDOWS_0_6_0_REPAIR_PLAN.md)) are implemented and covered by
   dedicated positive/negative suites:
   `tests/domain/v061-attachment-interpretation.test.ts`,
   `tests/domain/v061-conservative-interpretation.test.ts`,
@@ -145,7 +200,7 @@ Established at this point:
   additive; legacy sessions keep their historical reading; and no digest
   domain was reused.
 - The full local deterministic matrix (this section's top lists it in
-  `NEXT_VERSION_REPAIR_NOTES.md` and the repository instructions) and byte-identical
+  [historical notes](https://github.com/GreenLv/dsh-completion-guard/blob/d11009d8f755ecee7d288cff18250c7b372cfd2a/docs/NEXT_VERSION_REPAIR_NOTES.md) and the repository instructions) and byte-identical
   repeated builds of the candidate dist. The dist differs from the 0.6.0
   base until the 0.6.1 candidate is committed.
 
@@ -199,7 +254,7 @@ The local deterministic checks and [exact-candidate CI](https://github.com/Green
 
 Anonymous readback verified the annotated tag target, npm version and latest tag, embedded commit, registry integrity and downloaded package bytes. The GitHub Release title and bilingual body match the reviewed candidate. All seven attachments match the accepted files: package, checksum, artifact manifest, and the separate macOS/Windows annexes and transfer receipts. Windows result hashes were also matched to the original remote files before publication.
 
-This section and the updated main-branch installation instructions are post-release documentation; the tag and npm package retain their original bytes. The patch fixes prepare serialization and Git input guidance. The answer-delivery design remains future work in [the repair notes](NEXT_VERSION_REPAIR_NOTES.md).
+This section and the updated main-branch installation instructions are post-release documentation; the tag and npm package retain their original bytes. The patch fixes prepare serialization and Git input guidance. The answer-delivery design remains future work in [the repair notes](https://github.com/GreenLv/dsh-completion-guard/blob/d11009d8f755ecee7d288cff18250c7b372cfd2a/docs/NEXT_VERSION_REPAIR_NOTES.md).
 
 ## 0.5.2 published release (2026-09-11)
 

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/SEMANTIC_COMPATIBILITY.md

@@ -243,6 +243,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

package/package.json

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

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 工作流持续读取和更新，不应合并进产品主线或删除。