手动调度

手动 CI 分发行为、发布门禁回退机制以及 Windows Testbox Probe。属于 CI 范围与路由 索引的一部分。

手动分发¶

普通手动 CI 分发运行与常规 CI 相同的作业图，但会强制启用所有非 Android 作用域通道：Linux Node 分片、捆绑插件分片、插件与渠道契约分片、Node 24 最低兼容性、check-*、check-additional-*、构建产物冒烟检查、文档检查、Python 技能、Windows、macOS、完整 iOS 构建/测试与截图资格认证，以及 Control UI/原生应用 i18n。它们的逻辑运行器配置始终为 github，与 runs-on 选择的物理回退无关。Node 24 最低兼容性仅在 Full Release Validation 和手动分发中运行；push 和 pull request CI 会跳过它。精确头部的 release_gate 回退则保留 pull request 的 macOS、iOS 冒烟和生成原生语言环境作用域，但不选择 iOS 截图或原生测试。

自动源 PR 和发布门禁会验证原生提取清单以及 Android/Apple 本地化安全性，而不要求同一 PR 中包含已翻译或平台生成的输出。串行化的 Native App Locale Refresh 工作流会在一个隔离 PR 中重建这些产物，并在必需检查通过后启用精确头部自动合并。原生对等性对于生成产物 PR、生成作用域发布门禁、普通手动 CI、全作用域发布验证和发布准备仍是阻塞项。在语言环境刷新赶上之前，CI 会将已被证明过时的原生翻译 ID、Android 生成行和 Apple 目录行报告为警告；活动键覆盖率、正确性以及所有其他对等性检查仍为阻塞项。确切边界见本地检查。Control UI 语言环境对等性在自动 PR 和 main 运行上仍为建议性，在手动/发布 CI 上为阻塞性。

独立的手动 CI 分发仅在 include_android=true 时运行 Android（release_gate 输入也会强制 Android）；全作用域发布验证通过传递 include_android=true 而不设置 release_gate 来启用 Android；npm 资格认证作用域会推迟 Android。插件预发布静态检查、完整的 agentic-plugins 扫描、完整的扩展批量扫描以及插件预发布 Docker 通道均从 CI 中排除。Docker 预发布套件仅在 Full Release Validation 分发单独的 Plugin Prerelease 工作流且启用发布验证门禁时运行。

PR 基线棘轮从其检出的合成合并树中获取比较状态，并针对事件头部校验其头部父提交。max-lines 条目在断言安全检查之前，将环境变量预算与相同的 fork-point 引用串联起来，因此生产源码的增长不会首先在 main 上暴露。手动运行使用唯一并发组，因此发布候选的完整套件不会因同一 ref 上的另一次 push 或 PR 运行而被取消。可选的 target_ref 输入允许受信任调用者针对分支、标签或完整提交 SHA 运行该作业图，同时使用所选分发 ref 中的工作流文件；棘轮基线会与目标相对于该运行解析出的默认分支头部的合并基进行比较。release_gate 输入是面向容量停滞的 PR CI 的精确 SHA 维护者回退：它要求 target_ref 为与所分发分支头部匹配的完整提交 SHA，并要求 pull_request_number 标识其合并树被验证的未关闭 PR。发布门禁合并树 lint 使用与托管 PR CI 相同的五个核心条带外加一个扩展条带，因此没有任何单个托管运行器独自承担完整的类型感知 lint 工作负载。

普通规范手动 CI 还保留 QA Smoke 的完整配置和 Control UI 性能，并且不进行 owner-path 过滤。当目标声明 docker-seed-e2e-contract-v1 时，它会选择 published-upgrade-survivor，从而保留每次被接纳的规范 main 运行所使用的精确 legacy-operator-state 加 auto-auth 证明。每次普通手动分发都会通过 resolveDockerSeedLanes 添加 cron-mcp-cleanup、fleet-cache、mcp-channels、mcp-code-mode-gateway 和 update-channel-switch，包括 npm-beta 和 npm-stable 资格认证。没有层级选择器的旧目标仍保留 survivor 通道。普通手动 CI 构建完整包。仅 main 的 ciArtifacts 准备也适用于被接纳的 main 形态资格认证分发；这些分发会复现 main 作业以进行时间对比。Pull request 和精确头部 release_gate 回退会省略 Docker seed 和 QA Smoke。Full Release Validation 通过其常规 CI 子流程到达这些通道，且不设置 release_gate；冻结目标保留其现有能力检查。

gh workflow run ci.yml --ref release/YYYY.M.PATCH
gh workflow run ci.yml --ref main -f target_ref=<branch-or-sha> -f include_android=true
VALIDATION_SHA="<full-commit-sha>"
gh workflow run full-release-validation.yml --ref main \
  -f trusted_workflow_json='{"trustedWorkflow":null,"validationPurpose":"diagnostic","publicationSelection":null}' \
  -f ref="$VALIDATION_SHA" \
  -f expected_sha="$VALIDATION_SHA"

Gateway extended-stable 共享发布要求针对冻结的 extended-stable/YYYY.M.33 尖端，使用受信任的 main-pinned release-ci/* 编排器完成完整的精确目标 Full Release Validation。直接的 canonical 分支和 main 生产者不能满足受保护发布器。当前清单还提供合格的 npm 预检产物。共享的 OpenClaw Release Publish 父工作流从位于冻结的 trusted-main Tooling SHA 上的受保护轻量级 release-publish/<sha12>-<epoch> 标签分发，并使用 npm_dist_tag=extended-stable 发布官方 npm 插件和核心、附加证据、发布 Docker，并完成一个非 Latest 的 GitHub Release。只有 extended-stable* 容器别名会推进；ClawHub、native-app、网站、常规 npm latest 和私有 dist-tag 发布面均被排除。Core-resume 恢复会在恢复证据和继续定稿之前验证现有 registry 字节；仅 Docker 恢复不会改动 GitHub 发布定稿。命令与恢复步骤请参阅月度 Gateway extended-stable 发布。

Windows Testbox 探针¶

手动 windows-testbox-probe.yml 工作流将 Windows/WSL 探测和无头 Windows CI 保持在所选 runner_label 上。run_windows_ci 输入（默认 false）在未提供已安装包绑定时，请求运行无头 CI，并在 GitHub 托管的 windows-2025 上运行一个独立的原生计划任务证明作业。两个作业互不依赖，因此其结果保持独立可见；任一请求的证明失败都会使工作流失败。

设置 skip_defender_exclusions=true 可让 Windows Defender 策略在整个工作流中保持不变，包括原生和已安装计划任务证明作业。这仅跳过工作区和 Node 进程排除项；证明选择、隔离检查、原生生命周期测试、清理和证据上传保持不变。默认值为 false，保留 Windows CI 和精确重放现有的尽力而为排除项。

对于两种证明，将 target_ref 设置为精确的 40 字符提交 SHA。两个作业都会检出该目标，原生证明在运行生命周期测试前会验证检出一致性。原生预检在 setup 之前运行，并要求交互式 Windows 会话。非交互式 runner 会使资格检查失败，而不是静默跳过证明。选择 windows-2025 不会确立原生资格：不变的生命周期断言和清理必须在实际 runner 上通过。失败后仍会运行清理和诊断上传，保留的证据仅在清理和上传成功后移除。

已安装计划任务升级¶

设置 run_windows_ci=true，并提供来自一次成功 Package Acceptance 运行的一个 installed_startup_package 绑定、runner_label=windows-2025 和 keepalive_minutes=0。分发已审查的工作流修订版，并将其精确 SHA 用作 target_ref；该绑定独立固定产品包。关闭其他证明模式。当包绑定为空时，上述独立的仅源代码 CI 和原生作业保持其行为不变。

现有包解析器会对候选项进行身份验证，然后在同一工作流运行中将已验证工件传递给原生作业。该作业保留 contents: read 权限。它会针对候选项运行一个全新安装的候选项以及未更改的已发布 2026.9.3 和 2026.9.4 CLI 更新器。每次升级还会在其规范 Task 名称下保留一个独立的运行配置。实时状态握手必须与已验证包版本和构建 ID 匹配；更新后的 Gateway 必须具有新的 PID，而对等端保留其 PID 和基线身份。候选项更新预览和深度 Doctor 发现会检查实际注册的 Task 操作，包括一个被报告为多余的已禁用自定义命名 Gateway CMD 任务，以及一个已拥有的已禁用任务，其缺少启动器。新的 cell 还会检查一个已禁用的直接可执行操作，并验证打包更新预览使其不支持的自动服务管理保持不可用。这证明的是只读检查和保留，而不是直接操作执行或更新变更。

各 cell 按顺序准备自己的常规 npm 安装。在废弃可丢弃前缀和缓存或下一个 cell 启动之前，必须成功完成实际 Task 和后代清理以及不可变证明上传。失败的 cell 会保留其证据并停止序列；强制命令清理不能建立通过的自然退出结果。最终工件要求所有三个 cell。

测试夹具在工具设置后检查实际可用空间，并对照临时 13 GiB 全新安装和 29 GiB 已发布成对配额。这些是规划配额，而不是实测包边界或 runner 容量。它会在生命周期边界记录空间和拥有的分配；观察之间的瞬时峰值仍未知。现有命令、测试、步骤和作业截止时间保持不变。

精确 Windows 测试重放¶

对于来自已记录 CI 失败的有序诊断，将 windows_ci_replay 设置为包含 nodeVersion、packageManager、vitestVersion、maxWorkers、files 和 projects 的 JSON 对象。使用精确的 Node 24 补丁版本，以及检出中完整的 pnpm 完整性固定值和 Vitest 版本。maxWorkers 是 1 到 4 之间的整数。files 是原始有序的字面量、受跟踪测试路径数组；projects 是原始的 test/vitest/vitest.<name>.config.ts 路径有序数组。不接受通配符、shell 文本、任意 CLI 参数和环境变量覆盖。

将 target_ref 设置为精确的源 SHA，选择原始 runner_label，设置 keepalive_minutes=0，并关闭所有其他证明模式。这仅运行现有的 scripts/test-projects.mts 入口点，并带有 --fileParallelism、一次一个项目进程、请求的 worker 数量，以及原始 Windows CI 堆和扩展分片设置。常规 CI worker 策略保持不变。运行时准备和进程生命周期仍由冻结源代码的调度器负责；工作流不会将当前测试工具复制进去。

将基线和失败源作为同一已审查工作流修订版下的独立、串行工作流调用运行。每个调用都拥有自己的 runner 检出和冻结安装；切勿在活跃检出中切换源。记录两次运行的实际 CPU/RAM，而不是根据 runner 标签推断容量。

windows-ci-replay-<runId>-<attempt> 工件保留输入、源和工作流标识、依赖哈希、原生运行时/资源、精确 argv、组合输出、进程状态、观察到的项目顺序以及保留命名空间诊断。成功的测试命令如果缺少完整的预期项目序列，则资格检查失败。较早的失败会保留其部分序列并保持失败状态。不添加重放重试或通过/失败豁免。

没有持久 Testbox 租约、SSH 设置或 keepalive。现有测试所有者处理常规生命周期；Actions 负责最终作业/runner 拆除。当后代结算未验证时，冻结的 Windows runner 可能保留临时命名空间。不要在运行期间删除它们，也不要从零进程状态推断结算。保留该诊断，检查最终 runner 清理，并将任何缺失的拆除证据与测试结果分开报告。

已安装 repair-worker 兼容性与清理¶

将 installed_repair_worker=true 与一个 installed_startup_package 绑定一起设置， runner_label=windows-2025，以及 keepalive_minutes=0。将 target_ref 固定为 与已分发工作流相同的已审查提交。保持其他证明模式关闭。 现有包所有者安装并验证精确的候选工件； 原生准入门控要求一个全新的托管 runner，且没有凭据、 操作员挂载、Tailnet 附加或托管身份。

探针进行身份验证并安装 npm 版本 2026.9.4 和 2026.9.5，然后 针对已安装的候选 worker 调用它们未更改的已发布 repair 控制器。 版本 2026.9.4 委托其验证阶段；2026.9.5 也委托验证。 每个版本都必须在不产生 provider 请求、验证调用或合成状态更改的情况下 收到延迟的不可用结果。这证明的是控制器兼容性， 而不是完整的 installed-updater 升级。

独立的 cell 使用候选的打包 executor 和 ledger 所有者， 针对环回模型 fixture 准入真实委托工作，并拒绝错误的接收方。 真实工具会启动后代进程。worker 的正常退出和强制退出 都必须在父 executor 稳定前移除它们，同时外部 observer 及其 Windows Job 启动器保持存活。父级或外部清理无法满足该断言。 原始 90 秒 worker、 60 秒 turn、120 秒 cell 和 2 秒消亡截止时间保持不变。

windows-installed-startup-<runId>-<attempt> 工件保留 repair-results.json、失败或完成的 cell、原生 Job 观察、 PID/启动身份、精确的包/控制器/运行时/工具链哈希、合成 provider 计数、状态影响以及最终清理。探针在失败 cell 后停止， 并且从不以成功的 runner 拆除替代 worker 资格验证。

已安装 Gateway 启动测量¶

同一工作流可以在选定的 Windows runner 上测量一个不可变 npm 包。将 target_ref 设置为完整工具链提交，run_windows_ci=false， keepalive_minutes=0，并将 startup_node_version 设置为精确的 Node 版本 （默认 26.9.0）。保持 WSL 和 Defender 输入为默认值。可选的 installed_startup_package 输入是一个 JSON 对象，包含 runId、runAttempt、 workflowSha、artifactId、artifactDigest、packageSha256 和 sourceSha。 使用来自成功 Package Acceptance 运行的不可变 package-under-test-<runId>-<runAttempt> 工件。工作流验证其生产者和 工件元数据，通过 package-candidate 所有者解析它，并使用 常规 npm 生命周期脚本安装和重建。

在基准测试的生命周期 fixture 在 Windows 上通过后，已安装的 openclaw.mjs 先使用新的合成状态运行一次，然后使用相同状态 再运行八次。每个样本记录 HTTP 就绪状态、首次 status 和 health RPC 响应，以及已确认的优雅关闭。外层受管 Windows Job 包含控制器和所有后代；最终成功要求在强制 Job 清理前 同时实现干净的 Gateway 关闭和观察到的后代稳定。 测量期间不运行同步进程采样器或启动分析器。

windows-installed-startup-<runId>-<runAttempt> 工件保留全部九个 样本槽位、错误、包/运行时/辅助哈希、源代码和工具链提交、 runner 硬件、原始已安装 npm lockfile 以及清理证据。流式 cohort.log 保留活动 PID、阶段、子进程输出以及已完成的 probe/RPC 观察，即使取消阻止了最终样本检查点。合成数据库和编译缓存 保留在 runner 的临时目录中。失败或中断的 cohort 没有 已建立的摘要。“Fresh” 表示新状态，而不是冷文件系统；专用 runner 结果建立新基线，并不建立相对于另一台桌面计算机的加速。 Health RPC 成功与记录的插件可用性和降级诊断是分开的。

对于匹配比较，将 installed_startup_package 传递为 {"baseline": <package-binding>, "candidate": <package-binding>}。两个绑定 使用上述相同字段。工作流在测量前解析并通常在一个 runner 上安装两个包。它们的完整 npm lock 记录必须 匹配，除了独立验证的 OpenClaw tarball 引用和完整性。 任何依赖漂移都会在 Gateway 启动前停止比较；两个原始 lock 均保留为证据。包必须具有相同版本和依赖图。

每个包拥有自己的不可变安装和合成状态/缓存目录。 cohort 计划 18 个槽位：先 fresh 基线，然后 fresh 候选，随后是八对 重启，交替使用基线/候选和候选/基线顺序。两个 臂在重启之间保留各自状态。没有丢弃的预热或 替换样本。失败会停止 cohort，保留剩余未运行 槽位，并使比较摘要失效。每个样本的截止时间保持 不变；两个臂的外层生命周期预算从 30 分钟扩展到 60 分钟。

在所有样本和后代稳定后，比较报告每个臂 已建立的 readiness 和绝对首次 status/health 完成时间，以及配对的 候选减基线差值。负差值有利于候选。 Fresh 样本保持独立。交替顺序减少时间顺序偏差；它 不会使文件系统变冷，也不会在其他机器上建立性能。

对于 CPU 归因，使用一个包绑定设置 installed_startup_cpu_diagnostic=true。 该独立模式运行一次未分析的 fresh prime，然后使用相同合成状态 对一次已建立启动进行原生 CPU 分析。两次启动 仍要求 readiness、首次 status/health 请求、已确认关闭 以及后代稳定。它不生成计时摘要或配对比较。 工件保留原始 .cpuprofile 文件、主进程/线程身份、 preload 时钟观察、启动 trace 指标、配置哈希以及备份存在 事实。preload 的单调时钟和 performance-clock 观察在 Gateway 进程内仍可用于校准。Controller、Gateway 和 native-profile 时间戳具有分别识别的时钟域；它们的对齐尚未 建立。不要跨这些域比较绝对值，也不要假设某个 profile 的最后采样时间戳包含 preload 的退出观察。 控制台和流 trace 输出共享诊断 observer，包括在 Bun 下。 分析和 trace 观察会增加开销；main-isolate 样本未计入 未分析的 child 或 Worker CPU。常规计时 cohort 保持 未插桩。