触发一次验证运行

Full Release Validation 是发布产品验证的总括工作流。大部分工作在子工作流中完成，这样失败的环节可以重新运行，而无需重启整个发布流程。在冻结 Code SHA 之前运行发布准备；当后台机器人尚未落地 Control UI 语言环境输出时，它负责刷新该输出，然后强制执行与发布 CI 相同的严格零回退检查。

生成的语言环境漂移是分派前的警告，而非拒绝验证的理由。源代码 PR 和序列化的语言环境刷新工作流会分别落地，因此生成的输出可能暂时滞后。针对冻结的目标 SHA 记录任何预检漂移，然后继续分派。normal-CI 子工作流仍会运行严格的 control-ui-i18n 和 native-i18n 任务；其失败仍会显示在运行摘要中，并使验证失败。PR 侧的语言环境检查、发布准备和发布要求保持不变。

Linux（ubuntu）、Windows 和 macOS Gateway 跨操作系统全新安装与升级通道在 beta、stable 和 full 配置文件中把关发布。失败将阻止 Release Decision、npm publish 和 pnpm release:candidate。在清单和摘要中保留每个通道的实际结论；被选中的通道需要终态证据。

Normal CI、npm 资格验证、Docker、Package Acceptance 以及配置文件的性能和浸泡测试要求保持其现有的把关机制。

在将产品完成提交及其目标上下文冻结为 Code SHA/ref 之前，准备完整的历史清单和实质性的版本匹配发布说明。包源代码预检要求有匹配的发布章节；空的占位符不算准备就绪。如果说明是最终版本，此提交也可以作为 Release SHA。选择一个可信的工作流提交和上下文作为 Tooling SHA/ref，然后运行：

TOOLING_SHA="<recorded-full-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 \
  --workflow-sha "$TOOLING_SHA" \
  -f validation_purpose=publish \
  -f publication_selection_json="$PUBLICATION_SELECTION"

此示例选择常规的最终发布方式。对于 beta 版本，选择 npmDistTag=beta；当预期使用方是 prepared 发布按钮时，选择 route=prepared。核心发布要求 all-publishable 插件。仅插件的常规发布可以设置 publishOpenclawNpm=false、pluginPublishScope=selected，并在 plugins 中指定显式的规范包名。

每次全新运行都需要显式的 validation_purpose。publish 在投影所请求的发布选择之前、以及在解析过程可以发布任何选定的生产者之前，验证完整的已提交源代码元数据。其保留的源代码准入事实仅限源代码层面，不涉及注册表资格、产品测试成功或发布权限。diagnostic、main-qualification 和 postpublish-confidence 省略 publication_selection_json，并将发布源代码准入记录为不适用。覆盖范围是独立选择的。

新的发布请求还需要具有注册表准入资格的工具。源代码验证之后，解析过程为选定的包收集有界的公共 npm 和 ClawHub 观测数据，上传这些数据，然后在生产者可以启动之前绑定不可变工件和准入时间。必需的读取错误和不支持的引导状态会阻止准入；最新依赖漂移仅作为建议。受支持的首包或信任修复路径保留未解析的下游所有者权限，而非发布许可。源代码事实仍然仅限源代码层面。非发布请求不收集注册表观测数据。

SHA 固定的帮助程序将其语义化的 -f validation_purpose 和 -f publication_selection_json 参数打包到现有的 trusted_workflow_json 输入中。原始工作流分派使用此封闭信封：{"trustedWorkflow":{"ref":"main","fullRef":"refs/heads/main","sha":"<tooling-sha>"},"validationPurpose":"diagnostic","publicationSelection":null}。对于现有的直接分支路由，trustedWorkflow:null 让身份所有者推断执行身份；目的始终是显式的。子工作流仍然只接收解析后的身份元组。现有的请求工件可以重新打开，无需转换其输入或见证摘要。

pnpm release:candidate 默认使用常规发布路由。对于 prepared 按钮，在其首次分派之前选择 --publication-route prepared；仅仅提供受保护的工具引用并不会选择该路由。保存的状态绑定选择并拒绝矛盾的恢复请求。没有路由的历史状态保留常规恢复语义，并且不会获得源代码准入声明。对于已获注册表准入的父工作流，检查清单读取经过认证的保留规划摘要，而不是重复两次本地注册表扫描。准备和发布会将该证据与其实际选择的操作数进行比较；常规父工作流不能在事后更改命令来授权 prepared 路由。

为发布记录一次候选 SHA/ref 和 Tooling SHA/ref，并在后续的 Code-SHA、Release-SHA 和针对性重跑中复用它们。Main 血缘关系授权初始的 Tooling SHA 选择；它不授权从移动中的 main 刷新工具。

精确冻结目标测试排除¶

在分派之前，使用精确的仓库相对测试路径的 JSON 数组声明范围严格限定且理由充分的排除项。plugin_prerelease_node_exclude_patterns_json 适用于 Plugin Prerelease Node 通道，例如 ["src/plugins/manifest-registry.test.ts"]。extension_test_exclude_patterns_json 适用于 Plugin Prerelease 扩展分片，例如 ["extensions/codex/src/app-server/run-attempt.test.ts"]。两者均默认为 []；没有隐式的 Codex 测试排除。Normal CI 保留其自己的核心通道；Plugin Prerelease 负责完整的扩展扫描。

通过 SHA 固定的帮助程序以 -f name='["exact/path.test.ts"]' 形式传递它们。帮助程序将扩展输入打包到现有的可信分派信封中，以保持在 GitHub 的 25 个输入限制之内，并在创建工作流引用或分派之前拒绝没有匹配通道输入能力的工具。

预检（Preflight）使用所选目标的实际 Vitest 发现结果，拒绝格式错误、重复、不存在以及超出通道（out-of-lane）的路径。不接受 Globs 和基名（basenames）。固定工具链将每个精确省略项应用到执行配置的内联项目中，保留候选版本原有的测试运行器和设置，并在命令执行后恢复原始配置字节。它不依赖被冻结的候选版本支持新的排除环境变量。

不可变请求、覆盖标识、证据复用比较以及最终清单均保留两个输入值。更改它们需要新的验证请求；延续不能扩展现有省略项。在发布证据中记录每个被省略测试的原因及责任修复。省略项是未经测试的覆盖范围，而非通过的证据。

保留并核对根请求¶

对于新的派发（包括 --dry-run），辅助脚本首先在一个全新的临时仓库中通过裸 SHA 获取（bare-SHA fetch）证明 GitHub 提供确切的 Validation SHA。获取一旦失败，就会在任何请求制品或远程变更产生之前停止。辅助脚本在 Tooling SHA 上推送一个不可变的 release-ci/* 工作流引用，并以确切的 Validation SHA 作为 ref 和 expected_sha 进行派发。

在创建该工作流引用之前，辅助脚本会在 .artifacts/full-release-validation/<request-id>.json 处写入一个操作者私有制品并打印其路径。使用 --request-file <path> 选择制品位置。它保留仓库、工作流、冻结的目标/工具链标识、工作流传输引用、完整的类型化/默认输入、有效浸泡时长（effective soak）以及首次观察到的运行和尝试。辅助脚本在其唯一一次工作流派发 POST 之前记录尝试意图。

在响应丢失或中断后，复用该确切制品：

node scripts/full-release-validation-at-sha.mjs \
  --reconcile-request .artifacts/full-release-validation/<request-id>.json

现有的 --request-file 也会进入只读核对；冲突的目标、工具链或输入参数将被拒绝。恢复过程不执行引用创建/删除、派发、重新运行、取消、Git 获取或请求重写。dispatch=observed 报告的是确切的运行 URL 和尝试，并不代表验证成功。较新的尝试不能替换已保留的尝试。

在辅助脚本停止创建 validation/target-* 引用之前写入的请求仍记录 targetRef 和 refs.target，当前的辅助脚本会将其判定为无效。请从移除了目标引用的合并提交的父提交处（例如通过 git worktree add --detach <path> <merge-commit>^ 检出该提交）运行辅助脚本核对此类文件。两个版本在核对期间均不会创建或删除引用。只要 GitHub 重新运行或证据诊断仍可能需要，就保留任何剩余的 release-ci/* 或 validation/target-* 引用，然后有意识地将其删除。

缺失或不明确的运行、分页不完整、输入见证不可用或不匹配，以及发现已耗尽，这些情况均保持为 dispatch=unknown。完整的 HTTP 拒绝会保留为 dispatch=rejected；这两种状态都不允许重新派发。保留制品和打印的工作流引用以供调查。本地制品没有自动的保留到期或清理机制；只能通过操作者有意的清理来移除。丢失或删除它绝不能证明未执行。其他主机上的独立请求和副本不会进行全局去重。

新请求要求固定的工作流中包含 FULL_RELEASE_SOURCE_ADMISSION_CONTRACT=1 和 FULL_RELEASE_DISPATCH_WITNESS_CONTRACT=1。较旧的冻结工具链会在远程创建之前失败，而不是启动无法证明输入的工作。辅助脚本从不升级 Tooling SHA。对已在运行的冻结验证，使用 frv status；为新验证选择不同的工具链需要发布负责人的明确决定。该工作流单独的输入见证与尝试绑定，并保留七天。它直接读取事件文件，不会将输入插值到步骤环境变量或日志中。仅上传安全的 GitHub 上下文和 SHA-256 摘要：输入键按字典顺序排序，原始值规范化为传输字符串（wire strings），然后进行 JSON 序列化。不可变的工作流 SHA 绑定输入类型；完整的类型化映射和传输映射保留在私有本地制品中。运行器或制品服务故障可能使见证不可用；它绝不是发布回执或发布授权。

选择覆盖范围¶

provider 还接受 anthropic 或 minimax，用于跨操作系统接入（cross-OS onboarding）和端到端代理轮次。常规 release/* 目标接受分支的最终包版本或匹配的 beta 预发布版本。对于修正，使用 --target-ref release/YYYY.M.PATCH-N 以在打标签前保留预期的最终标签。当 vYYYY.M.PATCH 解析到确切的 Code SHA 时，其基础包版本也被接受；准备过程保留包版本，并为 vYYYY.M.PATCH-N 密封 npm 和 Docker 制品。辅助脚本将 beta 发布映射到 beta 配置，将最终版本映射到 stable。使用 -f key=value 传递备选工作流输入；仅在全面的提供方扫描（provider sweep）中使用 -f release_profile=full。

fail_fast 默认为 false，因此派发的子工作流会全部完成并一起暴露独立的失败。在该模式下，父工作流不会发起任何子工作流取消调用。仅当更短的先失败路径（first-failure path）更可取时，才传递 -f fail_fast=true；此时 Release Decision 仅取消拥有阻塞失败的那个仍处于活动状态的子工作流。

同一父级延续要求原始根请求已使用 fail_fast=false 派发。控制器在任何重新运行变更之前验证该确切记录的输入。当前运行会为 npm、Docker 和验证候选版本派发独立的 Full Release Artifacts 生产者。每个生产者拥有其不可变的派发记录和输出回执。父级重试恢复这些确切的生产者 ID 和尝试，重新检查其源码 SHA 和 Tooling SHA，并复用成功的构建。自行生成候选版本或发布制品的旧版父级无法继续：保持两个 SHA 冻结，并启动一次全新的全组验证。

自动测试重试已禁用。Dispatch 会拒绝 known_flaky_jobs_json；请移除该已退役输入项，并调查原始作业失败。诊断后，仍可通过继续命令进行显式操作员恢复。

在 Dispatch 之后，父级会写入一个不可变的 full-release-execution-plan-<run-id> 工件，并在精确的 run-ID Actions 缓存中保留相同字节。它记录所选与必需的覆盖率、门禁结果、复用身份、原始父级尝试、当准备运行时生成的新候选请求以及生产者和发布者证据，以及每个精确的子 run ID、尝试、标题、workflow ref 和 Tooling SHA。 Decision、Drain、manifest 生成、证据验证和最终验证器会针对其当前尝试消费该工件。在原始受保护上传成功后，sealer 会在其作业日志中记录计划摘要。 Collector 重试会在发布准入之前恢复精确的 run-ID 缓存，将其字节与该原始上传和摘要进行认证，并为当前尝试重新上传未更改的计划和准入。GitHub 会在完全重新运行时删除先前的父级工件，因此请保留缓存和原始作业日志。 如果缓存不可用，可访问的计划工件可以提供相同的已认证字节。缺失或无效的证据会失败关闭；重试永远不会重建计划、重新收集注册表观测或重新调度测试。 Release Decision 还会在复用的 run 能够通过之前重复规范复用链验证。密封的目标 SHA、证据 SHA、策略、变更路径集、所选 run、根 run、源 manifest、受信任的工具身份和子元组都必须仍然匹配。

在父级重试时，最终验证会独立选择最新可用的 Release Decision 和 Diagnostic Drain 工件。两者都必须绑定相同的不可变计划和精确的子元组；其源尝试仍会记录在工件中，并且当只有一个 Collector 需要重试时，它们可能不同。