release-skill 0.9.37 → 0.9.38

package/adapters/workbuddy/schemas/release-plan.schema.json

@@ -13,6 +13,7 @@
   ],
   "additionalProperties": false,
   "properties": {
+    "replacesPlanDigest": { "type": "string", "pattern": "^[a-f0-9]{64}$" },
     "planVersion": {
       "type": "integer",
       "enum": [

package/adapters/workbuddy/schemas/test-intake.schema.json

@@ -206,6 +206,7 @@
         "prepared": {
           "type": "object",
           "properties": {
+            "replacesPlanDigest": { "type": "string", "pattern": "^[a-f0-9]{64}$" },
             "status": false,
             "digest": false,
             "testAcceptance": false

package/adapters/workbuddy/skills/release-help/SKILL.md

@@ -7,11 +7,11 @@ description: "Discoverable entry point for release-skill: dependency and environ
 
 ## 触发
 
-用户询问 `release-skill` 用法、流程、依赖、环境、只读诊断或 `dry-run` 时使用。入口只说明能力并分诊，不执行操作。
+用户询问 `release-skill` 用法、流程、依赖、环境、只读诊断或 `dry-run` 时使用。
 
 ## 只读边界
 
-`help` 命令不联网、不检查认证、不修改文件、不生成发布计划，也不执行 Git 操作、宿主安装或外部发布写入。据环境评估准备度、建议下一步。
+`help` 命令不联网、不检查认证、不修改文件、不生成发布计划，也不执行 Git 操作、宿主安装或外部发布写入。它根据环境评估准备度，并给出下一步建议。
 
 核心流程跨平台；WorkBuddy 本机收尾仅支持 macOS。本地准备度由 Node.js ≥ 22 和 Git 决定。`npm` 与 `gh` 仅影响生产发布依赖；`pnpm` 缺失仅触发建议，不影响准备度判断。
 
@@ -19,7 +19,7 @@ description: "Discoverable entry point for release-skill: dependency and environ
 - `status: "READY"`
 - 退出码为 0
 
-通过读取 `readiness.localPreparation.status` 与 `missingRequired` 判断。生产发布另需检查 `readiness.productionPublish`：
+本地阶段是否通过，由 `readiness.localPreparation.status` 与 `missingRequired` 判断。生产发布另需检查 `readiness.productionPublish`：
 - 缺失 `npm` 或 `gh` 时为 `NOT_READY`
 - 已安装时仅为 `AUTH_CHECK_REQUIRED`，不代表认证、权限或发布授权已成立
 
@@ -29,56 +29,41 @@ description: "Discoverable entry point for release-skill: dependency and environ
 
 | 意图 | 推荐入口 | 说明 |
 |------|----------|------|
-| 了解能力、依赖或安全边界 | 保留 `release-help` | 仅提供能力说明与分诊 |
+| 了解能力、依赖或安全边界 | `release-help`（当前入口） | 仅提供能力说明与分诊 |
 | 检查接入状态 | `release-setup --assess-adoption` | `NOT_CONFIGURED` 表示首次接入，不创建配置 |
 | 分析配置、文档与发布就绪缺口 | `release-assess --offline` | 离线诊断，不运行构建或发布动作 |
 | 核对历史记录 | `release-assess`（显式提供 plan/approval/run 文件） | 仅读取用户提供的文件，不重新扫描 |
 | 读取已有证明 | `release-skill read-proof --proof-root <root> --proof <relative> --json`，只读现有文件、不扫描目标 | 三个只读入口可用 `--conclusion-output <absolute-path>` 排他输出共同证明 |
 
-诊断只运行 `release-skill` 自身只读检查，不调用目标 Skill、业务脚本、构建、hook 或发布动作。`prepare`、`verify`、`release-finish` 不作为静态治理入口。用户要求实际接入或发布时，应将已有授权带入对应原业务入口，各入口继续执行原有确认、副作用与状态机合同。
+诊断只运行 `release-skill` 自身只读检查，不调用目标 Skill、业务脚本、构建、hook 或发布动作。`prepare`、`verify`、`release-finish` 不作为静态治理入口。用户要求实际接入或发布时，应将已有授权带入对应原业务入口，各入口继续执行原有确认、副作用与状态机规则。
 
-## 0.9.37 能力与证据边界
+## 0.9.38 能力与证据边界
 
-四类工程材料由 `release-project` 字段统一管理。公开正式材料写入 `publicFiles`（含 `sourceScope` / `from` / `to` / `mode`）。运行必需资源写入 `requiredPublicFiles`，必须被同一单元的 `publicFiles[].to` 精确覆盖。
+`release-project` 的四类材料：公开正式（`publicFiles`：`sourceScope`、`from`、`to`、`mode`）、运行必需（`requiredPublicFiles`）、私有正式与非正式。公开≠正式。`requiredPublicFiles` 须被同单元的 `publicFiles[].to` 精确覆盖。私有材料由 `forbiddenPaths`、`forbiddenContentPatterns` 拦截，不进 `publicFiles`。`npm` 包由 `package.json.files`、入口闭包与映射共同限定；`delivery.include`、`delivery.exclude` 仅选宿主，不删必需资源，冲突拒绝。字段见 [配置](https://github.com/ifoohoo/release-skill/blob/release-skill-v0.9.38/references/02-project-config.md)及 `release-prepare`。
 
-私有正式材料与非正式运行材料**不列入** `publicFiles`，需通过 `forbiddenPaths` / `forbiddenContentPatterns` 阻挡。正式 ≠ 公开；是否进入公开快照由 `publicFiles` 是否列出决定。
+首次 `release-setup`：若已有配置（`ALREADY_CONFIGURED`/`CONFIG_EXISTS`），不得覆盖；合法旧字段保留。增量操作（`release-assess` / `release-config`）：先运行 `route`，仅 `config-only` 走 `prepare --workflow config`；`full-happy-end` / `mixed` 走完整流程。Foundation 0.25.0 版本精确，不因邻仓升级而变更。
 
-`npm` 是载荷渠道。`package.json` 的 `files` 字段与入口闭包、公开映射共同约束公开内容。`delivery.include` / `delivery.exclude` 仅用于选择宿主，不用于文件包含或排除。排除不得移除运行必需资源。配置冲突必须失败关闭。
+`REQUIRED_PUBLIC_FILE_MISSING`：仅 `setup --assess-adoption` 触发，按 `requiredPublicFiles` 匹配 `publicFiles[].to`，再检查仓根相对 `from` 是否存在。普通 `assess` / `verify-records` 无此码；`prepare` 原有 `PUBLIC_FILE_MISSING` / `CONFIG_INVALID`。`LICENSE_MISSING` 不能替代运行必需资源。仅禁路径类 `config-only` 增量在离线非生产 `prepare` 中可为 `PREPARED`，`workflowDecision` 为 `indeterminable` / `publish-needed`；`npm-entry-closure` / `entry_missing` 触发 `GATE_FAILED`。Foundation 建议不是发布批准。
 
-首次接入走 `release-setup`；已有 `.release-skill/project.yaml` 为 `ALREADY_CONFIGURED` / `CONFIG_EXISTS`，不覆盖。增量由 `release-assess` 诊断、`release-config` 处理。后者不是新增 CLI，须先 `route`；仅 `config-only` 执行 `prepare --workflow config`，`full-happy-end` 或混合路径走普通 full 流程，不得无条件执行。
+GitHub Git Data API `compare-and-swap` 绑定已观察分支头，远端授权不变。冻结安装 URL/ref/sha，安装后核对 name/version/载荷，门禁失败不写入。独立 checkpoint 批准；不支持回滚覆盖强推或重放旧计划。`ALREADY_CURRENT` 仍需核验。市场使用 `ifoohoo/skill-family-hub` 及 `release-skill@skill-family-hub`，旧独立市场弃用。
 
-`REQUIRED_PUBLIC_FILE_MISSING` 仅属于 `setup --assess-adoption`。接入评估按 `requiredPublicFiles` 快照目标匹配 `publicFiles[].to`，检查仓根相对 `from` 是否存在；缺失记该码。普通 `assess` 与 `verify-records` 不使用该码。`prepare` 仍使用自身原生错误，如 `PUBLIC_FILE_MISSING`、`CONFIG_INVALID`。`LICENSE_MISSING` 不能替代运行必需资源。Foundation 建议不能作为发布批准依据。
+`release-finish`：Kimi 2.2.0 变动行/无换行与 0.40.1 旧确认措辞兼容，始终核精确 ID/完整帧/唯一选中项再提交。未知歧义/未移动/不完整/timeout/EOF 拒绝。共享环境 setup 按 `unitId/plugin/version` 归并，Claude/Codex 的不同物理 `skillFile` 不会分裂 setup 归属。一个已加载宿主的精确 setup 反馈可满足共享环境，但各宿主安装加载专属配置分别核，反馈绑定 `host/unit/path/plan/config/root`。真正多插件归属仍须消歧；任一宿主失败则收尾为 `FAILED`，不改 `VERIFIED` / `DISTRIBUTED`。
 
-Hub 维持统一市场，沿用 GitHub Git Data API 的 `compare-and-swap` 写入，绑定并比较已观察分支头。该机制非本轮新增；远端授权未变，也不代表发布完成。仍须冻结安装 URL/ref/sha，安装后核对 name/version/载荷；门禁失败阻止写入。独立检查点仍须批准；不回滚、覆盖已完成步骤或强推，不重放历史冻结计划，`ALREADY_CURRENT` 仍强制执行。
+`--host-coverage <file>` / `--observe-hosts` 仍可诊断。Codex 0.154.0 对 11 份真实 Skill 的原字节静态检查不证明安装、会话选择或业务通过。批准、发布和验证状态以对应计划、批准及执行记录为准。
 
-继续采用 Foundation 0.25.0 精确依赖，不得因邻仓版本更新而升级。空白项目走 `release-setup`；已有配置保留合法字段，用 `release-assess` / `release-config` 做增量。仅禁路径一类的 `config-only` 增量，离线非生产 `prepare` 可为 `PREPARED`，`workflowDecision` 为 `indeterminable` / `publish-needed`，此为合法结果。`npm` 入口缺失时失败关闭，错误为 `GATE_FAILED` / `npm-entry-closure` / `entry_missing`。旧版独立 `release-skill` 市场已弃用，使用 `ifoohoo/skill-family-hub` 与 `release-skill@skill-family-hub`。
+Qoder 支持路径：`./adapters/qoder/skills/` 与 `./skills/`，核对 `name/version/skills`、包含性与载荷。私有 Hub 的 `RELEASE_SKILL_HUB_RELEASE_EVIDENCE` 必须由原始描述符指向已有普通文件的绝对路径，拒绝 `symlink`。交 `npm run release:check -- --release-evidence <file>` 核验。
 
-**0.9.32 历史事实**  
-Kimi 2.2.0 移除菜单移动后只重绘变动行，不重发插件标题，末行无换行。适配器须先重新观察选中项，确认唯一选中 `Remove plugin` 后才可提交。读帧前核实初始精确插件 ID；移动后重新观察并核对唯一选中项与精确 ID。未知、歧义、未移动、帧未完成、timeout、EOF 均失败关闭。确认页仍为 `Remove <displayName> (<id>)?`，含 Cancel 与 Remove plugin；已选中时无需方向键。显示名含 Confirm 或 Sure，或标题分块到达，仍核对精确身份。保留 Kimi 0.40.1 措辞 `Confirm remove plugin "<id>"?`、括号粘贴与 CSI Enter。
+冻结前 `prepare` / 新 `ship` 可重复 `--unit <id>`，默认全部；延期不进计划，不获状态。完整配置、生成物新鲜度及顶层 Hook 仍作用于全项目。`publicSourceAuthorityReceipt` 的 coordinator 与全部 subjects 必须共同选择。冻结后 `publish` / `reconcile` / `verify` / `distribute` 拒 `--unit`，只认 `plan.units`。
 
-同一 `unitId/plugin/version` 的共享环境 setup 按单元、插件、版本归并，Claude/Codex 不同物理 `skillFile` 路径不再视为多个 setup 归属。仅需一个已加载宿主的精确 setup 反馈即可满足共享环境检查要求。各宿主的安装、加载及专属配置仍需分别核实，反馈继续绑定 `host/unit/path/plan/config/root`；真正多插件归属仍需消歧，Kimi 失败或其他宿主失败均导致收尾状态为 FAILED，不改变 `VERIFIED`/`DISTRIBUTED` 发布状态。
+推荐 production ship 或转入新生产准备前核对 `testIntake`。缺失时默认推动 `skill-family-test:skill-family-test-plan` → 授权内 `skill-family-test:skill-family-test-run`。跳过须先征询，并取得本轮项目、版本、范围匹配的明确同意。沉默/拒绝/普通发布预授权/旧轮次、其他项目、版本或范围不匹配均不可跳过。本轮匹配答复可复用。不得把跳过写成测试已达标。只读路径只报告缺口。声明后仅生产 `prepare`：首次 `NEEDS_INPUT` / `exit13` 非正式候选，`--candidate` 续接才正式。候选不可 `approve` / `publish`，不能清除 `PARTIAL` / `PUBLISHED` / `VERIFIED`。轻量工作流和单元选择不免除项目级要求，未声明时原 hook 与完整门不变。非生产 `CONFIG_INVALID`；非交互 CLI 仍可选 `testIntake`，不新增选择参数。
 
-可选宿主覆盖诊断输入 `--host-coverage <file>` 与 `--observe-hosts`、Codex 0.154.0 对 11 份真实生成 Skill 的原字节静态检查能力未变。静态检查不证明安装、会话选择或业务通过；批准、发布和验证状态以对应计划、批准及执行记录为准。
-
-Qoder 本机更新路径处理维持既有能力，支持 `./adapters/qoder/skills/` 与 `./skills/` 两种布局，仍核对安装 name/version/skills、路径包含性与实际载荷。私有 Hub 的 `RELEASE_SKILL_HUB_RELEASE_EVIDENCE` 环境变量继续要求原始描述符指向的已有普通文件绝对路径（拒绝符号链接），交由 `npm run release:check -- --release-evidence <file>` 验证。
-
-在冻结前，`prepare` 或新建 `ship` 状态时可重复传入 `--unit <id>`；未传入则默认选择全部单元。延期单元不进入发布计划，亦不获得发布状态。完整配置、生成物新鲜度检查及顶层 Hook 仍作用于全项目范围。`publicSourceAuthorityReceipt` 的 coordinator 与全部 subjects 必须共同选择。
-
-推荐 production ship 或转入新生产准备前，核对 `testIntake`。缺失则说明缺项并默认推动 `skill-family-test:skill-family-test-plan`，再在授权范围内调用 `skill-family-test:skill-family-test-run`。跳过须先征询并取得本轮适用且项目、版本、范围匹配的明确同意。沉默、拒绝、普通发布预授权、旧轮次、其他项目、版本或范围不匹配均不可跳过；本轮匹配答复可复用。不得把跳过写成测试已达标。只读路径只报告缺口。已声明时仅生产 prepare 生效：首次返回 `NEEDS_INPUT` 与非正式候选（退出码 13），`prepare --candidate <path>` 续接后才有正式计划。候选不能批准或发布，也不能清除 `PARTIAL`、`PUBLISHED` 或 `VERIFIED`。未声明项目的 hook 与完整门不变。轻量工作流和单元选择不免除项目级要求。非生产 prepare 返回 `CONFIG_INVALID`。直接非交互 CLI 仍接受可选 `testIntake`，不新增选择参数。
-
-冻结后，发布流程（publish、reconcile、verify、distribute）不再接受 `--unit` 参数，仅以 `plan.units` 为唯一有效范围。
-
-每个单元必须声明 `previousPublicBaseline`：只有确认没有前序公开版本时，才使用 `none`；否则必须提供 `bound`，并包含 `repo/ref/commit` 信息。`none` 不绕过 publish 阶段的唯一性预检。
-
-Hook 缓存 v2 仅复用绝对路径，或已通过真实 cwd 核验的 cwd-relative 可执行文件身份；若依赖裸 PATH、PATHEXT、Windows 环境或观察不可用，将触发冷执行并失败关闭。稳定隔离安装树仅在宿主命令退出、目录隔离且扫描期间无并发写入时记录；附加链接仅记录，不跟随；声明载荷中出现 symlink 将导致失败关闭。
-
-版本能力不等于发布状态或真实宿主验收。
+每个单元必须声明 `previousPublicBaseline`；确认无前版为 `none`，否则为 `bound` + `repo/ref/commit`。`none` 不绕唯一性预检。Hook cache v2 仅绝对或真实 `cwd` 核验相对可执行身份复用；裸 `PATH` / `PATHEXT` / `Windows` / 观察不可用冷执行且失败关闭。隔离安装树仅宿主退出 + 隔离 + 扫描无并发才记录；附加链接记录不跟随，声明载荷 `symlink` 拒绝。
 
 ## 最短路径
 
-1. 从插件根运行 `help --json`，检查本地准备度；生产发布再检查生产准备度。  
-2. 只检查治理接入时，按上节选择 `release-setup` 或 `release-assess`，结束于范围明确的结论和下一入口。  
-3. 实际接入时进入 `release-setup`；实际发布评估使用 `release-assess`，准备发布时再进入 `prepare --offline`。  
+1. 从插件根运行 `help --json`，检查本地准备度；生产发布再检查生产准备度。 
+2. 只检查治理接入时，按上节选择 `release-setup` 或 `release-assess`，结束于范围明确的结论和下一入口。 
+3. 实际接入时进入 `release-setup`；实际发布评估使用 `release-assess`，准备发布时再进入 `prepare --offline`。 
 4. 生产发布优先使用可恢复的 `ship`；也可走 `prepare --online --production → approve → publish → verify`。
 
 ```bash
@@ -102,7 +87,7 @@ node "${CODEBUDDY_PLUGIN_ROOT}/bin/release-skill.mjs" route --root <path> --targ
 
 声明的 `postVerify` hook 可由 `postverify` 独立执行或由 `ship` 编排。计划声明该 hook 时，本机收尾必须等待完成的 postVerify run；没有声明时使用同一计划的 `VERIFIED` verify run。
 
-随后进入 `release-finish`，通过公共入口编排宿主更新、加载确认、已配置 setup 和源码分支检查：
+随后进入 `release-finish`，通过公共入口编排宿主更新、加载确认、已配置 setup 和源码分支检查。
 
 ```bash
 node "${CODEBUDDY_PLUGIN_ROOT}/bin/release-skill-local-finish.mjs" \
@@ -110,14 +95,14 @@ node "${CODEBUDDY_PLUGIN_ROOT}/bin/release-skill-local-finish.mjs" \
   --finish --json
 ```
 
-首次结果可能请求用户选择分支和本机宿主，或返回需要智能体实际加载并调用 setup 的请求。将绑定反馈写入文件后，以同一入口增加 `--finish-feedback <feedback-path>` 再次汇总。完整参数、反馈合同、宿主限制和 macOS Cursor 安装见 `release-finish`。仅有 `VERIFIED` 不构成本机写入、插件更新、分支合并或 setup 写入授权；收尾结果也不改写发布状态。
+完整参数、反馈合同、宿主限制和 macOS Cursor 安装见 `release-finish`。仅有 `VERIFIED` 不构成本机写入、插件更新、分支合并或 setup 写入授权；收尾结果也不改写发布状态。
 
 ## 专用工作流路由
 
-- 消费项目的 Cursor 场景配置、受控可执行目录、用户状态目录、结果不确定时的现场保留与复验，见 `release-verify`。  
-- README、CHANGELOG 和双语说明的 `docs refresh` 演练、摘要确认与受管写入，见 `release-docs`。  
-- VERIFIED 后的分支决定、宿主更新、加载反馈、setup 和源码检查，见 `release-finish`。  
-- 纯配置变更，见 `release-config`。  
+- 消费项目的 Cursor 场景配置、受控可执行目录、用户状态目录、结果不确定时的现场保留与复验，见 `release-verify`。 
+- README、CHANGELOG 和双语说明的 `docs refresh` 演练、摘要确认与受管写入，见 `release-docs`。 
+- VERIFIED 后的分支决定、宿主更新、加载反馈、setup 和源码检查，见 `release-finish`。 
+- 纯配置变更，见 `release-config`。 
 - 纯 marketplace 索引与快照变更，见 `release-marketplace`。
 
 这些入口保留各自的参数、确认和失败关闭规则；help 不复制或放宽它们。
@@ -137,4 +122,14 @@ node "${CODEBUDDY_PLUGIN_ROOT}/bin/release-skill-local-finish.mjs" \
 
 ## 人类最终回复
 
-纯问询或转交时短答：写明这次实际回答了什么、适用范围或转交理由、仍然有效的限制、以及下一步入口。已有 JSON 按原合同在回复中呈现。`route` 分类、推荐命令和未执行动作保持为建议。栏目只收录当前命令或分支已经返回的事实；有内容才设标题，短答直接成段。
+纯问询或转交时短答：写明这次实际回答了什么、适用范围或转交理由、仍然有效的限制、以及下一步入口。已有 JSON 按既定输出格式在回复中呈现。`route` 分类、推荐命令和未执行动作保持为建议。栏目只收录当前命令或分支已经返回的事实；有内容才设标题，短答直接成段。
+
+## 0.9.38：替代未发布计划
+
+仅生产 `testIntake` 启用：项目、发布单元ID集合、目标版本及外部目标均相同，旧计划 `PREPARED` 且从未产生发布运行权威。已有首个运行状态或 `PARTIAL`、`PUBLISHED`、`VERIFIED` 均拒绝。替代不代表发布成功或独立验收。
+
+首次 `prepare` 须显式指定 `--replace-unpublished-plan <path>`，选择本项目 `.release-skill/plans/<digest>.json` 不可变旧正式计划。首个新候选冻结前驱（旧计划），`--candidate` 续接不可后补前驱；重传不符前驱即拒绝。新候选用独立 `resultFile`，旧要求、判据、结果、计划、批准、运行全保留，由原接受方对新对象重新核收 `TEST`。
+
+新正式计划排他原子写入 `plans/<digest>.json` 才生效；写前失败无效，写后即使最新计划指针、FROZEN 标记或证据封口失败，也不得恢复旧计划发布资格，保留失败记录，沿原幂等路径核对新权威。新计划须新批准，旧批准不可跨用；`approve`、`publish`、`ship` 拒绝已替代计划。已发布或部分发布走原恢复谱系，不得以替代冒充恢复。来源提交须与远端 `main` 精确相等，`TEST`、远端冲突和批准门不变。Foundation 0.25.0 机制不变；0.9.38 入口不承诺全局撤销任意旧软件。
+
+字段、精确历史 writer 分支及失败处理见 `release-prepare`、`release-reconcile` 与[状态机](https://github.com/ifoohoo/release-skill/blob/release-skill-v0.9.38/references/01-state-machine.md)。

package/adapters/workbuddy/skills/release-prepare/SKILL.md

@@ -131,4 +131,24 @@ node "${CODEBUDDY_PLUGIN_ROOT}/bin/release-skill.mjs" prepare --root <path> --on
 
 纯问询或转交时短答：写明实际回答、适用范围或理由、必要限制和下一步。建议保持为建议。
 
-执行路径说明本轮实际阶段、发布范围、退出码和结构化结果，引用已有 `planPath`、从该计划实际字段整理的批准摘要和产物位置。保留 `NEEDS_INPUT`、`BLOCKED`、门禁失败和人工后续。仅当退出码为 0 且状态为 `PREPARED` 时，把本阶段写为计划已冻结。`PREPARED`、`PUBLISHED`、本机更新与 `VERIFIED` 按各自既有通过条件分别报告。已有计划文件按原合同呈现。栏目只收录当前命令已经返回的事实；批准摘要只转述该不可变计划中实际存在的字段。
+执行路径说明本轮实际阶段、发布范围、退出码和结构化结果，引用已有 `planPath`、从该计划实际字段整理的批准摘要和产物位置。保留 `NEEDS_INPUT`、`BLOCKED`、门禁失败和人工后续。仅当退出码为 0 且状态为 `PREPARED` 时，把本阶段写为计划已冻结。`PREPARED`、`PUBLISHED`、本机更新与 `VERIFIED` 按各自既有通过条件分别报告。已有计划文件按原合同呈现。栏目只收录当前命令已经返回的事实；批准摘要只转述该不可变计划中实际存在的字段。
+
+## 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` 源和完整运行谱系，不能将无权威诊断视为恢复输入。
+
+发布零外写诊断须独立于目标归属判断。仅当已核实 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 权威。
+
+所有未知、损坏、矛盾、不连续、封口不符或关系冲突的历史记录一律不可用。原件不得删除、搬移、补字段或重建。自引用、环、多有效后继或坏后继均不得使旧计划复活。
+
+替代操作不放宽来源提交与远端 main 的精确相等要求、`TEST` 状态、远端冲突或批准门限制。继续精确执行 Foundation 0.25.0 机制，目标归属由 Release Skill 领域责任判断，不依赖目录名、时间或错误文本推断。本轮未删除或重命名产品能力，替代仅作用于符合条件的运行计划。未发布候选或本地自测不代表发布成功，亦不构成独立验收。所有操作均基于 0.9.38 支持入口，不能撤销任意旧软件或绕过现有协议。

package/adapters/workbuddy/skills/release-publish/SKILL.md

@@ -71,4 +71,14 @@ node "${CODEBUDDY_PLUGIN_ROOT}/bin/release-skill.mjs" publish --root <path> --pl
 
 纯问询或转交时短答：写明实际回答、适用范围或理由、必要限制和下一步。建议保持为建议。
 
-执行路径说明本轮实际阶段、范围、退出码和结构化结果，引用已批准计划、approval 与 run 产物位置。保留预检阻断、`PARTIAL` 和人工后续。仅当退出码为 0 且状态为 `PUBLISHED` 时，把外写阶段写为已发布；随后仍须 `release-verify`。`PUBLISHED`、本机更新与 `VERIFIED` 按各自既有通过条件分别报告。已有 run 文件按原合同呈现。栏目只收录当前命令已经返回的事实。
+执行路径说明本轮实际阶段、范围、退出码和结构化结果，引用已批准计划、approval 与 run 产物位置。保留预检阻断、`PARTIAL` 和人工后续。仅当退出码为 0 且状态为 `PUBLISHED` 时，把外写阶段写为已发布；随后仍须 `release-verify`。`PUBLISHED`、本机更新与 `VERIFIED` 按各自既有通过条件分别报告。已有 run 文件按原合同呈现。栏目只收录当前命令已经返回的事实。
+
+## 0.9.38：替代未发布计划
+
+本功能适用于同一项目、相同发布单元ID集合、目标版本及外部目标下，旧正式计划处于 `PREPARED` 状态且未产生任何发布运行权威的场景。仅在生产环境的 `testIntake` 入口启用，用于显式替代尚未发布的正式计划。已有首个运行状态，或处于 `PARTIAL`、`PUBLISHED`、`VERIFIED` 的计划，不属于这一例外。替代不代表发布成功或独立验收。
+
+替代生效的唯一条件是：有效新正式计划成功排他原子写入原 `plans/<digest>.json`。写入前失败则不生效；写入后，即使最新计划指针、FROZEN 标记或证据封口失败，也不能恢复旧计划的可发布状态，必须保留失败记录并沿原幂等路径续接核对新权威。新批准仅绑定新计划，旧批准不可跨用。`approve`、`publish` 及其 `ship` 调用均不得继续处理已替代计划，`reconcile` 仍需具备原 `PARTIAL` 源和完整运行谱系，不能将无权威诊断视为恢复输入。
+
+操作过程复用 `.release-skill/lock` 的原锁域：`prepare` 已持锁；`approve` 的替代复核与批准写入在一次临界段内完成；`publish` 在同锁内最后复核替代关系并完成首次 `appendRunState(PUBLISHING)`，随后释放锁。新计划先提交则旧发布拒绝；旧发布先持久化首状态则替代拒绝，即使全部检查点仍为 `pending`。不得在 `ship` 外再套非重入锁，也不跨人工批准过程持锁。保证覆盖遵守协议的 0.9.38 入口，不声称限制任意旧二进制或人工绕过。
+
+替代操作不放宽来源提交与远端 main 的精确相等要求、`TEST` 状态、远端冲突或批准门限制。继续精确执行 Foundation 0.25.0 机制，目标归属由 Release Skill 领域责任判断，不依赖目录名、时间或错误文本推断。本轮未删除或重命名产品能力，替代仅作用于符合条件的运行计划。未发布候选或本地自测不代表发布成功，亦不构成独立验收。所有操作均基于 0.9.38 支持入口，不能撤销任意旧软件或绕过现有协议。

package/adapters/workbuddy/skills/release-reconcile/SKILL.md

@@ -77,3 +77,17 @@ PUBLISHED 后立即用新 `runPath` 运行 verify。VERIFIED 后发布完成。P
 纯问询或转交时短答：写明实际回答、适用范围或理由、必要限制和下一步。建议保持为建议。
 
 执行路径说明本轮实际阶段、范围、退出码和结构化结果，引用源 run、计划和命令返回的新 `runPath`。保留 `PARTIAL`、`BLOCKED`、远端冲突和人工后续。仅当退出码为 0 且状态为 `PUBLISHED` 时，把恢复写为外写检查点已齐；随后用新 `runPath` 进入 verify。`PUBLISHED` 与 `VERIFIED` 按各自既有通过条件分别报告。已有 run 文件按原合同呈现。栏目只收录当前命令已经返回的事实。
+
+## 0.9.38：替代未发布计划
+
+本功能适用于同一项目、相同发布单元ID集合、目标版本及外部目标下，旧正式计划处于 `PREPARED` 状态且未产生任何发布运行权威的场景。仅在生产环境的 `testIntake` 入口启用，用于显式替代尚未发布的正式计划。已有首个运行状态，或处于 `PARTIAL`、`PUBLISHED`、`VERIFIED` 的计划，不属于这一例外。替代不代表发布成功或独立验收。
+
+发布零外写诊断须独立于目标归属判断。仅当已核实 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 权威。
+
+所有未知、损坏、矛盾、不连续、封口不符或关系冲突的历史记录一律不可用。原件不得删除、搬移、补字段或重建。自引用、环、多有效后继或坏后继均不得使旧计划复活。
+
+替代操作不放宽来源提交与远端 main 的精确相等要求、`TEST` 状态、远端冲突或批准门限制。继续精确执行 Foundation 0.25.0 机制，目标归属由 Release Skill 领域责任判断，不依赖目录名、时间或错误文本推断。本轮未删除或重命名产品能力，替代仅作用于符合条件的运行计划。未发布候选或本地自测不代表发布成功，亦不构成独立验收。所有操作均基于 0.9.38 支持入口，不能撤销任意旧软件或绕过现有协议。

package/bin/release-skill-cli.mjs

@@ -413,6 +413,7 @@ Options:
   --answers <path> Human-reviewed setup answers JSON
   --write          Create an absent project.yaml during setup; never overwrites
   --confirm-setup <digest> Confirm exact setup facts and answers before create
+  --replace-unpublished-plan <path> Explicitly replace an unpublished immutable plan during production TEST prepare
   --discover-downstream Read-only discovery of downstream candidates (git remotes, marketplace/docs
                    clues, artifact-graph.config.yaml, foundation profile). Never writes
   --propose-hooks  Produce postPublish hook declaration drafts; with --write and exact --confirm-setup,
@@ -1366,6 +1367,8 @@ if (command === 'prepare') {
   const candidatePath = candidateIdx !== -1 && args[candidateIdx + 1] && !args[candidateIdx + 1].startsWith('--')
     ? args[candidateIdx + 1]
     : undefined;
+  const replacementIdx = args.indexOf('--replace-unpublished-plan');
+  const replaceUnpublishedPlan = replacementIdx >= 0 && args[replacementIdx + 1] && !args[replacementIdx + 1].startsWith('--') ? args[replacementIdx + 1] : undefined;
   const production = args.includes('--production') || candidatePath !== undefined;
   const workflowIdx = args.indexOf('--workflow');
   const workflow = workflowIdx !== -1 && args[workflowIdx + 1] ? args[workflowIdx + 1] : 'full';
@@ -1389,6 +1392,7 @@ if (command === 'prepare') {
   }
 
   try {
+    if (replacementIdx !== -1 && !replaceUnpublishedPlan) throw new ReleaseError(MISSING_PARAMETERS, '--replace-unpublished-plan requires a path value');
     if (candidateIdx !== -1 && !candidatePath) {
       throw new ReleaseError(MISSING_PARAMETERS, '--candidate requires a path value');
     }
@@ -1410,6 +1414,7 @@ if (command === 'prepare') {
       output,
       runDir,
       ...(candidatePath ? { candidatePath } : {}),
+      ...(replaceUnpublishedPlan ? { replaceUnpublishedPlan } : {}),
       ...(hasUnitSelection ? { unitIds } : {}),
     });