定时与维护工作流

每小时 main CI¶

完整的 main 验证层级直接由 ci.yml 在每小时的第 23 分钟运行。GitHub 的定时事件会选择规范的 main 修订版本；手动分派输入不能主张定时运行策略。该定时计划选择完整的 main 层级（包括 Android），不会过滤到最后一个提交。Node、原生平台、文档、QA Smoke、浏览器进程证明以及已发布更新器幸存者均针对该修订版本运行。Node 测试使用完整的紧凑清单（包括工具和 PR 豁免文件），并受其 77 行 main 层级上限约束。

现有的 Plugin Prerelease 工作流分别拥有完整的扩展运行时清单，在每小时第 37 分钟运行。定时运行固定到定时的规范 main SHA，并且只选择其扩展矩阵和所需摘要。仅清单的捆绑插件以及 extensions/ 正下方的测试使用其现有的文件分片执行路径；包支持的插件保留其现有的批处理所有者。现有的十二任务并发限制保持不变。一个非取消的每小时槽位让进行中的证明完成，而 GitHub 合并待处理的 tips；手动和发布运行保留独立的并发组和所有现有阶段。普通 CI 不再追加第二个部分扩展清单。检查 CI 和 Plugin Prerelease 以了解每小时覆盖情况；Full Release Validation 将两个现有的子项固定到其确切目标。

Full Release Validation 和普通手动 CI 默认保留 validation_tier=full。它们额外运行仅发布版的运行时/UI 测试、最低 Node 版本兼容性、iOS 截图、原生 Release 构建、Android 打包，以及全部六个 Docker seed 场景。每小时 iOS 保留 ios-build (tests)：Swift lint、Rust 测试、语音清理、原生 Access，以及完整的聚焦应用/通知生命周期清单。托管附件 UI/导出证明、Watch 操作模拟器套件和 Watch 交付 UI 证明仅在完整层级的手动/发布验证中运行，并且所有案例和断言都保留在那里。Android 保留手机/Wear 测试和 lint。Docker 幸存者使用现有的 main smoke 包，包括运行时、资源、公共 SDK 声明和 tarball 完整性。手动 SDK API 差异报告仅保留手动：定时 tip 没有可比较的变更范围。

Main 层级的 iOS 构建面向所选模拟器的原生架构，并禁用编译器索引，PR smoke 已经这样做。语音和生命周期测试禁用 Xcode 的详细诊断收集，同时保留其日志和 xcresult 捆绑包。完整层级的手动/发布验证保留通用模拟器构建和失败诊断。这消除了在 76–94 分钟的每小时任务中观察到的重复架构工作和诊断停滞；它并不建立新的完成时限。

定时 CI 使用自动 main runner 放置，包括在配置时于首次尝试时进行混合放置。原生 runner 标签、worker 限制和重试回退保持不变。Control UI 和原生翻译源检查保持强制；生成的 locale 漂移仅为建议性质，因为合并后的翻译工作流负责其修复。普通手动运行（包括 validation_tier=main）保留严格的 locale 一致性。

Main 层级的运行不会发出完整验证修订版确认。Docs Agent 的自动写入门禁需要该完整层级回执；其显式手动分派仍然可用。

直接检查定时 CI 运行及其 openclaw/ci-gate 任务。每次定时运行都独立启动，因此较旧的 iOS 模拟器阶段不会阻塞下一个小时的核心检查。只有定时 ios-build 任务共享一个非取消槽位：当另一个任务到达时，活动证明完成，而 GitHub 替换待处理的 iOS 任务。到达顺序不必与修订版顺序匹配。在聚合所有者处，openclaw/ci-gate 仅对 main 上定时的 openclaw/openclaw 运行接受所选 ios-build 结果为 cancelled，并发出“Hourly iOS proof coalesced”通知。真实的 iOS 失败或意外跳过仍会使门禁失败，其他所选通道的取消也是如此。手动和 PR iOS 取消保留其现有失败策略。带此通知的通过门禁会将 iOS 证明委托给稍后的定时任务；它不会在已取消的修订版上验证 iOS。即使聚合成功，GitHub 的工作流级结论仍可以是 cancelled。手动/发布 CI 保持独立，仅安全推送不能取消定时工作。CI 在发布验证期间仍然可用；OPENCLAW_RELEASE_PRIORITY_RUN 不控制准入。

每小时 CI 负责文档检查，包括 RunsOn 路由。独立的 Docs 工作流保留手动和选择加入的推送运行。

Node Runtime Conformance 和 Plugin Init Scaffold Validation 每小时在第 23 分钟检查更改的输入。仅当所需任务在同一分支上 24 小时内通过且完整输入差异未更改时，它们才重用证明。跳过的任务不能推进比较基线。缺少证明、不完整的差异或 API 错误会请求新的验证。每个决策都会报告其理由。这两个工作流都保留其 PR 范围，并每天刷新证明以应对依赖漂移。

Sandbox Common Smoke 每天 05:23 UTC 运行，并保留 PR 和手动运行。Plugin NPM Release 每小时运行其非发布元数据和未发布包 pack 预览。计划不能进入其仅手动的批准或发布任务。Vitest Cache Warm 在每小时的第 17 分钟运行，保留其手动和 repository-dispatch 恢复路径。该预热器是独立的。不保证其在 CI 之前完成。

恢复按推送 CI¶

在 Settings → Secrets and variables → Actions → Variables 下将 仓库 Actions 变量 OPENCLAW_CI_ON_PUSH 设置为 true。这将恢复 CI 中此前按路径过滤的完整 main 推送准入、独立检查、插件工件预览和缓存预热。GitHub 字符串比较不区分大小写；请使用文档记录的小写 true。未设置、空值、false 和其他值将保持仅每小时的 main 层级 CI。删除该变量或将其设置为 false 可恢复默认行为。无论哪种方式，每小时运行都保持启用。不需要更改 secret、提交或保护设置。

如需立即运行主层级 CI，请选择 CI → Run workflow → main，选择主验证层级和 Android，或运行：

gh workflow run ci.yml --ref main -f validation_tier=main -f include_android=true

各个独立工作流也可以手动运行。直接 CI 派发和发布验证子工作流保留其现有输入和行为；当需要完整的平台覆盖时，请设置 include_android=true。要衡量开发分支上的每小时覆盖情况，请在该分支上派发 ci.yml，并设置 validation_tier=main 和 include_android=true。主层级要求工作流与检出共享同一修订版本；它不能使冻结的发布目标合格，也不能替代精确头提交的 PR 发布门禁。

推送时仍保留的内容¶

CodeQL 保留所有七个主推送安全类别。CI 在现有的非文档推送范围内保留 security-fast（已提交的私钥、变更工作流安全审计，以及生产依赖审计）。默认主分支推送还会针对推送的确切 before SHA 运行基线增长、断言安全、测试超时竞态和新协议方法元数据守卫，因此定时 CI 的“主分支与自身比较”不会丢失这些检查；Workflow Sanity 在每次获准的推送中检查已跟踪的冲突标记。其工作流 lint 和安全工具仅在工作流、操作或 lint 策略输入发生变化时运行。完整的 CI 聚合作业在默认主分支推送时会被跳过，不会在可运行的 PR 或完整手动运行时被跳过。CodeQL 和 Workflow Sanity 在发布验证期间仍然可用。PR 必需检查名称和安全审查强制措施保持不变。

发布及其前置检查保持事件驱动：文档镜像和网站安装程序同步、Runner 镜像发布、locale 生成 PR 以及 ClawSweeper 活动转发均保留其现有的准入机制。稳定主分支收尾会在发布输入发生变化时运行。现有的 pnpm release:stable 收尾阶段会等待发布成功、验证主分支，然后派发收尾。如果保存了编排器状态，可以通过 pnpm release:stable YYYY.M.PATCH --from closeout 恢复。

如果在主分支前向移植之后直接从 Actions UI 发布，请在 Release Publish 成功且主分支包含已发布版本和变更日志后派发收尾：

gh workflow run openclaw-stable-main-closeout.yml --ref main -f tag=vYYYY.M.PATCH

不相关的源推送不再轮询发布完成情况。手动恢复保留其现有的证据检查。Docs Agent 在允许其自动写入作业之前，会验证确切成功的完整层级 CI 尝试。选择加入的完整主分支推送符合条件；每小时主层级运行和仅安全推送不符合条件。因此，在未设置 OPENCLAW_CI_ON_PUSH 的情况下，Docs Agent 的自动写入将被禁用。显式的非机器人 Docs Agent 派发仍然可用，并且其对当前主分支和每小时节奏的守卫仍适用于符合条件的工作流运行调用。Security Review 仍然处理 PR 和手动 CI 的完成。Release/tag 工作流和仅 PR 工作流保留其现有触发器；此更改不会在原本不存在的地方添加合并队列支持，也不会更改任何仓库规则集。

GitHub cron 在默认分支上是尽力而为的，而不是一小时延迟 SLA：在负载较高时，运行可能会延迟或被丢弃，公共仓库的定时计划在长时间不活动后可能被禁用。主层级 CI 刻意对未变更的 SHA 重新检查，而不是引入单独的“上次成功”记录。失败可以在下一个每小时机会时重试，手动派发仍然可用。如果 iOS 验证耗时超过一小时，之后的每小时运行可以在等待该时段的同时完成其他检查。被取代的待处理 iOS 作业可以在委托 iOS 验证的情况下让其聚合状态保持绿色，但无法通过 Docs Agent 的资格检查。这些已完成的检查仍然消耗 runner 时间；每次运行的 worker 限制并不能共同限制并发的每小时运行。该时段不涵盖手动/PR iOS 作业或由旧工作流准入的运行。这移除的是工作流准入阻塞，而不是 runner 容量等待。本文不声称有已测得的成本节省或严格的完成间隔。

夜间完整发布验证¶

Full Release Validation Nightly（full-release-validation-nightly.yml）每 3 小时在 UTC 第 7 分钟（7 */3 * * *）运行一次，以便在提交不断合入时保持发布就绪状态的最新性，使用 stable profile、soak 和阻塞性能、reuse_evidence=true、rerun_group=all 以及 main-qualification 用途。它检出调度器确切的主分支 SHA，并运行 SHA 固定的辅助命令（pnpm ci:full-release --sha <sha> --workflow-sha <sha>），该命令将该 SHA 同时用作 Validation 和 Tooling SHA，并从不可变的 release-ci/<sha12>-<id> transport ref 派发。一旦 main 发生移动，从 main 直接派发就会失败，因为父工作流拒绝从已移动的工作流引用派发子工作流。同一 SHA 下仍处于活动状态的父工作流会共享该 SHA 特定的 Full Release Validation 并发组，并将此派发排队；已完成的父工作流会再次验证，并通过重用采用其自己的精确目标证据。父工作流在配置 OPENCLAW_RELEASE_RUNNER_GROUP 时会自动使用它。定时作业使用与父工作流 release_decision 等待者相同的 runner 选择和 720 分钟预算运行，与辅助命令的 720 分钟监视时间匹配。

该作业通过父工作流的 Release Decision 和证据验证对其进行监视，因此其结论就是验证结果。一个并发组涵盖定时运行和手动运行，且不会取消：当某个作业仍在监视其父工作流时，下一个触发器会等待，GitHub 只保留最新的待处理运行，因此运行永远不会重叠，最新等待触发器对应的 SHA 会随后运行。子工作流重用是精确目标式的：当 main 自上次运行以来未移动时，reuse_evidence=true 会让每个子工作流采用该运行的凭证，而不是再次运行；而新的 SHA 会派发全新的子工作流。作业日志会打印父工作流运行的 URL；上传的 full-release-validation-nightly-request 工件保存辅助命令的请求记录，供 node scripts/full-release-validation-at-sha.mjs --reconcile-request <path> 使用。失败后，辅助命令会保留两个 transport refs，以便重跑和诊断。要列出夜间父工作流，请按 transport 分支过滤：

gh run list --workflow full-release-validation.yml --event workflow_dispatch \
  --json databaseId,headBranch,headSha,status,conclusion \
  --jq '.[] | select(.headBranch | startswith("release-ci/"))'

OpenClaw 性能¶

OpenClaw Performance 是产品/运行时性能工作流。它在 main 上每日运行，并且可以手动触发：

gh workflow run openclaw-performance.yml --ref main -f profile=diagnostic -f repeat=3
gh workflow run openclaw-performance.yml --ref main -f profile=smoke -f repeat=1 -f deep_profile=true -f live_openai_candidate=true
gh workflow run openclaw-performance.yml --ref main -f target_ref=v2026.5.2 -f profile=diagnostic -f repeat=3

手动触发通常会对工作流 ref 进行基准测试。设置 target_ref 可使用当前工作流实现对发布标签或其他分支进行基准测试。已发布的报告路径和 latest 指针以被测 ref 为键，并且每个 index.md 都会记录被测 ref/SHA、工作流 ref/SHA、Kova ref、profile、lane 认证模式、模型、重复次数和场景过滤器。

该工作流从固定版本安装 OCM，并从 openclaw/Kova 在固定的 kova_ref 输入处安装 Kova，然后运行三条 lane：

• mock-provider：针对本地构建运行时、使用确定性伪 OpenAI 兼容认证的 Kova 诊断场景。
• mock-deep-profile：针对启动、网关和 agent-turn 热点的 CPU/堆/跟踪分析。按计划运行，或在 deep_profile=true 时通过触发运行。
• live-openai-candidate：真实的 OpenAI openai/gpt-5.6-luna agent turn。按计划选择，或在 live_openai_candidate=true 时通过触发选择。不符合实时凭据条件的候选项会被跳过。对于已选择且符合条件的 lane，缺少 OPENAI_API_KEY 会使该 lane 失败，而不是跳过它。

在允许部分 Kova 判定之前，报告门控要求聚合 RSS 和 CPU 样本与单个记录匹配，包括重复测量。即使样本数量匹配，缺失或被替换的样本也会使门控保持非零。

OpenClaw 原生源码探针在独立的 source_performance 作业中运行，在 resolve_target 之后与 Kova lane 并行运行：覆盖默认、跳过通道、内部钩子和五十插件启动场景的网关启动计时和内存；捆绑插件导入 RSS、重复的 mock-OpenAI channel-chat-baseline hello 循环、针对已启动网关的 CLI 启动命令，以及 SQLite 状态冒烟性能探针。当针对被测 ref 可获取先前发布的 mock-provider 源码报告时，源码摘要会将当前 RSS 和堆值与该基线进行比较，并将大幅 RSS 增加标记为 watch。发布者会将这些源码工件包含在 mock-provider 报告包中，Markdown 摘要位于 source/index.md，原始 JSON 位于其旁边。

每条 lane 都会上传其完整的 GitHub 工件，包括 CPU、堆、跟踪和压缩诊断包。独立的发布者作业会下载并验证这些工件，然后铸造一个短生命周期的 ClawSweeper GitHub App token，其范围仅限于 openclaw/clawgrit-reports 内容，并且只将其传递给 Git push 步骤。它会在 openclaw-performance/<tested-ref>/<run-id>-<attempt>/<lane>/ 下提交 report.json、report.md、index.md、源码探针工件以及包元数据/校验和；完整诊断归档保留在关联的 Actions 工件中。发布者在尝试 push 之前会拒绝任何超过 50 MB 的报告文件。当前被测 ref 指针是 openclaw-performance/<tested-ref>/latest-<lane>.json。如果 app-token 创建或报告发布失败，计划运行和 profile=release 触发会失败。手动非 release 触发会将发布保持为建议性，并在认证或发布失败时保留 GitHub 工件。先前源码基线从公共报告仓库匿名获取，因此成功的基线获取不能证明发布者认证。

所有显式的 Performance 工作流 Git 命令都使用固定的 Git 生命周期所有者， 在每个作业所选 checkout 之前于 RUNNER_TEMP 中准备。目标解析、 Kova 修订/安装 Git、源码修订和基线 Git，以及本地发布者 操作保持无限制。只有初始报告获取、每次 push 和每次 对账获取具有 120 秒截止时间。所有者在读取、checkout 复用、工件消费者、输出或重试之前 排空整个 Git 进程树；独占报告获取仅在进程消亡后回收调用创建的锁。

报告准备和所有获取都是匿名的。App token 仅 在新报告准备完成后创建，立即从环境中移除，并且 仅作为掩码 Basic 头传递给 push 命令；它永远不会进入远程 URL 或仓库配置。已验证的现有报告在 token 创建之前成功。 只有成功的空 ls-tree 查找才意味着基线或报告不存在； 仓库/读取失败是终止性的。格式错误的基线指针 JSON 保持 建议性，验证清理后的普通基线获取失败也是如此。

发布允许恰好五次 push。每次失败的 push，包括第五次， 都会获得 2/4/6/8/10 秒退避，随后进行一次匿名对账获取。 获取到的远程报告即使在第五次模糊 push 之后也证明成功；直接 push 成功无需获取。否则，尝试 1–4 会在 detached FETCH_HEAD 上使用 cherry-pick -X theirs 重放报告提交， 在保留并发唯一报告的同时，让当前写入者赢得 latest 指针。没有第五次尝试 重放。普通获取失败会在尝试 1–4 时警告并重试。只有经过验证清理后的类型化 Git 失败或超时时才允许恢复；所有者设置、进程普查、 清理失败和取消会在回退、重试、重放或成功之前停止。 Full Release Validation 继续完全禁用发布者，并仅将 性能证据保留为工作流工件。

网关并发基准测试¶

手动 gateway-concurrency 模式会测量一个繁忙的隔离 Gateway，并保留 其结果作为 Actions 工件：

gh workflow run openclaw-performance.yml --ref main \
  -f mode=gateway-concurrency -f live_openai_candidate=true

一个任务会构建一次所选源码，运行模拟提供商，然后可选地使用真实密钥运行 OpenAI。每次运行会在 32 个代理中初始化 1,000 个会话，并在会话更新、历史读取、订阅和 64 轮探测的同时完成 96 轮对话。Dreaming 功能已被禁用；正常的索引、回顾和数据库空闲保留策略保持不变。实际运行（live run）会拒绝工具调用，并将模型输出上限设为 128 个 token。结果包含负载阶段的主线程和 Worker CPU 分析。这两个提供商代表不同的工作负载，而非前后速度对比。

实际执行需要使用默认分支的工作流，且被测 SHA 必须等于工作流 SHA。如果该条件不满足，或缺少 OPENAI_API_KEY，所请求的实际运行将失败。省略 live_openai_candidate 可仅获取 mock 证据。此模式不运行任何 Kova 通道、源码探测任务，也不发布报告，并且不会被每日计划选中。有关本地调用和结果解读，请参阅 Gateway 并发。

Vitest 配对基准测试¶

仅手动触发的 vitest-pair 模式使用候选提交中的工作流实现，对两个精确提交进行比较：

gh workflow run openclaw-performance.yml \
  --ref <candidate-branch> \
  -f mode=vitest-pair \
  -f baseline_ref=<40-character-baseline-sha> \
  -f target_ref=<40-character-candidate-sha>

两个输入都必须是全小写的完整 SHA，target_ref 必须等于 --ref 所选的工作流 SHA，并且拒绝重跑。请触发一次全新的工作流运行，而不要重试某个尝试。在此模式下，Kova、源码探测、报告发布及其仅制品守卫（artifact-only guard）均保持跳过。基准测试任务拥有只读的仓库权限，不接收密钥，不恢复或保存 Actions 缓存，并在禁用凭据的情况下检出帮助程序、候选提交和基线提交。

已提交的通道清单覆盖具有代表性的核心单元测试、Gateway 测试、Control UI jsdom 测试和工作器生命周期测试。在创建计时状态之前，两个提交必须呈现相同的所选测试/配置路径和字节，并通过正确性检查。正确性还要求双方报告相同的规范化测试文件、测试标识、状态和计数。之后的每次运行都必须与该已建立的执行摘要一致。随后，测试框架会为每侧每通道运行一次不计入结果的预热，执行七轮以交替侧顺序和轮转通道顺序进行的配对轮次，外加一次单独标记、使用全新缓存的冷配对。冻结安装仅用于准备阶段，且从不计时。

每个子进程都有固定的截止时间和进程组所有者。单独的 165 分钟测试框架截止时间，在 180 分钟任务超时内预留 15 分钟，用于清理、最终清单（terminal-manifest）定稿和制品上传。在拒绝继续启动子进程之前，它会先中止并回收（join）当前活跃的受管理子进程。每个安装、正确性、预热、计时（measured）和冷进程都会通过 npm_execpath 接收精确固定的 pnpm 可执行文件，并使用独立的 Corepack 和 pnpm 状态；解析出的可执行文件及其版本会记录在环境和运行记录中。

制品包含原始日志、原始 Vitest JSON 报告、执行摘要和计数、GNU time 用户/系统 CPU、墙钟计时、环境和 Git 身份、源码/配置哈希、逐次运行记录、配对比率分析，以及最终的成败清单。在测试框架失败后，工作流仍会尝试完成定稿和制品上传。运行器丢失或外部取消工作流仍可能阻止这些步骤执行。可变的 pnpm 与运行时缓存保留在未上传的临时目录树中。阈值固定于 scripts/vitest-pair-benchmark-lanes.json。验收使用七轮每轮聚合比率的中位数，按通道总时长对每轮加权，超过 5% 即失败。关键通道只有在其中位数测量比率高于 10% 且中位数配对差值至少为一秒时才会失败。单独的冷配对始终作为诊断证据保留，绝不导致验收失败。只有当每个代表性通道的中位数超过改进比率，且其七个配对中至少有五个单独满足该比率时，报告才会声称存在改进。否则，它只报告逐通道证据，而不作广泛的改进声明。制品名称中仅使用可信的工作流运行 ID 和尝试编号；确切的基线提交和候选提交仍记录于制品内部。

Security Review 对账器¶

Security Review 每十分钟对 CI 完成结果进行一次对账，覆盖从上次成功计划扫描开始前五分钟到五分钟前的时间范围（六十分钟回退，十二小时上限）。各次扫描无缝衔接；延迟或丢失的 cron 触发只会扩大下一个窗口，直至达到上限。运行列表涵盖从窗口开始前三小时到当前时间的创建时间。GitHub 将每个过滤查询的结果数量上限设为 1,000，因此当报告总数超过该限制时，解析器会对范围进行二分。每个较小的范围都会分页读取直至出现不满页，且其去重后的运行数量必须覆盖第一页报告的总数。出现十个整页或去重运行数少于报告数时，该次扫描会在任何状态发布或矩阵输出之前失败，并保留锚点以进行完整重试。包含端点的范围端点之间相隔一秒，并且跨页面和分片的运行 ID 会进行去重。短于十分钟但仍超过 1,000 次运行的范围会在状态发布或矩阵输出之前失败，因此不会推进已覆盖的窗口。下一次扫描将从最后一次成功扫描的位置重新开始扫描。计划解析器的各次扫描共享一个并发组，但不会取消正在进行的扫描；GitHub 会保留一个待处理的扫描，它仍将从最后一个成功的窗口开始。每次扫描最多选择 100 个 PR head，按 CI 完成时间从早到晚排序，运行 ID 用于打破并列；达到上限后便停止读取状态。如果仍有候选，reconcile-backlog 任务会在所选审查完成后使工作流失败。这保持了相同的锚点：已审查的 head 拥有最新状态，从而允许下一次计划扫描从同一窗口中选取剩余部分。

在协调器中断超过十二小时后，较早丢失的完成事件需要一次新的推送或一次安全审查重跑。

CI 重跑会保留其原始创建时间。对于在窗口之前超过三小时创建的运行的重跑，会依赖其自身的完成投递；如果该投递丢失，则通过新的推送或安全审查重跑来恢复它。

完全跳过的 CI 运行会被忽略。解析器按时间倒序读取状态历史，并且只使用来自 github-actions[bot]、创建者类型为 Bot 的最新 openclaw/ci-gate 状态。其他发布者会被忽略。常规审查仅在该 Actions 拥有的状态缺失、早于 CI 完成时间或处于 pending 状态时运行。只有在 CI 完成时或之后创建的非 pending 状态才会被判定为已解决，并停止重新选择。每个 pending 状态仍然符合条件，包括在 CI 完成前的读取之后发布的审查等待。当 head 合理地等待较新的进行中 CI 时，分块窗口会限制无害的额外审查。它从不检出 PR 代码，并且每次 pass 使用一个托管的 ubuntu-24.04 解析器作业，每个新完成的 head 使用运行列表读取加上分页状态历史读取，并且不使用 Blacksmith 注册。参见 安全审查检查。

QA Lab¶

QA Lab 拥有独立于主智能范围工作流之外的专用 CI 通道。Agentic 一致性嵌套在广泛的 QA 和发布测试框架之下，而不是独立的 PR 工作流。当一致性需要随一次广泛验证运行一起执行时，请使用带有 rerun_group=qa-parity 的 Full Release Validation。

• QA-Lab - All Lanes 工作流每晚在 main 上运行，并支持手动触发；它会扇出模拟一致性以及实时的 Matrix、Telegram、Discord、WhatsApp 和 Slack 作业。实时作业使用 qa-live-shared 环境；Telegram、Discord、WhatsApp 和 Slack 使用 Convex 租约，而 Matrix 会配置一次性本地凭据。
• 手动和计划聚合运行保留默认的 all 并发范围。受信任的发布调用使用独立的 matrix 和 buzz 范围，以便这些通道可以为一个目标 SHA 一起运行；同一 SHA 的 Matrix 调用仍然串行化，而 Buzz 调用跨 SHA 串行化，因为它们共享池化凭据。
• 发布 Matrix 目录验证在 16-vCPU 的 Blacksmith runner 上运行，作业预算为 90 分钟。对该超时、runner 大小或并发的更改需要匹配的工作流守卫和精确候选发布证明。
• QA Profile Evidence 将分类法类别组平衡到八个隔离作业中，将非隔离的实时通道保留在一个分片上，然后要求 QA Lab 将它们已验证的证据合并为一个经过证明的 qa-evidence.json。超时或缺失的分片始终导致聚合失败；allow_failures 仅在所有分片都完成并产生有效证据时适用。直接 Maturity scorecard 调度默认开启 allow_failures，以便不完整的证据仍可以渲染诊断文档工件。最终结果门在可选的生成 PR 发布之后运行，当任何场景失败或仍被阻塞时使运行失败；可重用的发布调用默认保持严格。

计划、手动和发布 Matrix 检查使用确定性 mock provider，以便将实时传输契约与模型延迟和常规 provider-plugin 启动隔离。Telegram 发布检查使用相同的确定性模型边界。实时传输网关禁用内存搜索，因为 QA 一致性会单独覆盖内存行为；provider 连接性由独立的实时模型、原生 provider 和 Docker provider 套件覆盖。

OpenClaw Release Checks 还会在发布批准之前运行发布关键的 QA Lab 通道；其 QA 一致性门将候选包和基线包作为并行通道作业运行，然后将两个工件下载到一个小报告作业中，用于最终一致性比较。

对于普通 PR，请遵循范围化的 CI/check 证据，而不是将一致性视为必需状态。

CodeQL¶

CodeQL 工作流有意设计为狭窄的初筛安全扫描器，而不是完整的仓库扫描。每日、手动、main 推送以及非草稿 pull request 守卫运行会扫描 Actions 工作流代码以及最高风险的 JavaScript/TypeScript 表面，使用高置信度安全查询，并过滤到 high/critical security-severity。

pull request 守卫保持轻量：它仅针对 .github/actions、.github/codeql、.github/workflows、packages、scripts、src 或拥有进程的捆绑插件运行时路径下的更改启动，并且运行与计划工作流相同的高置信度安全矩阵。Android 和 macOS CodeQL 不包含在 PR 默认项中。

安全类别¶

平台特定安全分片¶

• CodeQL Android Critical Security — 计划中的 Android 安全分片。为 CodeQL 在工作流健全性检查接受的最小 Blacksmith Linux 运行器上手动构建 Android 应用。上传到 /codeql-critical-security/android。
• CodeQL macOS Critical Security — 每周/手动 macOS 安全分片。在 GitHub 托管的 Linux 上准备生成的 Mermaid 资源，然后在 GitHub 托管的 Intel 运行器上为 CodeQL 手动构建 ARM64 macOS 应用，不包含未使用的 index-store 或 debug-info 工件；在上传的 SARIF 中过滤掉依赖构建结果，同时保留第一方生成的协议模型；并上传到 /codeql-critical-security/macos。其 macOS 作业有 90 分钟上限，因为完整的带跟踪构建和分析超过了之前的 45 分钟预算。由于即使构建干净，macOS 构建也主导运行时间，因此保留在每日默认之外。

关键质量类别¶

CodeQL Critical Quality 是对应的非安全分片。它仅在 GitHub 托管的 Linux 运行器上，针对狭窄的高价值表面运行仅错误严重级别、非安全的 JavaScript/TypeScript 质量查询，以免质量扫描消耗 Blacksmith 运行器注册预算。其拉取请求守卫有意比计划配置更小：非草稿 PR 仅运行其触及的表面所匹配的分片，来自十三个可 PR 路由的分片 — agent-runtime-boundary、channel-runtime-boundary、config-boundary、core-auth-secrets、gateway-runtime-boundary、mcp-process-runtime-boundary、memory-runtime-boundary、network-runtime-boundary、plugin-boundary、plugin-sdk-package-contract、plugin-sdk-reply-runtime、provider-runtime-boundary 和 session-diagnostics-boundary。ui-control-plane 和 web-media-runtime-boundary 不纳入 PR 运行。CodeQL 配置和质量工作流更改会运行完整的 PR 分片集合（网络运行时分片以其自身的 CodeQL 配置文件和网络所属源路径为依据）。

手动调度接受：

profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|network-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary

这些狭窄配置是用于隔离运行单个质量分片的教学/迭代钩子。

在拉取请求中，网络运行时分片从快速差异扫描开始。敏感 socket 导入/调用和代理策略令牌、对其查询/配置/测试夹具的编辑，以及对 Codex 传输的更改会在同一 PR 作业中选择完整 CodeQL 分析。受监控的非测试源缺失或空补丁也会选择完整分析；元数据获取或解析失败会停止分片选择，而不是静默跳过它。已知的普通差异保持快速路径。完整路径在分析之前运行语义查询测试，包括对配置的 packages/net-policy/src 目录的覆盖，以及保留精确的 owner/function 允许项和测试路径排除项。完整分析在任何 SARIF 发现或缺失 SARIF 输出时都会使作业失败；敏感差异是路由信号，而不是发现。

质量与安全保持分离，以便质量发现项可以被调度、度量、禁用或扩展，而不会掩盖安全信号。Swift、Python 和捆绑插件的 CodeQL 扩展应仅在窄配置具有稳定运行时和信号后，作为范围限定或分片的后续工作重新加入。

维护工作流¶

PR CI Sweeper¶

PR CI Sweeper 每小时在第 7 分钟检查最近的拉取请求。它通过有界的关闭/重新打开循环修复缺失的 pull_request CI 和 GitHub startup_failure 运行，并在开始基础设施恢复时发出警告。草稿、最近更新或存在冲突的 PR，以及启用自动合并的 PR 保持不变。关联的排队中、运行中、失败或已取消的 CI 会阻止恢复：取消并不能证明提供商失败或测试从未执行，因此清理器永远不会自动重新执行这些工作流。

评论自动化¶

评论作业在获取托管运行器之前拒绝已知的无操作。Maintainer Command Reactions 仅在使用其默认命令列表时跳过没有 / 的评论；任何非空的 MAINTAINER_COMMAND_REACTIONS 覆盖都会保留完整匹配器，包括没有斜杠的命令。Auto response 会跳过 Barnacle 已经忽略的 Bot 创建的问题评论，以及作者关联已经豁免的目标。其编辑准入保留标题、正文和 PR 基础变更。PR context checks 省略策略中已知的机器人和特权作者豁免。Labeler 保留标题/基础 PR 编辑，并跳过未更改标题的问题编辑。这些决策发生在检出和运行器分配之前。

Auto response、Labeler、PR context checks 和 ClawSweeper 仅在作业准入后获取并发槽位。跳过的事件不能替代有用的待处理工作。Labeler 为每个 PR 和问题使用单独的组，手动回填单独串行化；PR context checks 取消同一 PR 上已被取代的检查。ClawSweeper 保留其现有的逐项取消规则和所有标签/评论接收，仅跳过明确为空的元数据编辑。Security Review 省略仅 PR 文本编辑，同时保留基础/权限变更、head 变更和审批撤销；其按 head 的审查串行化保持不可取消。

依赖审计¶

Dependency Audit 每天在 UTC 07:23 以及手动派发时运行生产 lockfile 审计。它与 PR CI 保持分离，并在发现项、不可用的公告或无效数据时失败。每个依赖图作为一个请求提交；发布检查保持其产品和工具图分离。

普通 CI 和此严格审计都会在作业摘要中发布结果、包数量、持续时间、时间戳和有界失败原因。已完成的 npm 检查仅覆盖 npm 批量公告，而非所有上游公告源。

分诊负责人是 @steipete，于 2026-09-03 在 #137960 中设置。没有 .github/CODEOWNERS 规则覆盖 .github/workflows/dependency-audit.yml，因此该行是该项所有权的唯一记录。 调查失败的计划运行并重新运行严格工作流以确认恢复：

gh workflow run dependency-audit.yml --repo openclaw/openclaw --ref main

GitHub 会将计划运行通知发送给工作流创建者或最新的 cron 编辑器，具体取决于该账户的 Actions 通知设置。接管所有权时请保持这些通知启用；摘要提及不会发送警报。参见 GitHub 的工作流通知规则。

要在本地复现，运行 node scripts/pre-commit/pnpm-audit-prod.mjs --audit-level=high。添加 --ci 会选择更短的 30 秒诊断预算，但保留退出码：0 表示没有匹配发现，1 表示发现项或错误，2 表示覆盖不完整。 普通 CI、计划审计和本地钩子会传播所有非零退出码。 由 Full Release Validation 或版本发布派发的 CI 会将非零退出码报告为警告，因为公告从不阻止版本发布。

Docs Sync Publish Repo¶

Docs Sync Publish Repo 在 openclaw/docs 中组装英文、ClawHub 和保留的翻译页面。在每次最终 rebase 之后、推送之前，它使用 npm ci 安装发布者的现有 npm lock，并检查生成的文档树。推送重试会复用该安装，除非发布者清单或 lock 发生变化。检查器原生运行在 Node 24 上；不会安装单独的检查器依赖图或 TypeScript 加载器。

一次性 Actions 验证缓存按仓库相对路径和完整原始内容哈希记录成功的页面检查。检查器和辅助程序变更、Node/运行时变更，或请求/已安装的 npm lock 变更会使复用失效。缺失或损坏的缓存数据会触发完整检查；已删除页面会在下一次成功缓存中被清除。docs.json 每次都会检查，包括热运行。只有成功的主分支工作流会保存工件，且位于发布仓库之外。检查器保留其 Markdown/MDX 格式检测、毒化文本检查和组件缩进检查；它不会替代站点渲染器或跨页面链接验证。

文档代理¶

Docs Agent 工作流使现有文档与最近落地的变更保持一致。它没有纯定时触发。已选择加入的完整 main-push CI 运行可以允许自动写入；每小时 main-tier CI 不可以。当 OPENCLAW_CI_ON_PUSH 未设置时，使用显式的非机器人 Docs Agent 调度来运行它。一个只读作业会在允许可写入作业之前，验证规范 CI 工作流、精确的已完成运行尝试、当前 main SHA、成功的聚合以及成功的修订确认步骤。对于 main-tier 运行、仅安全推送、失败的完整 CI，以及针对其他目标或缩小范围的手动验证，该生产者步骤不存在/被跳过。普通机器人推送仍被排除。

只有被允许写入的作业占用不可取消的文档并发槽位，因此被跳过的推送无法挤占待处理且符合条件的自动或手动工作。工作流运行调用会重新检查 main 新鲜度，并检查最近最多 100 次运行的精确尝试作业证据。排队中或活动中的写入作业，或最近实际运行了代理的尝试，都计入一小时节奏。已取消和已跳过的工作流、被拒绝的验证，以及跳过了代理的已完成写入门控均不计入。当被允许时，代理从上一个成功写入作业（其代理步骤成功）的源 SHA 审查到当前 main。

失败的代理尝试可以在一小时内节流另一次尝试，但不会推进审查基线。如果无法读取历史证据，门控会在运行代理之前失败。

合并后的重复 PR¶

Duplicate PRs After Merge 工作流是用于合并后重复清理的手动维护者工作流。它默认执行 dry-run，并且仅在 apply=true 时关闭明确列出的 PR。在修改 GitHub 之前，它会验证已落地的 PR 已合并，并且每个重复项要么共享引用的 issue，要么具有重叠的变更 hunk。

gh workflow run duplicate-after-merge.yml \
  -f landed_pr=70532 \
  -f duplicate_prs='70530,70592' \
  -f apply=true

更新迁移¶

Update Migration 每周在周日 03:17 UTC 以及手动调度时运行扩展的已发布升级基线集。它同时保留 plugin-deps-cleanup 和 legacy-operator-state，且没有 provider 密钥。其独立的不可取消调度组会合并待处理运行，并且无法取消手动验证。有关运行时基线解析、按基线分组、每周 78–90 runner 分钟计划额度以及成功升级要求，请参阅 Package Acceptance 套件配置。Runner 注册预算 将每周突发与 PR 和 main 准入分开计算。

ClawSweeper 活动转发¶

.github/workflows/clawsweeper-dispatch.yml 是从 OpenClaw 仓库活动到 ClawSweeper 的目标端桥接。它不会检出或执行不受信任的 pull request 代码。该工作流从 CLAWSWEEPER_APP_PRIVATE_KEY 创建 GitHub App token，然后向 openclaw/clawsweeper 调度紧凑的 repository_dispatch 负载。

调度 API 调用会对速率限制失败进行最多五次重试，并使用二次退避。其他 API 错误会立即停止，重试耗尽后会保留最终 API 退出码。调度调用方在失败时发出警告并继续，而不是报告调度成功。

该工作流有三条通道：

• clawsweeper_item 用于精确的 issue 和 pull request 审查请求；
• clawsweeper_comment 用于 issue 评论中显式的 ClawSweeper 命令；
• github_activity 用于 ClawSweeper 代理可能检查的一般 GitHub 活动。

github_activity 通道仅转发规范化元数据：事件类型、操作、操作者、仓库、条目编号、URL、标题、状态，以及存在时的评论或审查短摘录。它有意避免转发完整的 webhook 主体。openclaw/clawsweeper 中的接收工作流是 .github/workflows/github-activity.yml，它将规范化事件发布到 OpenClaw Gateway hook，供 ClawSweeper 代理使用。

main 推送仍然是 github_activity 观察。它们不会生成托管的按 commit 报告或 commit Check Runs。

一般活动是观察，而不是默认投递。ClawSweeper 代理会在其 prompt 中接收 Discord 目标，并且仅当事件令人意外、可操作、有风险或在操作上有用时，才应发布到 #clawsweeper。常规打开、编辑、机器人变动、重复 webhook 噪声和正常审查流量应导致 NO_REPLY。

在整个此路径中，将 GitHub 标题、评论、正文、审查文本、分支名称和 commit 消息视为不受信任的数据。它们是用于摘要和分诊的输入，而不是工作流或代理运行时的指令。

Barnacle 将带有 bug 标签的 issue 视为验证候选项，而不是不活动关闭候选项。它可以添加 stale 标签，这会调度一次精确的 ClawSweeper 审查，但它不能关闭该 issue。ClawSweeper 随后可以应用有证据支持的解决方案；在当前 main 上已证实的修复会作为已完成关闭，而当前或结论不明确的 bug 保持打开。stale 工作流还会审计最近的关闭事件，并在 Barnacle 身份将 bug 作为 not_planned 关闭时失败。

相关¶

• 安装概览
• 发布渠道