release-skill 0.9.36 → 0.9.38

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "release-skill",
-  "version": "0.9.36",
+  "version": "0.9.38",
   "description": "Safe preparation and frozen GitHub/npm production publishing with full happy end verification",
   "author": {
     "name": "广州市风荷科技有限公司"

package/.codebuddy-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "release-skill",
-  "version": "0.9.36",
+  "version": "0.9.38",
   "description": "Safe preparation and frozen GitHub/npm production publishing with full happy end verification",
   "author": {
     "name": "广州市风荷科技有限公司"

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "release-skill",
-  "version": "0.9.36",
+  "version": "0.9.38",
   "description": "Safe preparation and frozen GitHub/npm production publishing with full happy end verification",
   "author": {
     "name": "广州市风荷科技有限公司"
@@ -19,7 +19,7 @@
     ],
     "defaultPrompt": [
       "Assess this project for release readiness.",
-      "Prepare a release plan for version 0.9.36.",
+      "Prepare a release plan for version 0.9.38.",
       "Help me understand the release workflow."
     ]
   }

package/.cursor-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "release-skill",
-  "version": "0.9.36",
+  "version": "0.9.38",
   "description": "Safe preparation and frozen GitHub/npm production publishing with full happy end verification",
   "author": {
     "name": "广州市风荷科技有限公司"

package/.kimi-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "release-skill",
-  "version": "0.9.36",
+  "version": "0.9.38",
   "description": "Safe preparation and frozen GitHub/npm production publishing with full happy end verification",
   "author": {
     "name": "广州市风荷科技有限公司"

package/.qoder-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "release-skill",
-  "version": "0.9.36",
+  "version": "0.9.38",
   "description": "Safe preparation and frozen GitHub/npm production publishing with full happy end verification",
   "author": {
     "name": "广州市风荷科技有限公司"

package/CHANGELOG.md

@@ -1,5 +1,61 @@
 # Changelog
 
+<!-- release-skill:changelog:start version=0.9.38 locale=en baseline=sha256:471af07096474e6d8585e3f246e041bf94452bb9ed91019087f759079dc7d13d -->
+## [0.9.38] - 2026-10-25
+
+0.9.38 applies to the same project, identical release unit ID set, target version, and external target where the old formal plan is in `PREPARED` state and has not yet generated any release-run authority, enabled only at the `testIntake` entry in production to explicitly replace an unpublished formal plan; three Foundation dependencies remain precisely pinned at Foundation 0.25.0, with no upgrades. This note is not evidence of publication, real-host acceptance, consumer installation verification, or independent acceptance.
+
+### Security
+
+- The operation reuses the existing `.release-skill/lock` lock domain: `prepare` holds the lock; `approve`’s replacement review and approval write occur within a single critical section; `publish` performs final verification of the replacement relationship within the same lock and completes the first `appendRunState(PUBLISHING)`, then releases the lock. If the new plan is submitted first, the old release is rejected. If the old release persists its first state first, replacement is rejected—even if all checkpoints remain `pending`. Do not wrap `ship` in another instance of the non-reentrant project lock or hold that lock across manual approval. The protocol ensures coverage of the 0.9.38 entry point, without claiming to restrict arbitrary legacy binaries or manual bypasses.
+- The replacement operation does not relax the exact equality requirement between source submission and remote `main`, `TEST` state, remote conflicts, or approval gate restrictions. The Foundation 0.25.0 mechanism continues to be enforced precisely. Target assignment is determined by Release Skill domain responsibility and must not be inferred from directory names, timestamps, or error text. No product capability was removed or renamed in this round; replacement applies only to qualifying run plans. An unpublished candidate or local test does not constitute a successful release or independent acceptance. All operations are based on the 0.9.38-supported entry point and cannot revoke any legacy software or bypass existing protocols.
+- The Skill Family Hub is inherited as the unified marketplace, with updates performed via GitHub Git Data API using compare-and-swap semantics to bind observed branch head; partial releases are never rolled back or force-pushed, and completed steps are not overwritten. All behaviors are based on 0.9.38’s supported entry points, without claiming to restrict arbitrary legacy binaries or manual bypasses. This release does not claim to introduce new market mechanisms or update behaviors.
+
+### Added
+
+- The replacement operation must be explicitly specified during the first `prepare` phase using `--replace-unpublished-plan <path>`, where `<path>` must point to the immutable prior official plan in the current project’s `.release-skill/plans/<digest>.json`. This parameter accepts only plans that exactly match the current project, unit, version, and external target; it is prohibited for switching repositories, branches, npm packages, or release channels. The first saved candidate will carry an optional field `replacesPlanDigest` at the `prepared` root, with the value being the digest of the prior official plan, and will follow the original `computePlanDigest` mechanism into the object, plan, and approval binding layer. If this field is not set, the original digest and behavior logic are preserved, and no new versioning protocol is initiated for the candidate or plan version. Subsequent use of `--candidate <path>` continues from the frozen predecessor; post-facto updates are not allowed. If the selection parameter is repeated, it must match the frozen predecessor; otherwise, it is rejected.
+
+### Fixed
+
+- The sole condition for replacement to take effect is: successful exclusive atomic write of the valid new official plan into the original `plans/<digest>.json`. If the write fails before completion, the replacement does not take effect. After a successful write, even if the latest plan pointer, `FROZEN` flag, or evidence sealing fails, the prior plan’s publishable state cannot be restored. Failure records must be retained, and verification must continue along the original idempotent path. New approvals bind only to the new plan; old approvals cannot be reused across plans. The `approve`, `publish`, and their `ship` invocations must not process the replaced plan further. The `reconcile` operation must still maintain access to the original `PARTIAL` source and full run lineage; a lack of authority must not be treated as a recovery input.
+
+### Upgrade Notes
+
+Configure another, distinct fixed `resultFile` before preparing the replacement. The original requirements, criteria, results, candidates, and reference originals must remain in their original paths with their original digests for verification. New results must not overwrite old results, nor may they create circular dependencies via `subjectDigest` naming based on unformed data. If the original reference is missing or has changed, replacement is rejected; old evidence is not reconstructed from new files. Version 0.9.38 must regenerate the candidate for this version and does not waive the `writerVersion` check from 0.9.37. The original acceptor must re-evaluate applicability; byte-for-byte equivalence does not automatically pass.
+
+Release zero-external-write diagnosis must be independent of target attribution. A diagnosis may only be based on a single, complete, continuous event sequence with matching closure, full required gate sequence, and no `release-run.json`, any `state` authority, execution, or checkpoint activity—**provided** the producer version is verified as 0.9.3, 0.9.14, 0.9.17, 0.9.33, 0.9.37, or the current version 0.9.38. Under these full conditions, three failure patterns remain valid for diagnosis: source gate failure; 0.9.17 failing directly after read-only `global-preflight` arbitration; 0.9.33 failing after `approval-load` with `DIAGNOSE` and no independent `gate-failed` event. Diagnosis does not establish plan, recovery, replacement, release, or `TEST` authority. It does not infer attribution from directory structure, timestamps, error text, or non-authoritative states.
+For reconcile failures, only two prior records from writers 0.9.22 and 0.9.27 may be used to verify true target attribution, each corresponding to targets 0.22.0 and 0.25.0 respectively. The `sourceRunId` and `sourceRunDigest` must match the original parent run of the current project. The child event stream must follow the full required prefix of the verified writer. Both `source-run-load passed` and `reconcile started` must reference the same parent run, and each `actionId`/`actionType` must map to the original action in the parent plan. Only after full verification may the true target be confirmed and replacement blocking be ruled out. The failure state itself does not constitute zero-external-write, nor does it grant recovery, replacement, or `TEST` authority.
+For verify failures, only two records—0.9.7 and 0.9.12—may be used to confirm true target attribution. The sole parent reference must come from the genuine `source-run-load passed` `sourceRunId`; fabricated `sourceRunDigest` is not accepted. Only fully verified, limited prefix and suffix from the confirmed writer are allowed. Using the original parent file under the current project’s `runs` directory, reuse `loadRun`, the current plan schema, immutable plan path, full lineage, and checkpoint mapping to confirm the parent run is `PUBLISHED`. Then verify the parent plan is `foundation-adoption-review@0.1.0`, distinct from 0.28.0. Each action identity must correspond to the parent plan. Same target, incomplete parent authority, unknown stage, or conflicting relationships still result in rejection. Record 0.9.7 executed isolated consumer installation, including `execute` and local writes. It cannot be described as “zero execute” or “zero local write,” nor can it be used to grant publication external write authority. Verify failures do not constitute proof of publish zero-external-write and do not grant release, recovery, replacement, or `TEST` authority.
+All unknown, corrupted, contradictory, discontinuous, mismatched closure, or relationship-conflicting historical records are invalid. Original records must not be deleted, moved, field-filled, or reconstructed. Self-reference, cycles, multiple valid successors, or invalid successors must not revive old plans.
+
+The release-skill standalone marketplace is deprecated; use `ifoohoo/skill-family-hub` as the unified marketplace, with plugin name restricted to `release-skill@skill-family-hub`.
+<!-- release-skill:changelog:end version=0.9.38 locale=en -->
+
+
+<!-- release-skill:changelog:start version=0.9.37 locale=en baseline=sha256:11b436a4b3d6a642189df7126078f2fa2a2d3cf0922d8031d0c33cb12d9680d3 -->
+## [0.9.37] - 2026-10-23
+
+0.9.37 fixes a false verification failure caused by write-bit changes to installed files in the single-plugin path where the frozen plugin root is the project root. It also adds a TEST intake choice before a Skill starts a new production preparation. The three Foundation dependencies remain pinned to 0.25.0. This note is not evidence of publication, real-host acceptance, consumer installation verification, or independent acceptance.
+
+### Security
+
+- Remote-write authorization and release approval remain unchanged. Consent to skip TEST intake is not release approval.
+- Skill Family Hub is the unified marketplace. Updates use GitHub Git Data API and compare-and-swap against the observed branch head; partial Hub publication is never rolled back or force-pushed, and completed steps are not overwritten.
+
+### Added
+
+- Before a Skill starts a new production preparation, it checks `testIntake`. When wiring is missing, the Skill directs the project through the existing `skill-family-test:skill-family-test-plan` and `skill-family-test:skill-family-test-run` entries to organize the plan and checks and return the actual result. The original business owner judges the result; invoking TEST or skipping intake does not mean the tests passed. Skipping requires an explicit prompt followed by consent that applies to the current run and matches the project, version, and scope. Silence, refusal, general release preauthorization, and stale or mismatched consent do not qualify. A matching response for the current run may be reused.
+
+### Fixed
+
+- Only in the single-plugin path where the frozen plugin root is the project root, `verify` ignores changes to all write permission bits (`mode & ~0o222`) when comparing installed files with the frozen snapshot. The frozen snapshot retains its original modes. File content, type, size, non-write mode bits, missing or extra paths, and frozen bindings remain strictly checked.
+
+### Upgrade Notes
+
+This applies only to new Skill-led production preparation. Read-only and non-production paths, and approval, publish, reconcile, and formal verify for plans that are already frozen, gain no new TEST intake obligation. The direct non-interactive CLI continues to accept optional `testIntake`; no CLI argument, consent format, authentication, or state machine was added. Test results remain bound to the existing candidate and requirements contract. The release-skill standalone marketplace is deprecated; use `ifoohoo/skill-family-hub` and `release-skill@skill-family-hub`.
+<!-- release-skill:changelog:end version=0.9.37 locale=en -->
+
+
 <!-- release-skill:changelog:start version=0.9.36 locale=en baseline=sha256:704d09597e835404867409d99c9b8d674751ef145a9e0855d6e2182d768bb3a2 -->
 ## [0.9.36] - 2026-10-22
 

package/INSTALL.md

@@ -2,7 +2,7 @@
 
 [简体中文](INSTALL.zh-CN.md)
 
-<!-- release-skill:release-version: 0.9.36 -->
+<!-- release-skill:release-version: 0.9.38 -->
 ## Prerequisites
 
 - Node.js `>=22.22.2 <23` (22.22.2 or newer, and below 23)
@@ -125,7 +125,7 @@ tag pinned to the exact version (never the bare repository URL, which installs
 the latest release or default branch), confirm the trust prompt, then reload:
 
    ```
-   /plugins install https://github.com/ifoohoo/release-skill/releases/tag/release-skill-v0.9.36
+   /plugins install https://github.com/ifoohoo/release-skill/releases/tag/release-skill-v0.9.38
    /plugins reload
    ```
 

package/INSTALL.zh-CN.md

@@ -2,7 +2,7 @@
 
 [English](INSTALL.md)
 
-<!-- release-skill:release-version: 0.9.36 -->
+<!-- release-skill:release-version: 0.9.38 -->
 ## 前置条件
 
 - Node.js `>=22.22.2 <23`（22.22.2 及以上，且低于 23）
@@ -113,7 +113,7 @@ release-skill 当前只采用并验证 Kimi Code 的交互式 TUI 路径，**无
 （切勿使用裸仓库地址，它会安装最新 release 或默认分支），确认信任提示后重新加载：
 
    ```
-   /plugins install https://github.com/ifoohoo/release-skill/releases/tag/release-skill-v0.9.36
+   /plugins install https://github.com/ifoohoo/release-skill/releases/tag/release-skill-v0.9.38
    /plugins reload
    ```
 

package/README.md

@@ -2,7 +2,7 @@
 
 [简体中文](README.zh-CN.md) · Installation: [English](INSTALL.md) / [简体中文](INSTALL.zh-CN.md)
 
-<!-- release-skill:release-version: 0.9.36 -->
+<!-- release-skill:release-version: 0.9.38 -->
 Release preparation for Claude Code, CodeBuddy, WorkBuddy, Codex, and Kimi Code, with human-edited files kept intact.
 
 release-skill helps a maintainer answer three questions: what will be released,
@@ -13,28 +13,43 @@ it freezes the reviewed artifacts first and publishes those same artifacts later
 Setup surfaces only the deterministic `compactSummary` review view; the full
 report stays in a temporary session directory.
 
+<a id="release-terms"></a>
+
+A release unit is a release object with independently configured version, public files, and distribution targets. A release plan is a record for review before approval, linking target versions, frozen artifacts, and proposed external actions; see the [human review and approval steps](#release-plan-review).
+
 <!-- release-skill:managed:start id=latest-release -->
-**0.9.36** (2026-10-22)
+**0.9.38** (2026-10-25)
 
-0.9.36 fixes incorrect rejection of valid dual-projection plugin directories in Qoder, ensures correct validation of market sources via both URL and GitHub-based manifests, and corrects Codex entry root detection to respect manifest-declared paths instead of hardcoding `skills/`. This release note is not evidence of publication, real-host acceptance, consumer installation verification, or independent acceptance. Foundation dependencies remain pinned to 0.25.0.
+0.9.38 applies to the same project, identical release unit ID set, target version, and external target where the old formal plan is in `PREPARED` state and has not yet generated any release-run authority, enabled only at the `testIntake` entry in production to explicitly replace an unpublished formal plan; three Foundation dependencies remain precisely pinned at Foundation 0.25.0, with no upgrades. This note is not evidence of publication, real-host acceptance, consumer installation verification, or independent acceptance.
 
 **Security**
 
-- Foundation 0.25.0 remains unchanged; the source, scope, commit/digest, and full payload are preserved. The frozen snapshot is re-verified before writing, and the full payload is compared after installation. No new market, first-install, host strategy, framework, dependency, or tier has been introduced. 0.9.35 is immutable. Skill Family Hub remains the unified marketplace, using GitHub Git Data API and compare-and-swap bound to the observed branch head. Partial Hub publication is never rolled back or force-pushed; completed steps are not overwritten.
+- The operation reuses the existing `.release-skill/lock` lock domain: `prepare` holds the lock; `approve`’s replacement review and approval write occur within a single critical section; `publish` performs final verification of the replacement relationship within the same lock and completes the first `appendRunState(PUBLISHING)`, then releases the lock. If the new plan is submitted first, the old release is rejected. If the old release persists its first state first, replacement is rejected—even if all checkpoints remain `pending`. Do not wrap `ship` in another instance of the non-reentrant project lock or hold that lock across manual approval. The protocol ensures coverage of the 0.9.38 entry point, without claiming to restrict arbitrary legacy binaries or manual bypasses.
+- The replacement operation does not relax the exact equality requirement between source submission and remote `main`, `TEST` state, remote conflicts, or approval gate restrictions. The Foundation 0.25.0 mechanism continues to be enforced precisely. Target assignment is determined by Release Skill domain responsibility and must not be inferred from directory names, timestamps, or error text. No product capability was removed or renamed in this round; replacement applies only to qualifying run plans. An unpublished candidate or local test does not constitute a successful release or independent acceptance. All operations are based on the 0.9.38-supported entry point and cannot revoke any legacy software or bypass existing protocols.
+- The Skill Family Hub is inherited as the unified marketplace, with updates performed via GitHub Git Data API using compare-and-swap semantics to bind observed branch head; partial releases are never rolled back or force-pushed, and completed steps are not overwritten. All behaviors are based on 0.9.38’s supported entry points, without claiming to restrict arbitrary legacy binaries or manual bypasses. This release does not claim to introduce new market mechanisms or update behaviors.
+
+**Added**
+
+- The replacement operation must be explicitly specified during the first `prepare` phase using `--replace-unpublished-plan <path>`, where `<path>` must point to the immutable prior official plan in the current project’s `.release-skill/plans/<digest>.json`. This parameter accepts only plans that exactly match the current project, unit, version, and external target; it is prohibited for switching repositories, branches, npm packages, or release channels. The first saved candidate will carry an optional field `replacesPlanDigest` at the `prepared` root, with the value being the digest of the prior official plan, and will follow the original `computePlanDigest` mechanism into the object, plan, and approval binding layer. If this field is not set, the original digest and behavior logic are preserved, and no new versioning protocol is initiated for the candidate or plan version. Subsequent use of `--candidate <path>` continues from the frozen predecessor; post-facto updates are not allowed. If the selection parameter is repeated, it must match the frozen predecessor; otherwise, it is rejected.
 
 **Fixed**
 
-- In 0.9.35, Qoder plugins incorrectly rejected valid dual-projection directories. The `name` and `version` in `.qoder-plugin/plugin.json` and `.claude-plugin/plugin.json` must bind to the same frozen target, though individual `skills` can differ. Each present candidate must be a valid JSON object, match the target identity, have non-empty `skills`, and resolve to a real directory within the plugin root. Native takes precedence; compatibility is only used when native is missing. If any candidate is invalid, installation fails immediately without fallback. After installation, the selected path and `skills` must exactly match the frozen choice, and full payload validation is retained.
-- Qoder now also accepts existing markets that provide `.claude-plugin/marketplace.json` instead of a root `marketplace.json`. The system supports two existing locations: a URL-based `marketplace.json` at the root, and a GitHub-based `marketplace.json` in `.claude-plugin/`. At least one must exist. Each present index must be valid and contain exactly one entry for the target plugin, bound to the same frozen identity; other plugin entries remain allowed. A bad source is not ignored just because another is valid. URL sources require exact repository and SHA verification, and any explicit `version` or `ref` must match. GitHub sources require exact verification of `repo`, `ref`, `sha`, and `entry.version`. Only confirmed missing files are considered absent. Validation occurs after market refresh and before plugin update. `ALREADY_CURRENT` remains read-only with zero update commands.
-- The Codex entry root check previously hardcoded `skills/`, rejecting valid paths like `.agents/skills/` declared in the manifest. Installation pre-check and post-install observation now respect the `skills` directory declared in the plugin manifest. When the field is missing, the default `skills/` path is retained, and existing prefix behavior is preserved. Explicitly invalid, out-of-bounds, or non-directory paths are rejected without fallback. Post-install observation and full payload verification must bind to the same frozen installation contract.
+- The sole condition for replacement to take effect is: successful exclusive atomic write of the valid new official plan into the original `plans/<digest>.json`. If the write fails before completion, the replacement does not take effect. After a successful write, even if the latest plan pointer, `FROZEN` flag, or evidence sealing fails, the prior plan’s publishable state cannot be restored. Failure records must be retained, and verification must continue along the original idempotent path. New approvals bind only to the new plan; old approvals cannot be reused across plans. The `approve`, `publish`, and their `ship` invocations must not process the replaced plan further. The `reconcile` operation must still maintain access to the original `PARTIAL` source and full run lineage; a lack of authority must not be treated as a recovery input.
 
 **Upgrade Notes**
 
-The release-skill standalone marketplace is deprecated; use `ifoohoo/skill-family-hub` and the updated `release-skill@skill-family-hub`, `release-finish`, and public CLI. Unmodified plugins need not be republished. Byte changes require a new frozen plan and matching approval. Installation does not imply loading — if actual loading is not observed, the state remains `reload-pending`. Local completion failure does not alter the remote `VERIFIED` status.
+Configure another, distinct fixed `resultFile` before preparing the replacement. The original requirements, criteria, results, candidates, and reference originals must remain in their original paths with their original digests for verification. New results must not overwrite old results, nor may they create circular dependencies via `subjectDigest` naming based on unformed data. If the original reference is missing or has changed, replacement is rejected; old evidence is not reconstructed from new files. Version 0.9.38 must regenerate the candidate for this version and does not waive the `writerVersion` check from 0.9.37. The original acceptor must re-evaluate applicability; byte-for-byte equivalence does not automatically pass.
+
+Release zero-external-write diagnosis must be independent of target attribution. A diagnosis may only be based on a single, complete, continuous event sequence with matching closure, full required gate sequence, and no `release-run.json`, any `state` authority, execution, or checkpoint activity—**provided** the producer version is verified as 0.9.3, 0.9.14, 0.9.17, 0.9.33, 0.9.37, or the current version 0.9.38. Under these full conditions, three failure patterns remain valid for diagnosis: source gate failure; 0.9.17 failing directly after read-only `global-preflight` arbitration; 0.9.33 failing after `approval-load` with `DIAGNOSE` and no independent `gate-failed` event. Diagnosis does not establish plan, recovery, replacement, release, or `TEST` authority. It does not infer attribution from directory structure, timestamps, error text, or non-authoritative states.
+For reconcile failures, only two prior records from writers 0.9.22 and 0.9.27 may be used to verify true target attribution, each corresponding to targets 0.22.0 and 0.25.0 respectively. The `sourceRunId` and `sourceRunDigest` must match the original parent run of the current project. The child event stream must follow the full required prefix of the verified writer. Both `source-run-load passed` and `reconcile started` must reference the same parent run, and each `actionId`/`actionType` must map to the original action in the parent plan. Only after full verification may the true target be confirmed and replacement blocking be ruled out. The failure state itself does not constitute zero-external-write, nor does it grant recovery, replacement, or `TEST` authority.
+For verify failures, only two records—0.9.7 and 0.9.12—may be used to confirm true target attribution. The sole parent reference must come from the genuine `source-run-load passed` `sourceRunId`; fabricated `sourceRunDigest` is not accepted. Only fully verified, limited prefix and suffix from the confirmed writer are allowed. Using the original parent file under the current project’s `runs` directory, reuse `loadRun`, the current plan schema, immutable plan path, full lineage, and checkpoint mapping to confirm the parent run is `PUBLISHED`. Then verify the parent plan is `foundation-adoption-review@0.1.0`, distinct from 0.28.0. Each action identity must correspond to the parent plan. Same target, incomplete parent authority, unknown stage, or conflicting relationships still result in rejection. Record 0.9.7 executed isolated consumer installation, including `execute` and local writes. It cannot be described as “zero execute” or “zero local write,” nor can it be used to grant publication external write authority. Verify failures do not constitute proof of publish zero-external-write and do not grant release, recovery, replacement, or `TEST` authority.
+All unknown, corrupted, contradictory, discontinuous, mismatched closure, or relationship-conflicting historical records are invalid. Original records must not be deleted, moved, field-filled, or reconstructed. Self-reference, cycles, multiple valid successors, or invalid successors must not revive old plans.
+
+The release-skill standalone marketplace is deprecated; use `ifoohoo/skill-family-hub` as the unified marketplace, with plugin name restricted to `release-skill@skill-family-hub`.
 <!-- release-skill:managed:end id=latest-release -->
 
 <!-- release-skill:capability:external-write-boundary -->
-> **Current boundary:** v0.9.36: this README records capabilities and verification boundaries;
+> **Current boundary:** v0.9.38: this README records capabilities and verification boundaries;
 > it is not evidence of
 > publication, consumer-installation verification, or independent acceptance.
 > Release availability must be established from the corresponding release records
@@ -58,7 +73,7 @@ The release-skill standalone marketplace is deprecated; use `ifoohoo/skill-famil
 > publish global preflight.
 
 <!-- release-skill:capability:safe-first-command -->
-> **Production path verified since the v0.1.1 milestone; for v0.9.36,
+> **Production path verified since the v0.1.1 milestone; for v0.9.38,
 > publication, consumer-installation verification, and independent acceptance
 > require version-specific release records and verification results.**
 > The npm-installed CLI is the supported user entry. Source checkout
@@ -68,10 +83,6 @@ The release-skill standalone marketplace is deprecated; use `ifoohoo/skill-famil
 > - npm install: `npm install -g release-skill` → `release-skill help`
 > - source checkout: `node "$RELEASE_SKILL_HOME/packages/release-skill/bin/release-skill.mjs" help`
 
-<a id="release-terms"></a>
-
-A release unit is a release object with independently configured version, public files, and distribution targets. A release plan is a record for review before approval, linking target versions, frozen artifacts, and proposed external actions; see the [human review and approval steps](#release-plan-review).
-
 ### 0.8.0 scope and verification boundaries
 
 For `prepare --workflow config`, public-byte comparison selects the branch:
@@ -615,6 +626,17 @@ of the current plan digest. Replacing the result, criterion, scope, or allowed
 limitation invalidates the previous approval. Approve, publish, and reconcile
 re-check those originals before acting.
 
+When a Skill starts a new production prepare, it checks intake first. If
+intake is missing, it names the gap and default-pushes the existing wiring.
+Skip is allowed only after this-round matching explicit consent. Silence,
+refuse, generic publish preauthorization, and stale, other-project, version,
+or scope-mismatched consent do not skip. A matching this-round reply is
+reused. Skip is never described as tests already passed. Already-frozen
+approve, publish, reconcile, and verify do not gain a new intake obligation.
+Read-only, non-production, and delegated marketplace-only paths do not add
+one. Direct non-interactive CLI still accepts optional `testIntake` with no
+new choice flag.
+
 Use `release-skill post-release --finish` for the complete local finish. It
 always reports merge, host update, actual host loading, setup, and source-branch
 steps. Exit 0 means every applicable step completed or was explicitly skipped;
@@ -964,3 +986,15 @@ declaration is narrowed to concrete targets.
 ## License
 
 Apache License 2.0. See [LICENSE](LICENSE) and [NOTICE](NOTICE).
+
+## Replacing an unpublished plan (0.9.38)
+
+This feature applies to the same project, identical release unit ID set, target version, and external target, where the prior official plan is in `PREPARED` state and has not yet generated any release-run authority. It is enabled only at the production `testIntake` entry point, for explicit replacement of an unpublished official plan. Plans that already have a first run state, or are in `PARTIAL`, `PUBLISHED`, or `VERIFIED` states, are excluded from this exception. Replacement does not imply successful release or independent acceptance.
+
+Configure another, distinct fixed `resultFile` before preparing the replacement. The original requirements, criteria, results, candidates, and reference originals must remain in their original paths with their original digests for verification. New results must not overwrite old results, nor may they create circular dependencies via `subjectDigest` naming based on unformed data. If the original reference is missing or has changed, replacement is rejected; old evidence is not reconstructed from new files. Version 0.9.38 must regenerate the candidate for this version and does not waive the `writerVersion` check from 0.9.37. The original acceptor must re-evaluate applicability; byte-for-byte equivalence does not automatically pass.
+
+The replacement operation must be explicitly specified during the first `prepare` phase using `--replace-unpublished-plan <path>`, where `<path>` must point to the immutable prior official plan in the current project’s `.release-skill/plans/<digest>.json`. This parameter accepts only plans that exactly match the current project, unit, version, and external target; it is prohibited for switching repositories, branches, npm packages, or release channels. The first saved candidate will carry an optional field `replacesPlanDigest` at the `prepared` root, with the value being the digest of the prior official plan, and will follow the original `computePlanDigest` mechanism into the object, plan, and approval binding layer. If this field is not set, the original digest and behavior logic are preserved, and no new versioning protocol is initiated for the candidate or plan version. Subsequent use of `--candidate <path>` continues from the frozen predecessor; post-facto updates are not allowed. If the selection parameter is repeated, it must match the frozen predecessor; otherwise, it is rejected.
+
+The sole condition for replacement to take effect is: successful exclusive atomic write of the valid new official plan into the original `plans/<digest>.json`. If the write fails before completion, the replacement does not take effect. After a successful write, even if the latest plan pointer, `FROZEN` flag, or evidence sealing fails, the prior plan’s publishable state cannot be restored. Failure records must be retained, and verification must continue along the original idempotent path. New approvals bind only to the new plan; old approvals cannot be reused across plans. The `approve`, `publish`, and their `ship` invocations must not process the replaced plan further. The `reconcile` operation must still maintain access to the original `PARTIAL` source and full run lineage; a lack of authority must not be treated as a recovery input.
+
+The replacement operation does not relax the exact equality requirement between source submission and remote `main`, `TEST` state, remote conflicts, or approval gate restrictions. The Foundation 0.25.0 mechanism continues to be enforced precisely. Target assignment is determined by Release Skill domain responsibility and must not be inferred from directory names, timestamps, or error text. No product capability was removed or renamed in this round; replacement applies only to qualifying run plans. An unpublished candidate or local test does not constitute a successful release or independent acceptance. All operations are based on the 0.9.38-supported entry point and cannot revoke any legacy software or bypass existing protocols.

package/README.zh-CN.md

@@ -2,33 +2,51 @@
 
 [English](README.md) · 安装指南：[中文](INSTALL.zh-CN.md) / [English](INSTALL.md)
 
-<!-- release-skill:release-version: 0.9.36 -->
+<!-- release-skill:release-version: 0.9.38 -->
 面向 Claude Code、CodeBuddy、WorkBuddy、Codex 和 Kimi Code 的发布准备工具，完整保留人工维护的文件内容。
 
 release-skill 帮助维护者回答三个问题：准备发布什么、还有哪些检查未通过、最终发布的内容是什么。它不重新生成、也不回写项目源文件。`prepare` 把每个配置的公开文件复制到隔离快照并验证字节——先冻结并供人工审阅，再从同一份冻结产物发布。`setup` 只显示确定性的 `compactSummary` 审阅视图，完整报告保留在临时会话目录中。
 
+<a id="release-terms"></a>
+
+发布单元是独立配置版本、公开文件和分发目标的发布对象。发布计划是供批准前审阅的记录，将目标版本、冻结产物和拟执行的外部动作关联起来；详见[人工审阅与批准步骤](#release-plan-review)。
+
 <!-- release-skill:managed:start id=latest-release -->
-**0.9.36** (2026-10-22)
+**0.9.38** (2026-10-25)
 
-0.9.36 修复 Qoder 插件清单对合法双投影目录的误拒，确保市场来源在 URL 与 GitHub 两种路径下均正确校验，修正 Codex 入口目录检测逻辑以尊重 manifest 声明路径而非硬编码 skills/。本发布说明不代表已经发布、完成真实宿主验收、完成消费者安装验证或通过独立验收。Foundation 依赖保持精确锁定为 0.25.0。
+0.9.38 适用于同一项目、相同发布单元ID集合、目标版本及外部目标下，旧正式计划处于 `PREPARED` 状态且未产生任何发布运行权威的场景，仅在生产环境的 `testIntake` 入口启用，用于显式替代尚未发布的正式计划；三个 Foundation 依赖仍精确钉扎为 0.25.0，不升级。本发布说明不代表已经发布、完成真实宿主验收、完成消费者安装验证或通过独立验收。
 
 **安全**
 
-- Foundation 0.25.0 保持不变；Hub 来源、user-scope、冻结 commit/digest 与完整载荷校验机制保留。写入宿主前复验冻结快照摘要，安装后比较完整载荷。无新增市场、首装、新宿主策略、新框架、新依赖或 tier 变化。0.9.35 不可变。Skill Family Hub 仍为统一市场，沿用 GitHub Git Data API，以比较后写入绑定已观察的分支头；部分发布不回滚、不覆盖已完成步骤。
+- 操作过程复用 `.release-skill/lock` 的原锁域：`prepare` 已持锁；`approve` 的替代复核与批准写入在一次临界段内完成；`publish` 在同锁内最后复核替代关系并完成首次 `appendRunState(PUBLISHING)`，随后释放锁。新计划先提交则旧发布拒绝；旧发布先持久化首状态则替代拒绝，即使全部检查点仍为 `pending`。不得在 `ship` 外再套非重入锁，也不跨人工批准过程持锁。保证覆盖遵守协议的 0.9.38 入口，不声称限制任意旧二进制或人工绕过。
+- 替代操作不放宽来源提交与远端 main 的精确相等要求、`TEST` 状态、远端冲突或批准门限制。继续精确执行 Foundation 0.25.0 机制，目标归属由 Release Skill 领域责任判断，不依赖目录名、时间或错误文本推断。本轮未删除或重命名产品能力，替代仅作用于符合条件的运行计划。未发布候选或本地自测不代表发布成功，亦不构成独立验收。所有操作均基于 0.9.38 支持入口，不能撤销任意旧软件或绕过现有协议。
+- 承继 Skill Family Hub 作为统一市场，更新采用 GitHub Git Data API，以比较后写入绑定已观察分支头；部分发布不回滚、不覆盖已完成步骤，也不 force-push。所有行为均基于 0.9.38 支持入口，不能撤销任意旧软件或绕过现有协议，不宣称本次新增市场机制或更新行为。
+
+**新增**
+
+- 执行替代需在首次 `prepare` 阶段显式指定 `--replace-unpublished-plan <path>`，其中 `<path>` 必须指向当前项目 `.release-skill/plans/<digest>.json` 中的不可变旧正式计划。该参数仅接受与当前项目、单元、版本和外部目标完全一致的旧计划，禁止用于切换仓库、分支、npm包或发布渠道。首次保存的新候选将在 `prepared` 根部携带可选字段 `replacesPlanDigest`，其值为旧正式计划摘要，并沿用原 `computePlanDigest` 机制进入对象、计划与批准绑定层。若未设置该字段，则保持原有摘要与行为逻辑，候选版本及计划版本不另起协议。后续使用 `--candidate <path>` 续接，前驱已在候选中冻结，不可事后补写；若重复提供选择参数，必须与冻结前驱一致，否则拒绝。
 
 **修复**
 
-- 0.9.35 版本中，Qoder 插件误拒自身合法的双投影目录。`.qoder-plugin/plugin.json` 与 `.claude-plugin/plugin.json` 中的 name/version 必须绑定同一冻结目标，各自 skills 可不同。每个已存在候选必须是合法 JSON 对象、目标身份匹配、skills 非空且解析为插件根内真实目录。原生优先，仅原生缺失时才选兼容；任一候选无效即失败，不回退。安装后路径与 skills 必须精确匹配冻结选择，完整载荷检查保留。
-- Qoder 现可接受只提供 `.claude-plugin/marketplace.json`、未提供根 marketplace.json 的既有市场。支持两种既有位置：根 marketplace.json 的 URL 来源，以及 `.claude-plugin/marketplace.json` 的 GitHub 来源。至少一份存在，每份已存在清单均须合法，且目标插件恰有一条、绑定同一冻结身份；市场仍可包含其他插件。不因另一份有效而忽略坏清单。URL 来源保留仓库与 sha 精确校验，显式 version/ref 必须匹配；兼容 GitHub 来源校验 repo/ref/sha/entry.version。仅确定缺文件视为缺席。市场刷新后、插件更新前校验；ALREADY_CURRENT 保持只读且零更新命令。
-- Codex 入口目录原检查写死为 skills/，误拒 `.agents/skills/` 等合法 manifest 声明路径。安装前检查与安装后观察均采用 manifest 声明的 skills 目录。字段缺省时继续使用既有 skills/ 默认路径，入口名前缀行为保留。显式无效、越界或非目录路径拒绝，不回退。已安装入口观察与完整载荷验证须绑定同一冻结安装合同。
+- 替代生效的唯一条件是：有效新正式计划成功排他原子写入原 `plans/<digest>.json`。写入前失败则不生效；写入后，即使最新计划指针、FROZEN 标记或证据封口失败，也不能恢复旧计划的可发布状态，必须保留失败记录并沿原幂等路径续接核对新权威。新批准仅绑定新计划，旧批准不可跨用。`approve`、`publish` 及其 `ship` 调用均不得继续处理已替代计划，`reconcile` 仍需具备原 `PARTIAL` 源和完整运行谱系，不能将无权威诊断视为恢复输入。
 
 **升级说明**
 
-原独立的 `release-skill` 市场已弃用。使用更新后的 `release-skill@skill-family-hub` 入口、`release-finish` 与公共 CLI。未改插件无需重发，改字节须新冻结计划与匹配批准。安装 ≠ 加载，未观察实际加载则保留 reload-pending 状态。本机收尾失败不改变远端 VERIFIED 状态。统一使用 `ifoohoo/skill-family-hub` 和 `release-skill@skill-family-hub`。
+替代操作必须预先配置另一个固定 `resultFile`，保留旧要求、判据、结果、候选及引用原件在原路径、原摘要下可核验；新结果不能覆盖旧结果，也不能根据尚未形成的 `subjectDigest` 命名配置造成循环依赖。旧原件缺失或变化即拒绝，不从新文件重建旧依据。0.9.38 必须重新生成本版候选，不豁免 0.9.37 的 `writerVersion` 检查。原接受方需重新判断适用性；字节相同不自动通过。
+
+发布零外写诊断须独立于目标归属判断。仅当已核实 producer 版本为 0.9.3、0.9.14、0.9.17、0.9.33、0.9.37 或本版 0.9.38 时，且满足单一版本、完整连续事件、相符封口、完整必要前置门禁顺序，同时无 `release-run.json`、任何 `state` 权威、执行或检查点活动，方可作为零外写诊断依据。三类失败情形在满足上述完整条件时仍可作为诊断：来源门禁失败；0.9.17 在只读 `global-preflight` 仲裁后直接失败；0.9.33 在 `approval-load` 后 `DIAGNOSE` 且无独立 `gate-failed` 事件。诊断不取得计划、恢复、替代、发布或 `TEST` 权威，不基于目录结构、时间戳、错误文本或非权威状态推断归属。
+
+针对 reconcile 失败，仅核实 0.9.22 与 0.9.27 两个 writer 的两条旧记录，分别归属于 0.22.0 与 0.25.0 目标；其 `sourceRunId` 与 `sourceRunDigest` 必须与当前项目原父运行一致，子事件流须符合已审 writer 的完整必要前缀，且 `source-run-load passed` 与 `reconcile started` 必须指向同一父运行，每个 `actionId`/`actionType` 必须对应父计划原动作。仅在完整核验后，方可确认其真实目标并排除替代阻断，失败状态本身不构成零外写，也不赋予恢复、替代或 TEST 权威。
+
+针对 verify 失败，仅 0.9.7 与 0.9.12 两条记录可被用于核实真实目标归属，其唯一父引用取自真实 `source-run-load passed` 的 `sourceRunId`，不接受补造 `sourceRunDigest`，仅接受已核实 writer 的完整有限前后缀。通过当前项目原 `runs` 内父文件，复用 `loadRun`、现行计划 Schema、不可变计划路径、完整谱系与检查点映射，确认父运行 `PUBLISHED`，再根据父计划核实其为 `foundation-adoption-review@0.1.0`，与 0.28.0 不同。每个动作身份必须对应父计划；同目标、不完整父权威、未知阶段、关系冲突或矛盾仍拒。其中 0.9.7 实际执行过隔离消费者安装，包含 `execute` 及本地写入，不能声称“零 execute”或“零本地写入”，亦不得由此授予发布外写权限。verify 失败不构成 publish 零外写证明，不赋予发布、恢复、替代或 TEST 权威。
+
+所有未知、损坏、矛盾、不连续、封口不符或关系冲突的历史记录一律不可用。原件不得删除、搬移、补字段或重建。自引用、环、多有效后继或坏后继均不得使旧计划复活。
+
+原独立的 `release-skill` 市场已弃用，使用 `ifoohoo/skill-family-hub` 作为统一市场，插件名限定为 `release-skill@skill-family-hub`。
 <!-- release-skill:managed:end id=latest-release -->
 
 <!-- release-skill:capability:external-write-boundary -->
-> **当前边界：** v0.9.36 的能力范围与验证边界见本 README，
+> **当前边界：** v0.9.38 的能力范围与验证边界见本 README，
 > 不代表已经发布、完成消费者安装验证或通过独立验收。
 > 版本可用性以对应发布记录及发布后验证结果为准。
 > v0.4.1 是更早的已发布里程碑（v0.2.2 曾处于已发布状态，后因平台验证收敛修复而更新）。
@@ -44,17 +62,13 @@ release-skill 帮助维护者回答三个问题：准备发布什么、还有哪
 > 远端唯一性检查在 `publish` 全局预检执行。
 
 <!-- release-skill:capability:safe-first-command -->
-> **生产路径自 v0.1.1 里程碑起已完成真实生产验证；v0.9.36 的发布、消费者安装验证和独立验收状态须由该版本的发布记录及验证结果确认。**
+> **生产路径自 v0.1.1 里程碑起已完成真实生产验证；v0.9.38 的发布、消费者安装验证和独立验收状态须由该版本的发布记录及验证结果确认。**
 > npm 安装的 CLI 是受支持的用户入口；源码 checkout 保留为开发/贡献者路径。
 >
 > **第一条命令：**
 > - npm 安装：`npm install -g release-skill` → `release-skill help`
 > - 源码 checkout：`node "$RELEASE_SKILL_HOME/packages/release-skill/bin/release-skill.mjs" help`
 
-<a id="release-terms"></a>
-
-发布单元是独立配置版本、公开文件和分发目标的发布对象。发布计划是供批准前审阅的记录，将目标版本、冻结产物和拟执行的外部动作关联起来；详见[人工审阅与批准步骤](#release-plan-review)。
-
 ### 0.8.0 范围与验证边界
 
 `prepare --workflow config` 按公开字节是否变化分支：
@@ -504,6 +518,8 @@ release-finish 在 `--root` 指定的当前发布项目根目录调用该入口
 
 可选的 `testIntake` 只声明要求文件和结果文件，并且只在生产 prepare 中生效。首次生产 prepare 保存一份非正式候选，返回 `NEEDS_INPUT`（`GATE_FAILED`，退出码 13），并给出 `candidatePath`、`candidateSha256` 和 `subjectDigest`，此时不写正式计划。用 `prepare --candidate <path>` 续接同一候选；适用的冻结前要求通过后才写入正式计划和 `PREPARED`。候选不能用于批准或发布，也不能清除 `PARTIAL`、`PUBLISHED` 或 `VERIFIED`。未声明 `testIntake` 的项目保持原有 hook、完整门和发布路径。docs、config、marketplace 工作流、单元选择和无需发布的配置都不免除项目级要求。非生产 prepare 拒绝 `testIntake`，错误码为 `CONFIG_INVALID`。可选的 `testAcceptance` 进入当前计划摘要。替换结果、准则、范围或允许的限制会使原批准失效。approve、publish 和 reconcile 在动作前复核这些原件。
 
+由 Skill 发起的新一轮生产准备先核对接入。缺失则说明缺项并默认推动现有接线；仅本轮适用且范围匹配的明确同意可跳过。沉默、拒绝、仅普通发布预授权、旧轮次、其他项目、版本或范围不匹配均不可跳过；本轮匹配答复可复用。不得把跳过写成测试已达标。已冻结计划的批准、发布、对账与正式验证不回头追加接入义务。只读、非生产及 marketplace-only 委托发布不新增接入义务。直接非交互 CLI 仍接受可选 `testIntake`，不新增选择参数。
+
 完整的本地收尾使用 `release-skill post-release --finish`。命令固定报告分支决定、宿主更新、实际加载、setup 和源码分支检查：全部适用步骤完成或明确跳过时退出 0，仍有待办时退出 2，确定失败时退出 1。智能体通过绝对路径的 `--finish-feedback` JSON 文件回传观察，文件必须绑定当前计划摘要、配置摘要和规范项目根目录。反馈只作为数据：脚本不执行其中字符串，也不把反馈当成新的写入授权。`--skip-local-hosts` 显示跳过宿主更新、加载和 setup，不得与 `--hosts` 或 `--update-local-hosts` 同时使用。
 
 `distributions` 是必填字段，但可以显式设为空数组。使用
@@ -782,3 +798,15 @@ GitHub Release 和受控终端交互，保留三个代理变量；只有仓库 U
 ## 许可证
 
 Apache License 2.0，见 [LICENSE](LICENSE) 与 [NOTICE](NOTICE)。
+
+## 0.9.38：替代未发布计划
+
+本功能适用于同一项目、相同发布单元ID集合、目标版本及外部目标下，旧正式计划处于 `PREPARED` 状态且未产生任何发布运行权威的场景。仅在生产环境的 `testIntake` 入口启用，用于显式替代尚未发布的正式计划。已有首个运行状态，或处于 `PARTIAL`、`PUBLISHED`、`VERIFIED` 的计划，不属于这一例外。替代不代表发布成功或独立验收。
+
+替代操作必须预先配置另一个固定 `resultFile`，保留旧要求、判据、结果、候选及引用原件在原路径、原摘要下可核验；新结果不能覆盖旧结果，也不能根据尚未形成的 `subjectDigest` 命名配置造成循环依赖。旧原件缺失或变化即拒绝，不从新文件重建旧依据。0.9.38 必须重新生成本版候选，不豁免 0.9.37 的 `writerVersion` 检查。原接受方需重新判断适用性；字节相同不自动通过。
+
+执行替代需在首次 `prepare` 阶段显式指定 `--replace-unpublished-plan <path>`，其中 `<path>` 必须指向当前项目 `.release-skill/plans/<digest>.json` 中的不可变旧正式计划。该参数仅接受与当前项目、单元、版本和外部目标完全一致的旧计划，禁止用于切换仓库、分支、npm包或发布渠道。首次保存的新候选将在 `prepared` 根部携带可选字段 `replacesPlanDigest`，其值为旧正式计划摘要，并沿用原 `computePlanDigest` 机制进入对象、计划与批准绑定层。若未设置该字段，则保持原有摘要与行为逻辑，候选版本及计划版本不另起协议。后续使用 `--candidate <path>` 续接，前驱已在候选中冻结，不可事后补写；若重复提供选择参数，必须与冻结前驱一致，否则拒绝。
+
+替代生效的唯一条件是：有效新正式计划成功排他原子写入原 `plans/<digest>.json`。写入前失败则不生效；写入后，即使最新计划指针、FROZEN 标记或证据封口失败，也不能恢复旧计划的可发布状态，必须保留失败记录并沿原幂等路径续接核对新权威。新批准仅绑定新计划，旧批准不可跨用。`approve`、`publish` 及其 `ship` 调用均不得继续处理已替代计划，`reconcile` 仍需具备原 `PARTIAL` 源和完整运行谱系，不能将无权威诊断视为恢复输入。
+
+替代操作不放宽来源提交与远端 main 的精确相等要求、`TEST` 状态、远端冲突或批准门限制。继续精确执行 Foundation 0.25.0 机制，目标归属由 Release Skill 领域责任判断，不依赖目录名、时间或错误文本推断。本轮未删除或重命名产品能力，替代仅作用于符合条件的运行计划。未发布候选或本地自测不代表发布成功，亦不构成独立验收。所有操作均基于 0.9.38 支持入口，不能撤销任意旧软件或绕过现有协议。

package/adapters/claude/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "release-skill",
-  "version": "0.9.36",
+  "version": "0.9.38",
   "description": "Safe preparation and frozen GitHub/npm production publishing with full happy end verification",
   "author": {
     "name": "广州市风荷科技有限公司"