dsh-completion-guard 0.8.2 → 0.8.4

package/docs/COMPATIBILITY.md

@@ -2,7 +2,9 @@
 
 Guard binds each accepted installation to its exact package identities, implementation bytes and dependency routes. Version admission and implementation qualification are separate checks; a matching version alone does not establish compatibility.
 
-## 0.8.2: DSH >=0.2.0-rc.2 and official Desktop
+## 0.8.2–0.8.4: DSH >=0.2.0-rc.2 and official Desktop
+
+0.8.4 retains the host admission and Desktop support introduced in 0.8.2. Each release still requires its own artifact acceptance.
 
 Version admission uses strict SemVer precedence, including later-tuple RCs and ignoring build metadata. The floor is `0.2.0-rc.2`, with no upper limit. `0.2.0-rc.1` keeps its recorded-evidence row but is refused as below the floor. Below-floor and malformed versions are refused. Cordis has a separate `>=4.0.4` peer range and qualification; a DSH version does not establish arbitrary Cordis compatibility.
 
@@ -16,13 +18,17 @@ Guard identifies the profile by its manifest name. A Desktop profile contains th
 
 Desktop's bundled pnpm 11.7 produces a physical hoisted plugin tree with a JSON `.modules.yaml` index and no package map. Guard verifies the index against the actual tree, then applies the same published-byte and dependency-route checks to local critical peers. Missing, unlisted, duplicate, escaped or changed critical packages are refused. A supported package-map layout remains accepted when present; malformed maps never fall back to the physical-tree path.
 
+The official market (`dshmarket`) is an ordinary third-party profile plugin on a Desktop profile: its bundle presence neither conflicts with the official bundle tuple nor identifies the surface as Web, and its package name grants no trust. Installing or removing the market changes the profile's importer, so the previous Desktop lock stops matching and must be rebuilt through the formal flow. Real-market coexistence acceptance (`desktop-market-coexistence/v1`) is recorded separately from the layered no-op gate in the matching Release annex; graphical-shell and real-model observations remain separate gates.
+
 The archive is read in place. The registry baseline closes the executable/JSON inventory of each critical package, including scripts outside `lib`. Its bytes must match the acquired official tarball digests. The signed archive metadata authenticates the packager's rewritten manifests; executable files have no rewrite exception. Nested critical packages, unlisted code and changed dependency routes are refused. The same fresh route and byte audit also checks critical peers selected from the physical profile.
 
 The lock binds the canonical archive, signed header, runtime manifest and metadata, carrier bytes, installed Guard manifest, profile manifest, map and lockfile. Inject and runtime revalidation use one evaluation path, including foreground renderers and default-workdir providers. Changed inputs refuse the injected lock. Receipts stay under physical, contained profile directories; directory links cannot redirect them elsewhere.
 
 `hostLockProfile: "desktop"` is preserved through composition and readback. Guard refuses Desktop restart with `host_capability_request_unsupported`; the graphical app owns its lifecycle. Exact-artifact backend acceptance, graphical-shell acceptance and real-model behavior are separate gates. Their results belong to the matching Release annexes.
 
-### 0.8.2 中文说明
+### 0.8.2–0.8.4 中文说明
+
+0.8.4 保留 0.8.2 的宿主准入范围与 Desktop 支持；各版本仍须独立核对制品验收结果。
 
 0.8.2 延续 0.8.x 的任务、证书与数据协议，主要适配 DSH RC.2、增加 Desktop 宿主锁并修复退出证据判定。最低 DSH 版本升至 `0.2.0-rc.2`；请先升级宿主，再安装 Guard、重新注入锁并回读。版本准入没有上限，但版本号相符仍不足以证明实现兼容。Cordis 的独立要求为 `>=4.0.4`。
 
@@ -30,6 +36,8 @@ Desktop 按应用自有的 `dsh-profile-desktop` 名称识别。安装须使用
 
 Desktop 自带 pnpm 11.7 生成平铺插件目录，安装索引为 JSON 格式的 `.modules.yaml`，不含 package-map。Guard 核对索引与实际目录，再对本地关键 peer 执行相同的官方字节与依赖路由认证。关键包缺失、未登记、重复、越界或发生改写时均拒绝准入；若存在受支持的 package-map，则使用该布局，损坏的 map 不会回退到平铺目录路径。
 
+官方插件市场（`dshmarket`）在 Desktop profile 上是普通第三方 profile 插件：它的 bundle 既不与官方 bundle 元组冲突，也不能把运行面识别成 Web，其包名本身不授予任何信任。安装或移除市场会改变 profile 的 importer，旧 Desktop 锁因此不再匹配，必须按正式流程重建。真实市场共存验收（`desktop-market-coexistence/v1`）在对应 Release annex 中与分层 no-op 门槛分开记录；图形界面与真实模型观察仍是独立门槛。
+
 Guard 先核验 macOS 的 DeepSeek Developer ID 签名或 Windows 的 DeepSeek Authenticode 发布者，再将 ASAR 头与签名载体内的摘要比对。随后原位读取归档，按独立获取的官方 tarball 清单核验关键包内全部可执行/JSON 文件，包括 `lib` 外的脚本。签名归档的元数据只用于认证打包器改写的 manifest；新增代码、嵌套关键包、错误依赖路由及本地被改动的关键 peer 均拒绝。宿主锁同时绑定应用、载体、profile、安装映射与锁文件；注入和运行时复验采用同一链路，并核验 shell 渲染器及默认工作目录提供者。
 
 Desktop 应用重启仍由应用自行管理，Guard 不提供该能力。最终制品的后端生命周期、图形界面和真实模型验收分别记录在对应 Release annex 中。定时提醒及超时问题的晚到答案仍不授予根指令权限；退出标记被后续 prose 遮挡时，结果保持 `unknown`，不再误判成功。
@@ -62,7 +70,7 @@ The plain npm/node-semver expression `>=0.2.0-rc.1` excludes later-tuple prerele
 
 0.8.0 metadata and its production selector accepted exactly `0.1.7-rc.2`, with Cordis `4.0.4`, cohort `dsh-0.1.7-rc.2-core-v1`, manifest `manifests/rc017-rc2-byte-audit.json`. That historical support scope is a property of the released 0.8.0 and is not rewritten by the 0.8.1 adaptation.
 
-Missing, duplicated, mixed, escaped or modified critical packages fail closed. A matching version or `allow-version` cannot bypass host identity. `auditedPlatforms: []` remains empty: local graph/module verification is separate from native acceptance of a frozen Guard tgz. See the [A01–A16 record](DSH_0_1_7_RC2_ACCEPTANCE.md).
+Missing, duplicated, mixed, escaped or modified critical packages fail closed. A matching version or `allow-version` cannot bypass host identity. `auditedPlatforms: []` remains empty: local graph/module verification is separate from native acceptance of a frozen Guard tgz. See the [A01–A16 record](https://github.com/GreenLv/dsh-completion-guard/blob/563f144bf8568793da5017b9ff71395a33dcd265/docs/DSH_0_1_7_RC2_ACCEPTANCE.md).
 
 Upgrade DSH first, install an accepted Guard artifact, rebuild the host lock and restart each profile. Goal is optional; neither Goal nor Inspector nor scheduling is assumed to be enabled. The 0.7.1 recovery fixes and independent proof, Goal and release gates remain in force.
 
@@ -188,7 +196,7 @@ managers therefore see the same two exact host releases as the host-lock
 registry; neither an unregistered stable release nor a future version is
 implicitly admitted.
 
-That historical artifact retained exact `0.1.5-rc.1` development pins. The current build pins DSH `0.2.0-rc.1` while public DSH peers declare the floor range. Historical peer declarations belong to their own release sections
+That historical artifact retained exact `0.1.5-rc.1` development pins. The current 0.8.4 build pins DSH `0.2.0-rc.2` while public DSH peers declare the floor range. Historical peer declarations belong to their own release sections
 above and are not part of the 0.5.2 contract.
 
 ## Terminal outcome contract

package/docs/HOST_LOCK_UPGRADE.md

@@ -1,6 +1,6 @@
 # Upgrading the core host lock
 
-Version 0.8.2 requires DSH `>=0.2.0-rc.2` and qualified Cordis `>=4.0.4`. Upgrade order and what each step produces:
+Version 0.8.4 requires DSH `>=0.2.0-rc.2` and qualified Cordis `>=4.0.4`. Upgrade order and what each step produces:
 
 1. Stop the host, upgrade DSH to `0.2.0-rc.2` or a later version, then install this Guard version.
 2. Rebuild the host lock for each Guard profile by running `inspect`, `inject` and `verify-dump` from an accepted package or matching source checkout:
@@ -81,7 +81,7 @@ certificate authority — completion certificates, mutation authorization,
 release pre-effect decisions and Goal/Stop boundaries — validates the lock
 freshly at the moment of its own decision.
 
-Version 0.8.2 registers `dsh-0.2.0-rc.2-core-v1` as the audited baseline cohort and derives graph cohorts for compatible hosts above the version floor (see the compatibility guide). Runtime checks authenticate the mapped files and verify that each critical dependency resolves to the mapped instance. Installation imports use native Node resolution; Profile imports use the host's local-first routing and installation fallback only when no local package is selected. A nearer shadow, missing edge, wrong export target or escaped path is rejected even when the recorded versions match.
+Version 0.8.4 registers `dsh-0.2.0-rc.2-core-v1` as the audited baseline cohort and derives graph cohorts for compatible hosts above the version floor (see the compatibility guide). Runtime checks authenticate the mapped files and verify that each critical dependency resolves to the mapped instance. Installation imports use native Node resolution; Profile imports use the host's local-first routing and installation fallback only when no local package is selected. A nearer shadow, missing edge, wrong export target or escaped path is rejected even when the recorded versions match.
 
 The manifest's `registry-derived-pending-native-audit` provenance and empty `auditedPlatforms` list describe its immutable source audit, which is part of the lock digest. Native acceptance belongs to each exact artifact's separate Release annexes; it does not rewrite that digest. Inspection, injection and dump verification report `audit_provenance` alongside the cohort and digest.
 
@@ -100,14 +100,14 @@ that matters for deciding whether you are migrating or just drifting:
   a DSH upgrade, and both are cured by re-running inspect, inject and verify against
   the new runtime rather than by editing the lock.
 
-Historical requirements and session records are retained; old certificates do not become certificates for the new lock. Historical host cohorts are test data only and are not accepted by 0.8.2.
+Historical requirements and session records are retained; old certificates do not become certificates for the new lock. Historical host cohorts are test data only and are not accepted by 0.8.4.
 The shared digest-v3 encoder and its upstream fixtures are unchanged.
 
 ## Official Desktop profile
 
 Stop the Desktop app before installing or rebuilding its lock. Use the CLI carrier shipped with that app: `Contents/Resources/runtime/cli/bin/dsh` on macOS, or `resources\runtime\cli\bin\dsh.cmd` in the Windows installation. A separately installed `dsh` CLI cannot manage the reserved Desktop profile.
 
-Install Guard through that carrier with `plugin --profile desktop add dsh-completion-guard@0.8.2`. Use the profile's own host-lock tool and the app's physical `app.asar` as `--runtime-root`. The default profile is `$DSH_HOME/profiles/desktop`, or `.dsh/profiles/desktop` under the user's home when `DSH_HOME` is unset. This POSIX example starts after installation:
+Install Guard through that carrier with `plugin --profile desktop add dsh-completion-guard@0.8.4`. Use the profile's own host-lock tool and the app's physical `app.asar` as `--runtime-root`. The default profile is `$DSH_HOME/profiles/desktop`, or `.dsh/profiles/desktop` under the user's home when `DSH_HOME` is unset. This POSIX example starts after installation:
 
 ```sh
 DSH_DESKTOP_ASAR=/absolute/path/to/DeepSeek-Harness.app/Contents/Resources/app.asar
@@ -123,7 +123,9 @@ On Windows use the `.cmd` host-lock launcher and the installation's `resources\a
 
 Check `supported` on inspect, inject and verify-dump. Keep Desktop stopped until all checks pass, then open the app when needed. Guard never edits the app archive or restarts the graphical app.
 
-Desktop 升级顺序相同：先停止应用并升级宿主，再用应用附带的 CLI 安装 Guard。普通外部 CLI 无法管理保留的 Desktop profile。以应用的 `app.asar` 和实际 Desktop profile 路径执行 `inspect`、`inject`、`dump-desktop`、`verify-dump`，确认三项 JSON 回读均为 `supported` 后再打开应用。`dump-desktop` 不启动宿主；配置输出可能包含私人信息，请留在本机。Guard 不修改应用归档，也不负责应用重启。
+The official plugin market (`dshmarket`) can be installed into the same Desktop profile through the official management entry; its package name neither conflicts with the Desktop bundle tuple nor grants any trust. Installing or removing the market changes the profile's importer, so the previous Desktop lock stops matching (`host_lock_installed_graph_drift`) and must be rebuilt with the full four-step flow: `inspect`, then `inject`, then generate a NEW composed dump with `dump-desktop`, then verify that new dump with `verify-dump --dump-config <new file>`. `dump-desktop` only composes a configuration for readback; it never substitutes for `verify-dump`. Verify the dump generated after this rebuild — a dump captured before the market change no longer matches and must be discarded. Rebuild the lock on this machine; a lock or digest copied from another profile or machine is not valid evidence. Desktop restart stays unsupported regardless of coexistence.
+
+Desktop 升级顺序相同：先停止应用并升级宿主，再用应用附带的 CLI 安装 Guard。普通外部 CLI 无法管理保留的 Desktop profile。以应用的 `app.asar` 和实际 Desktop profile 路径执行 `inspect`、`inject`、`dump-desktop`、`verify-dump`，确认三项 JSON 回读均为 `supported` 后再打开应用。`dump-desktop` 不启动宿主；配置输出可能包含私人信息，请留在本机。Guard 不修改应用归档，也不负责应用重启。官方插件市场（`dshmarket`）可以通过官方管理入口安装到同一 Desktop profile；其包名既不与 Desktop bundle 元组冲突，也不授予任何信任。安装或移除市场会改变 profile 的 importer，旧 Desktop 锁因此不再匹配（`host_lock_installed_graph_drift`），需要用完整四步流程重建：先 `inspect`，再 `inject`，然后用 `dump-desktop` 生成新的组合配置，最后用 `verify-dump --dump-config <新文件>` 校验这份新配置。`dump-desktop` 只负责生成配置供回读，不能替代 `verify-dump`。请校验本次重建后新生成的 dump——市场变化前捕获的旧 dump 已不匹配，应当丢弃。请在本机重建锁；从其他 profile 或其他机器复制的锁或摘要不构成有效证据。无论是否共存，Desktop 重启仍不受支持。
 
 ## Market and restart
 
@@ -154,7 +156,7 @@ exact artifact and platform; publication is recorded on its GitHub Release.
 
 ## Historical 0.5.1 evidence
 
-Version 0.5.1 registered DSH `0.1.5-rc.1` and `0.1.5-rc.2` with 33 critical packages. Its macOS and Windows results belong only to that artifact and those hosts; see the [0.5.1 release annexes](https://github.com/GreenLv/dsh-completion-guard/releases/tag/v0.5.1). These are historical records, not installation targets for 0.8.2.
+Version 0.5.1 registered DSH `0.1.5-rc.1` and `0.1.5-rc.2` with 33 critical packages. Its macOS and Windows results belong only to that artifact and those hosts; see the [0.5.1 release annexes](https://github.com/GreenLv/dsh-completion-guard/releases/tag/v0.5.1). These are historical records, not installation targets for 0.8.4.
 
 ## Rebinding compatible package versions
 

package/docs/LOCAL_ACCEPTANCE.md

@@ -1,18 +1,22 @@
 # Local Acceptance
 
-## 0.8.2 RC.2 and Desktop acceptance
+## 0.8.3 RC.2 and Desktop acceptance
 
-The candidate keeps the 0.8.x task, certificate and data protocols. Its changed host floor is DSH `0.2.0-rc.2`; use the [upgrade guide](HOST_LOCK_UPGRADE.md) before establishing a new lock. The [development plan](DEVELOPMENT_PLAN_DSH_0_2_0_RC2_DESKTOP.md) defines the source, portability, exact-package, native, model and reader gates.
+The candidate keeps the 0.8.x task, certificate and data protocols. Its host floor remains DSH `0.2.0-rc.2`; use the [upgrade guide](HOST_LOCK_UPGRADE.md) before establishing a new lock. The historical [RC.2/Desktop development plan](https://github.com/GreenLv/dsh-completion-guard/blob/563f144bf8568793da5017b9ff71395a33dcd265/docs/DEVELOPMENT_PLAN_DSH_0_2_0_RC2_DESKTOP.md) records the original adaptation scope; the current source, portability, exact-package, native, model and reader gates are defined below and in the repository instructions.
 
 Run the repository entrypoint twice for each native platform, always with the same frozen tgz and source commit. `host_bound_v070` covers Web/Headless. `desktop_bound` takes the physical app archive as `--runtime-root` and the exact DSH version as `--desktop-cohort`; it creates an isolated profile and uses the signed app's bundled CLI and actual Electron Node backend. Pass `--preflight` to each intended command before execution, with distinct unused external output and transfer-receipt paths.
 
-The Desktop backend annex uses `dsh-desktop-bound/v1`. It covers carrier/graph authentication, installation parity, strict second no-op, injection and real composed readback, loaded Guard behavior, graceful stop, uninstall and cleanup. It expressly skips `graphical_shell` and `real_model_request`. Those skips require separate GUI/model evidence before the complete Desktop release gate closes. Portable tests, source composition against a real archive and a backend annex cannot substitute for those observations.
+The Desktop backend annex uses `dsh-desktop-bound/v2`. It first installs Guard alone and immediately repeats that add: `single_package_strict_noop` requires byte equality for every tracked profile file and the frozen Guard tree. It then adds the inert update fixture and repeats the multi-package add: `multi_package_semantic_noop` permits only JSON object-key order changes in `node_modules/.modules.yaml`. Complete values, array order and types must remain equal; every other tracked file and the Guard tree still require byte equality. The supported metadata format is pnpm's two-space JSON serialization without a trailing newline; duplicate keys, YAML and other serialization formats fail closed. The producer never normalizes or restores metadata and never retries a failed gate.
 
-每个平台分别运行 Web/Headless 与 Desktop 原生入口，绑定同一份最终 tgz、源码提交及摘要。Desktop 使用 `--gate-profile desktop_bound --runtime-root <app.asar> --desktop-cohort 0.2.0-rc.2`，先加 `--preflight` 做同一次调用环境的能力预检，再去掉该参数执行。该入口在隔离 profile 中验证官方载体、安装字节、严格 no-op、组合配置、实际加载与卸载，并输出独立 annex；它不启动图形界面、不请求真实模型，二者须单独补齐。具体结果留在对应制品的外部回执和 Release 附件，避免文档自引用造成制品身份变化。
+pnpm 11.7.0 builds hoisted-location mappings asynchronously and writes their insertion order, so multiple unchanged packages can flip object-key order. The v2 contract explicitly distinguishes that host serialization limit from Guard single-package byte stability. Historical `dsh-desktop-bound/v1` failures remain failures and are not upgraded by this new contract. `schemas/native-desktop-bound-v2.schema.json` and the read-only `scripts/validate_native_desktop.py` consumer bind the new gate set to the exact source, tgz, driver, platform and Desktop lock. The command is `python scripts/validate_native_desktop.py <annex> --artifact <frozen-tgz> --repo-root <clean-checkout> --expected-platform macos --desktop-host-lock-digest <readback-digest>` (use `windows` for that platform).
+
+The backend annex also covers carrier/graph authentication, installation parity, injection and real composed readback, loaded Guard behavior, graceful stop, uninstall and cleanup. It expressly skips `graphical_shell` and `real_model_request`. Those skips require separate GUI/model evidence before the complete Desktop release gate closes. Portable tests, source composition against a real archive and a backend annex cannot substitute for those observations.
+
+每个平台分别运行 Web/Headless 与 Desktop 原生入口，绑定同一份最终 tgz、源码提交及摘要。Desktop 使用 `--gate-profile desktop_bound --runtime-root <app.asar> --desktop-cohort 0.2.0-rc.2`，先加 `--preflight` 做同一次调用环境的能力预检，再去掉该参数执行。该入口在隔离 profile 中验证官方载体、安装字节、单包严格字节 no-op、多包 JSON 值等价、组合配置、实际加载与卸载，并输出独立 annex；它不启动图形界面、不请求真实模型，二者须单独补齐。具体结果留在对应制品的外部回执和 Release 附件，避免文档自引用造成制品身份变化。
 
 ## 0.8.0 rc.2 source-stage snapshot
 
-The [A01–A16 source-stage snapshot](DSH_0_1_7_RC2_ACCEPTANCE.md) records development checks before exact-artifact acceptance. Final CI, platform and model results belong to the matching artifact receipts and Release attachments. This source snapshot neither predicts those results nor transfers earlier acceptance to the changed rc.2 adapter.
+The [A01–A16 source-stage snapshot](https://github.com/GreenLv/dsh-completion-guard/blob/563f144bf8568793da5017b9ff71395a33dcd265/docs/DSH_0_1_7_RC2_ACCEPTANCE.md) records development checks before exact-artifact acceptance. Final CI, platform and model results belong to the matching artifact receipts and Release attachments. This source snapshot neither predicts those results nor transfers earlier acceptance to the changed rc.2 adapter.
 
 ## 0.7.1 recovery feedback patch (2026-09-22; source evidence)
 

package/docs/README.md

@@ -1,14 +1,21 @@
 # Documentation map
 
-Start with [architecture](ARCHITECTURE.md), [compatibility](COMPATIBILITY.md), [privacy](PRIVACY.md), and [host-lock upgrades](HOST_LOCK_UPGRADE.md). [Distribution](distribution.md) describes installation and package channels. [Local acceptance](LOCAL_ACCEPTANCE.md) records evidence for exact candidates; an older result does not certify new package bytes.
+For installation and upgrades, start with [host-lock upgrades](HOST_LOCK_UPGRADE.md) and [compatibility](COMPATIBILITY.md). [Distribution](distribution.md) lists package channels. [Local acceptance](LOCAL_ACCEPTANCE.md) distinguishes source checks, installed-artifact results and their limits.
 
-The [core alignment contract](CORE_ALIGNMENT_CONTRACT_V2.md), [semantic compatibility](SEMANTIC_COMPATIBILITY.md), [upstream base](UPSTREAM_BASE.md), and frozen conformance pin describe shared semantics and their limits. Keep the [0.7.0 development plan](DEVELOPMENT_PLAN_0_7_0.md) with its [plan review](CORE_ALIGNMENT_PLAN_REVIEW.json): these are the original planning snapshot, not a current execution queue or proof of release. Their original bytes remain unchanged.
-
-The current [rc.2 adaptation plan](DEVELOPMENT_PLAN_DSH_0_1_7_RC2.md), [planning evidence](dsh-0.1.7-rc.2-planning-evidence.json), and [A01–A16 status](DSH_0_1_7_RC2_ACCEPTANCE.md) distinguish source work from artifact and native gates.
+For maintenance, use [architecture](ARCHITECTURE.md), [privacy](PRIVACY.md), the [writer-lock protocol](WRITER_LOCK_PROTOCOL.md), and [historical incident coverage](HISTORICAL_INCIDENT_COVERAGE.md). The [core alignment contract](CORE_ALIGNMENT_CONTRACT_V2.md), [semantic compatibility](SEMANTIC_COMPATIBILITY.md), [upstream base](UPSTREAM_BASE.md), and [porting notes](PORTING_NOTES.md) explain shared semantics and product boundaries. [Third-party licenses](THIRD_PARTY_LICENSES.md) records attribution.
 
 ## Historical development material
 
-Completed pre-0.7 plans and one-time execution handoffs have been removed from the current documentation tree. Their exact original content remains available below; historical instructions do not authorize new operations.
+Completed development plans, one-time planning evidence and previous release-note drafts are retained at immutable Git revisions rather than shipped in the current package. Their original bytes remain available below; their pending statuses and instructions describe those historical candidates, not the current release.
+
+- [DEVELOPMENT_PLAN_0_7_0.md](https://github.com/GreenLv/dsh-completion-guard/blob/563f144bf8568793da5017b9ff71395a33dcd265/docs/DEVELOPMENT_PLAN_0_7_0.md)
+- [CORE_ALIGNMENT_PLAN_REVIEW.json](https://github.com/GreenLv/dsh-completion-guard/blob/563f144bf8568793da5017b9ff71395a33dcd265/docs/CORE_ALIGNMENT_PLAN_REVIEW.json)
+- [DEVELOPMENT_PLAN_DSH_0_1_7_RC2.md](https://github.com/GreenLv/dsh-completion-guard/blob/563f144bf8568793da5017b9ff71395a33dcd265/docs/DEVELOPMENT_PLAN_DSH_0_1_7_RC2.md)
+- [dsh-0.1.7-rc.2-planning-evidence.json](https://github.com/GreenLv/dsh-completion-guard/blob/563f144bf8568793da5017b9ff71395a33dcd265/docs/dsh-0.1.7-rc.2-planning-evidence.json)
+- [DSH_0_1_7_RC2_ACCEPTANCE.md](https://github.com/GreenLv/dsh-completion-guard/blob/563f144bf8568793da5017b9ff71395a33dcd265/docs/DSH_0_1_7_RC2_ACCEPTANCE.md)
+- [DEVELOPMENT_PLAN_DSH_0_2_0_RC2_DESKTOP.md](https://github.com/GreenLv/dsh-completion-guard/blob/563f144bf8568793da5017b9ff71395a33dcd265/docs/DEVELOPMENT_PLAN_DSH_0_2_0_RC2_DESKTOP.md)
+- [RELEASE_NOTES_0_7_1.md](https://github.com/GreenLv/dsh-completion-guard/blob/563f144bf8568793da5017b9ff71395a33dcd265/docs/RELEASE_NOTES_0_7_1.md)
+- [RELEASE_NOTES_0_8_2.md](https://github.com/GreenLv/dsh-completion-guard/blob/563f144bf8568793da5017b9ff71395a33dcd265/docs/RELEASE_NOTES_0_8_2.md)
 
 - [DEVELOPMENT_PLAN_0_6_2.md](https://github.com/GreenLv/dsh-completion-guard/blob/784b5452b0da366a351dff6490fa46eeed2839a9/docs/DEVELOPMENT_PLAN_0_6_2.md)
 - [RELEASE_PLAN_0_6_2.md](https://github.com/GreenLv/dsh-completion-guard/blob/784b5452b0da366a351dff6490fa46eeed2839a9/docs/RELEASE_PLAN_0_6_2.md)
@@ -17,6 +24,4 @@ Completed pre-0.7 plans and one-time execution handoffs have been removed from t
 - [EXECUTE_0_6_3_PROMPT.md](https://github.com/GreenLv/dsh-completion-guard/blob/784b5452b0da366a351dff6490fa46eeed2839a9/docs/EXECUTE_0_6_3_PROMPT.md)
 - [DEVELOPMENT_HANDOFF_0_6_3.json](https://github.com/GreenLv/dsh-completion-guard/blob/784b5452b0da366a351dff6490fa46eeed2839a9/docs/DEVELOPMENT_HANDOFF_0_6_3.json)
 
-The [0.6.3 contract revision](CONTRACT_REVISION_0_6_3.md), [bounded cross-end result contract](CROSS_END_RESULT_CONTRACT.md), porting notes and acceptance history remain because they explain compatibility and earlier evidence boundaries. They do not replace the current core contract.
-
-This cleanup changes source documentation for a future package. It does not alter the immutable published 0.7.0 artifact or its acceptance identity.
+The [0.6.3 contract revision](CONTRACT_REVISION_0_6_3.md), [cross-end result contract](CROSS_END_RESULT_CONTRACT.md), and versioned acceptance history remain because current compatibility references still depend on their definitions. Older acceptance does not certify new package bytes.

package/docs/WRITER_LOCK_PROTOCOL.md

@@ -0,0 +1,63 @@
+# Private-ledger writer lock
+
+This document describes the current 0.8.4 protocol (Revision 3.2). It replaces the generation, slot/intent and earlier arbitration designs recorded in Git history. Those earlier designs are not operational instructions.
+
+## Purpose and limits
+
+Only one writer may append to a ledger root at a time. A crashed same-host writer with a complete owner record must be recoverable. Unknown owners, foreign hosts and PIDs that cannot be proved dead are refused. Only ESRCH proves death; PID reuse can delay recovery but must not authorize eviction of a live process.
+
+The protocol targets local filesystems supporting exclusive creation, hard links, append and atomic same-directory rename. Its arbitration model assumes that one complete record write with O_APPEND is ordered with other appends, and a subsequent read observes that order. This is a filesystem assumption, not evidence of native Windows or macOS acceptance; those platforms must be validated separately. A filesystem without hard-link support cannot use this admission path.
+
+## Files and authority
+
+| File | Role |
+| --- | --- |
+| `.writer.lock` | Complete v2-shaped owner record; excludes older writers. |
+| `pending.<nonce>.json` | Unique preparation file; has no admission authority. |
+| `arbitration.log` | Ordered claim, release and eviction records; replay determines the current holder. |
+| `arbitration.log.compact` | Temporary replacement written by the current holder during compaction. |
+
+A record identifies its nonce, PID and hostname. Pending filenames are unique per attempt and are not reused by the protocol. The ledger contents and shared anchors remain separate from these coordination files.
+
+## Admission
+
+1. Inspect pending records. Delete only complete records whose creator is provably dead on this host. Leave live, foreign and unparseable pending files untouched; they do not block admission.
+2. Classify `.writer.lock`. Unknown, foreign or live owners refuse admission. Adopt a complete same-host dead record without modifying or deleting it. If no barrier exists, preparation and publication below are required.
+3. Replay the arbitration log. Refuse a live or foreign holder. For a provably dead holder, append an eviction naming that holder's nonce, then retry classification.
+4. If a barrier is needed, create a unique pending file with O_EXCL, write the complete owner record and fsync it. Publish it with `link(pending, .writer.lock)`. A successful link exposes the complete inode atomically; EEXIST loses publication and causes reclassification. Never publish an empty preparation file.
+5. Append a claim and read the log back. Enter only when replay identifies this attempt's nonce as holder. An unsuccessful claimant removes only its own published barrier after matching its nonce, and its own pending file. An adopted barrier stays untouched.
+
+The barrier and claim use the same nonce. No process automatically removes an observed dead barrier to make room for a replacement.
+
+## Replay and linearization
+
+Replay starts with no holder. A claim grants ownership only when the slot is empty. Release and eviction clear the holder only when their expected previous nonce matches the current holder. An eviction is submitted only after a same-host ESRCH check. A delayed eviction of D therefore cannot remove a later holder B.
+
+Under the append-order assumptions, a successful claim takes effect at its position in the log. Its readback confirms admission; it does not authorize replacing a live holder. Losing claims remain ineffective in that replay order.
+
+Unparseable lines are skipped. Appenders prepend a newline when the observed file does not end at a line boundary. The protocol never truncates the log during tail repair. The parser also accepts a complete final JSON record without a newline; incomplete pending files have no role in this replay.
+
+## Release and compaction
+
+Release appends a record naming the writer's own nonce. It then removes only a barrier it published itself, after matching that nonce, and removes its own pending filename. Adopted barriers remain.
+
+Above the record threshold, the current writer compacts immediately after verified admission, before returning the held lock. The replacement contains the current holder's baseline claim. Compaction occurs during that holder's tenure, not after release. Concurrent stale claims and evictions cannot change that live holder under the admission rules. Readers see either the preceding log or the replacement, with the same holder. Do not move compaction after barrier removal or replace the baseline with a released owner.
+
+## Crash recovery and older versions
+
+| Crash point or state | Subsequent behavior |
+| --- | --- |
+| Before pending write, or during partial write | Only an inert pending file remains; other writers can proceed. Unparseable leftovers remain on disk. |
+| Complete pending, before link | No barrier was published; a dead creator's complete pending record may be collected. |
+| After link, before claim | The barrier contains a complete dead owner; a later writer adopts it and claims the empty slot. |
+| After claim | A later writer adopts the barrier, evicts the provably dead log holder and retries admission. |
+| Old writer holds `.writer.lock` | The new writer refuses while its owner is live or unknown. |
+| New writer holds or adopts `.writer.lock` | Old writers fail exclusive creation and refuse. |
+
+An adopted dead barrier continues to exclude older writers after the new writer releases. Returning to the older protocol requires an explicit maintenance window: stop every Guard process using that ledger root, verify exclusive access, then remove the stale barrier. Never delete a lock in a running shared profile based on its age alone. Unknown locks left by older versions require the same controlled investigation; they are not automatically recovered.
+
+## Regression evidence
+
+The concurrency suite exercises simultaneous child processes, stale evictions, live-holder exclusion, compaction during tenure and both upgrade directions. Deterministic production-child checkpoints cover pending before write, partial write, before link and after link before claim. Each checkpoint checks live-creator safety, kills and waits for that process, then requires subsequent appends to recover with a continuous ledger chain.
+
+These tests establish the tested source behaviors. Candidate CI and native exact-artifact acceptance remain separate gates. No finite test suite constitutes a proof for arbitrary filesystems, external file mutation or power-loss durability.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-completion-guard",
-  "version": "0.8.2",
+  "version": "0.8.4",
   "description": "A task-contract and completion-certification layer for DeepSeek Harness.",
   "repository": {
     "type": "git",
@@ -118,5 +118,5 @@
     "hooks",
     "typescript"
   ],
-  "gitHead": "913a4c7a6f0f600f4146ef4af694d3af6e477ef2"
+  "gitHead": "fd6b2dcf1015a192a81a50be121bd32d7cf18fe5"
 }

package/docs/CORE_ALIGNMENT_PLAN_REVIEW.json

@@ -1,144 +0,0 @@
-{
-  "schema": "multi-repository-plan-freeze/v1",
-  "subject": {
-    "kind": "plan_spec",
-    "paths": [
-      "docs/CORE_ALIGNMENT_CONTRACT_V2.md",
-      "docs/DEVELOPMENT_PLAN_0_7_0.md"
-    ],
-    "sha256": "d9b19bddfa99fff432e1001b762543049a02fcd62060821bfc8b19b4514c7f96",
-    "version": "070-014-plan.2"
-  },
-  "owners": {
-    "mutation_owner": "coordinator",
-    "reviewers": [
-      "mechanism_review",
-      "codex_next_audit"
-    ]
-  },
-  "review_contract": {
-    "lenses": [
-      "authority",
-      "identity",
-      "state_effect_readback",
-      "canonicalization",
-      "platform_feasibility",
-      "migration_versioning",
-      "verification_release_boundary"
-    ],
-    "blocking_severities": [
-      "P1"
-    ],
-    "scope_reopened": false,
-    "scope_reopen_reason": null
-  },
-  "baselines": [
-    {
-      "id": "dsh_source",
-      "kind": "mutable",
-      "value": "0.6.3 at 1735cfadecf0feddfa07bd811fa0297a49c7fd88; workflow/test-only baseline advanced; no 0.7.0 runtime implementation",
-      "refreshed_at": "2026-09-18"
-    },
-    {
-      "id": "codex_source",
-      "kind": "mutable",
-      "value": "0.13.9 at ce667adefd716f829fb1fb070b3089e789ed74c3; no 0.14.0 runtime implementation",
-      "refreshed_at": "2026-09-18"
-    },
-    {
-      "id": "stop_incident",
-      "kind": "mutable",
-      "value": "CGI-20260918-codex-future-observation-stop; Codex 0.13.9 macOS observed and isolated Hook reproduction; no DSH/Windows reproduction or runtime repair",
-      "refreshed_at": "2026-09-18"
-    }
-  ],
-  "issues": [
-    {
-      "id": "D070-R01",
-      "severity": "P1",
-      "status": "resolved",
-      "lens": "platform_feasibility",
-      "summary": "将效果前发布拒绝限定于Guard控制入口及契约预检，明确普通opaque通道无拦截保证/不可认证。",
-      "invalidates": [
-        "normative_spec",
-        "implementation_annex"
-      ]
-    },
-    {
-      "id": "CG14-R01",
-      "severity": "P1",
-      "status": "resolved",
-      "lens": "state_effect_readback",
-      "summary": "继续提示的actionable前提与虚假完成/proof纠正分离，合计每turn一次预算。",
-      "invalidates": [
-        "normative_spec",
-        "implementation_annex"
-      ]
-    },
-    {
-      "id": "CG14-R02",
-      "severity": "P1",
-      "status": "resolved",
-      "lens": "authority",
-      "summary": "显式release profile仍进入发布模式；空契约相关发布fail-closed。",
-      "invalidates": [
-        "normative_spec",
-        "implementation_annex"
-      ]
-    },
-    {
-      "id": "CG14-R03",
-      "severity": "P2",
-      "status": "resolved",
-      "lens": "platform_feasibility",
-      "summary": "P0加入两宿主真实工具事件、来源信任、readback、水位及平台能力清单。",
-      "invalidates": [
-        "normative_spec",
-        "implementation_annex"
-      ]
-    },
-    {
-      "id": "CG14-STOP-R01",
-      "severity": "P1",
-      "status": "resolved",
-      "lens": "state_effect_readback",
-      "summary": "Planning gap closed with AC05.1 action provenance/as-of facts, separate persistence/resume reasons and external-operation registration, plus A13 positive/negative production-path acceptance. Runtime incident remains reproduced and awaits implementation.",
-      "invalidates": [
-        "normative_spec",
-        "implementation_annex"
-      ]
-    },
-    {
-      "id": "D070-STOP-R01",
-      "severity": "P2",
-      "status": "resolved",
-      "lens": "verification_release_boundary",
-      "summary": "D070-00 explicitly freezes AC05.1 fields/version identities and A13 independent oracle at P0; M2 wires the frozen contract rather than defining it late.",
-      "invalidates": [
-        "implementation_annex"
-      ]
-    }
-  ],
-  "gates": [
-    {
-      "id": "structural_docs",
-      "status": "passed",
-      "evidence": "DSH repository audit: 29 Markdown files, zero errors/warnings; documentation unit tests 3/3 and release-pack tests 2/2 passed. Codex scoped audit: 2 Markdown files, zero errors/warnings; full validate-skills passed 36 skills. Native/product implementation acceptance is not claimed."
-    },
-    {
-      "id": "shared_copy",
-      "status": "passed",
-      "evidence": "Byte-identical shared planning copies; SHA256 523f9239168fb11d8daf72d6c3348b3121caa1b05aaa7f32afd3692952c477d5."
-    },
-    {
-      "id": "independent_review",
-      "status": "passed",
-      "evidence": "Plan.1 seven-lens review retained for unchanged contract. Incident reopened authority/state-effect/verification and affected migration only. mechanism_review and codex_next_audit independently read final bytes; D070-STOP-R01 corrected and rechecked. No open P1. Planning freeze only; product P0 and runtime implementation remain pending. Prior subject cd86da843acbc38190307e8e604ddab6a3e464be857f4baa9da4b4b3db3bb755."
-    }
-  ],
-  "freeze_decision": {
-    "status": "frozen",
-    "subject_sha256": "d9b19bddfa99fff432e1001b762543049a02fcd62060821bfc8b19b4514c7f96",
-    "open_p1_ids": []
-  }
-}

package/docs/DEVELOPMENT_PLAN_0_7_0.md

@@ -1,93 +0,0 @@
-# DSH Completion Guard 0.7.0 开发计划
-
-计划版本：1.1，2026-09-18。配对版本：Codex Context Guard 0.14.0。状态：开发规划，未实施新运行时；本轮按新增授权提交并推送规划文档，不安装或发布。后续执行者的操作范围由当时用户指令决定。
-
-## 1. 目标与本版决策
-
-0.7.0 要改变默认工作方式：普通业务由助手通过宿主工具执行，Guard 负责不丢要求、观察事实和检查完成；显式发布契约才进入 Guard 的受控执行。目标是共同职责与可观察结果对齐，不能以“共享了摘要算法”或“双方都拒绝”代替。
-
-这是 pre-1.0 的功能与兼容边界调整，使用 0.7.0；Codex 独立使用 0.14.0。0.6.3 对资格传递、目标字段和旧记录的修复作为历史回归保留，但其 `ExecutionQualification` 不能继续成为普通任务入口。不得继续通过增加疑问词、主体词、动作词、重述模板来证明普通执行权限。
-
-共同规范见 [CORE_ALIGNMENT_CONTRACT_V2.md](CORE_ALIGNMENT_CONTRACT_V2.md)。AC01–AC12 为本计划必须遵守的职责合同；本文负责 DSH 的替换路径、工作包和验证。0.6.3 计划、合同修订、发布事实均保持历史原文，不能将其局部验收复用为新架构已通过。
-
-## 2. 可变基线与已实现资产
-
-实施入口重新核对 HEAD、dirty、分支、宿主 cohort、工具版本与写入者；以下是 2026-09-18 本地观察，不是实施时自动有效的事实。
-
-| 对象 | 基线及影响 |
-| --- | --- |
-| DSH 0.6.3 | `4c26bee90a7b9e8b26ebbe91f335e356e7589fc3`；规划开始时 clean |
-| Codex | 0.13.9，HEAD `ce667adefd716f829fb1fb070b3089e789ed74c3`；0.14.0 尚是计划 |
-| 共享材料 | v1 镜像 pin `b59fcfe1aaf8ead3f0438bc67dc7f725c869a473`；v2 为 DSH 单边 candidate，不是共同验收 |
-| 本地已有能力 | 来源、work-unit/后代闭包、交付、分页、proof、migration、npm release 路径均已有实现；优先重接职责，不重造一套平行状态 |
-| 原生与安装 | 0.6.3 的已记录验收与安装只绑定旧制品；不证明0.7.0行为，不代替重启后的运行状态 |
-
-源码重点：`src/domain/{semantics,capture,derive,closure,checkpoint,stop-policy,goal-gate,compatibility,release}.ts`、`src/runtime.ts`、`src/tools/{evidence,action-preparation,prepare,release}.ts`。实施时检验路径存在，不猜未有的宿主 Hook 或 API。
-
-## 3. 逐机制处理决定
-
-| 0.6.3 机制 | 0.7.0 处理 | 必须保留的保护/替代路径 |
-| --- | --- | --- |
-| 文本生成 executionQualification，再授权普通 action | 新普通路径删除依赖，旧字段仅历史解码；普通操作移至宿主工具 | 原始禁止/等待仍给助手恢复；不把普通工具放行说成授权 |
-| context_guard_action 与 evidence 内 effect 分支 | 默认任务停用副作用；兼容调用只返回迁移诊断 | 已采用 release 的专用表面独立保留完整前置校验；不能用 policy 参数绕开 |
-| prepare 的“当前能执行吗” | 变为只读事实/证明诊断；普通任务无必要前置调用 | 同输入诊断与认证/发布判据一致，陈旧快照不可复用 |
-| Guard 自有 producer 链作为主要效果证据 | 接入真实宿主普通工具及回读，按 predicate 验证 | 来源/目标/前态要求不降低；历史不足不重复业务操作 |
-| informational/executable 的整句语言判定 | 变为覆盖完整原文的解释记录，未知残余保留 | 信息交付与业务执行分开；模型解释不制造事实或权限 |
-| pending/needs_review 与 Stop/Goal 相互牵连 | 普通结束、完整认证、Goal complete 分开 | unknown 不强迫普通工具前置审批；旧误完成仍阻断新认证 |
-| 目标字段与身份检查 | 复用精确身份库，分开根约束、实现选择、解析和观察 | 完整元组、大小写、跨仓库来源及 revision 仍严格 |
-| 现有 release 机制 | 保留并接新事实模型；最低保护现有 registry publish 表面 | 明确覆盖/不可覆盖，采用前拒绝不可履行契约，不引导绕行 |
-| upstream-deltas 的单一 aligned 标签 | 改为实现状态与实测比较状态两维 | 相同 fixture 双端结果及源码身份才可 aligned |
-
-不以删除旧代码行数衡量完成。默认工具描述、恢复提示、实际注册入口、影子调用、Goal 回调、旧会话重放和文档必须一起迁移；仅在普通工具外再包装一层“新认证工具”不满足本版目标。
-
-## 4. 工作包、所有权与先后关系
-
-| 包 | 具体产出 | 依赖及退出条件 |
-| --- | --- | --- |
-| D070-00 共同核输入 | 与 Codex owner 完成 AC01–AC12 的schema（含AC05.1当前动作依据、两类继续原因、as-of水位及版本身份）、规范事件/fact、投影、S/A fixtures（含A13独立oracle/反例）、协议身份、proof/release覆盖及真实宿主工具/事件能力清单 | P0 在 Codex 上游冻结，DSH精确镜像；不先写另一份单边v2 |
-| D070-01 默认路径迁移 | 去除普通 mutation 门禁/效果分支及资格依赖，更新真实工具注册与提示；保留显式release入口 | AC01/02，旧工具误调用无效果；普通任务无Guard授权轮次 |
-| D070-02 原生事实与证明 | tool call/result/持久化水位转换、普通文件/测试/Git回读、action-event/state-outcome分层 | AC06/07；正向可认证，缺能力诚实，副作用不重放 |
-| D070-03 解释与闭包 | 接统一来源/coverage、信息交付、目标关联、supersession、资产和分页；复用现有单元状态 | AC03/04；纯信息正常关闭、混合/未知不丢、相同原文入口可对照 |
-| D070-04 Stop 与 Goal | 普通结束、明确完成主张、proof、Goal completion 分层；落实AC05.1当前动作依据、原因分离、as-of判定；进展指纹与纠正预算 | AC05/08；A13不误造工作/等待，真正漏项仍提示；有界纠正不自旋，不新增host调度/暂停 |
-| D070-05 迁移与退役 | 0.6.3旧资格/answered/工具调用/票据迁移，协议/schema与回滚清单 | AC09；旧历史不改，旧发布效果未知不重做，正向恢复可达 |
-| D070-06 双端差分与声明 | Python/TS纯核、双端原文入口、生产注册/持久化/compact；重建两维delta | AC10/11，必修集无差异，不能用宿主专属标签排除共同需求 |
-| D070-07 候选与交付 | 版本、双语README/changelog、API迁移说明、dist、制品与四泳道原生计划 | AC12；独立证据绑定；按另行授权进入候选/原生/发布 |
-
-00先于依赖新schema的实现；01/02必须作为一个纵向切片验证，避免先拆执行器却留下无证据可完成。03/04接同一状态，05在新路径稳定后完成。06贯穿各包，07不允许用文档把未通过项写成完成。一个worktree一个writer；共享规范由上游owner串行修改，两个产品可各自实现不同宿主适配。
-
-## 5. 首个纵向切片与可执行里程碑
-
-M1（架构可行）：隔离普通任务“解释配置 → 修改指定文件 → 跑测试 → 回读”从真实宿主工具进入新 fact，再到完成判定；同时验证零效果final、无关成功、缺adapter、旧action调用。通过标准是普通工作没有Guard准备/审批步骤、正确结果可认证、缺证不误认证。M1不通过不得继续堆语言用例或候选全矩阵。
-
-M2（共同核心）：加入AC05.1当前动作依据与A13成对用例，再加入同工作单元跨仓库后续提交推送、信息/执行混合、真实歧义、明确等待、compact/resume、资产与完整范围proof；两端原文与规范事件双泳道均比较。完整矩阵见共同合同A01–A13及Codex计划S01–S12。
-
-M3（兼容与受控发布）：0.6.3旧会话/旧工具/旧资格恢复，旧证书历史保留；新完成资格不继承假通过；显式registry发布的成功、错身份、过期、重放、超时未知与读回。普通push全程不自动激活release。
-
-M4（候选）：本地全部必修通过、有限冷审无开放P1、产品文档与生成物一致；准备源码候选，不等于原生或发布放行。M5在另行授权后完成两产品×两平台同源/各自同制品的真实正向业务验收，再给出对齐结论。
-
-## 6. 验证与防止反复返工
-
-- 先锁定合同、独立期望和失败家族，再实现。已有事故是种子，不是期望的唯一来源；保留同义留出集与正常流程，不能全unresolved或只测拒绝来过关。
-- 同族第二个反例触发集中入口×动作×字段×状态审计；统一返还清单，停止“找到一条→全矩阵→再找一条”。修复后只复验受影响合同和开放项。固定集全部满足才冻结，不无限增加语言功能。
-- 按diff运行所属Vitest/portable/conformance；架构定型执行AGENTS规定完整矩阵：typecheck、lint、test、test:release-pack、test:stats、build、pack:check、文档审计及单测、diff check。生成dist须稳定；提交后的clean生成物检查另做，不能为了旧HEAD无diff撤回正确产物。
-- API/schema/摘要改动要跑全部消费者、跨语言和旧状态；不要只测直接函数，至少覆盖真实注册、结果materialization、持久化重放、Stop与Goal接线。
-- 真实模型A12必需，不能再用只有注入请求/检查拒绝的原生探针替代。业务只在一次性仓库/profile，网络push须有明确隔离目标权限；不重放事故原业务。
-- 对齐表列共同合同版本、双方commit、fixture digest、实际生产入口、平台、skip和差异。无相同API名不是不适用理由。必修差异或缺失就是未完成，只有宿主专属细节可不同。
-
-发布门槛保持：候选CI portability → 冻结唯一tgz → macOS/Windows相同字节与各自真实业务验收 → 按授权发布既定制品并公开回读。Codex用自己的runtime/cache身份，不要求两个产品hash相同。不得继承0.6.3原生证据为0.7.0通过。双方完成之前只能声明本侧候选状态。
-
-### 6.1 新增事故：未来观察说明误变成当前工作
-
-Codex 0.13.9 在本轮修复完成答复中，将未来使用效果的限制说明当成 generic 当前待办，随后把修复指令推为持续执行要求并阻止结束。已在安装版本的隔离 `UserPromptSubmit → Stop` 入口复现；改写为稳定性观察仍触发，真实待跑测试正例也会触发。移除限制说明后可静默结束，但“未提交”还可能被误标为 external wait，说明只修一个匹配词会留下相邻错误。
-
-DSH 尚无此具体事故的本机复现，不应复制 Codex 的补词方案。将 AC05.1 作为 D070-04 的共同模型要求：未来评估/能力限制不造待办，明确真实动作才构成续跑依据；解释候选不能签发权限，真实等待有来源。默认工具边界及已有 proof/Goal/release 保护不改变。
-
-新增 A13 在纯核、生产 Session/Stop/Goal 接线、持久化恢复和四泳道真实模型路径复验。成对保留“已做完本轮任务但收益以后观察”和“本轮测试尚未跑/用户明确要求现在评估”；还要测后来的提交推送指令不会反向改变前一次 Stop。独立标注期望：误继续为零、误造已登记等待为零、真实剩余动作不漏掉；不以全部静默或全部未决过关。公共合成 fixture 由 Codex 上游维护；错误素材库记录 `CGI-20260918-codex-future-observation-stop`，仅作为事故索引，不成为公开产品依赖。
-
-## 7. 不在本次范围与停止规则
-
-不重写DSH调度/权限/会话实现，不引入额外远程模型服务，不扩张所有操作的认证适配器，不增加宿主自动化，不追求任意自然语言完备，不把缺能力的动作变成新的强制授权语法。
-
-开发计划已经选定责任分离方向；实际wire/schema/reference在P0冻结。若宿主不能提供最低普通证据路径、旧接口不能安全退役或必修release路径不可履行，记录具体阻塞和最小方案，先修对应合同而不是隐瞒降级。削减必修功能、改变权限来源或让旧资格继续控制普通任务，必须显式重开计划，不能以实现方便自行决定。
-
-本轮仅规划；规划文档按当前授权提交推送。执行实现、跨平台验收、发布和日常升级需由用户后续安排，不能把本计划当作已授权执行全部阶段的提示词。