release-skill 0.9.36 → 0.9.38

package/package.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/platform-manifest.json

@@ -2,11 +2,11 @@
   "schemaVersion": "1.0.0",
   "platformId": "release-skill",
   "platformName": "release-skill Plugin Platform",
-  "version": "0.9.36",
+  "version": "0.9.38",
   "logicalRoot": "skills-src/",
-  "logicalRootDigest": "7ea5732a23d0b214990070bb6d3d9201cb5881f29efcfb2cbe4af5dd54531272",
-  "projectionDigest": "1e2ae0eeb42be53db44d4e1de02aea4034a68f6aa530afc681a53f24bd4c4622",
-  "projectionId": "release-skill:platform:0.9.36",
+  "logicalRootDigest": "fc2e36145209d9b7dc06a3b0f2d3ea2f371e78bd9607be3df565943b78cccf53",
+  "projectionDigest": "efb8af2d347940dd7547c5d485b81d09c68d256f8333512d17984107acf6a3a5",
+  "projectionId": "release-skill:platform:0.9.38",
   "manifestRequired": true,
   "projectionSources": {
     "skills-src-root": {

package/references/01-state-machine.md

@@ -217,3 +217,29 @@ plan、approval、冻结制品身份、远端状态、检查点和 `PARTIAL` 血
 - 错误码与证据格式见 `05-evidence-and-errors.md`。
 - Adapter 的 preflight/execute/observe/verify 接口和授权门见 `06-adapter-contract.md`。
 - 发布计划冻结和批准界面内容要求见本文档第 4.4 节和 `06-adapter-contract.md` 第 3 节。
+
+## 0.9.38：替代未发布计划
+
+本功能适用于同一项目、相同发布单元ID集合、目标版本及外部目标下，旧正式计划处于 `PREPARED` 状态且未产生任何发布运行权威的场景。仅在生产环境的 `testIntake` 入口启用，用于显式替代尚未发布的正式计划。已有首个运行状态，或处于 `PARTIAL`、`PUBLISHED`、`VERIFIED` 的计划，不属于这一例外。替代不代表发布成功或独立验收。
+
+替代生效的唯一条件是：有效新正式计划成功排他原子写入原 `plans/<digest>.json`。写入前失败则不生效；写入后，即使最新计划指针、FROZEN 标记或证据封口失败，也不能恢复旧计划的可发布状态，必须保留失败记录并沿原幂等路径续接核对新权威。新批准仅绑定新计划，旧批准不可跨用。`approve`、`publish` 及其 `ship` 调用均不得继续处理已替代计划，`reconcile` 仍需具备原 `PARTIAL` 源和完整运行谱系，不能将无权威诊断视为恢复输入。
+
+读取方仍严格读取和解析正式目录全部 `.json` 文件；顶层必须是对象，`units` 非空，每项 `id` 与 `targetVersion` 有效非空，单元 ID 不得重复，目标信息不得冲突。文件名、`plan.digest` 与原 `computePlanDigest` 必须相符；任何读取、解析、权威路径或摘要问题均导致失败关闭。不得以非 production 为由跳过文件名绑定。
+
+当前选定计划、前驱、本次目标相关计划，任何实际存在 `testAcceptance` 或 `replacesPlanDigest` 字段的记录，以及被关系引用的前驱，均须使用原 `validatePlan` 进行当前 Schema 完整核验。字段值为 `null`、空串、`false`、错类型均不能降级。任一完整目标版本集合与当前集合有交集，即为本次目标相关，不能仅因完整 `targetIdentity` 不同就豁免。
+
+仅当完整明确目标版本集合与当前目标无交集、既无上述两字段、又未被关系引用的旧记录，方可保留原只读历史及目标排除角色；不认证其历史 Schema 合法性，也不授予接受、替代或发布权威。缺目标、坏项、重复、显式目标字段冲突均不能判为无关。
+
+现有正式关系全边覆盖前驱和连续后继；端点缺失、自引用、环、同一前驱多有效后继、跨目标边、损坏后继或权威冲突均失败关闭，不丢坏边让旧计划复活，不建第二份登记表。普通候选查询、无替代参数续接也应保持面对无关旧记录时原可用行为，并保留接受依据冲突/重复判断；不能因当前旧计划自身没有 `replacesPlanDigest` 就跳过后继检查；仅按 `subjectDigest` 查询时，无 TEST 且无关系的旧记录不能成为接受命中。
+
+操作过程复用 `.release-skill/lock` 的原锁域：`prepare` 已持锁；`approve` 的替代复核与批准写入在一次临界段内完成；`publish` 在同锁内最后复核替代关系并完成首次 `appendRunState(PUBLISHING)`，随后释放锁。新计划先提交则旧发布拒绝；旧发布先持久化首状态则替代拒绝，即使全部检查点仍为 `pending`。不得在 `ship` 外再套非重入锁，也不跨人工批准过程持锁。保证覆盖遵守协议的 0.9.38 入口，不声称限制任意旧二进制或人工绕过。
+
+目标归属与发布零外写证明分别判断。有效计划、运行摘要与完整父谱系决定目标；未绑定 `publish` 失败只有满足下述完整条件，才可作为零外写诊断。诊断不取得计划、恢复、替代、发布或 `TEST` 权威。任何基于目录结构、时间戳、错误文本或非权威状态推断归属的行为均被拒绝。未知 producer、混合 producer、缺失、损坏、矛盾、不连续或封口不符的历史记录一律不可用。所有原件均保留，不删除、搬走、补字段或重建。
+
+针对 publish 零外写诊断，仅接受已核实 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` 事件。历史诊断均基于精确已发布源码与原件核实，保留现有 `route` 证明函数的可复用部分，不构建通用解析器、版本兼容框架或平行判定标准。本版 0.9.38 须直接验证相应写序。
+
+针对 reconcile 失败，两条旧记录分别对应 0.22.0 与 0.25.0，仅用于核实其真实绑定目标后，从当前 0.28.0 替代的阻挡记录中排除。沿用已有 `sourceRunId`/`sourceRunDigest`、当前项目原父运行与完整父权威核验，子事件流必须符合已审 writer 的完整必要前缀；`source-run-load passed` 与 `reconcile started` 必须指向同一父运行。每个 `actionId`/`actionType` 必须对应父计划原动作。仅在完整核验后，方可确认其真实目标归属并排除替代阻断，失败状态本身不构成零外写，也不赋予恢复、替代或 TEST 权威。
+
+针对 verify 失败，两条旧记录分别来自 0.9.7 与 0.9.12；核实属于其他目标后，才可从当前替代的阻挡记录中排除。仅接受这两个已核实 writer 的完整必要前缀与后续有限形状。唯一父引用取自真实 `source-run-load passed` 的 `sourceRunId`；这两个失败 writer 不写 `sourceRunDigest`，不可补造，也拒绝其不会写出的字段。通过当前项目原 `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/references/02-project-config.md

@@ -124,19 +124,100 @@ policy:                     # 可选，安全策略
 
 ### 2.0 显式测试接入
 
-`testIntake` 可选。只含两个项目相对普通文件路径：`requirementsFile` 与 `resultFile`。两者归一化后必须不同；`a/./b` 与 `a/b` 视为同一路径。未知字段、绝对路径、`..` 和结尾斜杠在配置加载时拒绝。
+`testIntake` 为可选配置项，仅包含两个项目相对普通文件路径字段：`requirementsFile` 与 `resultFile`。路径经归一化后必须互异；`a/./b` 与 `a/b` 视为同一路径。配置加载时拒绝以下内容：
+- 未知字段；
+- 绝对路径；
+- 包含 `..` 路径组件的路径；
+- 以斜杠结尾的路径。
 
-未声明 `testIntake` 的项目保持原有 hook、完整门、缓存和发布路径，不因此增加 TEST、Graph 或 Registry 依赖。`--test-selection incremental` 仍在冻结时拒绝。
+未声明 `testIntake` 的项目维持原有 hook 机制、完整门控、缓存策略与发布路径，不引入 TEST、Graph 或 Registry 依赖。
 
-声明之后只允许生产 `prepare`。非生产 prepare 返回 `CONFIG_INVALID`，原因 `TEST_INTAKE_NON_PRODUCTION`。assess 等其他命令仍可加载这份配置。docs、config、marketplace 轻量工作流、`selectedUnits` 和无需发布的配置分支都不免除项目级要求：未选中单元的单元级要求可以不进入本轮，项目级要求始终适用。
+`--test-selection incremental` 在 `prepare` 或冻结过程中均被拒绝，不得在任何准备阶段启用。该拒绝行为不延迟至冻结完成后。
 
-要求文件与结果文件的字段以 `schemas/test-intake.schema.json` 为准。release 只核收原件：预冻结项必须有一条可核验结果，处置为 `executed`、`reused`，或由 owner 确认的 `not-applicable`；结论为 `passed`；`acceptedBy` 与声明的 acceptor 一致，`not-applicable` 时与 owner 一致；引用文件可读且摘要一致；结果里的 `subjectDigest` 与 `requirementsSha256` 绑定当前对象。退出码 0、全局 PASS、空证据、`failed` / `incomplete` / `uncovered`、未知字段，或把后续阶段项提前标成完成，都不能通过。未知失败原因保持 `unknown`。安装、加载和业务证据继续分开保存，不合并成一个类别。
+#### 交互式 Skill 的接入职责
 
-首次生产 prepare 生成适用快照和 tarball 后，只保存一份非正式候选 `.release-skill/runs/<run>/test-candidate.json`，返回 `NEEDS_INPUT`（`GATE_FAILED`，退出码 13），并给出 `candidatePath`、`candidateSha256`、`subjectDigest`。此时不写正式计划，也不进入 `PREPARED` 或 `FROZEN`。之后用 `prepare --candidate <path>` 续接：新的运行目录，不覆盖旧运行目录、旧证据或旧候选。结果补齐并核验通过后才写正式计划。对象、配置、权威要求或其他实质输入变化时返回 `TEST_CANDIDATE_REPREPARE`，原候选字节保持不变。只往结果文件补入仍绑定该对象的有效内容，不算输入漂移。
+生产准备前，Skill 必须核对接入状态。若未声明 `testIntake`，系统默认触发公开 TEST 0.1.0 的 `skill-family-test:skill-family-test-plan`，随后在授权范围内调用 `skill-family-test:skill-family-test-run`。
 
-候选不能传给 approve 或 publish，也不能把 `PARTIAL`、`PUBLISHED`、`VERIFIED` 或任何已成功的外部检查点改成完成。`ship` 在接受前保持持久状态 `NEW` 与 `testCandidate`，不重建候选。没有 `testCandidate` 的 `NEW` 记录仍走原来的准备路径。
+跳过接入须满足以下条件：
+- 基于本轮适用且范围匹配的明确同意；
+- 必须先明确征询再作决定；
+- 沉默、拒绝、仅普通发布预授权、旧轮次、其他项目、版本或范围不匹配均不可跳过；
+- 本轮匹配的答复可复用。
 
-正式计划上的可选 `testAcceptance` 进入当前计划版本的绑定摘要，记录层剥离不移除它。替换结果、准则、范围或允许的限制会改变 plan digest，原批准不再适用。不改变这些原件的注释不会使批准失效。没有 `testAcceptance` 的计划保持原摘要路径。approve、publish 和 reconcile 在动作前复核绑定原件；原件缺失或被改写时失败关闭，不重新批准，也不重放已经成功的外部检查点。
+不得将跳过表述为测试已达标，亦不得以跳过清除已声明的适用要求。
+
+以下请求不新增接入义务：
+- 只读请求；
+- 非生产路径；
+- marketplace-only 委托发布。
+- 已冻结计划的批准、发布、对账与正式验证不追加接入义务。
+
+直接非交互 CLI 支持可选 `testIntake`，不新增选择参数、同意文件 Schema 或身份认证。选择责任由实际交互的 Skill 承担，答复记入既有任务或执行计划。
+
+#### 声明后的命令与要求适用范围
+
+声明 `testIntake` 后，仅允许执行生产 `prepare` 命令。非生产 `prepare` 返回 `CONFIG_INVALID`，错误码为 `TEST_INTAKE_NON_PRODUCTION`。
+
+`assess` 等其他命令仍可加载该配置。
+
+轻量工作流（如 docs、config、marketplace）、`selectedUnits` 与无需发布的配置分支不免除项目级要求：未选中单元的单元级要求可不进入本轮，但项目级要求始终适用。
+
+#### 核收原件与失败条件
+
+`release` 仅核收原件，要求如下：
+- 预冻结项必须存在一条可核验结果；
+- 结果状态必须为 `executed`、`reused` 或由 owner 确认的 `not-applicable`；
+- 结论必须为 `passed`；
+- `acceptedBy` 与声明的 acceptor 一致；`not-applicable` 时与 owner 一致；
+- 引用文件可读且摘要一致；
+- 结果中的 `subjectDigest` 与 `requirementsSha256` 均必须绑定当前对象。
+
+以下情况均不通过核收：
+- 退出码为 0；
+- 全局 PASS；
+- 空证据；
+- 状态为 `failed`、`incomplete`、`uncovered`；
+- 未知字段；
+- 提前将后续阶段项标记为完成；
+- 未知失败原因（保持 `unknown`）。
+
+安装、加载与业务证据须分开保存，不得合并为单一类别。
+
+核收依据 `schemas/test-intake.schema.json` 定义的字段结构。
+
+#### 首次生产 prepare、候选续接和输入漂移
+
+首次生产 `prepare` 执行后，生成适用快照与 tarball，仅保存一份非正式候选：
+- 路径：`.release-skill/runs/<run>/test-candidate.json`；
+- 返回状态：`NEEDS_INPUT`（`GATE_FAILED`，退出码 13）；
+- 附带字段：`candidatePath`、`candidateSha256` 与 `subjectDigest`。
+
+此时不写正式计划，也不进入 `PREPARED` 或 `FROZEN` 状态。
+
+后续使用 `prepare --candidate <path>` 续接：
+- 创建新运行目录；
+- 不覆盖旧运行目录、旧证据或旧候选；
+- 结果补齐并核验通过后，才写入正式计划。
+
+当对象、配置、权威要求或其他实质输入发生变更时，返回 `TEST_CANDIDATE_REPREPARE`，原候选字节保持不变。
+
+**仅当向仍绑定原对象的 `resultFile` 补入有效结果内容时，不视为输入漂移。**
+
+首次候选、有效结果、正式计划与正式业务接受为不同阶段，不得将 `NEEDS_INPUT` 或工具成功改写为通过。
+
+#### 后续计划与批准绑定
+
+候选不可传给 `approve` 或 `publish`，亦不可将 `PARTIAL`、`PUBLISHED`、`VERIFIED` 或任何已成功的外部检查点修改为完成状态。
+
+`ship` 在接受前保持持久状态 `NEW` 与 `testCandidate`，不重建候选。无 `testCandidate` 的 `NEW` 记录仍沿用原有准备路径。
+
+正式计划中的可选字段 `testAcceptance` 进入当前计划版本的绑定摘要，记录层剥离不移除该字段。
+
+替换结果、准则、范围或允许的限制将改变 plan digest，原批准不再适用。未改变这些原件的注释不会使批准失效。
+
+无 `testAcceptance` 的计划保持原摘要路径。
+
+`approve`、`publish` 与 `reconcile` 在执行前复核绑定原件；原件缺失或被改写时，动作失败并关闭，不重新批准，也不重放已成功的外部检查点。
 
 ### 2.1 本地发布收尾
 
@@ -496,3 +577,23 @@ profile 是预设的默认配置模板，提供常见发布拓扑的开箱配置
 - 供应链安全中的最小权限和 Action 固定要求见 `04-supply-chain.md`。
 - 错误码定义见 `05-evidence-and-errors.md`。
 - Adapter 接口见 `06-adapter-contract.md`。
+
+## 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/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/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/skills/release-config/SKILL.md

@@ -7,36 +7,29 @@ description: "Config-only workflow profile: route confirms config-only diff, ass
 
 ## 触发
 
-用户询问或执行纯配置变更的发布流程。包含 `.release-skill/project.yaml`、配置 schema 等配置文件的修改，且无代码、文档或 marketplace 变更。
+用户发起仅配置变更的发布流程，涉及 `.release-skill/project.yaml`、配置 schema、`releaseUnits` 映射、`policy` 策略定义等配置文件的修改，且无代码、文档或 marketplace 变更。
 
 ## 当前状态
 
-`release-config` 是工作流配置文件 (§4) 定义的独立工作流之一，专门处理仅配置变更的场景。它遵循简化生命周期，专注于配置验证和发布路径决策分支。
+`release-config` 是工作流配置文件（§4）定义的独立工作流之一，专门处理仅配置变更场景。其遵循简化生命周期，专注于配置验证与发布路径决策分支。
 
-**机械实现**: `prepare --workflow config` 确定性地裁剪代码类门禁（H5），并比较当前
-per-unit `snapshotDigest` 与最新冻结 plan——公开字节未变 → `publishPath:
-'no-publish-needed'`（externalActions 被移除，无 publish 路径）；字节变化或无对比
-plan → `publishPath: 'publish-needed'`（fail-safe）。决策以 `workflowDecision` 绑定
-进 plan digest，不可篡改。**不存在** `NO_PUBLISH_NEEDED`/`REPORTED` 虚构状态：
-prepare 的真实输出是 plan 内的 `workflowDecision`。
+**机械实现**：`prepare --workflow config` 确定性地裁剪代码类门禁（H5），并比较当前 per-unit `snapshotDigest` 与最新冻结 plan——公开字节未变 → `publishPath: 'no-publish-needed'`（`externalActions` 被移除，无 publish 路径）；字节变化或无对比 plan → `publishPath: 'publish-needed'`（fail-safe）。决策以 `workflowDecision` 绑定进 plan digest，不可篡改。**不存在** `NO_PUBLISH_NEEDED`/`REPORTED` 虚构状态：prepare 的真实输出是 plan 内的 `workflowDecision`。
 
 **边界**：裁剪代码类检查（declared hooks、snapshot-verify gates、skill-resource-closure），保留基线、快照、计划冻结和文档新鲜度检查。来源权威检查按发布分支决定，不能一并裁掉：
 
-- 场景 A：公开字节未变，`externalActions=[]`，不生成 `plan.sourceAuthority`（冻结的源码来源权威），也不进入 approve/publish/verify。即使配置了公开来源收据，这一边界也不变。
-- 场景 B：公开字节变化或不可判定，需要发布。production prepare 必须通过现有来源权威检查并冻结 `plan.sourceAuthority`；publish、reconcile、verify 继续校验冻结绑定和远端一致性，consumer-verify 保留。
+- **场景 A**：公开字节未变，`externalActions=[]`，不生成 `plan.sourceAuthority`（冻结的源码来源权威），也不进入 approve/publish/verify。即使配置了公开来源收据，这一边界也不变。
+- **场景 B**：公开字节变化或不可判定，需要发布。production prepare 必须通过现有来源权威检查并冻结 `plan.sourceAuthority`；publish、reconcile、verify 继续校验冻结绑定和远端一致性，consumer-verify 保留。
 
 旧 production 计划缺少 `sourceAuthority` 时，仍在外部写入前拒绝。未发生外部写入的旧计划必须重新 prepare 并批准新摘要，不补字段、不迁移旧批准。已有 `PARTIAL` 保留检查点，走匹配版本的恢复路径。docs production 同样要求来源权威；marketplace 委托目标工作区发布的边界不变。
 
 ## 职责与边界
 
-- **步骤① diff 确认 config-only**: 调用 `release-skill route` command 确认仅有配置变更
-- **步骤② assess with schema validation**: 执行配置结构验证、schema 检查、contract 一致性
-- **步骤③ prepare --workflow config**: 本地 freeze 检查，生成只读计划；输出 `workflowDecision`
-- **步骤④ decision branch**（来自 plan.workflowDecision）:
-  - 场景 A：`publishPath === 'no-publish-needed'`（公开字节未变化）→ 记录决策并结束，
-    无 publish 路径，不运行 approve/publish/verify
-  - 场景 B：`publishPath === 'publish-needed'`（公开 surface 变化或不可判定）→ 运行
-    轻链 (approve→publish→verify)
+- **步骤① diff 确认 config-only**：调用 `release-skill route` 命令确认仅有配置变更
+- **步骤② assess with schema validation**：执行配置结构验证、schema 检查、contract 一致性
+- **步骤③ prepare --workflow config**：本地 freeze 检查，生成只读计划；输出 `workflowDecision`
+- **步骤④ decision branch**（来自 plan.workflowDecision）：
+  - **场景 A**：`publishPath === 'no-publish-needed'`（公开字节未变化）→ 记录决策并结束，无 publish 路径，不运行 approve/publish/verify
+  - **场景 B**：`publishPath === 'publish-needed'`（公开 surface 变化或不可判定）→ 运行轻链（approve→publish→verify）
 
 存量增量只改本轮目标映射。已有合法字段、历史发行记录与精确授权保持不变，不要重建 `.release-skill/project.yaml`。
 
@@ -44,25 +37,27 @@ prepare 的真实输出是 plan 内的 `workflowDecision`。
 
 `delivery.include/exclude` 不是文件包含或排除。排除不得覆盖 `requiredPublicFiles`。互相冲突的配置必须失败关闭。Foundation 建议不能作为发布批准。未经精确批准不产生远端动作。分类文字不会机械识别全部私有内容。接入评估缺失码 `REQUIRED_PUBLIC_FILE_MISSING` 不属于本技能的 prepare 路径；config-only prepare 仍走 `release-prepare` 原生错误。
 
-**授权边界**: 命令调用本身即授权执行配置的 hooks/gates。config-only 工作流的远程写操作受标准 approval 机制约束，不 bypass 安全 gate。
+**授权边界**：命令调用本身即授权执行配置的 hooks/gates。config-only 工作流的远程写操作受标准 approval 机制约束，不 bypass 安全 gate。
 
-**阶段通过规则**:
-- 场景 A: prepare 输出 `workflowDecision.decision === 'public-bytes-unchanged'`（无 publish 路径）
-- 场景 B: `status === 'VERIFIED'` + CLI exit code 0
+**接入选择**：进入本入口的新一轮生产准备前，必须按 `release-prepare` 同一完整流程核对 `testIntake`。若缺失，须说明缺项并默认推动 `skill-family-test:skill-family-test-plan`，再在授权范围内调用 `skill-family-test:skill-family-test-run`，由 TEST 组织检查并交回结果。跳过须先明确征询，再依据本轮适用且范围匹配的明确同意决定。**沉默、拒绝、仅普通发布预授权、旧轮次、其他项目、版本或范围不匹配均不可跳过**。本轮匹配答复可复用。**不得把跳过写成测试已达标，也不得用跳过清除已声明的适用要求**。已冻结计划的批准、发布、对账与正式验证不回头追加接入义务。只读和非生产准备不新增接入义务。直接非交互 CLI 仍接受可选 `testIntake`，不新增选择参数。答复与适用范围记入既有任务或执行计划。
+
+**阶段通过规则**：
+- **场景 A**：prepare 输出 `workflowDecision.decision === 'public-bytes-unchanged'`（无 publish 路径）
+- **场景 B**：`status === 'VERIFIED'` + CLI exit code 0
 
 ## 正向执行路径
 
-1. 运行 `release-skill route --root <path> [--target-version <ver>] --json` 获取 diff 分类；已知目标版本时显式传入，route 只是工作流建议
+1. 运行 `release-skill route --root <path> [--target-version <ver>] --json` 获取 diff 分类；已知目标版本时显式传入，`route` 只是工作流建议
 2. 若推荐 `workflowKind === 'config-only'`，则使用本技能
 3. 执行步骤②：运行 `release-skill assess --root <path> --offline --json` 进行 schema validation
-4. 执行步骤③：运行 `release-skill prepare --offline --workflow config --target-version <ver> --json`
-5. 读取输出中的 `workflowDecision`：
-   - **A**: `publishPath === 'no-publish-needed'` → 记录决策（plan 已冻结，无
-     externalActions），结束。无需 approve/publish/verify
-   - **B**: `publishPath === 'publish-needed'` → 继续 approve → publish → verify 链条
-6. (场景 B 续) 执行步骤⑥：运行 `release-skill approve --plan <path> --actor <name>`
-7. (场景 B 续) 执行步骤⑦：运行 `release-skill publish --plan <path> --approval <path>`
-8. (场景 B 续) 执行步骤⑧：运行 `release-skill verify --plan <path> --run <path>`
+4. 进入本入口新一轮生产准备前完成接入选择：按 `release-prepare` 同一完整流程核对 `testIntake`，默认推动 `skill-family-test:skill-family-test-plan` 与授权范围内的 `skill-family-test-run`。跳过须先明确征询再依据本轮匹配答复决定。未完成接入且无有效跳过时，不进入下一步 `prepare`。该分支只决定后续是否进入发布链，不改变生产 prepare 前的测试接入要求。
+5. 执行步骤③：运行 `release-skill prepare --offline --workflow config --target-version <ver> --json`
+6. 读取输出中的 `workflowDecision`：
+   - **A**：`publishPath === 'no-publish-needed'` → 记录决策（plan 已冻结，无 `externalActions`），结束。无需 approve/publish/verify
+   - **B**：`publishPath === 'publish-needed'` → 继续 approve → publish → verify 链条
+7. （场景 B 续）执行步骤⑥：运行 `release-skill approve --plan <path> --actor <name>`
+8. （场景 B 续）执行步骤⑦：运行 `release-skill publish --plan <path> --approval <path>`
+9. （场景 B 续）执行步骤⑧：运行 `release-skill verify --plan <path> --run <path> --json`
 
 ## 确定性脚本调用
 
@@ -135,21 +130,21 @@ node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" verify \
 
 ## 与其他工作流的关系
 
-- **docs-only**: 纯文档变更时使用 `release-docs`
-- **marketplace-only**: 仅 marketplace 变更时使用独立工作流
-- **full-happy-end**: 混合变更（code+config+docs）时降级到此完整路径
+- **docs-only**：纯文档变更时使用 `release-docs`
+- **marketplace-only**：仅 marketplace 变更时使用独立工作流
+- **full-happy-end**：混合变更（code+config+docs）时降级到此完整路径
 
 ## 关联技能
 
-- `release-skill route`: 快速入门决策路由（§4.3）
-- `release-assess`: 配置 schema/contract 验证入口
-- `release-prepare`: 离线冻结检查（`--workflow config` 输出 publish-path 决策）
-- `release-approve`: Plan approval（仅场景 B）
-- `release-publish`: 制品发布（仅在 public surface 变化时执行）
-- `release-verify`: 消费者验证（场景 B 的最终验证门）
+- `release-skill route`：快速入门决策路由（§4.3）
+- `release-assess`：配置 schema/contract 验证入口
+- `release-prepare`：离线冻结检查（`--workflow config` 输出 publish-path 决策）
+- `release-approve`：Plan approval（仅场景 B）
+- `release-publish`：制品发布（仅在 public surface 变化时执行）
+- `release-verify`：消费者验证（场景 B 的最终验证门）
 
 ## 人类最终回复
 
 纯问询或转交时短答：写明实际回答、适用范围或理由、必要限制和下一步。建议保持为建议。
 
-执行路径说明实际分支、已完成步骤、未执行步骤，以及既有计划、`workflowDecision` 产物和限制。`publishPath` 为 `no-publish-needed` 时按原合同结束，无发布路径。场景 B 只写入已经执行的 approve、publish、verify 结果。已有文件输出按原合同呈现。栏目只收录当前命令或分支已经返回的事实。
+执行路径说明实际分支、已完成步骤、未执行步骤，以及既有计划、`workflowDecision` 产物和限制。`publishPath` 为 `no-publish-needed` 时按原合同结束，无发布路径。场景 B 只写入已经执行的 approve、publish、verify 结果。已有文件输出按原合同呈现。栏目只收录当前命令或分支已经返回的事实。

package/skills/release-docs/SKILL.md

@@ -7,44 +7,47 @@ description: "Docs-only workflow profile: route confirms docs-only diff, style-g
 
 ## 触发
 
-用户询问或执行纯文档变更的发布流程。包含 `docs/public/site/`, `README*`, `CHANGELOG`, `release-notes/` 等文件的修改，且无代码、配置或 marketplace 变更。
+用户发起纯文档变更的发布流程，涉及 `docs/public/site/`、`README*`、`CHANGELOG`、`release-notes/` 等文件的修改，且无代码、配置或 marketplace 变更。
 
 ## 当前状态
 
-`release-docs` 是工作流配置文件 (§4) 定义的独立工作流之一，专门处理仅文档变更的场景。它遵循标准发布生命周期，裁剪代码类检查（声明式 hooks、snapshot-verify gates、skill-resource-closure），保留文档质量检查。
+`release-docs` 是工作流配置文件（§4）定义的独立工作流之一，专门处理仅文档变更场景。其遵循标准发布生命周期，但裁剪了代码类检查（如声明式 hooks、snapshot-verify gates、skill-resource-closure），保留文档质量与发布表面一致性检查。
 
-docs production 仍由 release-skill 执行发布，因此 prepare 必须通过现有来源权威检查，并冻结 `plan.sourceAuthority`（源码来源权威）。publish、reconcile、verify 继续校验冻结绑定和远端一致性，不能把来源权威当作代码类检查裁掉。config 场景 B 适用同一要求；场景 A 无发布动作、不生成该字段。marketplace 委托目标工作区发布的边界不变。
+文档生产仍由 `release-skill` 执行发布，因此 `prepare` 阶段必须通过现有来源权威检查，并冻结 `plan.sourceAuthority`（源码来源权威）。`publish`、`reconcile`、`verify` 阶段继续校验冻结绑定与远端一致性，**不可将来源权威视为代码类检查而裁掉**。配置场景 B 适用相同要求；场景 A 无发布动作，不生成该字段。marketplace 委托目标工作区发布的边界不变。
 
-旧 production 计划缺少 `sourceAuthority` 时，仍在外部写入前拒绝。未发生外部写入的旧计划必须重新 prepare 并批准新摘要，不补字段、不迁移旧批准。已有 `PARTIAL` 保留检查点，走匹配版本的恢复路径。
+旧 production 计划若缺少 `sourceAuthority`，在外部写入前即被拒绝。未发生外部写入的旧计划必须重新 `prepare` 并批准新摘要，**不补字段、不迁移旧批准**。已有 `PARTIAL` 状态保留检查点，走匹配版本的恢复路径。
 
-**机械实现**: `prepare --workflow docs` 在 prepare 内确定性地裁剪代码类门禁（H5），
-plan 记录 `workflowKind: 'docs'` 与 `workflowDecision`（绑定进 plan digest）。
-**边界**: NOT merging repos；不对代码类 gates（如 schema validation、contract verification）负责。
+**机械实现**：`prepare --workflow docs` 在 `prepare` 阶段确定性地裁剪代码类门禁（H5），`plan` 记录 `workflowKind: 'docs'` 与 `workflowDecision`（绑定进 `plan digest`）。
+
+**边界**：不合并仓库；不对代码类 gates（如 schema validation、contract verification）负责。
 
 ## 职责与边界
 
-- **步骤① diff 分类确认**: 调用 `release-skill route` command 对工作树 diff 分类，确认仅有文档变更
-- **步骤② style-guard 三道门**: 调用 `check-style.mjs`（只接受文件路径参数，exit 0/1/2）执行事实性/可读性/风格检查
-- **步骤③ render-public-site --check**: 调用 `render-public-site.mjs --check [--repo <name>]` 做渲染漂移扫描（内存泄漏扫描 + 树基线对比）
-- **步骤④ docs refresh**: 执行 rehearsal → binder 写入（本地文档更新，不 commit/push）
-- **步骤⑤ prepare --workflow docs**: 轻量 freeze（裁剪代码类 gates，保留 docs freshness/public-surface/baseline/snapshots/plan freeze）
-- **步骤⑥–⑧**: approve → publish → verify（consumer-verify 保留）
+- **步骤① diff 分类确认**：调用 `release-skill route` 命令对工作树 diff 分类，确认仅含文档变更  
+- **步骤② style-guard 三道门**：调用 `check-style.mjs`（仅接受文件路径参数，exit 0/1/2）执行事实性、可读性、风格检查  
+- **步骤③ render-public-site --check**：调用 `render-public-site.mjs --check [--repo <name>]` 执行渲染漂移扫描（内存泄漏扫描 + 树基线对比）  
+- **步骤④ docs refresh**：执行 rehearsal → binder 写入（本地文档更新，不 commit/push）  
+- **步骤⑤ prepare --workflow docs**：轻量级冻结（裁剪代码类 gates，保留 docs freshness/public-surface/baseline/snapshots/plan freeze）  
+- **步骤⑥–⑧**：approve → publish → verify（consumer-verify 保留）
+
+**授权边界**：命令调用本身即授权执行配置的 hooks/gates。本地文档写入授权仅覆盖声明的本地文档目标，**不等同于 Git commit/push/publish 或安装的授权**。
 
-**授权边界**: 命令调用本身即授权执行配置的 hooks/gates。本地文档写入授权只覆盖声明的本地文档目标，不是 Git commit/push/publish 或安装的授权。
+**接入选择**：进入本入口的新一轮生产准备前，按 `release-prepare` 同一完整流程核对 `testIntake`。若缺失，说明缺项并默认推动 `skill-family-test:skill-family-test-plan`，再在授权范围内调用 `skill-family-test:skill-family-test-run`，由 TEST 组织检查并交回结果。跳过须先明确征询，再依据本轮适用且范围匹配的明确同意决定。**沉默、拒绝、仅普通发布预授权、旧轮次、其他项目、版本或范围不匹配均不可跳过**。本轮匹配答复可复用。**不得把跳过写成测试已达标，也不得用跳过清除已声明的适用要求**。已冻结计划的批准、发布、对账与正式验证不回头追加接入义务。只读、非生产准备不新增接入义务。直接非交互 CLI 仍接受可选 `testIntake`，不新增选择参数。答复与适用范围记入既有任务或执行计划。
 
-**阶段通过规则**: `status === 'VERIFIED'` 且 CLI exit code 为 0。`PARTIAL` 状态保留并跳过已成功的检查点，只安全重试未完成的步骤。
+**阶段通过规则**：`status === 'VERIFIED'` 且 CLI exit code 为 0。`PARTIAL` 状态保留并跳过已成功的检查点，仅安全重试未完成的步骤。
 
 ## 正向执行路径
 
-1. 运行 `release-skill route --root <path> [--target-version <ver>] --json` 获取 diff 分类和工作流建议；已知目标版本时显式传入，route 不承担发布授权
-2. 若推荐 `workflowKind === 'docs-only'`，则使用本技能
-3. 执行步骤②：调用 `check-style.mjs <doc-path>...` 执行事实/可读性/风格检查
-4. 执行步骤③：调用 `render-public-site.mjs --check [--repo <name>]` 验证渲染无漂移
-5. 执行步骤④：运行 `release-skill docs refresh --unit <id> --write --confirm-refresh <digest> --ack-local-document-write`
-6. 执行步骤⑤：运行 `release-skill prepare --offline --workflow docs --target-version <ver>`
-7. 执行步骤⑥：人工审阅后运行 `release-skill approve --plan <path> --actor <name>`
-8. 执行步骤⑦：运行 `release-skill publish --plan <path> --approval <path>`
-9. 执行步骤⑧：运行 `release-skill verify --plan <path> --run <path>`
+1. 运行 `release-skill route --root <path> [--target-version <ver>] --json` 获取 diff 分类和工作流建议；已知目标版本时显式传入，`route` 不承担发布授权  
+2. 若推荐 `workflowKind === 'docs-only'`，则使用本技能  
+3. 执行步骤②：调用 `check-style.mjs <doc-path>...` 执行事实/可读性/风格检查  
+4. 执行步骤③：调用 `render-public-site.mjs --check [--repo <name>]` 验证渲染无漂移  
+5. 执行步骤④：运行 `release-skill docs refresh --unit <id> --write --confirm-refresh <digest> --ack-local-document-write`  
+6. 进入本入口新一轮生产准备前完成接入选择：按 `release-prepare` 同一完整流程核对 `testIntake`，默认推动 `skill-family-test:skill-family-test-plan` 与授权范围内的 `skill-family-test:skill-family-test-run`。跳过须先明确征询再依据本轮匹配答复决定。未完成接入且无有效跳过时，不进入下一步 `prepare`  
+7. 执行步骤⑤：运行 `release-skill prepare --offline --workflow docs --target-version <ver>`  
+8. 执行步骤⑥：人工审阅后运行 `release-skill approve --plan <path> --actor <name>`  
+9. 执行步骤⑦：运行 `release-skill publish --plan <path> --approval <path>`  
+10. 执行步骤⑧：运行 `release-skill verify --plan <path> --run <path>`
 
 ## 确定性脚本调用
 
@@ -97,22 +100,22 @@ node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" verify \
 
 ## 与其他工作流的关系
 
-- **config-only**: 仅配置变更时使用 `release-config`
-- **marketplace-only**: 仅 marketplace 变更时使用独立工作流
-- **full-happy-end**: 混合变更（code+docs）时降级到此完整路径
+- **config-only**：仅配置变更时使用 `release-config`  
+- **marketplace-only**：仅 marketplace 变更时使用独立工作流  
+- **full-happy-end**：混合变更（code+docs）时降级到此完整路径
 
 ## 关联技能
 
-- `release-skill route`: 快速入门决策路由（§4.3）
-- `release-assess`: 项目发布就绪度评估
-- `release-prepare`: 冻结发布计划（`--workflow docs` 裁剪代码类门禁）
-- `release-publish`: 发布 GitHub/npm 制品
-- `release-verify`: 消费者验证和远程状态重检
-- `skill-family-docs-style-guard`（skill-family-docs adapter）: `check-style.mjs` 文档质量三道门
-- `render-public-site`（skill-family-doc-render）: 站点渲染漂移与泄漏扫描
+- `release-skill route`：快速入门决策路由（§4.3）  
+- `release-assess`：项目发布就绪度评估  
+- `release-prepare`：冻结发布计划（`--workflow docs` 裁剪代码类门禁）  
+- `release-publish`：发布 GitHub/npm 制品  
+- `release-verify`：消费者验证和远程状态重检  
+- `skill-family-docs-style-guard`（skill-family-docs adapter）：`check-style.mjs` 文档质量三道门  
+- `render-public-site`（skill-family-doc-render）：站点渲染漂移与泄漏扫描
 
 ## 人类最终回复
 
 纯问询或转交时短答：写明实际回答、适用范围或理由、必要限制和下一步。建议保持为建议。
 
-执行路径说明实际分支、已完成步骤、未执行步骤，以及演练或写入产物和限制。本地文档写入只在 `--write --confirm-refresh --ack-local-document-write` 三项绑定已经实际执行后报告。发布链只报告已经跑完的 prepare、approve、publish、verify；仅当退出码为 0 且状态为 `VERIFIED` 时，把发布终态写为已验证。已有文件输出按原合同呈现。栏目只收录当前命令或分支已经返回的事实。
+执行路径说明实际分支、已完成步骤、未执行步骤，以及演练或写入产物和限制。**本地文档写入仅在 `--write --confirm-refresh --ack-local-document-write` 三项绑定已实际执行后报告**。发布链只报告已经跑完的 `prepare`、`approve`、`publish`、`verify`；**仅当退出码为 0 且状态为 `VERIFIED` 时，把发布终态写为已验证**。已有文件输出按原合同呈现。栏目只收录当前命令或分支已经返回的事实。