dsh-completion-guard 0.6.0 → 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)
@@ -62,6 +100,120 @@ The two scope facts decided on 2026-09-14 (candidate-only v2 plus open parity;
 attributed as an approved scope reduction) are recorded in
 [SEMANTIC_COMPATIBILITY.md](SEMANTIC_COMPATIBILITY.md).
 
+## 0.6.0 publication facts (verified 2026-09-15)
+
+The "not established" list of the 2026-09-14 source-candidate section below was
+written before publication and is superseded by the following readback, recorded
+the same day it was performed. The historical section text is kept as written.
+
+- The annotated tag `v0.6.0` resolves to commit
+  `cc5cbc6d408664172d9383de7c83c55ec6dfd602`, and the GitHub Release `v0.6.0`
+  targets the same commit.
+- The npm registry carries `dsh-completion-guard@0.6.0`; its registry
+  `dist.integrity` is
+  `sha512-xIV5wAmDhdXGr7xlpOAceaVJUYgkxmqO2/7zuIat95T+QH2k0e09oYRGokUpH18NNNC2p6UVqnjO8fcpp1V58Q==`
+  and `dist.shasum` is `4573474855d2f36c011cb64cc7139ec2bf68d613`.
+- The byte-level comparison of the published artifact against the release
+  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
+release, not an artifact acceptance, and not a native-platform result; each of
+those is a separate fact that, when established, gets its own section and its
+own frozen-artifact identity.
+
+Established at this point:
+
+- The five W060-01–05 repairs from the Windows 0.6.0 session review
+  ([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`,
+  `tests/domain/v061-discovery-pagination.test.ts`,
+  `tests/domain/v061-evidence-contract.test.ts`, and
+  `tests/domain/v061-ordinary-observation.test.ts`, alongside the full
+  pre-existing regression matrix. The suites include the review rounds'
+  counterexamples: an answer that states the images were not viewed closes no
+  asset; a replayed log without interpretation records keeps assets `pending`;
+  an OLD asset closes through the turn that explicitly re-interpreted it, and
+  the closing turn must be the interpreting turn; a receipt contradicting the
+  call, item, revision, or asset identity is an `interpretation_receipt_mismatch`
+  integrity violation that records nothing, and so is a transplanted result
+  whose call turn and receipt turn disagree, while a valid-identity receipt
+  with a MISSING turn association simply records nothing and keeps the log
+  valid; a real order containing a relative wh-clause ("Create a file where
+  logs are stored") stays executable; unknown requests stay unresolved
+  regardless of wording, under the final interpretation contract: a
+  grammatical declarative can express a task requirement, so no surface
+  shape proves a clause is closable information — the review rounds'
+  holdouts all stay unresolved and unanswered ("Please sanitize inputs
+  that are untrusted", "请处理被遮挡的面板", "Have these inputs
+  sanitized", "处理被遮挡的面板", "处理没有标签的输入", "Sanitize inputs
+  I have received", the long-attributive "处理被异常宽大…遮挡的面板",
+  "I need you to sanitize these inputs", "Our requirement is to sanitize
+  all inputs", "避免面板被遮挡", "没有标签的输入也要处理", "Sanitize all
+  inputs", and declarative contexts like "设置面板被遮挡。请修复登录页。"
+  whose undecidable context stays pending) — while clauses with POSITIVE
+  information grounds (questions, quoted actions, past/aspect reports as the
+  clause's entire predicate such as "我刚才已经推送过了") keep closing
+  through their own turn's answer, a bare whole-message acknowledgment
+  ("当然。") is session talk that is never captured, and an unresolved
+  clause — including explanation/investigation openers and every holdout
+  above — is closable only in parts: the implemented structured-interpretation
+  pathway (`context_guard_interpret`) requires a span partition
+  (information_spans/unknown_spans) validated against the full input spans,
+  and only the information sub-item closes with that turn's answer while
+  every unknown/undeclared sub-span stays pending ("Explain the issue,
+  sanitize all inputs" keeps the sanitize demand open); a verbatim concrete
+  clarification supersedes an unresolved clause; a successful command whose
+  text merely contains quoted
+  action text flags nothing; and a git effect that already holds (push with
+  the remote at the local head, pull/fetch already up to date) is refused
+  with `effect_already_applied` before any command runs. The test host lifecycle
+  now disposes every started loop host, which removes the intermittent
+  FileHandle garbage-collection failure of the full-suite run.
+- Compatibility boundaries hold: the asset obligation's contract text is
+  byte-identical to 0.6.0 (replayed contract digests do not move, recorded
+  certificates still verify); asset closure requires a per-asset
+  `context_guard_interpret` record plus the turn's trusted delivery, so logs
+  written by 0.6.0 replay with their assets `pending` — the same status 0.6.0
+  produced; new fields, the interpretation tool, and reason codes are
+  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
+  [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.
+
+Not established here, and deliberately not claimed:
+
+- No 0.6.1 tgz has been packed with `scripts/release-pack.mjs`, so there is no
+  frozen artifact digest for 0.6.1.
+- No native macOS or Windows Web/Headless run has been executed against a
+  0.6.1 artifact; the v5-session, attachment, discovery, and
+  unattributed-observation behaviours above have deterministic coverage only.
+- No tag, npm publication, GitHub Release, or consumer installation exists for
+  0.6.1 in this state.
+
 ## 0.6.0 source candidate (2026-09-14)
 
 This section records a **source and deterministic** claim only. It is not a
@@ -102,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.0",
+  "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": "cc5cbc6d408664172d9383de7c83c55ec6dfd602"
+  "gitHead": "63326f22d40407099baa70c8947c37029749588e"
 }

package/docs/NEXT_VERSION_REPAIR_NOTES.md

@@ -1,81 +0,0 @@
-# 下个版本：准备工具、Git 取证与问答残留
-
-状态：局部修复已随 0.5.3 发布（2026-09-14）；本页记录的后续语义设计已随 0.6.0 实现（2026-09-14），实现状态与验收边界见下节与[语义兼容说明](SEMANTIC_COMPATIBILITY.md)。本页以 0.5.2 为事故修复基线；精确制品与平台结果见[验收记录](LOCAL_ACCEPTANCE.md#053-published-release-2026-09-14)。
-
-## 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 候选的原生 macOS/Windows 验收、精确制品冻结、tag、npm 与 GitHub Release 均未执行，属于后续独立阶段。
-
-## 已实施的局部修复
-
-### 准备工具返回合法 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 上运行。Codex 本轮仅新增问题与设计文档，不修改其运行时；上游没有新增可用于镜像的 v2 规范或 fixture。