release-openclaw-ci

OpenClaw 发布 CI

当发布候选版本需要全面验证、安装/更新验证、实时提供商检查或 CI 恢复时，请配合使用 $release-openclaw-maintainer 和 $openclaw-testing。

防护规则

• 未经操作员明确批准，不得更改版本号、创建标签、发布到 npm、创建 GitHub 发布或提升发布。
• 在压缩、恢复或收到新的指示后，根据操作员最新的明确指示，重写当前有效目标和所处阶段。不得将旧范围重新并入当前发布。
• 一旦存在发布分支或 Code SHA，就冻结发布范围。验证并发布该精确版本；不要把不断变化的 main 变成第二个待办队列。
• 记录 C（候选版本）、Q（资格验证）、P（准入／验证器／发布器）、重跑组、配置文件、有效浸泡时长以及上下文／传输引用。新候选版本的资格验证默认 Q=C，包括完整工作流、可复用工作流、本地操作、脚本、规划器、契约和覆盖范围闭环。Code SHA 和 Release SHA 是生命周期角色，不是额外的工作流身份。
• 候选版本辅助工具接受未设置发布标签，或已存在且解析为精确候选 SHA 的轻量标签或附注标签。标签冲突或远程查询失败时，停止验证；切勿移动标签来补救。
• 冻结 C/Q，并在 main 或受保护的发布标签上独立选择可信的 P。C/Q 不必是 P 的祖先。缺失的候选契约需要有意回移；切勿悄悄替换为更新的 main 工具。
• 冻结 Code SHA 后应用发布隔离线。仅接纳已确认的产品缺陷、错误或无法验证的包字节、安全缺陷，或导致无法发布的故障。其他发现排入发布后置信度验证或下一版 beta。依赖项公告绝不属于发布隔离线的接纳范围：将其记录为发布证据，并在发布后将升级排入 main；只有已知恶意软件会阻止发布。
• 冻结的 CI 子任务使用 Q 的 Node 分片规划器和实测耗时，同时从候选版本检出中发现并执行测试。托管的完整发布计划将超过 12 分钟的实测行拆分；保留文件覆盖范围、工作线程限制和完整的耗时数据代次。不可拆分且超出预算的任务必须拆分，不得提高发布预算。子任务完成后，收尾时针对该次运行执行 scripts/ci-shard-timings-refresh.mts 并提交生成的耗时数据；不得手动编辑测量结果。
• 候选版本资格验证运行其自身冻结的 Q 闭环。仅 main 上的检查和未来 main 场景不会自动成为发布要求。修复冻结的资格验证测试框架意味着创建新的 C/Q，并绑定新的证据。仅 P 的准入／验证器／发布器修复可以保留 C/Q 及其原始证据。
• 受保护的轻量 release-publish/<12sha>-<provenance-run> 标签标识 P，而非 Q。后缀记录标签创建时的来源，不代表当前父级。发布辅助工具保留其 --workflow-sha <P> 参数；FRV 辅助工具的 --workflow-sha 则选择 Q，且在候选版本路径上必须等于 C。
• 仅在操作员要求变更，或 main 自身负责且无法在发布分支处理、并会阻止本次发布的最小关键阻塞问题时，才改动 main。main 的 CI 健康状况从不作为发布门槛。如果 main 上的故障阻碍仅涉及发布工具的变更入库，且故障并非由该变更造成，则在干净的 main 检出中证明故障已存在，将其记录在 PR 正文中，然后合并；发布期间，此特定情况允许管理员合并。另设独立工作流并行修复红色的 main，不得影响发布关键路径。
• 在 main 上提交仅涉及工具的修复时，须在推送前添加 release-fast-lane 标签（参见发布工具快速通道）：openclaw/ci-gate 随后只运行 lint、类型检查、守卫检查、依赖项检查、文档检查，以及变更涉及的 Node 行。通过原生 scripts/pr 路径提交，并完成 ClawSweeper 审查；该标签下的发现仅供参考，因此发布负责人若决定不修复任何 P1，须在合并前将该问题及后续处理记录在 PR 中。
• OPENCLAW_RELEASE_RUNNER_GROUP 可选地将验证父任务和工作线程，以及 Release Publish 父任务及其发布子任务，路由到保留容量，同时保持标签不变；需要凭证的发布和审批任务仍使用默认 GitHub 托管标签。请先配置符合条件的运行器和仓库访问权限；未设置时保留常规路由。共享工作线程继承调用方组；PR/main CI 和无关的计划任务不受其影响。
• 分派新的 main 验证前，检查 Code SHA 对应的 nightly 父任务；如果输入匹配，它会封存每个子任务的收据，供目标明确的分派采用。nightly 运行此显式的可信 main 辅助工具路径（--sha <main-sha> --workflow-sha <main-sha> --trusted-workflow-ref main），因此其父任务在 release-ci/<sha12>-<id> 分支上运行，而非 main。
• 每条选定的验证通道都必须通过；参见发布要求。稳定版标签需要稳定版／完整证据、浸泡测试和阻断式性能测试。beta 配置文件证据不能为稳定版提供资格。任何通道或浸泡豁免都不能绕过这些要求。全组资格验证要求覆盖全部九种 Linux／Windows／macOS Gateway 安装／升级组合。保留首次失败记录、身份信息和完整证据。
• 原生 macOS、Windows、Linux 和 Android 发布独立于 npm/ClawHub、GitHub 收尾和 main 收尾。每个平台均保留各自的签名、资格验证、制品和更新器要求；准确报告待处理的平台，并行修复仅限原生平台的问题。
• 不得将未经验证的 1Password 候选值设为 GitHub 密钥。如果候选值返回 401/403，请保留现有密钥不变，并报告确切缺少的提供方。
• 读取／写入密钥时使用 $one-password：一个持久的 tmux 会话，仅访问指定条目，不输出密钥。
• 使用 pnpm frv watch --run <parent> 监控一个父任务运行（参见监控）。避免使用 gh run view 进行大范围轮询；很容易耗尽 REST 配额。
• 仅获取失败或当前阻塞任务的日志。如果配额不足，请停止轮询并等待重置。
• 将实时提供方偶发故障与代码故障分开处理：在编辑代码前，证明密钥有效、提供方 HTTP 状态、重试证据以及确切的失败通道。
• 诊断实时提供方故障时，模型列表响应只能证明已通过身份验证，不能证明具有计费或推理权限。将凭据视为有效前，须使用真实补全请求探测进行确认。先修复凭据；不得仅为绕过失败的发布凭据而添加备用身份验证路径。
• 完整发布验证将精确子任务分派、发布决策和诊断排空分开。设置 fail_fast=false 时，不会调用任何子任务取消操作；除非收集器本身被取消或失去 GitHub API 访问权限，否则诊断排空会跟踪每个选定的子任务直至终态。设置 fail_fast=true 时，发布决策只能取消仍在运行且造成阻塞失败的精确子任务。
• 只有在分派原始根任务时使用了 fail_fast=false，才能继续同一父任务。控制器会在任何重跑变更之前验证该精确的日志输入。
• 如果父任务已生成自身封存的候选制品，则不能继续该任务：GitHub 重跑会使前一次尝试生成的这些制品不可用。保持候选版本和资格验证 SHA 冻结，替换该父任务，并启动全新的一组完整发布验证。
• 分派后，一个不可变的执行计划制品会记录原始父任务尝试、精确的子任务元组和标题、所选覆盖范围、门槛以及复用身份。同一份字节还会使用精确的运行 ID 缓存键保存。决策、排空、清单写入、证据验证和最终验证都会读取当前尝试对应的制品。收集器重试时会恢复缓存的计划、验证该计划、重新上传其制品并采用相同的子任务；计划状态缺失属于编排故障，不代表可以重建计划或重新分派。
• 复用的证据不会仅因计划封存时发现了它就被视为可信。发布决策在返回 passed 前，会重新检查已封存的目标 SHA、证据 SHA、策略、变更路径、所选运行、根运行、来源清单、可信工具身份和精确子任务。
• 父任务重试会分别选择最新的决策和排空制品；即使其来源尝试不同，两者也必须绑定同一份不可变计划。
• 只有当子任务运行 ID、工作流路径、引用、Q SHA、分派标题、事件、目标、候选版本和验证输入均保持精确不变时，子任务重试才属于同一不可变计划。较新的子任务尝试会替换匹配的任务；较新尝试中缺失的任务会沿用。重复任务身份、缺失尝试、尝试次数倒退或元组变更都会导致失败关闭。GitHub 暂时在最新重试尝试中返回重复任务时，frv status 和 continue 最多允许 60 秒的只读协调时间。运行元组和尝试次数保持固定；持续存在的重复项和与较早尝试冲突的情况仍会报错。
• 使用 pnpm frv status|watch|rerun --job|rerun --child|continue --failed|verify 进行能识别尝试的恢复。控制器是无状态的：不可变执行计划、精确的 GitHub 运行尝试、诊断排空和最终清单是唯一权威来源。它绝不会写入标签、包、注册表条目、发布候选版本或发布内容。
• 合并后控制器证明必须通过非发布的 FRV Proof Broker 和 FRV Proof Fixture，在受保护的 main 上使用经过审查且已入库的 SHA。分派 broker 时，提供已合并 PR 的编号和精确的入库提交。broker 必须要求该 PR 的合并提交与入库提交匹配，证明入库提交与其可信工作流 SHA 相同或为其祖先，并在重跑 fixture 前立即重复检查权限、合并状态和祖先关系。要求精确的固定空操作 fixture 运行从预期的第一次失败推进到第二次通过。broker 必须生成收据，且不得创建发布候选版本、发布制品、发布内容、仓库引用、替代父任务或进行其他工作流变更。这是通过托管 GitHub 目标任务重跑进行的证明；有针对性的控制器测试负责验证不可变计划资格、保留成功尝试、同一父任务收集以及严格验证器调用。切勿使用真实的完整发布验证运行进行此证明。参见完整发布验证。
• 当前失败面仅使用一名发布操作员、一个 frv watch，至多再配一名调查人员。不得围绕单个工作流转换构建审计审查计划树。
• 对于常规 beta／稳定版发布，Code SHA 可能已经包含最终说明，并可作为 Release SHA。一次成功的新完整父任务可能同时为两个角色及其精确发布字节提供资格。如果之后更改了说明，则只有当 Release SHA 相对于 Code SHA 的完整差异仅更改选定的 CHANGELOG/YYYY.M.PATCH.md，以及可选的 CHANGELOG.md 和 CHANGELOG/records/YYYY.M.PATCH.md，且没有其他路径、重命名或删除时，后续 Release SHA 才能复用产品证据；其变更字节仍需通过资格验证。
• 扩展稳定版验证一个精确的分支顶端；它不复用常规的 Code-SHA/Release-SHA 证据模型。
• 在稀疏工作树或 Testbox 源代码同步中，首先确认 package.json、pnpm-lock.yaml 以及所选检查会读取的每个源文件路径。如果有任何文件缺失，该检出无法验证发布依赖项或 Docker 通道：请停止，并使用仓库远程的变更门控或完整任务工作树。如果输入齐全，且发布修复更改了 package.json 或 pnpm-lock.yaml，则仅在任务拥有的一次性 box 中重新执行 CI=true pnpm install --frozen-lockfile，随后在运行 Docker 或针对性测试前，显式执行 require.resolve() 探测。CI 标志允许 pnpm 在无需交互确认的情况下重新创建预热过的 modules 目录。不得削弱 lockfile，也不得将稀疏检出故障标记为产品／Docker 故障。
• 如果候选版本在预热后经过变基或其基准 SHA 发生变化，请停止任务拥有的 box，并预热一个新的 box 后再测试。Testbox 源代码同步是相对于预热时的源代码树进行的；继续操作可能会混合旧基准文件与新候选差异，从而导致虚假的 lockfile 或 Docker 故障。
• 首次成功运行后，复用的 Testbox 会根据记录的源代码进行检查。仅更改源代码时可以复用租约；基准、依赖项、包装器或 Testbox 工作流发生变化时则必须使用新租约。不得为发布证据设置 OPENCLAW_TESTBOX_ALLOW_STALE=1。
• 对于配备受支持的胶囊感知包装器的已提交发布候选版本，在 Testbox 中运行时，须从该候选版本的检出目录执行 node scripts/crabbox-wrapper.mjs run --blacksmith-ref main -- <command>。该胶囊会保留候选版本源代码和冻结的依赖项，同时由 main 提供当前准入限制。如果候选版本缺少此包装器契约，请使用下方的精确目标发布验证路径，并分别指定 Validation 和 Tooling SHA。不要分派候选版本的 Testbox 工作流引用，也不要借用其他检出的包装器。

延迟 CI 恢复

发布验证不会暂停 CI 或支持性工作流。当前工作流准入机制会忽略旧版 OPENCLAW_RELEASE_PRIORITY_RUN 变量，且 pnpm frv prioritize --run 已停用。使用 pnpm frv prioritize --restore <record> 恢复由旧版工作流修订延迟的运行，并清除其变量。 请保留必需的发布证明和浸泡测试门槛。

持续发布就绪状态

定时主分支验证（每 3 小时一次，在 UTC 时间 :07）会为确切的 main SHA 生成一份直接根清单和每个子项的收据。 若要在当天切分版本，请在下一次定时运行前将发布列车（版本和变更日志）合入 main， 然后在该次运行的 SHA 上切出 release/YYYY.M.PATCH，使 Code SHA 与已验证的 SHA 相同。 每个子项的采纳会匹配确切的目标 SHA、角色和分发输入（不包括 dispatch_id）： productPerformance 会被采纳，因为其输入不依赖上下文且匹配。 使用 --target-ref release/YYYY.M.PATCH 分发的稳定候选版本会解析为 coveragePolicy=npm-stable-v1 和 ci_release_scope=npm-stable，而 main 上的范围为 full。 normalCi、插件预发布和发布检查会重新分发，因为其输入会添加 target_context_ref；插件预发布和发布检查还会添加 allow_frozen_target_scenario_omissions=true，且范围不同。 采纳整个父级运行要求清单中的 validationInputs 字节完全一致，包括 validationPurpose、 publicationSelectionJson、targetContextRef、targetVersion、allowUnreleasedChangelog 和 coveragePolicy； main-qualification 夜间运行绝不会被整体采纳为以 publish 为目的的稳定候选版本。 跨目的/上下文的采纳是后续的验证器策略工作。

发布工具快速通道

在应使用快速通道的推送之前，将 release-fast-lane 标签添加到拉取请求；PR CI 会读取触发事件中的标签，而标签事件不会 启动 CI。对于已经推送的分支头，先运行 gh pr ready --undo，再运行 gh pr ready，即可使用当前标签重新触发 PR CI。此标签仅会在规范的拉取请求上缩小 openclaw/ci-gate 的范围，且其更改路径必须全部属于发布工具： .github/workflows/**、scripts/**、test/scripts/**、 .agents/skills/release-*/**、docs/reference/RELEASING.md，或单独检查的文档。准入的运行仍会执行 security-fast、check-shard（lint、 生产/测试类型、保护检查、依赖项、npm 锁文件）、文档有更改时的 check-docs，以及有更改的 Node 矩阵项；对规划器编辑而言，紧凑的打包策略完整计划证明会放宽为仅执行这些矩阵项。合约、基线棘轮、捆绑协议、Bun 启动器、其他检查、构建产物（除非有更改的矩阵项需要 dist）、Control UI、Windows、macOS、iOS、Android、i18n 和技能通道都会跳过，并列在预检步骤摘要的“Release fast lane”下。若标签不获准（路径不在范围内、Node 全局输入、fork、推送、分发、仅文档更改），系统会记录警告，并保持常规选择不变。门禁仍然完整：每个选定通道都必须通过，且每小时运行的完整 main CI 会覆盖合并后的结果。此标签仅缩小 CI 门禁范围：fork 分支头会被拒绝，原生的 scripts/pr 合并路径及其已完成的 ClawSweeper 审查保持不变。ClawSweeper 对带标签 PR 的发现仅供参考：若发布负责人决定不在 PR 中修复某项 P1，则须在合入前将其发现及后续跟进记录在该 PR 中。

运行标识和重试预算

在监视或恢复完整发布验证之前，记录 C、Q/ref、P/ref、目标上下文 ref、父运行 ID、 尝试次数和阶段。在台账中将 Code SHA 和 Release SHA 记录为生命周期角色；它们可以指向同一提交。将 不可变的 Release Publish 父级收据与标签记录的源分别记录。 对于此基础强制执行的核心和插件 npm 变更，请重新读取 受保护的精确轻量标签，并重新验证精确的父级运行元组。 在每次 publish 或 dist-tag 变更前立即执行。拒绝标签缺失、被移动、带注释或 SHA 不匹配；拒绝仓库、工作流、运行 ID、尝试次数、工具身份或父状态 不匹配，以及存在任何同名分支。切勿从当前 main 刷新任一身份。 阻止其他特权写入者，直至其所依赖的强制执行变更落地。

• 概念阶段与当前输入的映射如下：

  • beta-publish：release_profile=beta，run_release_soak=false
  • postpublish-confidence：已发布软件包的输入，且 run_release_soak=true 或指定了明确的关注组
  • stable-publish：release_profile=stable 或 full，并启用 soak 和阻断性性能测试

• 对于实际 beta 软件包，在与其匹配的规范发布分支或 beta 标签上运行未启用 soak 的 all，会记录 coveragePolicy=npm-beta-v1。此策略仍会覆盖 Linux/macOS/Windows Node、Control UI、插件、软件包、安装/更新、Linux/Windows/macOS 跨操作系统、QA 奇偶性、运行时配对/重启，以及工具。所有选定测试都会阻断 npm/ClawHub 发布。原生应用 CI、性能测试和已发布软件包的 Telegram 测试推迟到 confidence 阶段。beta 软件包的 all 在未启用 soak 时，也会推迟 Package Acceptance Telegram 测试，包括对 main 进行的 beta 配置检查。将推迟的检查记录为未运行，绝不能记录为通过。Stable/full、soak 和关注组会保留其覆盖范围；选定的子项仍须提供终态证据。缺少覆盖策略时，保留历史上的完整行为。

• 对于相同的 C + Q + 重跑 分组 + 发布配置 + 有效 soak 覆盖范围，最多保留一个活跃父级。Stable/full 始终包含 soak。不同覆盖配置可以独立运行；并发运行不会自动取消较早的精确子项。

• 取消父级或超时不会停止已接管且身份已验证的子项。当子项不再有用时，操作员必须明确取消该精确子项。不得根据分支、标题前缀或最新运行顺序推断子项身份。

• 用一次诊断、必要时的一次修复和一次小范围重试来恢复一个失败的测试面，然后重新评估发布决策。不要自动调度 rerun_group=all。

• 只有在负责人记录了失败测试作业属于真实阻塞问题还是偶发故障的判断后，才重跑失败或超时的测试作业（参见维护者技能中的共享发布边界）。偶发故障在同一 Release SHA 上最多记录两次重跑，并行期间还须在 main 上创建修复 issue 或 PR；绝不能重新切包、修改工具链或创建新的 FRV。新的调度会拒绝 known_flaky_jobs_json。

• 对于受支持的父级，pnpm frv rerun --run <parent-run-id> --job "<child-key>:<exact job name>" 会使用已接受的 Actions 作业 ID，重跑一个已执行且处于终态的作业。通过 frv status --json 获取子项键和精确作业名称。GitHub 也会重跑依赖作业。控制器只会等待该子项，然后发送请求；不会重试无关的失败。

• pnpm frv rerun --run <parent-run-id> --child <child-key|run-id> [--max-attempts N] 会记录上述有次数限制的重跑之一。它会等待子项完成，恰好发送一次重跑失败作业的请求，并在新的尝试创建且没有重复作业后返回。发送请求前，它会打印每个失败作业的运行器标签和当前的 OPENCLAW_CI_RUNNER_BACKEND；之后会将审计行追加到 $TMPDIR/openclaw-frv/<repo>-<parent>-reruns.jsonl。它会拒绝已通过的子项、产物生成作业（请使用 continue --failed），以及超过尝试次数上限的子项：默认值 2 允许重跑一次；仅对已确认的偶发故障传入 --max-attempts 3。当失败的消费者绑定到成功产物生成作业的运行尝试（安装冒烟测试候选载荷，#161317）时，它会改为重跑该产物生成作业及其依赖项。使用 continue --failed 重新封存。

• pnpm frv continue --failed --run <parent-run-id> 会在每个失败的子项进入终态后立即重跑，即使父级或其他子项仍处于活跃状态。它会接管活跃的尝试并保留成功的子项。所有必需子项都成功且原始父级完成后，它会重跑一次父级，以恢复相同的不可变计划并封存更新后的 all-group 清单。过早重试可能导致原始 Decision/Drain 配对失效；最终重新封存和严格验证才是完成依据。

• 每次子项或父级重跑变更在每次调用中只会发送一次；遇到不明确的传输故障时，会进行次数受限的只读协调。不要盲目重复被中断或超时的命令：先检查精确的尝试记录。定向 JSON 结果会记录作业 ID、已接受的源尝试和观察到的重试尝试。请将命令放在长时间运行的 Shell 中执行，其默认操作时限为 12 小时。

• 仅检查，不做变更：

  pnpm frv status --run <parent-run-id>
  pnpm frv verify --run <successful-parent-run-id>
  

• 其不可变计划早于支持按尝试追踪证据的父级任务无法继续。请启动全新、覆盖所有组的完整发布验证；绝不要重建旧状态或派发替代父级任务。

• 控制器重试项包括 ci、plugin-prerelease、install-smoke、 cross-os、live-e2e、package、qa-parity、qa-live、npm-telegram 或 performance。绝不要使用已移除的 release-checks 句柄。qa 仅用于直接子任务的手动汇总，不是控制器重试 API。

• 除非筛选条件属于所选组，否则筛选重试将采取失败关闭策略。覆盖所有组的运行也接受 cross_os_suite_filter：例如， -f cross_os_suite_filter=ubuntu,macos 会排除 Windows。如果显式筛选时省略了 OS 通道，只要仍选择了所有 Linux 套件且满足其他策略要求，npm-stable-v1 和 npm-beta-v1 仍符合条件。 绝不要将推导出的空筛选条件转换为不带筛选的广泛运行。

• 只有在共享编排发生变化、较早的证据对所选元组无效，或操作员明确要求时，才有理由创建新的、覆盖所有组的父级任务。请记录导致证据失效的事件。

• 范围较窄的子任务或组级证据本身并不构成发布授权。请将其保留在证据台账中，供发布负责人依据当前发布门禁进行判断。

预检

在派发完整矩阵之前，请在经批准的隔离环境中，针对冻结的可信目标运行 pnpm ui:i18n:check 和 pnpm native:i18n:check。将两项结果都绑定到该确切 SHA。将生成的本地化内容漂移报告为警告，并继续派发；源代码变更和串行执行的本地化刷新工作流可能会暂时导致生成的输出落后。启动验证前无需重新生成。FRV 的常规 CI 子任务仍保留严格的 control-ui-i18n 和 native-i18n 作业，并在运行摘要中报告其实际结果； 所选本地化作业失败将阻止 npm/ClawHub 发布。PR 端检查和发布准备门禁保持不变。目标执行必须在可信派发辅助程序之外进行——不要将任意目标检出内容作为辅助程序代码执行。

在进行成本较高的完整验证前，还要在经批准的隔离环境中，使用冻结的依赖项，在同一冻结的可信目标上运行 pnpm ui:build，且必须在可信派发辅助程序之外执行。记录目标 SHA，以及成功的生产构建、预压缩资源验证和启动/最大资源预算结果；任何失败都会阻止扇出。不要用开发服务器替代，也不要提高预算以放行目标。

要提供本地完整 E2E 证明，请在初始构建时，为已准备好依赖项且内容已冻结的证明检出添加私有 QA 条目：

OPENCLAW_BUILD_PRIVATE_QA=1 pnpm build

然后运行所选 E2E 命令，并启用其常规就绪检查。 scripts/lib/vitest-build-prerequisites.mts 会请求私有 QA 条目； scripts/run-node.mts 会在缺少这些条目时触发另一次完整构建。此预检可避免仅因 missing_private_qa_dist 而重新构建。此标志仅限于此任务专用的证明检出及命令。发布包和镜像字节仍由发布工作流及其密封制品管理。

在完整发布验证之前：

gh api rate_limit --jq '.resources.core'
git status --short --branch
git rev-parse HEAD

发布前

对于常规 beta/stable 受保护发布，在证据验证后，使用预期标签、确切的 Full Release Validation 运行和尝试、npm dist-tag、插件范围以及受保护发布工具引用运行 pnpm release:publish-preflight。pnpm release:candidate 会使用其已下载的清单调用此检查；不要重新下载清单，也不要替换选定的尝试。解决所有 FAIL 和需要负责人处理的 WARN 后，才使用报告中针对所选发布途径的确切调度命令。Extended-stable 仍采用单独的负责人工作流，不在此预检的准入范围内。Alpha 版本已停止发布。

重试失败的发布前，请检查报告：保留已验证、用于已发布核心字节的 openclaw_npm_resume_run_id，检查匹配的草稿/已发布版本状态，并在取消之前找出确切的孤立插件/ClawHub 子任务。 预检为只读，不授权发布、不取消子任务，也不能证明本地凭据中存在仓库密钥。引导候选版本需要使用仓库实际的 NPM_TOKEN 进行只读 npm whoami 探测；请遵循 引导令牌探测 中的密钥隔离步骤，并保留其运行 URL。不要将轮换凭据作为诊断检查的一部分。

调度

完成源准入、插件兼容性就绪检查和证据复用选择后，同时调度仅源代码子任务以及 npm 和 Docker 制品生成任务。候选版本获取原始 npm 字节的同时，资格审查继续进行；候选版本验证完成后，立即启动候选版本的插件预发布检查和发布检查，无需等待独立验证或 Docker。保留不可变执行计划和最终制品资格审查。

每个选定的验证子任务都会通过可信工作流工具上传不可变的 full-release-child-evidence-<target-sha>-<role>-<run-id>-<attempt> 收据。收据保留规范化的调度输入（包括候选描述符），并跨尝试组合前置任务。其 workloadConclusion 不包括正在运行的发布任务。收集失败会丢失复用元数据，但不会改变工作负载资格。启用 reuse_evidence=true 时，调度最多扫描最近的 100 次运行，探测最多 40 个目标收据清单，并在两分钟内按角色完整验证最多五份匹配收据。其他目标和其他工具运行不会占用完整验证预算。空字符串输入等同于未提供的输入，因为 GitHub 会从 github.event.inputs 中省略这些输入；非空默认值和候选描述符字节必须完全匹配。它只能在当前父级相同的工具 SHA 下采用失败、已取消或仍在运行的父级中的绿色子任务，并且仍要求存在 main 祖先关系。父级工具信息缺失或不同会导致安全拒绝；没有任何路径可豁免。调度日志会标识复用的子任务、说明每项已评估的拒绝原因，并汇总跳过的运行和新调度的任务。当前父级采用见证和不可变执行计划共同约束每项选择。收集器和最终验证会重新检查子任务的实时尝试和结论、工具是否相同、main 祖先关系、输入、制品身份/摘要/有效期，以及可信的密封/上传步骤是否成功。出现更新的尝试会使复用失效；不要重新运行已采用的子任务来修复收集器。当前父级的源代码/发布准入以及单独的成功父级变更日志复用路径保持不变。制品生成任务继续使用现有的密封收据。候选版本准入不会扩大此逐子任务收据复用约定：存在差异的 Q 会运行新的子任务；整个父级的已认证证据复用仍遵循其单独的原始 Q 约定。

提前运行的独立产品性能测试属于可选的 beta 信心验证。如有需要，可在发布工作进行的同时，针对冻结的 Code SHA 启动该测试：

# Optional beta confidence; stable/full qualification requires blocking performance.
fail_on_regression=false
gh workflow run openclaw-performance.yml \
  --repo openclaw/openclaw \
  --ref main \
  -f target_ref=<code-sha> \
  -f profile=release \
  -f repeat=3 \
  -f deep_profile=false \
  -f live_openai_candidate=false \
  -f fail_on_regression="$fail_on_regression"

• 请勿为这个可选的 Beta 信号额外添加强制性的发布前等待。
• 发布或收尾前，将可用的 Kova、网关启动和 CLI 启动指标与较早的 发布证据或 clawgrit 报告进行比较。
• 在发布证据中记录回归并调查其对产品的影响。 Stable/full 资格认定需要阻断性性能要求。每个选定的性能子项都必须成功；不能豁免失败。
• npm-beta-v1 会延后性能子项。每个选定的子项仍需要终态证据，并且必须证明仅发布制品。

使用规范的辅助工具进行经审核的候选资格认定。它会先在 P 上对 openclaw-release-prepare.yml 运行轻量级的 admit-qualification 操作，然后在 Q=C 时调度 FRV。P 会记录操作员证明、完整的标准化输入以及仅含数据的冻结 Q 覆盖范围； 不可变描述符通过现有的 trusted_workflow_json 信封传递。 请勿在 P 的准入步骤中执行候选代码，也不要手动组装信封。

PUBLISHER_SHA="<recorded-full-trusted-main-ancestor-sha>"
PUBLICATION_SELECTION='{"route":"normal","npmDistTag":"latest","publishOpenclawNpm":true,"pluginPublishScope":"all-publishable","plugins":[]}'
pnpm ci:full-release \
  --sha <code-sha> \
  --target-ref release/YYYY.M.PATCH \
  --trusted-workflow-ref candidate \
  --admission-workflow-sha "$PUBLISHER_SHA" \
  --admission-workflow-ref main \
  --request-file <private-request-file> \
  -f validation_purpose=publish \
  -f publication_selection_json="$PUBLICATION_SELECTION"

Q 默认值为 C；显式指定的 --workflow-sha 必须等于 C。P 则可以使用已有的受保护 release-publish/* 标签及其精确 SHA。在调度前审核候选项和覆盖范围：准入记录的是操作员证明，而非机器人例外。定时主分支资格认定会显式使用 --trusted-workflow-ref main，并保留其受信任主分支语义。

现有的 --request-file 会协调原始请求，不会更改其路由、Q/P 身份或输入。--reconcile-request <file> 仅供读取。 只有 --resume-request <file> 才能在准入后、任何 Q ref 变更或 FRV POST 之前继续候选请求。Stable/checklist 拒绝会为 Q ref 仍符合预期的 v2 准备请求打印确切的下一条命令；请显式运行该命令，然后重新运行辅助工具。仅进行协调不会将已准入的请求推进到资格认定阶段。不确定的写入绝不重试。重用证据时，请保留原始生成方和当前使用方的身份。

Beta 发布时选择 npmDistTag=beta，仅在有意让准备按钮的使用方消费时选择 route=prepared。源码准入结果不会对注册表状态进行资格认定，也不授权发布。非发布调查应使用显式的 validation_purpose=diagnostic，且不选择发布；重复的主分支资格认定使用 main-qualification，精确已发布软件包的可信度验证使用 postpublish-confidence。覆盖范围和配置文件的选择应保持独立。

对于常规 release/* 验证，若没有 target_context_ref，绝不要直接调度工作流（辅助工具的 --target-ref 会记录该值）。规范的 release/* 和 extended-stable/* 工作流 ref 仍是受支持的路由，但其 Telegram 子项必须在 OIDC 和证明中保留精确的父工作流 ref 和 SHA。受信任工作流的发布分支 CI 会传递 target_ref + release_candidate_ref；在那里绝不要使用 release_gate——它要求 workflow head == target。（下方的 PR head ci.yml 回退是另一种调度方式，会使用 release_gate=true。） 冻结 Code SHA 后，发布分支可能继续前进。只有当该冻结 SHA 仍是规范发布分支的祖先，且其软件包版本为该分支的最终版本或匹配的 beta 预发布版本时，辅助工具才会接受它。扩展稳定版分支和所有标签都要求软件包版本完全匹配。 对于新的候选资格验证，保留 Q=C，并单独传入 P。缺少冻结合约时必须安全失败，需要有意进行候选回移，而不能回退到 main。显式历史/跨修订路径仍为 --trusted-workflow-ref main --workflow-sha <recorded-main-tooling-sha> （或受保护的工具标签）。此路径上的新请求仅用于诊断、main 资格验证或发布后置信度验证，绝不能用于发布资格验证。此新派发限制生效前重新打开的现有历史发布请求，会保留其原有的 trusted-main 祖先关系合约；它们不是候选版本拥有的证据。绝不要从不断变化的 main 刷新任一路径记录的身份。除非操作人员有意选择 -f reuse_evidence=false，否则仍会启用证据复用。

如果在新的完整资格验证前已提交最终说明，则保留该 Code SHA 作为 Release SHA，并在候选版本和发布检查中使用同一个成功的父运行/尝试及其完全相同的准备字节。仍须通过必需的门禁，并完成最终的渠道专属 SDK 审核。发布器使用密封的确认记录；必要时，候选辅助工具会保留其显式参数。

只有在资格验证后说明发生变更时，才提交选定的发布条目及任何匹配的记录/索引更新，然后可选择使用复用功能，针对新的 Release SHA 运行辅助工具。该父运行必须报告 policy=split-changelog-release-v1、evidenceSha=<code-sha> 和完整的 changedPaths：必须包含选定的 CHANGELOG/YYYY.M.PATCH.md，且只能同时包含 CHANGELOG.md 和 CHANGELOG/records/YYYY.M.PATCH.md。允许新增或修改条目/记录；索引必须是修改。重命名、删除、其他发布内容以及文档源文件编辑都需要进行新的产品资格验证。仅涉及根目录的历史回执仍使用 changelog-only-release-v1。拆分路径应复用产品矩阵，而不是派发子任务通道。Npm 预检和软件包/安装验收仍须针对完全相同的 Release SHA 及其新 tarball 字节运行。

当前全组 FRV 也负责只读的核心及选定插件 npm 源码/构建/资格验证，以及 Docker 准备。使用其成功运行的 preflight_run_id；候选辅助工具默认使用该运行。除非要恢复历史的独立证据，否则不要派发第二次 npm 预检。常规最终资格验证会记录 beta 和 latest 两个渠道的 SDK 报告；请根据实际发布渠道审核确认记录。准备好的描述符位于完全匹配的最终清单中的 publicationArtifacts。Release Prepare 会采用清单中的插件 npm 描述符，并且只准备 ClawHub；FRV 之后绝不会重新打包插件 npm。产品证据复用绝不会用 Code-SHA 软件包或映像字节替代最终 Release SHA 的对应字节。对于失败的独立 npm 资格验证，使用 pnpm frv continue --failed： 失败的 npm 任务会在原运行中重试，成功的准备任务和诊断子任务会沿用，父运行会验证生成的回执。仅仅失败并不构成拒绝继续的理由。冻结工作流会执行其原有回执逻辑；本地控制器升级不会改造该逻辑，最终验证仍负责确认恢复结果。 这个固定 SHA 的辅助程序会为匹配的 beta 候选发布版本推断 beta，为稳定版／修正版本推断 stable，然后传递 C/Q/P 运行标识。规范的 beta all 不带 soak 时使用 npm-beta-v1；main 和非 beta 目标不符合该策略。将延后的原生、性能、Telegram、广泛实时 QA 和 E2E 测试作为发布后置信度验证，使用确切已发布的包，并设置 run_release_soak=true 或明确指定组。稳定版和完整配置文件会强制执行发布 soak。原生构件发布仍需通过自身的构建、签名、公证和晋级门槛。针对性修复后使用范围较窄的 rerun_group；绝不自动扩大范围。 在封存时，父级会记录来自合格 npm 收据的 SDK 证据摘要，并根据注册表解析每个包的 npm 计划。清单中的 publishInputs 提供发布者／预检默认值。SDK API 变更仍需操作员确认；已封存的证据不会授予权限。变更负责人须重新检查实时发布权限、选择器和不可变字节。

发布要求

使用 release_profile=from-validation 发布，以使用已封存的配置文件。 稳定版发布要求稳定版／完整证据、soak 和阻断性性能结果。对每项失败测试都要判定为阻断问题或偶发故障。最多在同一 Release SHA 上重跑偶发故障两次，并在 main 上提交并行修复问题／PR。所选作业若仍为红色，仍会阻止发布；绝不要仅为清除偶发故障而重新切版、更改工具或启动新的 FRV。跳过、取消、缺失和未知覆盖率也会阻止发布。不适用任何通道或 soak 豁免。

发布子任务

有关发布顺序以及预备／直接恢复，请参阅维护者发布恢复指南。

• pnpm release:stable <version>（编排式稳定版发布） 仅调度一次父工作流，批准父工作流的 npm-release 门禁；仅在旧版工具不支持 npm-publish 时打印子工作流批准命令，并在需要时打印过期子工作流清理命令 （绝不修改子工作流运行）。遇到任何拒绝时，都会打印包含准确恢复命令的 Next:。

• 父工作流的 npm-release 批准会签发经证明的 openclaw-release-approval-v1-<parent run>-<attempt> 收据；由机器人调度的 子工作流会在通过门禁前验证该收据 (scripts/release-approval-receipt.mjs verify)。ClawHub OIDC 子工作流在收据 验证通过后跳过 clawhub-plugin-release 门禁，转而等待父工作流的 openclaw-clawhub-parent-authorization-v2-* 收据，然后再发布。npm 子工作流 (Plugin NPM Release、openclaw-npm-release.yml) 在通过验证收据的路径上 跳过 npm-release 批准作业，并在 npm-publish 中发布，受信任的发布者绑定到 该环境。发布前会立即等待父工作流尝试的收据，并要求该尝试仍处于 in_progress 状态。每次发布只需一次人工批准。 npm-publish 没有审核者，且只接受受保护的 release-publish/<sha12>-<n> 标签。实际的手动／恢复 npm 调度必须使用此类 工具标签，且仍需通过其自身的 npm-release 批准作业； 只读 OIDC 预检也使用 npm-publish，并要求使用此标签。 仅限工件的预检保留现有引用，且不使用环境。

• 切勿手动批准 plugin-clawhub-release.yml 子工作流。机器人路径会验证收据， 不需要批准。openclaw-clawhub-recovery-approval-<run>-1 的 Artifact not found 行是非致命探测。父工作流结束后，迟到的人工批准会在 Revalidate trusted tooling identity 步骤失败，并显示 parent state completed/failure is not allowed by authorization route （2026.9.6：运行 35930335388/35930341394）。如果核心 npm 已发布，请通过显式的 ClawHub 恢复操作进行恢复 （发布恢复）； 否则，取消子工作流并重新调度父工作流。引导子工作流 (plugin-clawhub-new.yml) 始终会等待 clawhub-plugin-bootstrap。在无密钥的 打包作业完成后批准它们 （首个软件包）。

• v2 ClawHub 子工作流可以暂存大部分软件包，但其中一个失败会导致被等待的父工作流 失败，从而无法完成其余已暂存软件包的最终处理。重新发布或恢复父工作流之前， 请核对原始子工作流的 *-publish-json 工件。使用 pnpm release:clawhub-recovery -- --version <version> --reason '<parent failure>' --clawhub-source <isolated pinned ClawHub checkout> <package-publish.json>... 打印准确的尝试恢复命令；固定来源的 CLI 和授权执行方式请参阅发布恢复指南。公开的 版本 404 无法区分已暂存和缺失的版本，尝试状态则需要发布者身份验证。仍然需要 父工作流收据和实时授权重新验证；恢复操作不会将失败的父工作流变成成功凭证。

• 在首次调度子工作流之前，父工作流会扫描所有选定的发布方，查找同一版本中更早的 失败父工作流所遗留的 waiting／queued 子工作流（ClawHub 和核心通过 parent=<run>/<attempt> 运行标题识别；插件 npm 通过发布 SHA 识别，且仅在没有 其他发布父工作流正在运行时进行）：它会尝试拒绝门禁并取消工作流，然后等待每个 工作流最多 5 分钟。拒绝操作因 403 被拒时需要审核者；日志和步骤摘要会包含 拒绝／取消命令。未能确认取消时会发出警告。核心 npm 有独立的发布槽位，并会重新 检查其运行中的父工作流，因此不会造成阻塞；插件 npm 和 ClawHub 保留按目标 串行化的槽位，如果取消仍未得到确认，就会在任何新调度之前拒绝执行。无法识别的 旧版 ClawHub 子工作流或正在运行的发布方也会保留调度保护。父工作流失败时会取消 其自身正在等待的 npm 子工作流。作为审核者清理时，请列出由 github-actions[bot] 为此版本创建的 workflow_dispatch 运行，拒绝其门禁，并取消：

  for s in waiting queued; do gh api "repos/openclaw/openclaw/actions/runs?status=$s&per_page=100" \
    --jq '.workflow_runs[] | select(.event=="workflow_dispatch" and .actor.login=="github-actions[bot]") | select(.name | test("plugin-clawhub|Plugin NPM Release|openclaw-npm-release")) | [.id,.name,.created_at] | @tsv'; done
  env_id=$(gh api repos/openclaw/openclaw/actions/runs/<child>/pending_deployments --jq '.[0].environment.id')
  gh api -X POST repos/openclaw/openclaw/actions/runs/<child>/pending_deployments \
    -f state=rejected -f comment="Reject stale release gate" -F "environment_ids[]=$env_id"
  gh run cancel <child> --repo openclaw/openclaw
  

• 在插件 npm 子任务上执行 gh run rerun --failed 会导致其基于尝试次数的预检工件回读失败。父任务会等待原子任务结束，并传播其失败状态，而不会派发替代任务。请先诊断并修复失败的所有者，再明确恢复发布；保留成功的不可变软件包和证据。

扩展稳定版验证

对于 .33+ 扩展稳定版验证，也使用同一个由候选版本所有的辅助工具：C 是精确冻结的分支头，Q=C 拥有其完整的资格验证闭包，而独立受信任的 P 会准入并验证它。规范的 extended-stable/YYYY.M.33 分支提供上下文，不具有工作流权限。在冻结 C 之前，有意回移缺失的契约。

VALIDATION_SHA="<exact-candidate-sha>"
PUBLISHER_SHA="<recorded-full-trusted-main-ancestor-sha>"
CONTEXT_REF="extended-stable/YYYY.M.33"
pnpm ci:full-release \
  --sha "$VALIDATION_SHA" \
  --target-ref "$CONTEXT_REF" \
  --admission-workflow-sha "$PUBLISHER_SHA" \
  --admission-workflow-ref main \
  -f validation_purpose=publish \
  -f publication_selection_json='{"route":"extended-stable","npmDistTag":"extended-stable","publishOpenclawNpm":true,"pluginPublishScope":"all-publishable","plugins":[]}' \
  -f release_profile=stable \
  -f run_release_soak=true \
  -f fail_fast=false \
  -f rerun_group=all \
  -f reuse_evidence=false \
  -f dispatch_release_evidence=false

只有辅助工具会在准入后创建不可变的 release-ci/<Q-prefix>-<timestamp> 传输分支。切勿原始派发、手动创建其引用，或为 Q 生成受保护的发布标签。使用原始身份协调现有的历史跨修订发布请求；切勿将其重新标记为由候选版本所有。新的显式 main/受保护路线只能用于诊断、main 资格验证或发布后置信度验证，不能替代这项已准入的 Q=C 发布证明。

仅接受完整的 rerun_group=all 运行，且其清单必须针对受支持的精确目标。工作流 SHA 必须与候选 SHA 分别绑定；清单目标、软件包版本、保存的 run_attempt 和最终标签必须标识同一个候选版本。拒绝范围过窄的运行、不受信任的工具、目标不匹配以及较早尝试的证据。

all 组父任务会自行准备 core 和选定的插件 npm tarball，并将其不可变描述符记录在 publicationArtifacts 中。发布必须使用这些精确的工件和尝试。独立的 npm 或插件 npm 预检仅用于诊断，不能替代与清单绑定的证据。

产品故障需要经批准的回移。冻结目标的工具故障需要最小且保持行为不变的修复。提供商、审批、运行器或日志竞态应保持候选版本不变。记录修复和已被取代的运行；任何分支变更都需要新的完整父任务。仅当某个冻结目标场景被明确标记为不受支持时，才可省略；切勿省略所需行为或软件包。

冻结目标测试省略项

仅在 Plugin Prerelease Node 流水线中，使用 plugin_prerelease_node_exclude_patterns_json 指定精确的 src/plugins/ 测试路径。在 Plugin Prerelease 扩展分片中，使用 extension_test_exclude_patterns_json 指定精确的 extensions/ 测试路径。常规 CI 不负责此项测试。两者默认均为 []；没有隐式的 Codex 省略项。在初始派发时传入 JSON 数组，并保留说明理由和负责修复的所有者；将省略的覆盖范围报告为未运行。

预检必须在所选冻结目标流水线中发现每个请求的路径；不存在、超出流水线范围、重复、仅提供基本名称或使用 glob 的输入都必须明确报错。受信任的工具会将精确排除项应用于内联 Vitest 叶节点，同时保留候选版本的运行时准备，并在分片命令后恢复原始配置字节。切勿改用 CLI --exclude 或新增目标端环境变量：冻结的内联项目可能会忽略它们。输入会保留在不可变请求、覆盖范围/复用身份和最终清单中；修改这些输入需要新请求，切勿继续原请求。

监控

使用可识别尝试的控制器监控子任务：

pnpm frv watch --run <full-release-run-id>

它从父任务的派发作业日志行 （Dispatched <workflow>: <url> (attempt N)）中解析子任务运行 ID， 绝不使用显示标题；并会报告每次父任务和子任务尝试状态的转换，以及每个失败作业一次，同时显示运行器标签。临时的 GitHub 5xx 响应或 HTML 错误正文会在下一次轮询时重试，绝不会被报告为作业结果。状态保存在 $TMPDIR/openclaw-frv/<repo>-<parent>-watch.json 中（--state 可覆盖该路径），因此在 harness 或 Monitor 超时后重启也不会重复报告。--once 获取一次快照，--interval <seconds> 设置轮询间隔（默认为 60）， --json 输出 NDJSON。父任务和所有已派发的子任务都进入终态后，监控器便会退出；若之后重新运行，请重启监控器。不要自行编写 bash 或 gh 监控器。

对于父任务的 Release Decision，请使用仅报告状态转换的摘要监控器：

node scripts/release-ci-summary.mjs <full-release-run-id> --watch

如果 SHA 固定的辅助程序仍在前台运行，请勿启动此监控器。辅助程序会自行读取确切的 Release Decision 工件。当状态为 blocked_diagnostics_running 时，它会立即以非零状态退出，保留临时工作流引用，并让 Diagnostic Drain 继续收集剩余的终态证据。 对于单独派发的父任务，监控器行为相同：它会报告一次 Release Decision 阻断项，然后在 Drain 继续运行时退出。

如需获取一次性快照：

node scripts/release-ci-summary.mjs <full-release-run-id>

release-ci-summary 仅接受 Full Release Validation 父任务运行。 分叉的发布分支日志：使用 --first-parent 加上有界数量。 结束本轮操作或切换策略前，请停止监控器。

对于 PR 和子任务门禁，请读取确切的工作流运行，而不是提交的检查运行列表：commits/<sha>/check-runs 会保留同一分支头对应的已被取代或已取消运行的条目，因此过时的 cancelled 或 failure 可能会掩盖更新的成功结果。解析该分支头对应的最新 CI 运行（actions/runs?head_sha=<sha>），并从该运行的作业中读取 openclaw/ci-gate，然后再重试或报告。

准确解读状态：

• qualifying：尚无决定性阻断项；所选子任务仍在运行。
• blocked_diagnostics_running：发布受阻；Diagnostic Drain 仍在收集独立故障。立即诊断，并在失败的子任务进入终态后使用 frv rerun 或 continue --failed；父任务最终重新封存仍须等待证据完整。
• passed：所有必需策略和确切子任务证据均已通过。
• blocked_complete：发布受阻，且所有选定的诊断任务都已进入终态。
• orchestration_error：GitHub API 或收集器故障导致无法得出结论。 这不表示使用了错误的来源。请针对同一批确切子任务恢复收集器；切勿重新派发测试来修复收集问题。
• cancelled_with_children：收集器取消时，确切的子任务仍在运行。

读取每个选定泳道的实际结论。passed 要求每个选定的验证泳道都成功；未纳入的覆盖项代表未运行，而不是已通过。

full-release-diagnostics-<run-id>-<attempt> 工件是终态故障和耗时清单。遇到较早出现的阻断项后，请使用它，而不要仅为查明仍在运行的子任务发现了什么就重启 all。 稳定的 full-release-execution-plan-<run-id> 工件是每次收集器尝试中的身份来源；重试时会先恢复其不可变且按运行 ID 缓存的字节。

故障排查

1. 确认父级 SHA 和子级运行 ID。
2. 使用 pnpm frv watch --run <parent> --once 列出失败的作业；该命令会显示每个失败作业的尝试次数、运行器标签和 URL。
3. 获取一个失败作业的日志。如果遇到速率限制，记录重置时间，并避免继续调用 REST API。
4. 对于看起来与密钥有关的失败，在修改代码前，先验证同一密钥来源能否完成一次真实操作。成功获取模型列表并不足以证明有效。 Claude CLI 订阅凭据属于独立的原生身份验证路径；请在干净的主目录中通过 CLI 探测来验证，绝不可用它替代所需的 Anthropic API 密钥通道。
5. 对于实时缓存失败，检查原因是缺少密钥／密钥无效、文本为空、提供方拒绝、超时，还是未命中基线。没有明确的提供方证据时，不要放宽发布门槛。
6. 修改前，先将每项失败测试判定为阻塞问题或偶发问题。对于 main 上的偶发问题，跟踪修复；发布前仍必须确保每个选定作业都通过。 进一步分类阻塞问题：
   • 已确认的产品／代码故障：修复发布分支，冻结新的 Code SHA，并使产品证据失效
   • 资格验证框架／契约缺陷：修复候选版本闭包并冻结新的 C/Q；保留已被取代的证据及其失效原因
   • 仅限 P 的准入／验证器／发布器缺陷：保留 C/Q 和原始制品，修复独立可信的 P，并恢复受影响的部分
   • 基础设施／凭据故障：保留 C/Q/P，修复外部前置条件，仅重试失败的部分
   • 封装器／监控器故障：保留子级和候选版本标识；分别记录封装器结果与子级结果
   • 更新日志／发行说明故障：仅修改选定的发布条目，以及 split-changelog-release-v1 下允许修改的记录／索引路径；保留 Code SHA 证据，并重新验证 Release SHA
   • 发布子级／注册表选择器故障：保留 Release SHA 并恢复失败的子级；绝不要重新构建已发布的不可变版本
   • 核心 npm 已发布后父级失败（例如，过期的 beta dist-tag 导致完成验证失败）：保留成功的原始 npm 运行和通过资格验证的字节，修复选择器，并在恢复选定的发布路径前协调失败父级中确切的子级。 直接完成通常要等 npm 和 Docker 验证通过；预备按钮还会验证 ClawHub 下载。不要手动取消草稿状态来绕过这些门槛。直接恢复或启动新的预备按钮运行，请遵循发布恢复。
   • 子级卡在 waiting、ClawHub 报错 Artifact not found，或父级因 ClawHub dispatch blocked by waiting run 而失败：请参阅发布子级 只有产品或资格验证框架缺陷会更改 C/Q。完成一次诊断／修复／小范围重试后，应重新评估，而不是再次启动全组流程。
7. 运行器路由：由 FRV 分发的 CI 和 Plugin Prerelease 子级始终使用托管的 ubuntu-24.04（或发布运行器组）运行。其他发布通道遵循 OPENCLAW_CI_RUNNER_BACKEND；因此，在 Blacksmith 中断期间切换为 github 会将它们转移到托管运行器，但 QA Lab runtime-pair 通道除外：它在托管运行器上会失败，因此固定使用 Blacksmith，并在中断期间排队等待。切换生效期间，Release Checks 会显示 Release runner routing 通知。Codex 扩展测试会作为按文件划分的 Plugin Prerelease 作业运行，因为有一次托管 Codex 批次耗时 36-60 分钟。
8. 如果必需的 PR CI 运行因容量不足而停滞，作业处于排队状态且没有活动作业，不要取消无关工作，也不要接受常规手动分发。 首先确认 PR head 包含当前的回退架构： gh api 'repos/openclaw/openclaw/contents/.github/workflows/ci.yml?ref=<pr-head-branch>' --jq .content | base64 --decode | rg -q 'pull_request_number:'。如果不存在，从 main 更新 PR head 并使用新的 head SHA；先让常规 CI 运行，再考虑其他回退方案。 从 PR head 分支分发明确指定精确 SHA 的回退： gh workflow run ci.yml --repo openclaw/openclaw --ref <pr-head-branch> -f target_ref=<full-pr-sha> -f pull_request_number=<pr-number> -f include_android=true -f release_gate=true。 该流程会在 GitHub 托管运行器上运行，且只有其运行标题为 CI release gate <full-pr-sha> 时才会被接受。请在发布证据中记录停滞的 Blacksmith 运行和回退运行。 如果 Blacksmith Build Artifacts Testbox 是唯一剩余的必需门槛，且仍在排队、没有运行器，那么已完成的精确回退可以覆盖它，因为 CI 的 build-artifacts 作业已经构建、打包并对制品进行了冒烟测试。若制品工作流已启动或未成功完成，则不得使用此覆盖方式。

证据

记录：

• 发布生命周期台账：常规发布的 Code SHA 和 Release SHA； extended-stable 的规范分支、准确 SHA 和不可变标签；任一轨道的 C/Q/P、 原始准入描述符和留存请求
• 证据复用策略、覆盖策略和完整的变更路径集
• 当前有效的完整父运行 URL、尝试次数、工作流 SHA，以及任何被取代的父运行 及其确切的替换原因
• 所选子运行 ID 和结论：CI、Release Checks、Plugin Prerelease、NPM Telegram、Product Performance；将延期的置信度记录为未运行
• 最终清单中准确的核心和插件 npm 发布制品描述符
• 所有选定通道的结论，包括 Linux/Windows/macOS 跨操作系统结论
• 相较于先前发布版本的性能比较结果（如有）
• 定向本地验证命令
• 冻结目标兼容性修复或省略的不适用场景，并附其源 PR 和不变量
• 将托管验证及其部署先决条件与本地契约测试分开；模拟不能证明 Actions 准入、OIDC、环境访问权限或发布
• 已知缺口或无关故障

有关经验和恢复模式，请阅读 references/release-ci-notes.md。