作业预算

分片数量、并发与矩阵预算、lint 内存策略、Android 行以及缓存键边界。属于 CI 范围与路由 索引的一部分。

独立 UI 套件通过与其受信任预热器中的受限四文件种子相同的组执行器和缓存叶子运行三个原生 Vitest 分片。每行保留根 Node worker 上限为三；Chromium 使用其项目默认值。这些分片保留完整的四项目清单以及每个项目的隔离和清理策略。使用当前分片运行器的精确目标调度保留所有三个分片，包括 Full Release Validation 的完整 Node 和 Bun 运行。只有使用历史包测试命令的兼容性目标保留其单例、未分片的封装。window.open lint 检查在第一行运行一次。每行保留其 20 分钟截止时间，矩阵最多同时允许三行。

额外的两个作业在 Blacksmith 路由上为每个选定的自动运行添加两次 Blacksmith 注册，在托管路由上则不添加。精确目标调度会添加两个托管行，但不改变自动运行预算。它们不保证工作流在八分钟内完成：预检、设置、排队时间和其他作业仍然适用。其原生报告器记录运行时 CPU 与内存实际数据、已配置的项目 worker 数量、模块诊断信息以及观察到的排队/结束事件。浏览器池日志记录实际的 Chromium 会话。运行开始时的项目计数描述的是分片前的发现结果；已完成的模块标识和最终计数则证明覆盖范围。事件间隔并非调度器准入时间；重复的 environment/prepare 时长不得累加为墙钟时间。这些记录并不能证明 transform-cache 命中。工具条带仅在所选文件包含文档翻译测试时才安装 Go；历史完整配置计划保留其现有设置。该工作流固定运行器的 Go 版本，使冻结目标无法选择不同的编译器。更新时保持该固定版本与当前翻译模块的首选工具链以及两个 Testbox 引导工作流一致。

大量使用 Shell 的 macOS 签名与提权用例每个文件最多允许三个用例，并以 Node 的可用并行度为上限。独立的 checkout fixture 表保留其两用例上限。每个用例拥有自己的命令和临时根目录；清理会先等待其进程树和回调工作结束，再移除这些输入。外部套件和剩余的 checkout 契约用例保持顺序执行。

一旦准入，标准 Linux CI 最多允许 96 个并发 Node 测试作业。该清单单独强制执行总作业预算：标准推送 70 个 Node 行，标准 PR 130 个，包括 precise 和 plugin 计划。GitHub 还将单个作业的组合输出限制为 1 MiB（以 UTF-16 计），因此所有矩阵合计的预检输出为 524,288 个字符。Node 行显式列出每个条带化测试文件。该清单先投影分片运行器所消费的字段，然后在目标包含该编解码器时使用 gzip+base64（groups_gzip_base64）。扁平配置行（包括手动 CI 和 exact-head PR 发布门禁）使用一个打包组，同时保留其原始作业和测试选择。不具备该能力的目标保留其原始扁平字段或投影出的旧版 groups JSON。工作流测试将完整生成输出保持在限制的一半以下。较小的 fast/check 通道仍以 12 为上限；Windows 以 2 为上限；Android 在正常的同仓库 Blacksmith 首次尝试中以 4 为上限，否则为 2。紧凑的完整配置批次以 120 分钟的批次超时运行，而 include-pattern 组共享相同的受限作业预算。

少于 8 个 CPU 或 24 GiB 内存的 CI 运行器上的类型感知 lint 使用现有的 Go 编译器内存策略（GOGC=30、GOMEMLIMIT=3GiB）以减少交换压力。显式 Go 设置仍然具有权威性。该限制是软限制，仅适用于 lint 子进程；声明准备保留其自己的策略。显式核心条带调用将 src/agents、src/gateway、src/infra 和 ui 放在独立的 lint 进程中，与各自条带的其余目标分开。当与邻近目标合并时，它们的语义缓存可能超过 Go 软限制。受限运行器串行执行这些进程，并在启动下一个进程之前释放每个进程树。五个条带分配、工作流行、lint 规则和文件覆盖范围保持不变；这不会增加任何运行器注册。自动完整 lint（pnpm lint）保留原有的五个聚合核心 Program，即使它继承了 CI 环境变量也是如此。已发布的 Git 更新器以固定的 20 分钟命令截止时间调用此完整流水线；显式条带调用者不得在该预检中增加编译器启动。

常规 Android PR/main CI 和 PR release_gate 调度使用四行：Play 和 Wear 共享单元测试；第三方单元测试；Wear 单元测试/lint 加第三方应用 lint；以及针对所有四个模块的 Kotlin lint，外加 Play 应用和 Wear 共享 lint。每个手机风味都有自己的源集和 SensitiveFeatureConfig；apps/android/app/src/thirdParty/AndroidManifest.xml 声明额外的权限和组件。Kotlin lint 行还会在 benchmark 或 Android 构建/依赖输入发生变化时编译 benchmark；变更路径数据缺失或不可用时仍会进行该构建。每个原生调用在其行内保持顺序，所有选定的 Gradle 任务恰好运行一次。

常规全范围手动验证保留六个 Android 行：三个测试行、build-play、build-wear 和 Kotlin lint。构建行自行承担 lint，不在测试行中重复。build-play 组装两个手机风味和 Wear 共享模块，并编译 benchmark；build-wear 组装 Wear。build-play-compat 为较旧的冻结目标保留仅 Play 的打包。GitHub 托管的 build-play 为其三次内存受限的 Gradle 调用分配 35 分钟的作业预算。所有其他 Android 任务（包括现在仅单元测试的手机行）使用 20 分钟。预算跟随当前尝试的运行器路由，即使重试复用原始预检矩阵也是如此。每个当前 Gradle 任务都有一个受保护的粘性磁盘；PR 作业使用一次性克隆，而受保护运行会就地刷新内容寻址的 Gradle 条目。现有的 Android 选择加入和 npm 资格验证延迟保持不变。

Robolectric 在 Gradle 依赖缓存之外解析 Android SDK 工件，因此每个 Android test-* 任务都会收到一个由工作流拥有的 Gradle 初始化脚本，该脚本将测试 JVM 指向专用 Maven 本地仓库。Actions 缓存恢复按任务、平台和 Android 契约限定范围；前缀恢复可以为已变更的契约提供种子，但只有成功的受信任运行才可以在未命中后发布完整的精确缓存。冷运行可以下载缺失的 SDK 工件，而热运行会复用精确归档。构建和 lint 任务不会收到 Robolectric 初始化脚本。

其余 Blacksmith sticky-disk 键有意仅受支持的任务维度限定，绝不使用 PR 编号、commit、run、分支或依赖哈希。依赖、运行时转换和编译缓存改用 Actions 缓存，因为不可变归档可提供可验证的恢复/保存结果，并避免可变快照提升失败。在 sticky 键版本迁移后，仅将确切的已废弃键、架构和区域标识添加到 .github/retired-sticky-disks.json，从 main 以相同维度和确认派发 Sticky Disk Cleanup，验证删除，然后移除这些条目。该工作流将 ARM 标识路由到 ARM runner，拒绝 runner 区域不匹配，使用 Blacksmith 的精确键删除操作，并且从不删除 Docker 构建器缓存或通配符前缀。Actions 缓存归档使用常规 LRU 和非活动驱逐。

check-dependencies 分片运行 Knip 依赖、未使用文件和未使用导出检查。两个守卫在生产扫描和全树扫描中均强制零发现，且没有未使用文件允许列表。导出守卫还会审计脚本入口导出。生产扫描排除测试支持消费者；全树扫描和脚本扫描将测试作为消费者包含在内。根据情况，在 config/knip.config.ts、config/knip.all-exports.config.ts 或 config/knip.scripts-exports.config.ts 中建模有意为之的动态消费者。每个守卫都会报告所有扫描结果，并在任何扫描失败时失败。历史目标在提供导出守卫时运行该守卫，否则保留其旧的死代码回退。