release-skill 0.9.37 → 0.10.0

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "release-skill",
-  "version": "0.9.37",
+  "version": "0.10.0",
   "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.37",
+  "version": "0.10.0",
   "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.37",
+  "version": "0.10.0",
   "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.37.",
+      "Prepare a release plan for version 0.10.0.",
       "Help me understand the release workflow."
     ]
   }

package/.cursor-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "release-skill",
-  "version": "0.9.37",
+  "version": "0.10.0",
   "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.37",
+  "version": "0.10.0",
   "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.37",
+  "version": "0.10.0",
   "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.10.0 locale=en baseline=sha256:dfff93ef727de178ff140fc2de189fdab65205a99cc4c5734bc8c9889ef28e54 -->
+## [0.10.0] - 2026-10-26
+
+0.10.0 enables explicit testing provider selection via Agent Method Registry 0.2.0 on codex and claude-code, while maintaining TEST 0.2.0 as the default testing Skill family. Foundation dependencies remain pinned to 0.25.0. This description is not evidence of publication, real-host acceptance, consumer installation verification, or independent acceptance.
+
+### Security
+
+- Method selection does not alter result contracts, domain acceptance, business permissions, or release approval. Foundation dependencies remain pinned to 0.25.0. Full release gates, channel checks, and host verification remain separate requirements; these notes do not confirm their completion. The inherited Skill Family Hub remains the unified marketplace. Binding to observed branch heads is achieved via GitHub Git Data API and compare-and-swap (CAS). Partial publication is never rolled back or force-pushed.
+
+### Added
+
+- The preparation Skill resolves and verifies a single testing provider for testing/skill-family/plan and run using existing source selection and v1 overlay. Project Skills and explicitly selected external catalogs are supported on codex and claude-code; other hosts retain their original path. Disabled, missing, ambiguous, or invalid providers halt dependent calls without fallback or waiver of testIntake obligations.
+
+### Fixed
+
+- Candidate acceptance now compares both unit.id and targetVersion. Conflicts no longer occur between different units sharing the same version; acceptance remains denied for the same unit and version with differing acceptance bases, including partial overlaps in multi-unit plans. Existing checks for authority, history, replacement, and writer remain unchanged.
+- When no frozen host targets are present, a plugin-qualified setup is skipped only if the current configuration has exactly one matching localHostUpdate.plugin owner and that unit is not selected. Unknown or ambiguous ownership, unqualified setups, or selected owners remain pending; selected hosts require actual loading and setup feedback.
+
+### Upgrade Notes
+
+Upgrading from writer version 0.9.38 to 0.10.0 requires a fresh prepare, candidate generation, and result file creation. Preserve all prior candidates, results, approvals, and run records; do not modify writerVersion. The documented local-checkout CLI is a development entry point and does not indicate that 0.10.0 is published or loaded by a host. The release-skill standalone marketplace is deprecated; use ifoohoo/skill-family-hub with plugin id release-skill@skill-family-hub instead.
+<!-- release-skill:changelog:end version=0.10.0 locale=en -->
+
+
+<!-- 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
 

package/INSTALL.md

@@ -2,7 +2,7 @@
 
 [简体中文](INSTALL.zh-CN.md)
 
-<!-- release-skill:release-version: 0.9.37 -->
+<!-- release-skill:release-version: 0.10.0 -->
 ## 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.37
+   /plugins install https://github.com/ifoohoo/release-skill/releases/tag/release-skill-v0.10.0
    /plugins reload
    ```
 

package/INSTALL.zh-CN.md

@@ -2,7 +2,7 @@
 
 [English](INSTALL.md)
 
-<!-- release-skill:release-version: 0.9.37 -->
+<!-- release-skill:release-version: 0.10.0 -->
 ## 前置条件
 
 - 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.37
+   /plugins install https://github.com/ifoohoo/release-skill/releases/tag/release-skill-v0.10.0
    /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.37 -->
+<!-- release-skill:release-version: 0.10.0 -->
 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,31 +13,35 @@ 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.37** (2026-10-23)
+**0.10.0** (2026-10-26)
 
-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.
+0.10.0 enables explicit testing provider selection via Agent Method Registry 0.2.0 on codex and claude-code, while maintaining TEST 0.2.0 as the default testing Skill family. Foundation dependencies remain pinned to 0.25.0. This description 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.
+- Method selection does not alter result contracts, domain acceptance, business permissions, or release approval. Foundation dependencies remain pinned to 0.25.0. Full release gates, channel checks, and host verification remain separate requirements; these notes do not confirm their completion. The inherited Skill Family Hub remains the unified marketplace. Binding to observed branch heads is achieved via GitHub Git Data API and compare-and-swap (CAS). Partial publication is never rolled back or force-pushed.
 
 **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.
+- The preparation Skill resolves and verifies a single testing provider for testing/skill-family/plan and run using existing source selection and v1 overlay. Project Skills and explicitly selected external catalogs are supported on codex and claude-code; other hosts retain their original path. Disabled, missing, ambiguous, or invalid providers halt dependent calls without fallback or waiver of testIntake obligations.
 
 **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.
+- Candidate acceptance now compares both unit.id and targetVersion. Conflicts no longer occur between different units sharing the same version; acceptance remains denied for the same unit and version with differing acceptance bases, including partial overlaps in multi-unit plans. Existing checks for authority, history, replacement, and writer remain unchanged.
+- When no frozen host targets are present, a plugin-qualified setup is skipped only if the current configuration has exactly one matching localHostUpdate.plugin owner and that unit is not selected. Unknown or ambiguous ownership, unqualified setups, or selected owners remain pending; selected hosts require actual loading and setup feedback.
 
 **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`.
+Upgrading from writer version 0.9.38 to 0.10.0 requires a fresh prepare, candidate generation, and result file creation. Preserve all prior candidates, results, approvals, and run records; do not modify writerVersion. The documented local-checkout CLI is a development entry point and does not indicate that 0.10.0 is published or loaded by a host. The release-skill standalone marketplace is deprecated; use ifoohoo/skill-family-hub with plugin id release-skill@skill-family-hub instead.
 <!-- release-skill:managed:end id=latest-release -->
 
 <!-- release-skill:capability:external-write-boundary -->
-> **Current boundary:** v0.9.37: this README records capabilities and verification boundaries;
+> **Current boundary:** v0.10.0: 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
@@ -61,7 +65,7 @@ This applies only to new Skill-led production preparation. Read-only and non-pro
 > publish global preflight.
 
 <!-- release-skill:capability:safe-first-command -->
-> **Production path verified since the v0.1.1 milestone; for v0.9.37,
+> **Production path verified since the v0.1.1 milestone; for v0.10.0,
 > 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
@@ -71,10 +75,6 @@ This applies only to new Skill-led production preparation. Read-only and non-pro
 > - 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:
@@ -978,3 +978,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,36 +2,40 @@
 
 [English](README.md) · 安装指南：[中文](INSTALL.zh-CN.md) / [English](INSTALL.md)
 
-<!-- release-skill:release-version: 0.9.37 -->
+<!-- release-skill:release-version: 0.10.0 -->
 面向 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.37** (2026-10-23)
+**0.10.0** (2026-10-26)
 
-0.9.37 修复单插件发布单元在冻结插件根为项目根目录时，安装文件写权限变化造成的验证误报，并在 Skill 发起新一轮生产准备前加入 TEST 接入选择。三个 Foundation 依赖均精确锁定为 0.25.0。本发布说明不代表已经发布、完成真实宿主验收、完成消费者安装验证或通过独立验收。
+0.10.0 的发布准备支持在 codex 和 claude-code 上通过 Agent Method Registry 0.2.0 显式选择测试提供方，同时保留 TEST 0.2.0 作为默认测试技能族。Foundation 依赖仍严格锁定在 0.25.0。本版本不代表已经发布、完成真实宿主验收、完成消费者安装验证或通过独立验收。
 
 **安全**
 
-- 远端写入授权和发布批准保持不变。同意跳过 TEST 接入不等于发布批准。
-- Skill Family Hub 是统一市场，更新采用 GitHub Git Data API，并以比较后写入绑定已观察的分支头；部分发布不回滚、不覆盖已完成步骤，也不 force-push。
+- 方法选择不影响结果合同、领域接受方、业务权限或发布批准。Foundation 依赖仍严格锁定在 0.25.0。完整的发布门禁、渠道检查与宿主验证仍为独立要求；本说明不证明其已达成。继续使用 Skill Family Hub 作为统一市场。通过 GitHub Git Data API 与比较后写入（compare-and-swap）绑定已观察分支头。部分发布不回滚、不覆盖。
 
 **新增**
 
-- Skill 启动新一轮生产准备前会核对 `testIntake`。缺少接线时，Skill 会引导项目通过现有的 `skill-family-test:skill-family-test-plan` 和 `skill-family-test:skill-family-test-run` 入口组织方案与检查，并交回实际结果。结果仍由原业务职责方判读；调用 TEST 或跳过接入都不表示测试已通过。跳过前必须明确征询，并取得适用于本轮且与项目、版本、范围匹配的同意。沉默、拒绝、一般发布预授权及过期或不匹配的同意都不能作为跳过依据；本轮匹配的答复可以复用。
+- 准备技能通过现有来源选择与 v1 overlay，针对 testing/skill-family/plan 和 run 解析并验证单一测试提供方。codex 和 claude-code 支持项目自有技能及显式指定的外部 catalog；其他宿主维持原有路径。提供方被禁用、缺失、存在歧义或无效时，将终止依赖调用，不触发回退机制，也不豁免 testIntake 义务。
 
 **修复**
 
-- 仅在单插件发布单元且冻结插件根为项目根目录的验证路径中，`verify` 比较已安装文件与冻结快照时忽略所有写权限位（`mode & ~0o222`）。冻结快照保留原始权限；文件内容、类型、大小、非写权限位、缺失或新增路径及冻结绑定仍严格检查。
+- 候选接受逻辑现同时比对 unit.id 与 targetVersion。不同单元使用相同版本不再引发冲突；同一单元与版本但接受依据不同，包括多单元计划中仅部分目标重叠的情况，仍被拒绝。原有权威性、历史记录、替代关系及 writer 检查规则保持不变。
+- 当无冻结宿主目标时，仅当当前配置恰好存在一个匹配的 localHostUpdate.plugin 所属单元，且该单元未被选中，才跳过带插件前缀的 setup。归属未知或模糊、未限定插件前缀、或所属单元已被选中时，仍保持待处理状态；已选宿主仍需完成实际加载并返回 setup 反馈。
 
 **升级说明**
 
-本项只适用于由 Skill 开始的新一轮生产准备。只读、非生产路径，以及已有冻结计划的批准、发布、对账和正式验证不新增 TEST 接入义务。直接非交互 CLI 仍接受可选 `testIntake`；本版本未增加 CLI 参数、同意格式、认证或状态机。测试结果继续按既有合同绑定候选与要求。原独立的 `release-skill` 市场已弃用，请使用 `ifoohoo/skill-family-hub` 和 `release-skill@skill-family-hub`。
+从 0.9.38 升级至 0.10.0 工具版本时，需重新执行 prepare、生成新候选并创建新的结果文件。请保留所有原有候选、结果、批准记录与运行日志，不得修改 writerVersion。文档中提及的本地源码 CLI 仅为开发用途入口，不代表 0.10.0 已发布或被宿主加载。原独立的 `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.37 的能力范围与验证边界见本 README，
+> **当前边界：** v0.10.0 的能力范围与验证边界见本 README，
 > 不代表已经发布、完成消费者安装验证或通过独立验收。
 > 版本可用性以对应发布记录及发布后验证结果为准。
 > v0.4.1 是更早的已发布里程碑（v0.2.2 曾处于已发布状态，后因平台验证收敛修复而更新）。
@@ -47,17 +51,13 @@ release-skill 帮助维护者回答三个问题：准备发布什么、还有哪
 > 远端唯一性检查在 `publish` 全局预检执行。
 
 <!-- release-skill:capability:safe-first-command -->
-> **生产路径自 v0.1.1 里程碑起已完成真实生产验证；v0.9.37 的发布、消费者安装验证和独立验收状态须由该版本的发布记录及验证结果确认。**
+> **生产路径自 v0.1.1 里程碑起已完成真实生产验证；v0.10.0 的发布、消费者安装验证和独立验收状态须由该版本的发布记录及验证结果确认。**
 > 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` 按公开字节是否变化分支：
@@ -787,3 +787,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.37",
+  "version": "0.10.0",
   "description": "Safe preparation and frozen GitHub/npm production publishing with full happy end verification",
   "author": {
     "name": "广州市风荷科技有限公司"