dsh-completion-guard 0.8.2 → 0.8.3

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.3: DSH >=0.2.0-rc.2 and official Desktop
+
+0.8.3 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.
 
@@ -22,7 +24,9 @@ The lock binds the canonical archive, signed header, runtime manifest and metada
 
 `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.3 中文说明
+
+0.8.3 保留 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`。
 
@@ -62,7 +66,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 +192,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.3 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.3 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.3 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.3.
 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.3`. 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
@@ -154,7 +154,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.3.
 
 ## 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.3 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.3",
   "description": "A task-contract and completion-certification layer for DeepSeek Harness.",
   "repository": {
     "type": "git",
@@ -118,5 +118,5 @@
     "hooks",
     "typescript"
   ],
-  "gitHead": "913a4c7a6f0f600f4146ef4af694d3af6e477ef2"
+  "gitHead": "146bc1d1c5ad6e273305e50b53d9f1750bcc7a87"
 }

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路径不可履行，记录具体阻塞和最小方案，先修对应合同而不是隐瞒降级。削减必修功能、改变权限来源或让旧资格继续控制普通任务，必须显式重开计划，不能以实现方便自行决定。
-
-本轮仅规划；规划文档按当前授权提交推送。执行实现、跨平台验收、发布和日常升级需由用户后续安排，不能把本计划当作已授权执行全部阶段的提示词。