CI 管道作业

OpenClaw CI 在推送到 main 时运行，该推送会更改 **/*.md 和 docs/** 之外的路径、在每个非草稿拉取请求以及手动调度时运行。仅文档主推跳过 CI；混合文档和代码推送仍然可以运行它。拉取请求文档范围未更改。上游 main 推送使用由运行号奇偶校验键控的两槽管道，因此最多两个集成运行重叠。每个插槽都是不可取消的，并保留一个合并的待处理提示：新的合并会替换该插槽的旧待处理运行，而不是取消已注册铁匠矩阵的工作。两个槽中的运行可能会乱序完成；精确头消费者仍然受到其请求的 SHA 的约束，并且不受影响。拉取请求仍然取消被取代的头，并且手动调度使用隔离组。草稿无操作事件在作业门控之前使用每次运行的隔离组，因此延迟的草稿事件无法取代挂起或正在运行的准备审核 CI。 converted_to_draft 保留 PR-wide 组取消较早的 CI，同时跳过其自己的作业。显式工作流取消和手动调度行为不变；草案隔离不增加下游自动恢复。 preflight 对差异进行分类，并在仅不相关区域发生变化时关闭昂贵的通道。普通手册 workflow_dispatch 有意绕过智能范围界定，并扇出完整的图表以进行候选版本和广泛验证。精确头 release_gate 回退保留拉取请求的 macOS、iOS 烟雾和本机生成的区域设置范围，而不是强制不相关的 Apple 通道或区域设置奇偶校验。本机源验证仍在运行。 Android 通道通过 include_android（或 release_gate 输入）保持选择加入状态。仅发布插件覆盖范围位于单独的 Plugin Prerelease 工作流程中，并且仅从 Full Release Validation 或显式手动调度运行。

完整的 Node 计划通过 RELEASE_ONLY_TOOLING_SHARDS 保留了完整的维护人员工具系列，并且匹配的维护人员保留了混合快速配置。纯产品 PR 在精确和广泛的后备计划中都忽略了这个系列。 PR 接触工具测试或所有者运行整个系列：scripts/**、src/scripts/**、test/**、.github/**、config/**、根包和 pnpm 输入、工具配置以及按共享分类为工具的其他输入scripts/test-projects.test-support.mts 中的更改路径所有者。该所有者还涵盖 Docker、agent/Crabbox 工具、应用程序 scripts/Fastlane 和扩展 scripts/package 输入。现有工具 Vitest 配置和快速配置清单仍然决定执行。维护者叶子保留其原始的普通、隔离或假定时器配置和进程引脚；过滤混合组会保留其产品测试并使用单独的子集计时标识。五个 test/scripts/*.e2e.test.ts 产品集成门仍然在此维护者层之外。

src/cli/update-cli/update-command-legacy-finalize.test.ts 中的已发布更新程序组合使用该层中现有的 tooling-isolated 项目。它的真正终结器、本机重启、租赁权限和取消清理案例保持不变。普通产品PR和主推省略；工具所有者 PR 和 manual/full-release 验证保留它。直接文件运行和广泛的 pnpm test src/cli 运行仍然选择其独立的所有者。

每个 CI 手动调度都包含完整的工具系列。完整发布验证的 normal_ci 子级将 CI 分派给冻结的候选者，其中 Run Node test shard 在常规发布发布门接受活动之前执行那些未更改的测试。 OpenClaw 发布检查和插件预发布是单独的证明所有者。这是候选人验证，而不是推迟到晋升的测试。直接的人类测试版发布以及经批准的仅飞行前证据仍然是全面活动验证的明确现有例外；此级别不会改变出版机构。 Fork 存储库保留其现有的完整工具覆盖范围，因为它们不使用共享的更改测试计划程序。针对此存储库的分叉源 PR 使用标准 PR 选择并保留变更所有者覆盖范围。

主推计划已经省略了命名的工具碎片；他们现在还省略了以前由快速配置保留的维护者留下的内容，甚至对于工具所有者的更改也是如此。因此，后续主合并引入的回归对于主 CI 来说仍然不可见，直到受影响的 PR 或完整的 manual/release 验证运行该系列。 PR merge-ref 结果仅证明了它测试的树。当前ci-gate聚合了选定的作业；它没有针对以后的主要修订添加单独的工具证明。

计划的 QA 每晚 04：41 UTC 运行。其实时运行时作业运行 gateway-restart-full-access-live 场景和 openai/gpt-5.6-luna 以及三次重启重放安全场景。完全访问检查必须保留 shell 访问和委派，而不会重复中断的副作用；失败使工作失败。这两个场景都串行运行，并将其报告保留在作业的上传工件中。

流水线概览

部分工作流重新运行会重复使用同一运行的早期尝试中的成功屏幕截图碎片。减速器仍然需要匹配源和工作流 SHA、运行 ID、固定工具、工件摘要和成功捕获。它保存了每个家庭的生产者尝试，并分别记录减速器尝试；未来尝试的工件仍然无效。

Android 屏幕截图使用共享 Android 工具链操作的 API 36 手机和 API 34 穿戴设备图像和 KVM 设置在 ubuntu-24.04 上连续运行手机和穿戴设备。它调用 pnpm android:screenshots，该脚本也由 Android Fastlane 发布通道调用，无需签名或存储凭据。捕获失败、取消和选定的跳过失败 openclaw/ci-gate。工件将 JPEG、source/hash 清单、UI 转储、活动启动和 emulator/app 诊断保留 14 天，包括来自失败捕获的可用证据。

选择涵盖 Android 应用程序和构建输入、屏幕截图工具、共享资产、本机协议和区域设置生成输入以及 CI 设置。普通 JVM 测试、仅基准测试更改、商店列表元数据和文档不选择捕获。不可用的changed-path信息选择捕获。与 iOS 屏幕截图一样，该通道不包括每小时主要目标、兼容性目标和部分 npm 发布范围。它检查管道完整性和现场准备情况；它不会将像素与基线进行比较。

Test运行时选择

本地开发和测试现在默认使用固定的 Bun 前叉； CI 保留其规划器选择的运行时间。仅主 Node 通道（包括 Control UI 测试）是已知的 Bun 覆盖差距：更改可以通过主 CI，同时破坏本地 Bun 执行。 PR 和双运行时验证提供当前的 Bun 覆盖范围。

CI 的 setup-test-bun 操作通过 scripts/stage-openclaw-bun.sh 消耗 scripts/lib/openclaw-bun.json，macOS 和 Tauri 应用程序使用相同的所有者。每个引脚凸块都需要 both、配对的 CI Bun-lane 重播和 Bun-only 烟雾，以及 macOS 运行时检查以及两个二进制测试集，针对相同的已发布的分叉标签。如果任一门失败，应用程序和 CI 都不会前进； Linux-only 运行时回归也会停止共享 repin。保留最后共同承认的标签并将准确的标签证据附加到repin PR上。仅仅发表并不意味着被录取。共享 pin/stager 更改了选定的 macOS、Linux 配套和 Bun 测试通道。请参阅 共享引脚架构和再生 。

Linux 测试分片选择 Bun 到 scripts/lib/ci-test-runtime.mts。普通单元快速通道对其现有文件库存进行分区：Node 诊断报告、可转让管道句柄合约和本机 Node/SQLite 历史基准保留在 Node 上；兼容的其余部分在 Bun 上运行。那些 Node 文件仍然执行；它们不被排除在 CI 之外。隔离单元快车道完全运行在Bun上。

Bun 测试进程禁用 Node- 兼容的字节码缓存，因为固定的分叉在 V​​itest 拆卸期间生成字节码。 Bun 的转译器缓存和 Vitest 转换缓存仍然可用。 Node 编排、工作器编译和 Node 测试选择保留其现有的缓存设置。

Bun 的 Vitest 父级在创建测试线程之前完成共享 SQLite 本机关闭检查。每个工作人员都会继承该决定，允许有能力的运行时重用读取器，同时负面检查保留保守的清理。

经过审计的普通单元快速测试使用 Bun 的本机测试运行器，包括合格的异步回调和独立的零参数设置挂钩。采用 Vitest 上下文的挂钩保留 Vitest：Bun 将挂钩参数解释为完成回调。在解决之前注册待定承诺断言的测试保留 Vitest：本机 Bun 在该匹配器内等待。同一运行时所有者将其资格数据与标准库存和每个现有条带的包含模式相交。其余兼容文件保留在 Bun 上的 Vitest。本机准入检查测试、设置和固定辅助字节；更改或不可读的输入将受影响的测试返回给 Vitest，而不会丢失覆盖范围。生产来源仍然可以自由改变并且仍然可以行使。额外的 Vitest 参数（包括缓存预热集合）保留现有的 Vitest 路径。

更改的共享设置指纹会使整个本机队列失效。刷新这些指纹需要对保留的条目进行新的限定；没有匹配证明的测试保留其 Vitest 覆盖范围。 CI 预检会在每次工作流程尝试时检查记录的指纹一次。当共享设置、测试或夹具助手输入发生更改或变得不可读时，它会添加一个通知和一个作业摘要部分，列出陈旧的条目和受影响的输入。此报告不会更改运行时选择或失败 CI。分片不重复通知；没有检查员的地方规划和历史目标保持沉默。

本机 Bun 接收显式文件路径、现有密封环境设置、存储库 tsconfig 和共享测试截止日期。它会禁用自动 env 文件加载，并在现有计划和工作人员预算内运行一个测试进程。共享进程所有者保留输出看门狗、中断处理和联合后代清理。发布验证在同一插槽中的兼容 Bun/Vitest 和本机 Bun 部分之前运行完整的 Node 选择；每个结果仍然是必需的。本机执行不添加 CI 作业或工作线程扇出。

处理通道默认为 Bun。 Node 保留可转让的管道句柄经纪人合约，包括具有经纪人断言的混合套件，以及 Node- 特定的子收割机和两进程中继报废案例。现有的配置排除仍然保留单元快速文件和数据库工作文件及其所有者。经纪商事件订单和团体托管测试练习继承了 NODE_OPTIONS 预加载；他们的 Windows 排除项仍然存在。固定前叉支持 Bun.Terminal.pause() 和 resume()，因此其原生真实 PTY 案例在 Linux 上运行。 macOS 和 Linux 在具有该功能的构建上选择不带 Node 的本机 PTY，包括固定叉子的 macOS 子出口修复。其他 Bun 版本保留 Node 帮助程序，该帮助程序需要安装 Node 运行时，并在选择它时跳过 Bun 的 node 填充程序。 Windows 保留 node-pty。合格的TypeScript编译器分析文件和src/library.test.ts在Bun上运行。固定叉公开了 TypeScript 的同步本机 API 使用的子进程管道句柄和流引用控件。混合运行时套件中的编译器断言保持启用状态。仅 src 单元所有者也默认为 Bun。状态租约保留测试将其单独的基础设施所有者保留在 Node 上：已完成的工作心跳案例仍保留其调用者的异步上下文。除了先前合格的标准化核心字素测试之外，聚合单元所有者共享仅 src 文件的 Bun 准入，并为单独的 ACP、安全性和包清单保留 Node。代码模式执行器使用分叉的写时复制诊断通道订阅者处理与 Bun 上的 Vitest 一起运行。 Markdown 渲染感知分块作为单位快速的一部分在固定叉上运行。完整的假定时器通道、插件和代理保留测试以及其他 Control UI 测试支持 Bun。 Control UI WeakRef - desktop-mobile-keyboard.test.ts、chat-pane-retention.test.ts、chat-thread-retention.test.ts、session-snapshot-store.test.ts 和 usage-page-retention.test.ts 中的集合证明保留在 Node 上，因为 JavaScriptCore 的保守堆栈扫描可以在强制收集后使无法到达的目标保持活动状态。不合格的 V8- 特定堆和工作限制断言以及剩余的 Node-only 选择仍在 Node 上运行。 Missing-Docker 测试也在 Bun 上运行，使用空的可执行目录而不是空的 PATH，Bun 通过其默认搜索路径进行解析。其他系列保留 Node，直到他们在现有 CI 资源预算内传递固定叉。精确的 PR 目标使用现有的测试项目规划器来查找其所有者。运行时所有者只承认合格的配置、确切的文件和分区；不明确的选择保留 Node。不会从所选清单中删除任何测试。

完整的代理支持、CLI、命令、嵌入式代理运行和网关方法叶配置也支持 Bun。他们现有的池、排除和工人限制仍然有效。 CLI-process 和其他代理以及网关所有者保留各自的资格政策。代理支持、命令和网关方法包括覆盖，仅将 Bun 用于已注册的所有者模式或证明属于该所有者的文字文件；广泛或不确定的模式保留了完整的 Node 选择。双重验证在同一工作插槽中的 Bun 之前先在 Node 上运行每个完整选定的所有者。命令将轻量命令、数据库工作程序和单元快速文件保留在其现有所有者中；它的接纳不会改变它们的运行时策略。

OpenAI 实时工作人员消息传递 （extensions/openai/realtime-quicksilver-peer-worker.test.ts）、插件 CommonJS 互操作性 （src/plugins/plugin-module-generation.interop.test.ts）、插件 SDK 别名边界 （src/plugins/sdk-alias.test.ts）、oxlint 配置 （test/scripts/oxlint-config.test.ts） 和更新超时诊断当合格文件构成其现有范围所有者中的整个精确选择时，（test/scripts/upgrade-survivor-timeout-diagnostics.test.ts） 也支持 Bun。混合和广泛的 PR 选择保留其原始 Node 调用。双运行时验证保留完整的 Node 选择，并仅添加原始包含模式选择的合格文件。具有固定钩子功能的叉子将整个文件资格扩展到经过验证的工具、更新、Doctor、切换、QA 和工作区哈希固定装置。 Crabbox 包装器套件保留了 Node，因为其保留分配和源封装短写案例在 Bun 上仍然失败。整个文件资格还涵盖测试项目发现、工作人员内存核算、网关和本机 Codex 会话目录采样以及现有范围所有者中的诊断内存日志记录。 diagnostic-heap-profile.test.ts 中的本机分配归属情况仍会在 Bun 上跳过，因此该文件保留 Node 所有权。五个确切的 UI E2E 选项也支持 Bun：启动模块边界、设备平台标识、新会话云启动恢复、手机过时版本恢复和服务工作人员更新。它们保留普通 E2E 配置的资源项目、池、捆绑包所有权和排除项。此资格不会更改专用的广泛或分片 UI E2E 作业或单独的预构建配置；这些作业保留其现有的 Node 执行。

网关客户端叶配置还支持 Bun。其现有的有序网关 core/gateway-client 条带使用核心叶的精确文件限定，并在 Bun 上按顺序在原始工作插槽中运行客户端部分。广泛和混合的核心选择保留了 Node。两个叶子都保留其选择的包含模式和工人限制。除了保留完整的 Node 条带之外的显式项目并行覆盖。双运行时验证在 Node 上保留完整的原始条带，并在 Bun 上添加合格的核心文件和客户端部分。共享的 Vitest 配置将 ws 解析为已安装的包，因此其导入和模拟在两个运行时上使用相同的模块标识。

完整的内存插件配置（memory-lancedb 和 memory-wiki）还支持 Bun，及其现有的隔离工作线程和数据库工作线程排除。与前面的 Bun ddfce5d01 / WebKit 4429d113 构建的配对 Linux 测试箱比较，两个工作人员在每个运行时通过了相同的 53 个文件、474 个测试和一个平台跳过。 Bun 通过热缓存和反向运行时间顺序，减少了从 58.72s 到 52.79s 冷的完整测试命令挂起时间，以及从 43.51s 到 38.68s：更快 10–11%，在 3.94 附近使用热聚合 RSS两者均 GiB。 PR 选择使用 Bun。完整版本验证的插件预发布批次保留其完整的 Node 库存，并在同一工作插槽中的每个合格内存组之后添加 Bun。 Node 上仍存在不合格的数据库工作线程测试。两个运行时都保留选定的文件、排除项和工作上限；要么失败，要么工作失败。不支持双批次的历史目标保留其原始 Node 执行。

拉取请求及其发布门回退在 Bun 上运行兼容的选择。普通手册 CI（包括完整版本验证的 normal_ci 子项）在 Node 上运行完整的原始选择，并在同一作业和工作槽中的 Bun 上运行其兼容部分。其他选择在 Node 上运行。主推保留Node。不具有运行时选择功能的历史目标将保留其原始 Node 行为。 UI 作业通过目标的运行时所有者检查其实际配置和参数，因此较旧的仅单元帮助程序、需要已停用的全局 FTL 标志的帮助程序以及旧版兼容性目标保留 Node。当前运行者目标使用三个本机分片和每行三个工作人员，包括精确目标完整发布验证调度。历史兼容性目标保留其未分片的包命令。 UI 运行时分区在 Vitest 选择每个本机分片后应用，因此文件保留其原始分片所有权。兼容的 PR 选择在 Bun 上运行完整的分片。双重验证在 Node 上运行完整的 UI 选择，然后在 Bun 上运行，包括六个保留断言。在省略 Node 工作之前，部分运行时分区仍然需要原始分片库存。没有浏览器文件的分区保留本机分片的浏览器发现，但省略 Chromium 版本检查和 Playwright 的推测性浏览器启动。

在这两个运行时上，没有缓存测试结果的非隔离 UI 项目在本机分片后按环境和选项对文件进行分组。该排序器以 96 个文件批次为目标，并在同一轮中分散较小的环境，以减少重新启动，而无需在一次长时间工作运行中保留每个兼容文件。每个环境中的本机排序、项目顺序、覆盖范围、隔离和工作人员预算保持不变。批处理目标是调度启发式的，而不是工作进程的生命周期或内存限制；本机池仍然决定重用。缓存项目保留 Vitest 的 failure/duration 排序，显式文件改组保留其本机种子顺序。

UI 运行时所有者延迟 FTL 编译，warmup/soon 阈值为 512000/8000。这些短命的工人受益于较少的编译工作；受保护的缓存发布者在收集 Bun 上的七个标准 UI 种子文件时使用相同的策略。 PR 作业将 Bun 种子与 Node 种子一起恢复，并具有单独的转换缓存叶。同一所有者设置 MIMALLOC_PURGE_HOLES_MIN_INTERVAL=1000 以减少短 UI 更新之间的分配器清理工作；正常回收和默认堆保持启用状态。

测试运行时设置操作仅为需要它的作业安装 openclaw/bun 的校验和固定预发行版。源提交、存档校验和以及可执行校验和一起存在于 scripts/lib/openclaw-bun.json 中，由 CI 和应用程序共享。共享 stager 根据 SHA256SUMS 检查发布 zip 和清单，然后根据清单检查提取的可执行文件。即使发布元数据发生变化，独立的存档和可执行引脚也会保持选定的字节固定。该分支拥有 node:vm 缓存字节码的后备存储，因此在原始缓存缓冲区被垃圾收集后，编译后的函数仍然有效。它还在零时间事件循环轮询期间保留分配器所有权，同时保留可能阻塞的轮询的空闲切换。

固定版本在预发行版 openclaw-v1.4.3-20261014-94f8f5ffec-webkit-01f208ae7a 中将 Bun 94f8f5ffec48f47b3b3fb84891ef5ced046f5814 与 WebKit 01f208ae7a87661e7503f514c946a37bc76ad1d1 配对。此构建在整个单调捕获间隔内测量 CPU 配置文件，在退出之前耗尽 Worker stdio，在 node:path 中保留未配对的 UTF-16 代理，并在设置 ServerResponse.writableFinished 之前等待最终套接字写入。仅当写入挂起时，它才会取消已销毁的子标准输入，将本机 HTTPS 请求套接字公开为 tls.TLSSocket，并保留可克隆的 Worker 加载程序错误。 ESM 说明符现在根据 Node 解码 URL 转义；文字 # 启动一个片段，因此包含 # 的文件名必须在其导入 URL 中使用 %23。它保留 node:vm 缓存命中的共享源缓冲区、重构的模块解析、Node- 兼容的 TLS 拆卸、子进程退休修复，并强制执行 Node- 兼容的进程和工作堆限制。它修复了 Worker 之间的 N-API 清理和外部字符串，释放 Worker 本地事件名称状态，并在 Worker 关闭时跳过初步完整收集。 WebKit 修复了过时的 VM-entry 存储初始化，使用两指针 VMEntryScope，并修复了 Linux 外部堆栈挂起死锁。它保留了延迟的 VM 字节码生成、整体堆采样字节大小、检查器快照清理以及之前的工作程序堆上限、模块分辨率、测试截止日期、GC 节奏和空闲工作程序修复。该版本发布了来自 OpenClaw Foundation 的 Darwin/Linux 目标和 Authenticode 签名的 Windows x64/arm64 目标。 Darwin 可执行文件仍经过开发人员 ID 签名和公证；共享引脚将 Windows 目标记录为已签名而非仅用于测试。

该构建为大型模块图添加了自适应、有界的 node:vm 编译缓存。它在 1,750 个不同的编译源后激活，默认为每个 VM 256 MiB 字节预算。 CI 使用这些默认值。此缓存与为上述 Bun 测试进程禁用的 Node- 兼容字节码缓存分开。

该构建保留同步 module.registerHooks resolve/load 链和取消注册。 JavaScriptCore 的限制仍然很明确：静态输入属性不可用，静态循环可以重复解析，完成的导入可以由 require 重用。不安全的运行中记录冲突会抛出 ERR_MODULE_HOOK_REENTRANCY，静态解析返回的类型属性会抛出 ERR_MODULE_HOOK_ATTRIBUTE_IDENTITY。即使钩子可用，插件加载器也会保留其 Bun-native 路径；直接调用钩子的工具和装置使用新的实现。挂钩接收 Bun- 替换包和虚拟模块的有效 WHATWG URL，而本机加载保留其原始模块标识。安装的替代品会暴露文件 URL；丢失的包和不透明的虚拟 ID 使用 bun-builtin: 和 bun-virtual: URL。这可以避免 tsx Invalid URL 故障，而无需替换 Bun 的本机实现。它保留了对子进程生成跟踪结果的修复，保留运行中套接字写入期间的破坏错误，MessagePort 创建异步上下文和发出的有效负载，保留重复的标准 I/O 描述符，继承的 NODE_OPTIONS 预加载以及套接字标准 I/O 关闭。强制完整的 GC 现在完成了正在进行的 JIT 计划，解决了使用页面保留故障。对于受支持的库存 Bun 版本，标准 I/O 关闭解决方法仍然是必需的。它保留了对工作堆容量报告、OS-visible process.title、同步事件侦听器异常传播和排队 WebSocket 升级的修复。运行时自动安装默认为关闭：装置必须声明并安装其依赖项。 Darwin 手表合并不会影响 Linux CI。它保留了对后脚本 -- 参数分隔符、隐藏 CommonJS 数据导出、大型本机标准 I/O 写入和 Darwin kqueue 文件监视的修复。它保留了对编译缓存空闲唤醒、v8.queryObjects、重复本机可读 ref/unref 调用、默认 module-sync 条件和 process.once 包装器标识的修复。它通过 4b02e1031d 保留上游 Bun 同步，并修复了线程安全函数所有权、共享环境删除和模块密钥崩溃。共享提供商目录保留测试在此版本上合格并在 Bun 上运行；断言 V8 堆行为的不合格测试继续在 Node 上运行。 UI 保留测试在两个运行时上都使用本地检查器的 HeapProfiler.collectGarbage。只有不可用的检查器方法才允许旧的 Bun GC 回退。合格的 UI 库存没有 Node-only 子集，因此每个本机 UI 分片在 bun-compatible 下运行一次； dual 仍然运行两个运行时。该分叉将生命周期脚本 node shim 保留在每个用户目录中，当该目录不可用时，会进行私有回退。 NODE 和 npm_node_execpath 指向任一位置的可执行文件。这允许一台主机上的多个帐户运行 Bun 安装，而无需 Node。同一版本保留了 tsconfig、诊断通道和 inspector/GC 修复。上面的渲染感知分块异常保留了缺失的 WebKit 分段修复的覆盖范围。其预发布标签包括两个源修订版，因为 Bun.revision 本身无法区分与不同 WebKit 修订版链接的构建。

Node 继续负责编排、构建、编译器准备和清理。 Vitest 及其工作人员使用选定的运行时；合格的本机选择使用 bun test 并跳过 Vitest 编译和转换缓存。 Bun/Vitest、本机 Bun 和 Node 具有单独的计时标识，并且两个 Vitest 运行时保留单独的转换缓存目录。任何失败的测试引擎都会导致作业失败。这不会添加矩阵行或跑步者注册。

NODE_OPTIONS（在配置时）限制 Node 堆； UI 通道保留 Node 的默认堆限制。 Bun 不使用 V8 限制。在允许更多车道之前，将观察到的内存使用情况与经过的时间进行比较。兼容性证据必须使用 CI 安装的确切 fork 版本；库存 Bun 结果和不同的前叉版本是单独测量的。

Node 执行和运行时兼容性

目前，大多数 Node 测试、lint 和类型检查作业都从 .github/actions/setup-node-env 继承 24.x； Node 分片还明确提供了该默认值。该组合的 ensure-node.sh 在下载之前会重用匹配的活动或缓存运行时。因此，通配符并不能保证最新的补丁。在测量工具链更改时比较准确的版本，并与测试主体分开测量设置。

Preflight 的清单引导程序使用 ci.yml （24.21.0） 中的确切 NODE_VERSION 引脚。与存储库帮助程序不同，actions/setup-node 可以满足来自 OpenClaw 支持层以下较旧缓存补丁的 24.x 请求。

CI的执行版本没有定义支持的用户运行时矩阵。 package.json 接受 Node 24.16+ 和 Node 26.1+。完整手册CI图检查Node 24.16.0地板； node-runtime-compat.yml 每周并在发货时检查 Node 26.1.0。当前打包的全新安装和升级检查在 Node 24.21.0 和 Node 26.1.0 上运行，并在 24.16.0. 上运行 Windows Node 24 全新安装证明两个运行时变体都使用相同的候选包。这些支持单元独立于普通执行引脚的变化； source/build 单独冒烟并不能证明已安装升级。请参阅 封装验证矩阵。

在项目命令之前选择受支持的 Node 运行时，包括轻量级工作流程检查和发布编排。托管镜像可以默认为Node 22；缺少版本引脚并不能证明运行时受支持。运行程序映像还可以包含未使用的旧工具链，并且恢复包有意保留旧语法目标，以便不受支持的运行时可以打印升级诊断信息。这些版本与支持的运行时和测试作业版本是分开的。 GitHub JavaScript 操作也有自己的运行时，独立于作业上的 node 的 PATH。

iOS 模拟器证据

iOS 和手表模拟器测试命令将完整的 xcodebuild 输出直接写入文件。将模拟器日志转发到拥塞的操作管道可能会在模拟传输运行之前停止定时测试操作。每个命令退出后，CI 最多打印 8 个 KiB 日志并保留其退出状态。生命周期证据工件保留了有关成功和失败的完整日志以及 .xcresult 捆绑包；测试超时、断言和诊断收集保持不变。

macOS 快速阶段

macos-swift (tests) 构建并运行应用程序的完整默认配置文件和命名配置文件测试分区并进行覆盖。 macos-swift (packages) 独立运行 OpenClawKit Talk-trait opt-out 构建、OpenClawKit 测试和 Swabble 测试。这些单独的包图之前在一项作业中构建应用程序之前运行；托管基线在 21 分 48 秒的工作中花费了 7 分 57 秒。将它们分开可以让应用程序编译和测试自己的 30 分钟预算，而不会消除覆盖范围或增加测试过程的并行性。

完整的非发布手动验证还分阶段精确的候选运行时，并通过两个新的 .app 测试主机进程运行普通的捆绑恢复和重新启动。现有的启动器拥有他们的私人住宅、Keychain、精选服务和流程结算。两个阶段事件流均保留在 macos-bundled-recovery-proof 中。只有这个全层测试阶段才有 75 分钟的预算用于运行时构建、暂存和本机组合；普通测试和独立包保留30分钟。该证明不会签署或发布应用程序。

应用程序测试在三个连续的启动器调用中运行：默认配置文件套件，在新的默认配置文件进程中呈现快速聊天，然后是命名配置文件固定装置。渲染的套件将其目录、披露和快捷流程保持在一起，并与更改流程范围执行器的测试分开。每个分区保留覆盖检测和完成检查；普通的 CI 故障不会停止后续分区。渲染的快速聊天使用 AppKit 拥有的运行循环进行本机菜单跟踪。具有启动器的历史目标保留其原始默认和命名配置文件分区，包括 XCTest 的渲染流排序。

每个启动器调用都会在 macos-native-test-logs 工件中保留完整日志。 CI 在调用退出后仅转发有界尾部，将操作日志背压保持在测试之外，同时保留资源清理之前的进程和输出关闭检查。默认配置文件捕获工件保留每个调用的目录，因此来自批量套件的浏览器登录捕获在以后的快速聊天运行中仍然存在。

这两个阶段都在 GitHub- 托管的 xcode-27（预览 macOS 27 映像）上使用 Xcode 27，最多有两个并发作业。完全手动验证在同一上限下添加了现有的 release 阶段。软件包拆分增加了一项托管 Mac 作业及其每次选定运行的 checkout/setup 成本，无需额外的 Blacksmith 注册。在将删除的串行工作视为观察到的加速之前，比较完整的托管计时（包括队列和设置时间）。

Xcode 27 的推出保留了现有的托管布局、作业数量、30 分钟阶段预算、覆盖范围和 Swift 6.3 源语言最低要求。原生 builds/tests 和完整的作业计时必须符合新工具链的要求；早期的封装分割测量并不能确定其性能。

只有应用程序阶段才会恢复应用程序构建缓存。 SwiftPM 依赖项缓存在 packages 中保持仅恢复状态；现有的主阶段拥有共享缓存写入。聚合门要求每个选定的阶段都能成功。

调试 Swift CI 构建忽略 IDE 索引并使用行表调试信息。覆盖率检测和源代码行回溯保持启用状态；交互式调试器 type/value 检查需要正常的本地调试构建。应用程序测试缓存使用单独的构建配置文件，因此无法恢复旧的索引产品；发布构建标志和缓存保持不变。

macOS 外围作业使用本机 SwiftPM 后端及其 .cache/periphery-swift 下的暂存目录和索引存储构建测试，然后使用 --skip-build 扫描该索引。显式索引路径使 Periphery 跳过其构建。 Periphery 3.8 无条件排除 .build 源，这将隐藏 SwiftPM 插件生成的第一方协议模型。单独的暂存路径使这些模型可见，同时其依赖项检出仍被排除。本机测试崩溃会发出非交互式 Swift 回溯，没有寄存器转储。

docs/ 下的普通 Markdown 和 MDX 页面，加上根 README.md，除了精确的拉取请求 Node 测试之外，还保留其单独的 check-docs 覆盖范围。页面删除和重命名可以保留此目标。 Markdown 输入的显式 Node 所有者保持选中状态； docs/reference/templates/ 下的工作区模板和无主源输入保留完整的后备。

当docker-seed-e2e选择已发布的升级幸存者时，即使失败后也会上传docker-seed-upgrade-survivor-proof。该工件包含调度程序摘要和经过清理的幸存者报告。失败的报告包括有界的、经过编辑的基线和候选代理轮次输出；私有场景状态和原始日志保留在上传之外。

完整上游 main 通过 Node runtime-config 所有者推送运行操作员配置和先前发布状态启动语料库。当预检在完全相同的签出版本上验证所需 Node 矩阵中的每个语料库文件时，上游拉取请求还会省略重复的 Check 启动语料库 步骤。部分、过滤或未知的计划保留显式步骤；发布门调度保留其单独的合并树证明。两个状态修复都通过，所有静态基线棘轮和所需的 Node 故障聚合保持不变。八个状态测试文件共享一个矩阵库存，因此执行器可以在工作人员之间分配所有 release/config 对。每对仍然运行 Doctor 和 Gateway 启动检查。显式步骤使用 pnpm build qaRuntime 准备一次运行时，然后在一个 Vitest 进程中运行配置语料库和所有八个状态文件，最多有四个工作线程。失败的准备会在工作进程消耗内存或尝试自己的构建之前停止该步骤。文件分割之前的冻结目标保留其配置进程和四个状态进程，以每四个可用 CPU 一个插槽（至少一个插槽）的方式分批接纳。报告语料库运行失败，而其余分片仍在运行。语料库使用普通的捆绑插件解析器从此结帐中选择准备好的运行时，而不是强制使用 TypeScript 插件入口点。 Doctor 合约要求源加载的插件保留该行为；完整的 config/state 矩阵及其断言保持不变。

仅更改独立 Control UI 单元测试条目的普通拉取请求会保留所有三个 UI 单元行和现有的 type/lint 门，而无需重复专用的 UI E2E 作业。浏览器和 Node 测试条目、共享 fixtures/helpers、生产或构建输入以及其他所有者导入的测试保留 E2E 覆盖范围。主推、手动验证和冻结目标保留其现有选择。

docker-seed-e2e 作业使用 scripts/lib/ci-docker-seed-plan.mts 中的 resolveDockerSeedLanes 在每个已承认的上游 main 运行上准确选择 published-upgrade-survivor，而与更改的路径无关。仅文档推送在触发时仍被排除。该通道针对 auto-auth 的确切发布前身运行 legacy-operator-state：发布的驱动程序必须更新并替换正在运行的托管网关。模式拒绝或回滚使门失败。操作员状态、插件收敛、cron 所有权、代理轮换、无操作更新和备份回滚断言仍然存在。

Main，包括每小时的 validation_tier=main 调度，使用 pnpm build:ci-artifacts 准备其烟雾 tarball，然后是 scripts/package-openclaw-for-docker.mjs --skip-build。这将保留所有运行时 JavaScript、插件资产、Control UI、元数据和公共 SDK 声明；共享加壳器仍然运行其完整的 tarball 完整性检查。调度程序通过 OPENCLAW_CURRENT_PACKAGE_TGZ 使用该 tarball，而不重建它。完整发布验证儿童使用相同的烟雾包；普通全层手册CI保留声明完整的全包构建。

普通上游手册CI保留幸存者并增加cron-mcp-cleanup、mcp-channels、mcp-code-mode-gateway和update-channel-switch。这包括 full、npm-beta 和 npm-stable 范围中完整版本验证的 normal_ci 子级。冻结目标必须声明Docker种子能力；没有 resolveDockerSeedLanes 的目标保留幸存者后备。 CI 直接加载目标的 Docker 层规划器。

调度程序在符合资格的主推中保留一名 16 级铁匠亚军。当未配置发布运行程序组时，完整发布验证子级也会使用该类；托管中断覆盖和重试保留托管恢复。主、发布、普通手册CI保留序列加权录取。拉取请求及其精确头部回退调度不会选择此证明。每个承认的上游主运行和普通 manual/release CI 仍然需要安装驱动程序升级覆盖范围；现有基础设施超时保持不变。该作业是 openclaw/ci-gate 的一部分。每次选定的跑步最多使用一个跑步者注册；扩大幸存者选择不会增加全库存注册上限、作业数量或矩阵扇出。

独立外围工作流程强制 iOS 和 macOS 应用程序发现零死代码。共享的 OpenClawKit 工作流程并行扫描两个使用者，并且仅当 Periphery 从两个构建中发出相同的 Swift USR 时才报告声明。其生成的 GenerateGatewayProtocol/GatewayModels.swift 构建插件输出保留为生成器拥有的代码，而不是视为应用程序本地死代码。共享扫描和本机 CI 作业将过滤的网关协议生成器依赖项与其现有的本机资产依赖项一起安装； CodeQL 在 Swift 构建之前安装相同的生成器依赖项。

所有四次扫描都使用 scripts/install-periphery.sh 在专用的运行程序临时目录中安装校验和固定的外围设备 3.8.0 OSS 版本，包括其相邻的 libIndexStore.dylib。安装程序会拒绝下载、校验和以及版本失败，而不会回退到 Homebrew。安装程序更改选择所有三个本机工作流程。

Upstream存档了OSS项目。该 pin 仍然是维护者拥有的桥梁，而不是声称持续的上游支持。所有四次扫描均以 GitHub- 托管的 xcode-27 上的 Xcode 27 为目标。工具链、固定发布或分析器更改需要对应用程序扫描和共享使用者进行本机兼容性证明，从而保留零发现策略和精确的 USR 交集，而无需基线或较弱的回退。四个特定于声明的注释保留了已确认的 SwiftUI 误报；他们不会将其文件或运行时测试排除在验证之外。

安全审查检查

安全审查将维护人员可以批准的产品更改与需要 SecOps 批准的一小组安全策略和实施文件分开。

安全审查工作流程从受信任的存储库代码运行这两个防护。它发布名为 openclaw/ci-gate 的提交状态，该状态需要适用的批准以及来自当前 PR 头的最新适用 CI 运行的成功本机 CI 门。已完成、完全跳过的拉取请求运行不会取代实质性的 CI 运行。较新的运行、失败或取消的运行仍然优先，并且跳过的发布门调度仍然阻止批准。现有 CI 作业保留其同名检查。当 GitHub 共享所需上下文时，需要检查和提交状态。缺少批准、未通过 CI 或评估错误未通过审核状态。丢失或运行 CI 会使其处于挂起状态，并保持合并受阻。 CI 完成后会自动再次对其进行评估。批准意见不会重新运行测试套件。

每十分钟，解析器就会协调 CI 从上一次成功的计划传递开始前五分钟到五分钟前的完成情况（六十分钟回退，十二小时上限）。无间隙地穿过瓷砖；延迟或下降的 cron 刻度只会扩大下一个窗口，直到上限。运行列表涵盖从窗口前三小时到当前时间的创建时间。 GitHub 将每个过滤查询的上限限制为 1,000 个结果，因此解析器将报告总数超出该限制的范围一分为二。每个较小的范围都会被分页，直到一个短页，并且其不同的运行计数必须覆盖其首页上报告的总数。在任何状态发布或矩阵输出之前，十个整页或少于报告的不同运行都会失败，保留锚点以进行完整重试。包含范围端点间隔一秒，运行 ID 跨页面和切片进行重复数据删除。短于 10 分钟但仍超过 1,000 次运行的范围在状态发布或矩阵输出之前失败，因此覆盖的窗口不会前进。下一次扫描将从上次成功扫描的基础上重新扫描。预定的解析器传递共享一个并发组，而不取消活动传递； GitHub 保留一个待处理的传递，该传递仍然从最后一个成功的窗口开始。每个通道最多选择 100 个 PR 头，最旧的 CI 首先完成，运行 ID 打破平局，并在达到上限时停止读取状态。如果候选人仍然存在，则 reconcile-backlog 作业在选定的审核完成后将无法通过工作流程。这保持了相同的锚点：审查的头具有新的状态，允许下一个计划的传递从同一窗口中选择剩余的部分。

协调器中断时间超过 12 小时后，较旧的丢失完成需要重新推送或重新运行安全审查。

CI 重播会保留其原始创建时间。窗口前三个多小时创建的运行的重新运行依赖于其自己的完成交付；如果丢失，新的推送或重新运行安全审查可以恢复它。

解析器按时间倒序读取每个磁头的状态历史记录，并仅使用创建者类型为 Bot 的 github-actions[bot] 中的最新 openclaw/ci-gate 状态。其他出版商将被忽略。当 Actions 拥有的状态缺失、早于 CI 完成或待处理时，它会安排正常审核。只有在 CI 完成时或之后创建的非待决状态才会被解决并停止重选。每个待处理状态仍然符合资格，包括预完成 CI 读取后发布的审核等待。当头部合法地等待更新的正在进行的 CI 时，平铺窗口会限制无害的额外审查。完全跳过的运行将被忽略。它从不检查 PR 代码。每一次传递都需要一个托管的 ubuntu-24.04 解析器作业、运行列表读取以及每个新完成的磁头的分页状态历史读取，并且不需要 Blacksmith 注册。

评估完成时，包括当所需的提交状态因缺少批准或失败的 CI 而阻止合并时，安全审核操作作业会成功。这可以防止在自动重新评估清除状态后早期评估留下陈旧的失败作业。评估错误仍然会导致作业失败并保持所需的状态已关闭。

如果 PR 头在评估之前或期间发生更改，则过时的运行会成功停止，而不会发布对替换提交的批准。新头的自动事件拥有其评价。关闭未合并的 PR、将其设为草稿或更改其目标也可以成功停止过时的评估。 GitHub 在 PR 关闭时禁用维护者编辑不会阻止这种彻底停止或合并审查证据的完成。开放PR的权限变更、其他身份变更、真实评估错误仍然失败；生命周期更改不会隐藏早期的防护错误。清理和合并准入保留严格的检查。

计划修订的合并可以完成安全评估，包括合并后开始强制执行的时间。两名警卫都会在状态、评论和工作流程摘要中保留他们的发现，因此强制合并不会丢弃该证据。自动锁定文件清理仍然需要在写入之前立即打开 PR。解析器仅选择开放的 PR，因此不会安排新的合并后审核。如果普通CI还在运行，合并后合并状态可以保持pending； CI 工作流程保留其自己的最终结果。

在长读取序列期间，审核会再次检查实时 PR，然后在 30 秒后允许再次读取。非配额恢复也每 30 秒等待检查一次，因此被取代的工作会停止，而不会完成分页或等待差异恢复。飞行中的请求保留 30 秒的最后期限；写入和自动清理清理不会中断。服务器控制的速率限制等待必须在允许另一个 API 请求之前完成。签出和运行时设置不在这些检查点之内。按人头非取消出版物连载和所有最终批准检查保持不变。

当 GitHub 返回速率限制响应时，解析程序和审核脚本将停止 API 请求，遵守 Retry-After 和耗尽配额重置时间，并使用新的 PR、批准、角色和 CI 数据重新启动。每个脚本允许在其作业的共享 65 分钟期限内最多重新启动 3 次；单个 HTTP 请求仍然有 30 秒的超时。没有计时指导的次要限制使用至少一分钟的指数退避。配额重置后，小的随机延迟会导致重试。工作的工作时间有 75 分钟的上限，等待占据了他们的跑步时间。恢复在同一运行中自动进行，不需要另一个 PR 事件或手动调度。精疲力竭的恢复使工作失败； GitHub 错误还可能阻止发布新状态。普通权限错误和其他评估错误不会重试。签出、运行时设置和单独创建的自动清理令牌到期均不在此恢复机制之外。

短暂的提交状态发布失败也会重新启动完整的评估。 HTTP 500、502、503 和 504 响应和识别的连接故障使用一秒、两秒和四秒延迟，与速率限制恢复共享三次重新启动限制和作业截止时间。 GitHub 可能已接受失败的写入，因此审核会重新读取当前的 PR、批准、角色和 CI 数据，而不是重播旧决策。在实施过程中，相同的有界恢复处理暂时的粘性通知创建和更新失败。如果 GitHub 接受了先前的写入，则每次重新启动都会重新读取评论并更新现有的拥有的通知，而不是盲目地发布另一条评论。仍然需要必要的批准。自动锁定文件清理、其他不确定的写入、取消和写入请求超时仍不在此发布恢复范围内。

另外，只读 GET 和 HEAD 请求重试 HTTP 500、502、503 和 504 响应，并在标头到达之前或读取成功的响应正文时识别瞬时连接失败。它们在原始 30 秒请求超时内共享一秒、二秒和四秒的重试预算。这些重试不包括写入、调用者取消、证书错误、无效的 JSON、过大的响应和无法识别的错误。 HTTP、连接和响应正文错误标识请求方法和端点。

GitHub 尝试 CI 的 100 个作业页面可能会持续失败，而较小的页面会成功。审核会读取页面大小为 100、50、25 的 CI 作业。大于 25 的大小会跳过服务器错误重试，并立即以一半大小请求相同的作业范围。 25 个作业的页面使用正常的读取重试、超时和恢复。枚举仍必须达到报告的作业计数。

如果只读请求达到 30 秒的截止时间，包括在读取其响应正文时，脚本将使用新的 PR、批准、角色和 CI 数据重新启动完整评估。这些重新启动使用一秒、两秒和四秒延迟，并共享现有的三次重新启动限制和作业截止时间。持续读取超时会使作业失败。写入超时不会触发此恢复，因为 GitHub 可能已经接受了突变。

如果 GitHub 的更改文件计数和文件列表不一致，或者计数在验证后发生变化，则脚本会在一分钟、两分钟和四分钟后重新启动完整评估。这些重试与 API 恢复共享三次重新启动限制和作业截止日期。每次尝试都会重新读取完整文件列表、PR 元数据、批准、角色和 CI 状态；目标、作者和其他与批准相关的元数据必须仍然与原始评估匹配。更新的头取代了过时的运行。两个守卫共享每次尝试的已验证文件列表。对于直接 PR 事件，准备步骤会分析依赖关系，并在不需要清理锁定文件时在一个进程中完成两个防护。清理候选者仍会执行现有的 App-token/autoscrub 步骤和新的最终执行。只有完成评估才能跳过重复执行过程；错误和不合格的 PR 会使该步骤处于活动状态。 CI- 完成、计划和命令审查保持其单独的执行步骤和发布许可。恢复也在检测步骤中运行，因此恢复的不匹配不会使较早的步骤呈红色。持续不匹配会使审核失败，并报告预期、返回和当前文件计数。

安全敏感防护发布openclaw/security-sensitive-review。其在.github/security-review-policy.yml中的库存涵盖了网关认证、配对和权限；凭证、秘密和编辑；沙箱和执行策略；产品安全检查；和 .gitignore。普通文档、测试和测试支持不会触发此清单。重命名会检查旧路径和新路径，因此移动敏感文件不会消除其审查要求。

Dependency Guard 发布 openclaw/dependency-review 并保留其依赖项分类和锁定文件自动清理行为。已经符合信息性条件的依赖项删除仍然是信息性的。自动锁定文件清理是尽最大努力。如果两个清理应用程序都无法提供写入令牌，或者 GitHub 明确拒绝清理突变的权限，则依赖项通知会解释如何删除剩余的更改或请求维护者批准。这些预期的访问限制不会使操作作业失败或满足依赖性审查。意外的清理错误仍然是失败。

编辑 .github/security-review-policy.yml 以更改路径分类。其 categories 组产品路径以及说明和审查指南； exclude 指定仅产品排除； dependencies 列出清单、锁定文件和其他依赖文件。路径被引用，存储库相对全局：* 保留在路径段内，** 跨目录，{a,b} 匹配任一替代项。包括隐藏路径。匹配区分大小写，除非排除显式设置 case-insensitive: true。产品排除永远不会免除依赖性更改。第一个匹配的产品类别提供通知的指导；匹配不是 CODEOWNERS 规则。

JavaScript 加载器处理验证和匹配；它不包含路径清单。无效策略未通过安全审查。 YAML 库存及其装载机都需要 SecOps 代码所有者批准。工作流程从受信任的签出加载它们，并通过 .github/actions/setup-security-review 仅安装锁定的 parser/matcher 运行时，并禁用生命周期脚本和依赖项缓存。该操作的清单和 npm 锁定镜像根依赖项引脚和 pnpm-lock.yaml；当这些引脚发生变化时，将它们一起更新。批准决策和依赖图分析保留在 JavaScript 中。

两个守卫都使用当前存储库权限。只有具有 maintain 或 admin 访问权限的 GitHub 用户帐户才能授予命令批准或获得作者豁免。 write 访问权限和组织成员资格不足。推送到外部贡献者分支的维护者不会转移作者豁免。使用 GitHub 用户帐户的自动化符合相同角色检查的条件； GitHub 应用机器人身份不符合条件。

对于其他作者，请等待适用的防护通知显示当前的 PR 提交，然后在新的 PR 注释中将命令发布在其自己的行上：

/allow-security-sensitive-change/allow-dependencies-change

每个司令部只批准自己的警卫。当两个警卫都需要批准时，这两个命令都是必需的，并且可以在一个注释中出现在不同的行上。在该注释中仅使用命令行，不要使用散文、引号或代码围栏。正常的 GitHub Approve 评论和标签不会替换这些命令。

警卫将命令与其可信通知中记录的修订相关联。在通知请求批准该修订之前发布的命令无法批准该修订。新提交后，等待通知更新并发布新评论。编辑较旧的评论并不授予新的批准。删除批准注释或删除其命令会撤销该批准；每当守卫运行时，都会再次检查当前角色。

GitHub 提交状态适用于一次提交，而不是一个 PR。在发布成功之前，安全审查会验证头部是否仅属于针对该基本分支的当前开放 PR。重复的头会阻止批准，因此一个 PR 无法重复使用另一个 PR 的作者豁免或命令。关闭重复的 PR 或推送不同的提交；安全审查会自动评估受影响的 PR。

每个警卫都会更新一条 PR 评论，其中包含受影响的文件、审阅指南、当前修订版本和剩余操作。敏感变更标签在批准后仍然存在，因此审阅者仍然可以识别受影响的责任。受信任的 issue_comment 事件会自动重新评估审批命令并编辑或删除审批注释。编辑会检查先前和当前的文本，因此删除命令仍会撤销批准。普通的评论活动不会重新评估守卫或改变他们的状态。散文、引用或代码围栏中提及的命令不是批准注释。工作流程在分配跑步者之前过滤普通评论；命令提及可以启动轻量级解析器，该解析器在安排审核之前验证语法。 GitHub 仍记录普通注释跳过的工作流程运行。两名警卫共享一项审查工作，并且评论事件不会重新运行测试套件。评估使用可信存储库代码和 GitHub 元数据，无需执行贡献者代码或评论文本。

硬层仅存在于 .github/CODEOWNERS 中：安全策略、所有权、CodeQL、选定的扫描配置和安全审查强制关闭。将 SecOps 保留为这些条目的唯一所有者。 GitHub 接受匹配行上的任何所有者，并且稍后的匹配模式将替换先前的所有权。发布经理条目保留其单独的批准责任。此库存并不使每个通用 CI 或扫描仪更改 SecOps 都拥有。

软层保护分叉贡献者的审查流程。它不是针对敌对存储库编写者的安全边界：具有写入令牌的另一个工作流可以发布相同的状态上下文。将所需的上下文绑定到 GitHub 操作应用程序可识别发布者应用程序，而不是特定的工作流程。这是一种可以接受的权衡，以避免单独的带有凭证的发布者。现有的维护者 CI 绕过还允许绕过缺少的命令批准。本机 CODEOWNERS 审查执行仍然独立于这些状态并且 CI 绕过。

结果适用于工作流程评估的 PR 头部。新的 PR 头、基分支重定向、命令注释事件和 CI 自动完成重新评估；十分钟对账恢复丢失的 CI- 完成交付。对 main 的无关推送则不会。敏感路径策略和权限更改将在下一次自动评估时生效。守卫执行不需要手动调度或手动重新运行。

部署后启用强制执行

合并工作流程文件不会启用 GitHub 合并保护。工作流程和审核后的 CODEOWNERS 库存位于默认分支上后：

1. 保留 openclaw/ci-gate 为必填项并绑定到 GitHub 操作应用程序。保留现有的维护者旁路并禁用 要求分支保持最新状态 。两种审核状态仍然可见，无需单独的所需检查条目。
2. 验证 PR 当前磁头上的本机 CI 检查和安全审查提交状态，包括命令批准后、后续推送和 CI 完成。确认批准更新不会启动另一次测试运行。
3. 在没有旁路参与者的单独规则集中，启用需要拉取请求、需要代码所有者的审查和在推送新提交时忽略过时的拉取请求批准。验证 openclaw-secops 是否有资格获得代码所有权，并且硬清单需要其批准。如果普通无主变更应保留其现有的审核政策，则将一般所需的批准计数保持为零；代码所有者审查是一项单独的要求。现有的发布管理器条目也成为必需的。
4. 验证CI绕过是否无法跳过单独的代码所有者审核规则。需要 PR 还会限制直接推送到受保护的分支。

在声明强制实施之前，请验证实时 GitHub 设置以及维护者、外部贡献者、自动化帐户和 SecOps 拥有的路径案例。

作业排序和故障报告

1. preflight 决定存在哪些车道。移动协议事件覆盖在现有所需的 security-fast 作业中运行，因此正确性故障无法抑制清单扇出。 docs-scope 和 changed-scope 逻辑是此作业中的步骤，而不是独立作业。上游 main 立即在两个奇偶校验时隙之一中启动；每个槽位允许一次完整的运行，并随后合并推入其最新的待处理提示。下游作业等待清单，然后符合条件的 Blacksmith 作业会从可信预热器恢复确切的依赖关系，或者在未命中时回退到普通 pnpm-store 缓存。针对工作流程修订的推送、拉取请求和手动运行使用本机 Node 运行预检并跳过依赖项设置。针对不同版本的手动运行安装依赖项并保留该目标的 tsx 工具。
2. security-fast、check-*、check-additional-*、check-docs 和 skills-python 会快速失败，而无需等待较重的工件和平台矩阵作业。额外检查在预检后立即开始。带有额外检查的窄 PR 还会将现有的 check-guards 和 check-dependencies 行放在那里：它们的完整防护、依赖项、未使用文件和导出扫描不会消耗已安装的 compiler/lint 计划。警卫使用相同的命令并在结帐期间获取准确的比较基础。没有该系列的完整选择和运行保留中心行，并且聚合需要每个选定的所有者。当已选择的附加边界行拥有完整的核心图检查时，可以从四个非核心图规划仅扩展编译器输入。这需要现有的常规源文件没有符号链接别名；混合源更改保留完整的发现，丢失或不确定的输入保留完整的检查。已知的完整选择会跳过发现并在已选择的附加边界行或所需的规划器中保留边界证明。该优化不允许额外的边界行。普通的pull-request、push和预定的CI跳过生产依赖审核。仅以 full-release-validation- 或 release-native-android- 开头的 workflow_dispatch ID 运行它。审核会发送一张完整的图表，其中最多包含四次尝试和四分钟的总请求预算，包括重试和响应读取。每个非零审计退出都会生成警告并退出 0，包括结果、不可用的建议和无效数据。不可用的审计是不完整的覆盖范围，而不是干净的结果。可选的预提交审核挂钩使用相同的仅警告包装器。单独的每日 Dependency Audit 对于分类仍然严格，不是必需的 PR 检查，并指向依赖项碰撞后续操作。发布依赖性证据保留其单独的已知恶意软件门；漏洞公告仍然是警告。
3. build-artifacts 和区域设置检查与快速 Linux 通道重叠。 Control UI 和本机应用程序源 PR 排除生成的语言环境 snapshots/resources；他们的序列化刷新工作流程会在后台修复并自动合并隔离生成的 PR。源 CI 仍会阻止过时的源库存和不安全的本地化调用。生成的 PR、手动 CI 和发布准备强制执行完整的 translated/platform-generated 奇偶校验。上游 release/YYYY.M.PATCH 分支可能包括发布准备区域设置修复以及其他生成的发布输出。
4. 基线棘轮和选定的Node测试碎片在预检后独立启动。 Node 行消耗清单，而不是棘轮输出。 ci-gate仍要求每个选定的棘轮都通过；棘轮失效会使同级作业继续运行。冻结目标保留其现有的棘轮选择。
5. 目前计划有守卫在那里运行 check:coercion-helpers 一次；仅快速计划保留其独立行。其他平台和运行时通道独立扇出：checks-fast-core（包括启动语料库）、checks-fast-contracts-plugins、checks-fast-contracts-channels、checks-windows、macos-node、macos-swift、ios-build、屏幕截图碎片和android。
6. PR 作业和独立检查步骤在失败后继续运行，包括分叉和重新运行。 check-plan 在运行所需的全局防护之前实现其输出；消费者需要这些产出，而不是绿色卫士的结果。准备好的 SDK 和候选包消费者同样需要上传的工件，而不是生产者作业传递中的每个检查。独立的 shell 检查收集每个退出，然后一起失败。 Node 项目、静态编译器组、lint、文档检查和 Docker 种子通道完成其选定的清单。 Setup/build/plan 故障仍然可以防止消费者丢失数据，并且合约信封在失败后停止，以避免在安全清理之前接纳另一个信封。取消、看门狗和超时仍然是故意停止。失败的跑步需要更长的时间并消耗更多的跑步者时间；选择、名称、跑步者数量和并发性保持不变。 pr-failure-report 等待计划的作业，然后使用 ci-known-main-red.mjs 将每个失败或超时的作业与 main 上运行的最新完成的计划 ci.yml 中的相同 name/shard 进行比较。匹配失败的作业是 pre-existing，只要现有 Node 或静态证据助手支持比较，就需要匹配签名。其他职位在原因中仅识别其职位名称匹配；在归因这些失败之前，先检查主要的失败测试。主通过或不同的失败签名是new。缺失、取消、计划外或以其他方式无法比较的主要工作是 unknown；不可用的支持证据并不意味着匹配。检测到的构建验证程序或 lint 模式范围差异为 unknown；原因说明何时未比较所选范围。紧凑摘要链接主运行和作业，并复制到 openclaw/ci-gate 的摘要和日志中。 JSON 输出公开脚本和代理的 job、conclusion、class、mainRunId、mainJobId 和 reason。报告保留现有的运行路径和扇出预算；它永远不会取消工作。
7. openclaw/ci-gate 等待每个选定的通道和故障报告。预检和安全检查必须成功；仅当清单和现有事件、运行程序和兼容性条件未选择时，下游作业才可以跳过。意外选择的跳过、失败和取消保留其现有的门语义，包括下面的已知主红色容差。仅靠分类并不会导致门通过失败。被取代的运行保留其现有的并发行为。

仅包含生成的本机语言环境数据和资源的机器人编写的同一存储库 PR 保留严格的本机源和生成的奇偶校验验证，同时省略不相关的 Node 和本机构建。源更改、空或未知差异以及没有硬生成伴侣的基本 Android XML 保持普通选择。在下一次 PR 运行之前添加 ci:full，以保留该生成队列的普通选择。标签本身不会触发额外的 CI 运行。主要验证和手动验证保持正常覆盖范围。

现有的已知主红色津贴直接从 GitHub 读取最新完成的每小时主运行。在一份故障报告中，归属和配额共享计划的运行清单、其尝试作业页面和下载的日志。每份报告都开始了新的观察； PR 身份、当前主要身份、血统和变更主题检查仍然是单独的入学读取。仅当其文件和完整签名与 main 匹配时，受支持的 Node Vitest 断言、编译器诊断或托管 lint 诊断才是建议性的，并且 PR 既不更改文件也不更改其直接主题。主体所有权保守地包括文件目录、相关导入目录和经过验证的工作空间包目录；未解决的导入保留阻塞行为。工作流程、工具、配置和依赖项更改不能使用此异常。主运行必须从 PR 合并基础下降，或验证当前主运行本身。随后对这些主题进行的主要更改会在下一次每小时运行之前取消异常。矩阵兄弟和打包测试组都在报告发出尝试绑定收据之前完成。分片运行程序在清理后记录完整的计划和进程计数；现有证据所有者将每个内部调用与其本机测试摘要进行协调。编译器图表和托管 lint 条带同样需要连接的本机诊断以及完整的组和步骤接收。这些跑步者在报告覆盖率之前完成普通的诊断故障。没有完整契约的混合或缩小的 lint 命令会保留阻塞行为。然后聚合注释 known main red，由 main 拥有。证据缺失或不完整、suite/import 错误、边界检查以及每个不匹配或 PR- 拥有的故障都会阻塞，包括微小的 lint 和类型错误。单独的维护者登陆策略拥有针对 PR- 引起的错误的任何明确例外，并立即进行后续修复。即使聚合接受其主拥有的断言，失败的作业仍然在操作中可见。

重复的头 SHA 是重复的候选者，不可重复使用的验证：PR 合并树可能已更改。每个 PR 并发合并待处理的工作并取消被取代的工作； CI 不会将之前的仅头部成功转变为跳过不同合并树上的测试。

要重新翻译每个 Control UI 或本机应用程序字符串，请使用 full_refresh=true 从 main 调度 Control UI Locale Refresh 或 Native App Locale Refresh。普通运行仍保持增量。两个工作流程都使用现有的转换 OpenAI API 密钥从 OPENCLAW_I18N_MODEL 和 OPENCLAW_I18N_FALLBACK_MODEL GitHub 密钥读取主要模型和后备模型。只有显式的 model_not_found 提供程序错误才会选择后备；身份验证、配额和网络故障则不会。生成的元数据和公共诊断省略模型标识符。

合并协调员可以在最多 24 小时内为同一拉取请求头重复使用经过身份验证的成功 openclaw/ci-gate。这可以避免在不相关的 main 更改后重写贡献者分支。可重用的结果不会取代针对当前 main 的单独严格的、应用程序拥有的测试合并检查。稍后待处理或失败的重新运行不会删除新鲜度窗口期间未更改的磁头的早期成功结果。重用 CI 检查不会取代当前的安全审查提交状态。

默认分支规则集需要 GitHub Actions 拥有的 openclaw/ci-gate 上下文。存储库维护人员和管理员保留其 CI 旁路，包括缺少命令批准的旁路。正常的拉取请求合并使用门。即使绕过 CI，单独的代码所有者规则集也需要 PR 和适用的所有者批准；组织规则仍然阻止删除和非快进更新。单独的严格的应用程序拥有的测试合并检查仍然将头部绑定到当前的 main。

当新的头登陆时，GitHub 可能会将被取代的拉取请求作业标记为 cancelled。将其视为 CI 噪声，除非同一 PR 的最新运行也失败。上游main运行在入场后不会取消；两个奇偶校验槽中的每一个仅用最新的提示替换其较旧的待处理运行。所有 CI 矩阵都使用 fail-fast: false，build-artifacts 直接报告嵌入式通道、核心支持边界和网关监视故障，而不是对小型验证器作业进行排队。上游主 CI 并发密钥已版本化（CI-v8-*），因此旧组中的 GitHub-side 僵尸无法阻塞两槽管道；可运行的 PR 组保留在 CI-v7-* 上，而被动草稿运行则使用 CI-draft-v1-*。手动全套运行使用 CI-manual-v1-* 并且不会取消正在进行的运行。插件列表启动内存保护在自托管 Blacksmith Linux 上保留 400 MiB 上限，并在 GitHub- 托管的 Linux 上允许 425 MiB，其 RSS 基线对于相同构建而言更高CLI。启动内存检查在每个运行器上开始其他内置工件检查之前单独完成，因此并发验证器不会干扰 RSS 测量。

Testbox 验证、本机 Periphery、OpenGrep PR Diff、Sandbox Common Smoke 和插件初始化脚手架验证工作流程将被动草案 PR 事件（opened、reopened 和 synchronize）与有用事件隔离开来。 PR 工作在并发准入。因此，在跳过草稿作业或扫描之前，延迟的草稿有效负载无法取消活动的就绪运行或替换待处理的运行。单独禁用 cancel-in-progress 仍会取代待处理的工作。已订阅的，converted_to_draft留在普通PR群故意取消作品；非草稿头替换和每个工作流程的现有 manual/push 分组保持不变。外围设备报告发布分别检查源意图和实时 PR 状态；请参见 范围和路由 。

然后，在任何其他验证器读取运行时插件覆盖之前，单例烟雾会重建它。在 Blacksmith 上，Gateway Watch 接下来完成其构建收据写入和整树测量； Doctor、SQLite 生命周期、通道、核心支撑边界和 Discord 附件检查可以重叠。托管 4 核运行程序保留其现有的串行序列和 channel/core 对。 TUI 金丝雀在所有其他验证程序完成后运行。每个验证者都拥有一个单独的 Vitest 模块缓存，并且每个选定的结果仍然是同一失败聚合的一部分。 Wave 步骤是无条件的，因为它的启动和单例检查始终运行；个别检查保留其选择门。工件作业仅消耗其选定的签出，因此基本提交提取保留在实际比较修订版本的作业中。

使用 pnpm ci:timings、pnpm ci:timings:recent 或 node scripts/ci-run-timings.mjs <run-id> 总结 GitHub 操作的挂起时间、启动延迟、最慢的作业和失败。使用 pnpm ci:timings:trend 进行 72 小时基线以及最新 12 小时与之前 12 小时的比较。趋势模式包括每个主推结果、cancellation/pass 速率和成功运行的挂壁时间，然后默认加载最多 100 次成功运行的平衡 latest/prior 样本。其详细示例将工作流准入、作业 dependency/gate 延迟（job.created_at 减去第一个作业的创建）、运行器 queue/start 延迟（job.started_at 减去 job.created_at）和执行分开；它还报告关键路径所有权和实际 GitHub API 请求计数。重新运行使用特定于尝试的作业，并且从运行级别 wall/admission 分发中排除，因为 GitHub 保留原始工作流创建时间。使用 --detail-runs 提高或降低详细运行选择上限（运行超过 100 个作业需要多个请求），使用 --json 将 JSON 发送到标准输出，或使用 --output .artifacts/ci-timings/trend.json 保存相同的报告；缺少的输出目录会自动创建。基线必须至少覆盖两个比较窗口。

在本地运行计时助手；工作流程中没有计时总结作业（一旦本地助手成为每个人实际使用的工具，就会删除永久禁用的作业）。对于构建计时，请检查 build-artifacts 作业的 Build dist 步骤：pnpm build:ci-artifacts 打印 [build-all] phase timings: 并包含 ui:build；该作业还上传 startup-memory 工件。

Run Node test shard 步骤打印 Bash time -p 总计：已用 （real）、用户 CPU （user） 和系统 CPU （sys） 秒，包括等待的子进程。将 CPU 总计与等效运行的经过时间进行比较，以区分额外的 CPU 工作和类似 CPU 工作的较慢执行。仅凭这些总数并不能确定跑步者的竞争情况。

Android 测试行在 android-test-reports-<task>-<checkout-revision>-<run-attempt> 工件中保留其现有 Gradle JUnit XML 14 天，包括失败的运行，除非取消。报告确定测试用例和持续时间；编译、lint、设置和队列时间在作业日志中保持独立。阅读 XML 以及该尝试的 Gradle 任务结果：由 FROM-CACHE 恢复或由 UP-TO-DATE 重用的报告描述了较早的执行，因此它们的时间是历史的。它们没有显示当前运行中的新测试执行或加速。 Gradle 写入 XML 之前的失败不会留下任何工件；上传警告，但不替换原来的失败。该工件仅包含电话和 Wear 单元测试 XML，而不包含依赖项缓存或应用程序构建输出。

需要内置 CLI 的 Node 测试分片在启动 Vitest 之前运行 pnpm build qaRuntime。此配置文件构建运行时 JavaScript、插件资产以及新鲜度和出处元数据。私有 QA 分片选择其私有运行时条目。 build-artifacts作业拥有Control UI和SDK声明验证；发布包构建仍然会生成完整的声明。

仅源 Linux Node 24 个分片可以从受保护的缓存预热器中恢复已编译的 Vitest 工作线程。温暖者在 SDK 或运行时构建变更包解析之前准备一代，加入准备所有者，并仅发布保留的缓存。 PR 作业将其恢复而不发布。仅当存档存在时，消费者才可以重用；冷跑者保持普通新鲜编译。工作线程所有者在借出一代之前验证源和依赖字节、编译器身份、解析拓扑、环境、输出库存以及准确的签出和输出槽路径。更改或不兼容的输入在本地重建。冻结的目标、其他 Node 版本和运行时构建分片保留了最新的准备工作。

工件作业保留其构建的输出以用于其自己的烟雾和边界检查。不再打包或上传未使用的dist-runtime-build和bundled-plugin-assets档案。运行时分片仍会在预检后启动；它们不等待 SDK 声明、Control UI 构建或工件检查。诊断和证明上传仍然可用。

在 lint 成功后，托管的 Linux SDK 声明由现有的完整主 lint stripe 1 发布。 Hybrid 使用其插件 lint row； GitHub 配置文件使用其核心行，该行还检查插件条带 1。两者都使用工作流的固定 Node 运行时，并为准备好的 SDK 及其经过验证的收据保留恢复存档的路径合同。温暖器保留其其他缓存和非托管 SDK 所有权，避免第二个托管 SDK 排放。 PR 仍然仅恢复，并且语义 source/toolchain/output 检查仍然运行。

已完成的上游主扩展边界作业将其现有编译器收据发布到由 OS、架构和运行器环境分隔的缓存中。 PR 恢复该存档，回退到 SDK 温暖器的仅声明存档。每个恢复的收据仍然验证其编译器、配置、源、解析查找和输出哈希；负边界金丝雀总是运行。收据包括缺失的候选者、目录列表和符号链接解析，因此不相关的新测试可以保留命中，而新的有效类型依赖项则使其无效。每个验证快照共享各个收据的实际检查结果，同时比较每个记录的事实。全新编译仍然会密封整个解析命名空间，以防止编译期间发生更改。旧的或格式错误的收据将重新编译。这不增加生产者工作或包装选择豁免。

声明缓存对所选编写器的传递生成器导入、包和插件元数据、显式模式和构建元数据输入以及编译器记录的源文件进行哈希处理。编辑不相关的 CI 脚本不会重建声明。解析拓扑仍然参与缓存键，并且未解析的生成器导入会停止构建而不是信任缓存。完整构建在捕获声明输入之前完成独立的插件运行时和源资产生成。运行时清理保留最终声明，同时丢弃仅用于暂存的 dist-runtime 副本（构建后重新创建）。因此，保留的缓存输入不依赖于早期构建中剩余的插件工件；包输出更改仍然使它们无效。

本地 pnpm build:ci-artifacts 使用与完整构建和包构建相同的内存占用。协调器将解析的堆预算传递给每个子进程，包括 SDK 声明编写器，因此本地构建不依赖于 CI 的 NODE_OPTIONS 设置。现有的主机和 cgroup 策略限制并保留本机内存空间。如果默认预算无法适应构建，它将在构建步骤或缓存恢复之前停止； OPENCLAW_TSDOWN_MAX_OLD_SPACE_MB 仍然是尝试不同预算的显式操作员覆盖。

Control UI 尺寸预算

pnpm ui:build 生成并验证捆绑包，然后报告其压缩大小。违反预算并不能阻止工件的生成。单独的 control-ui-performance 作业会强制执行预算，而不会阻止其他作业构建或测试同一源。

初创公司 CSS 的咨询目标为 45 KiB，硬上限为 50 KiB。增长低于1 KiB通过；启动 CSS 或最大 CSS 文件中增加 1 KiB 或更多将导致比较失败。现有的最大文件、JavaScript、请求计数和隔离渲染器上限仍然独立适用。报告包括精确字节、基本增量和剩余余量，并在最大 CSS 文件的余量小于 1 KiB 时发出早期警告。

JavaScript 会计将普通块、延迟特殊用途块、启动资产和完整捆绑包总额分开。 215 KiB 普通块天花板不包括隔离的 Mermaid 渲染器和配置的区域设置目录。语言环境目录必须匹配 assets/<locale>-<nonempty-suffix>.js；每个配置的语言环境都可以生成一个延迟块，总共最多有 20 个语言环境块，每个块的上限为 300 KiB。区域设置块在启动资产集中仍然被禁止。 JavaScript 会计总计包括用于报告的普通资产、递延资产和启动资产，同时执行仍保持在特定类别的限制范围内。

CI 使用相同安装的 Node、Vite 和依赖项构建选定的结帐和精确的预检基础。在比较之前，临时基地的 CSS sidecar 通过候选者的固定压缩器进行标准化。该报告确定了修订版本和工具链。没有手动更新的CSS基线，累积上限仍然限制了一系列小的变化。

安装依赖项后在本地运行相同的比较：

pnpm ui:check-performance:base <base-commit-sha>

要在现有构建上强制执行绝对预算，请运行 pnpm ui:check-performance。使用 --base-dist <directory> 与已构建的基础进行比较，或使用 --report-only 报告违规行为而不会失败。丢失或格式错误的构建工件在仅报告模式下仍然是错误。

相关内容

• 安装概览
• 发布渠道