chore(i18n): refresh zh-CN translations

docs/zh-CN/ci.md

@@ -1,75 +1,75 @@
 ---
 read_when:
-    - 你需要了解为什么某个 CI 作业运行了或没有运行
+    - 你需要了解某个 CI 作业为什么运行或未运行
     - 你正在调试一个失败的 GitHub Actions 检查
     - 你正在协调一次发布验证运行或重新运行
-summary: CI 作业图、范围门禁、发布总括和本地命令等效项
+summary: CI 作业图、范围门禁、发布总括项和本地命令等价项
 title: CI 流水线
 x-i18n:
-    generated_at: "2026-04-30T23:44:01Z"
+    generated_at: "2026-05-01T02:24:10Z"
     model: gpt-5.5
     provider: openai
-    source_hash: 67bfe0245e2d78e88357f7068cc9bf9b99559655f87f9b65ffa89649b39bec44
+    source_hash: 0c2ee36f96ccf86d4adb739f5f7efb82c05f733e7693571ce391269d2538fec7
     source_path: ci.md
     workflow: 16
 ---
 
-OpenClaw CI 会在每次推送到 `main` 以及每个拉取请求时运行。`preflight` 任务会对差异进行分类，并在只有无关区域变更时关闭昂贵的任务通道。手动 `workflow_dispatch` 运行会有意绕过智能范围限定，并为候选发布版本和广泛验证展开完整图。Android 通道通过 `include_android` 保持选择加入。仅发布的插件覆盖位于单独的 [`Plugin Prerelease`](#plugin-prerelease) 工作流中，并且只会从 [`Full Release Validation`](#full-release-validation) 或显式手动触发运行。
+OpenClaw CI 会在每次推送到 `main` 以及每个拉取请求时运行。`preflight` 作业会分类差异，并在只有无关区域发生变化时关闭昂贵的执行通道。手动 `workflow_dispatch` 运行会有意绕过智能作用域划分，并为候选版本和广泛验证展开完整图。Android 通道通过 `include_android` 保持可选启用。仅发布用的插件覆盖率位于单独的 [`Plugin Prerelease`](#plugin-prerelease) 工作流中，并且只会从 [`Full Release Validation`](#full-release-validation) 或显式手动分发运行。
 
 ## 流水线概览
 
-| 任务                              | 目的                                                                                      | 运行时机                       |
+| 作业                             | 用途                                                                                         | 运行时机                           |
 | -------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------- |
-| `preflight`                      | 检测仅文档变更、变更范围、变更插件，并构建 CI 清单      | 始终在非草稿推送和 PR 上运行 |
-| `security-scm-fast`              | 通过 `zizmor` 进行私钥检测和工作流审计                                        | 始终在非草稿推送和 PR 上运行 |
-| `security-dependency-audit`      | 针对 npm 公告执行无依赖的生产 lockfile 审计                             | 始终在非草稿推送和 PR 上运行 |
-| `security-fast`                  | 快速安全任务的必需聚合项                                                | 始终在非草稿推送和 PR 上运行 |
-| `check-dependencies`             | 生产 Knip 仅依赖检查，以及未使用文件 allowlist 防护                    | Node 相关变更              |
-| `build-artifacts`                | 构建 `dist/`、Control UI、构建产物检查，以及可复用下游产物          | Node 相关变更              |
-| `checks-fast-core`               | 快速 Linux 正确性通道，例如内置/插件契约/协议检查                 | Node 相关变更              |
-| `checks-fast-contracts-channels` | 分片渠道契约检查，并提供稳定的聚合检查结果                         | Node 相关变更              |
-| `checks-node-core-test`          | 核心 Node 测试分片，不包括渠道、内置、契约和插件通道             | Node 相关变更              |
-| `check`                          | 分片主本地门禁等价项：生产类型、lint、防护、测试类型和严格 smoke   | Node 相关变更              |
-| `check-additional`               | 架构、边界、插件表面防护、包边界和 gateway-watch 分片 | Node 相关变更              |
-| `build-smoke`                    | 已构建 CLI smoke 测试和启动内存 smoke                                               | Node 相关变更              |
-| `checks`                         | 已构建产物渠道测试的验证器                                                    | Node 相关变更              |
-| `checks-node-compat-node22`      | Node 22 兼容性构建和 smoke 通道                                                   | 用于发布的手动 CI 触发    |
-| `check-docs`                     | 文档格式化、lint 和断链检查                                                | 文档已变更                       |
-| `skills-python`                  | 面向 Python 支持的 Skills 的 Ruff + pytest                                                       | Python Skill 相关变更      |
-| `checks-windows`                 | Windows 特定进程/路径测试，以及共享运行时导入说明符回归         | Windows 相关变更           |
-| `macos-node`                     | 使用共享构建产物的 macOS TypeScript 测试通道                                  | macOS 相关变更             |
-| `macos-swift`                    | macOS 应用的 Swift lint、构建和测试                                               | macOS 相关变更             |
-| `android`                        | 两种 flavor 的 Android 单元测试，以及一次 debug APK 构建                                 | Android 相关变更           |
-| `test-performance-agent`         | 受信任活动之后的每日 Codex 慢测试优化                                    | 主 CI 成功或手动触发 |
+| `preflight`                      | 检测仅文档变更、变更作用域、变更插件，并构建 CI 清单                                         | 始终在非草稿推送和 PR 上运行       |
+| `security-scm-fast`              | 通过 `zizmor` 进行私钥检测和工作流审计                                                       | 始终在非草稿推送和 PR 上运行       |
+| `security-dependency-audit`      | 针对 npm 公告进行无依赖的生产锁文件审计                                                      | 始终在非草稿推送和 PR 上运行       |
+| `security-fast`                  | 快速安全作业所需的聚合项                                                                     | 始终在非草稿推送和 PR 上运行       |
+| `check-dependencies`             | 生产 Knip 仅依赖检查，加上未使用文件允许列表防护                                             | Node 相关变更                      |
+| `build-artifacts`                | 构建 `dist/`、Control UI、构建产物检查，以及可复用的下游产物                                 | Node 相关变更                      |
+| `checks-fast-core`               | 快速 Linux 正确性通道，例如内置/插件契约/协议检查                                            | Node 相关变更                      |
+| `checks-fast-contracts-channels` | 分片的渠道契约检查，并提供稳定的聚合检查结果                                                 | Node 相关变更                      |
+| `checks-node-core-test`          | Core Node 测试分片，不包括渠道、内置、契约和插件通道                                         | Node 相关变更                      |
+| `check`                          | 分片的主要本地门禁等价项：生产类型、lint、防护、测试类型和严格冒烟                           | Node 相关变更                      |
+| `check-additional`               | 架构、边界、插件表面防护、包边界和 Gateway 网关 watch 分片                                   | Node 相关变更                      |
+| `build-smoke`                    | 已构建 CLI 冒烟测试和启动内存冒烟                                                           | Node 相关变更                      |
+| `checks`                         | 构建产物渠道测试的验证器                                                                     | Node 相关变更                      |
+| `checks-node-compat-node22`      | Node 22 兼容性构建和冒烟通道                                                                 | 用于发布的手动 CI 分发             |
+| `check-docs`                     | 文档格式、lint 和断链检查                                                                    | 文档变更                           |
+| `skills-python`                  | 面向 Python 支撑的 Skills 的 Ruff + pytest                                                   | Python Skill 相关变更              |
+| `checks-windows`                 | Windows 专用进程/路径测试，加上共享运行时导入说明符回归                                     | Windows 相关变更                   |
+| `macos-node`                     | 使用共享构建产物的 macOS TypeScript 测试通道                                                 | macOS 相关变更                     |
+| `macos-swift`                    | macOS 应用的 Swift lint、构建和测试                                                          | macOS 相关变更                     |
+| `android`                        | 两种 flavor 的 Android 单元测试，加上一次调试 APK 构建                                      | Android 相关变更                   |
+| `test-performance-agent`         | 受信任活动后的每日 Codex 慢测试优化                                                         | 主 CI 成功或手动分发               |
 
 ## 快速失败顺序
 
-1. `preflight` 决定哪些通道实际存在。`docs-scope` 和 `changed-scope` 逻辑是此任务内的步骤，而不是独立任务。
-2. `security-scm-fast`、`security-dependency-audit`、`security-fast`、`check`、`check-additional`、`check-docs` 和 `skills-python` 会快速失败，无需等待更重的产物和平台矩阵任务。
-3. `build-artifacts` 会与快速 Linux 通道重叠执行，因此下游消费者可以在共享构建准备好后立即开始。
+1. `preflight` 决定哪些通道实际存在。`docs-scope` 和 `changed-scope` 逻辑是此作业中的步骤，而不是独立作业。
+2. `security-scm-fast`、`security-dependency-audit`、`security-fast`、`check`、`check-additional`、`check-docs` 和 `skills-python` 会快速失败，而不等待更重的产物和平台矩阵作业。
+3. `build-artifacts` 会与快速 Linux 通道重叠运行，以便共享构建就绪后下游消费者可以立即开始。
 4. 更重的平台和运行时通道随后展开：`checks-fast-core`、`checks-fast-contracts-channels`、`checks-node-core-test`、`checks`、`checks-windows`、`macos-node`、`macos-swift` 和 `android`。
 
-当同一 PR 或 `main` ref 上有更新推送落地时，GitHub 可能会将被取代的任务标记为 `cancelled`。除非同一 ref 的最新运行也失败，否则将其视为 CI 噪声。聚合分片检查使用 `!cancelled() && always()`，因此它们仍会报告正常的分片失败，但不会在整个工作流已经被取代后继续排队。自动 CI 并发键带有版本号（`CI-v7-*`），因此 GitHub 侧旧队列组中的僵尸任务无法无限阻塞较新的 main 运行。手动完整套件运行使用 `CI-manual-v1-*`，并且不会取消正在进行的运行。
+当较新的推送落在同一个 PR 或 `main` ref 上时，GitHub 可能会将被取代的作业标记为 `cancelled`。除非同一 ref 的最新运行也失败，否则将其视为 CI 噪声。聚合分片检查使用 `!cancelled() && always()`，因此它们仍会报告正常的分片失败，但不会在整个工作流已经被取代后继续排队。自动 CI 并发键带有版本号（`CI-v7-*`），因此 GitHub 侧旧队列组中的僵尸项无法无限阻塞新的 main 运行。手动完整套件运行使用 `CI-manual-v1-*`，并且不会取消正在进行的运行。
 
-## 范围和路由
+## 作用域和路由
 
-范围逻辑位于 `scripts/ci-changed-scope.mjs`，并由 `src/scripts/ci-changed-scope.test.ts` 中的单元测试覆盖。手动触发会跳过变更范围检测，并让 preflight 清单表现得像每个限定范围区域都已变更。
+作用域逻辑位于 `scripts/ci-changed-scope.mjs`，并由 `src/scripts/ci-changed-scope.test.ts` 中的单元测试覆盖。手动分发会跳过变更作用域检测，并让 preflight 清单表现得像每个有作用域的区域都发生了变化。
 
-- **CI 工作流编辑**会验证 Node CI 图以及工作流 lint，但本身不会强制执行 Windows、Android 或 macOS 原生构建；这些平台通道仍限定于平台源代码变更。
-- **仅 CI 路由编辑、选定的廉价核心测试 fixture 编辑，以及窄范围插件契约 helper/测试路由编辑**会使用快速的仅 Node 清单路径：`preflight`、security，以及单个 `checks-fast-core` 任务。当变更仅限于该快速任务直接覆盖的路由或 helper 表面时，此路径会跳过构建产物、Node 22 兼容性、渠道契约、完整核心分片、内置插件分片和额外防护矩阵。
-- **Windows Node 检查**限定于 Windows 特定进程/路径包装器、npm/pnpm/UI runner helper、包管理器配置，以及执行该通道的 CI 工作流表面；无关源代码、插件、install-smoke 和仅测试变更会留在 Linux Node 通道上。
+- **CI 工作流编辑**会验证 Node CI 图和工作流 linting，但不会单独强制 Windows、Android 或 macOS 原生构建；这些平台通道仍限定为平台源代码变更。
+- **仅 CI 路由编辑、选定的低成本核心测试 fixture 编辑，以及窄范围插件契约 helper/测试路由编辑**使用快速的仅 Node 清单路径：`preflight`、security，以及单个 `checks-fast-core` 任务。当变更仅限于该快速任务直接覆盖的路由或 helper 表面时，此路径会跳过构建产物、Node 22 兼容性、渠道契约、完整核心分片、内置插件分片和额外防护矩阵。
+- **Windows Node 检查**限定于 Windows 专用进程/路径包装器、npm/pnpm/UI 运行器 helper、包管理器配置，以及执行该通道的 CI 工作流表面；无关源代码、插件、安装冒烟和仅测试变更仍停留在 Linux Node 通道上。
 
-最慢的 Node 测试族会被拆分或均衡，让每个任务保持较小规模而不过度预留 runner：渠道契约作为三个加权分片运行，小型核心单元通道会配对，auto-reply 作为四个均衡 worker 运行（其中 reply 子树拆分为 agent-runner、dispatch 和 commands/state-routing 分片），agentic gateway/插件配置会分散到现有的仅源代码 agentic Node 任务中，而不是等待构建产物。广泛的浏览器、QA、媒体和杂项插件测试使用各自专用的 Vitest 配置，而不是共享的插件兜底配置。include-pattern 分片会使用 CI 分片名称记录计时条目，因此 `.artifacts/vitest-shard-timings.json` 可以区分整个配置和经过过滤的分片。`check-additional` 会将包边界编译/canary 工作放在一起，并将运行时拓扑架构与 gateway watch 覆盖分开；边界防护分片会在一个任务内并发运行其小型独立防护。Gateway watch、渠道测试和核心支持边界分片会在 `dist/` 和 `dist-runtime/` 已经构建完成后，于 `build-artifacts` 内并发运行。
+最慢的 Node 测试族会被拆分或平衡，使每个作业保持较小规模且不过度预留运行器：渠道契约作为三个加权分片运行，小型核心单元通道会配对，auto-reply 作为四个均衡 worker 运行（reply 子树拆分为 agent-runner、dispatch 和 commands/state-routing 分片），agentic gateway/插件配置则分散到现有的仅源代码 agentic Node 作业中，而不是等待构建产物。广泛的浏览器、QA、媒体和杂项插件测试使用其专用 Vitest 配置，而不是共享插件兜底项。include-pattern 分片使用 CI 分片名称记录计时条目，因此 `.artifacts/vitest-shard-timings.json` 可以区分整个配置和过滤后的分片。`check-additional` 将包边界编译/canary 工作保持在一起，并将运行时拓扑架构与 Gateway 网关 watch 覆盖分离；边界防护分片会在一个作业内并发运行其小型独立防护。Gateway 网关 watch、渠道测试和核心支持边界分片会在 `dist/` 和 `dist-runtime/` 已经构建完成后，在 `build-artifacts` 内并发运行。
 
-Android CI 会运行 `testPlayDebugUnitTest` 和 `testThirdPartyDebugUnitTest`，随后构建 Play debug APK。third-party flavor 没有单独的 source set 或 manifest；它的单元测试通道仍会使用 SMS/通话记录 BuildConfig 标志编译该 flavor，同时避免在每次 Android 相关推送上重复执行 debug APK 打包任务。
+Android CI 会同时运行 `testPlayDebugUnitTest` 和 `testThirdPartyDebugUnitTest`，然后构建 Play 调试 APK。第三方 flavor 没有单独的源码集或清单；其单元测试通道仍会使用 SMS/call-log BuildConfig 标志编译该 flavor，同时避免在每次 Android 相关推送中重复执行调试 APK 打包作业。
 
-`check-dependencies` 分片运行 `pnpm deadcode:dependencies`（生产 Knip 仅依赖检查，固定到最新 Knip 版本，并为 `dlx` 安装禁用 pnpm 的最低发布年龄）和 `pnpm deadcode:unused-files`，后者会将 Knip 的生产未使用文件发现结果与 `scripts/deadcode-unused-files.allowlist.mjs` 对比。当 PR 添加新的未经审查未使用文件，或留下过期 allowlist 条目时，未使用文件防护会失败，同时保留 Knip 无法静态解析的有意动态插件、生成产物、构建、live-test 和包桥接表面。
+`check-dependencies` 分片运行 `pnpm deadcode:dependencies`（生产 Knip 仅依赖检查，固定到最新 Knip 版本，并为 `dlx` 安装禁用 pnpm 的最低发布时间限制）和 `pnpm deadcode:unused-files`，后者会将 Knip 的生产未使用文件发现结果与 `scripts/deadcode-unused-files.allowlist.mjs` 进行比较。当 PR 新增未经审查的未使用文件或留下过期的允许列表条目时，未使用文件防护会失败，同时保留 Knip 无法静态解析的有意动态插件、生成内容、构建、实时测试和包桥接表面。
 
-## 手动触发
+## 手动分发
 
-手动 CI 触发运行与普通 CI 相同的任务图，但会强制开启每个非 Android 限定范围通道：Linux Node 分片、内置插件分片、渠道契约、Node 22 兼容性、`check`、`check-additional`、构建 smoke、文档检查、Python Skills、Windows、macOS 和 Control UI i18n。独立手动 CI 触发仅在 `include_android=true` 时运行 Android；完整发布总入口会通过传递 `include_android=true` 启用 Android。插件预发布静态检查、仅发布的 `agentic-plugins` 分片、完整插件批量扫描和插件预发布 Docker 通道不包含在 CI 中。Docker 预发布套件仅在 `Full Release Validation` 使用已启用的 release-validation 门禁触发单独的 `Plugin Prerelease` 工作流时运行。
+手动 CI 分发运行与普通 CI 相同的作业图，但会强制开启每个非 Android 作用域通道：Linux Node 分片、内置插件分片、渠道契约、Node 22 兼容性、`check`、`check-additional`、构建冒烟、文档检查、Python Skills、Windows、macOS 和 Control UI i18n。独立手动 CI 分发只有在 `include_android=true` 时才运行 Android；完整发布总控通过传递 `include_android=true` 启用 Android。插件预发布静态检查、仅发布用的 `agentic-plugins` 分片、完整插件批量扫描以及插件预发布 Docker 通道都不包含在 CI 中。Docker 预发布套件只在 `Full Release Validation` 以启用 release-validation 门禁的方式分发单独的 `Plugin Prerelease` 工作流时运行。
 
-手动运行使用唯一并发组，因此候选发布版本完整套件不会被同一 ref 上的另一次推送或 PR 运行取消。可选的 `target_ref` 输入允许受信任调用方在使用所选触发 ref 中工作流文件的同时，针对分支、标签或完整提交 SHA 运行该图。
+手动运行使用唯一并发组，因此候选版本完整套件不会被同一 ref 上的另一个推送或 PR 运行取消。可选的 `target_ref` 输入允许受信任调用方针对分支、标签或完整提交 SHA 运行该图，同时使用所选分发 ref 中的工作流文件。
 
 ```bash
 gh workflow run ci.yml --ref release/YYYY.M.D
@@ -77,17 +77,17 @@ gh workflow run ci.yml --ref main -f target_ref=<branch-or-sha> -f include_andro
 gh workflow run full-release-validation.yml --ref main -f ref=<branch-or-sha>
 ```
 
-## Runner
+## 运行器
 
 | 运行器                           | 作业                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
 | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `ubuntu-24.04`                   | `preflight`、快速安全作业和聚合项（`security-scm-fast`、`security-dependency-audit`、`security-fast`）、快速协议/契约/内置检查、分片的渠道契约检查、除 lint 以外的 `check` 分片、`check-additional` 分片和聚合项、Node 测试聚合验证器、文档检查、Python Skills、workflow-sanity、labeler、auto-response；install-smoke 预检也使用 GitHub 托管的 Ubuntu，因此 Blacksmith 矩阵可以更早排队 |
-| `blacksmith-4vcpu-ubuntu-2404`   | `CodeQL Critical Quality`、较低负载的插件分片、`checks-fast-core`、`checks-node-compat-node22`、`check-prod-types` 和 `check-test-types`                                                                                                                                                                                                                                                                                                                   |
+| `ubuntu-24.04`                   | `preflight`、快速安全作业和聚合作业（`security-scm-fast`、`security-dependency-audit`、`security-fast`）、快速协议/契约/内置检查、分片渠道契约检查、除 lint 以外的 `check` 分片、`check-additional` 分片和聚合作业、Node 测试聚合验证器、文档检查、Python Skills、workflow-sanity、labeler、auto-response；install-smoke 预检也使用 GitHub 托管的 Ubuntu，这样 Blacksmith 矩阵可以更早排队 |
+| `blacksmith-4vcpu-ubuntu-2404`   | `CodeQL Critical Quality`、较低权重的插件分片、`checks-fast-core`、`checks-node-compat-node22`、`check-prod-types` 和 `check-test-types`                                                                                                                                                                                                                                                                                                                   |
 | `blacksmith-8vcpu-ubuntu-2404`   | `build-artifacts`、build-smoke、Linux Node 测试分片、内置插件测试分片、`android`                                                                                                                                                                                                                                                                                                                                                                           |
-| `blacksmith-16vcpu-ubuntu-2404`  | `check-lint`（对 CPU 足够敏感，8 vCPU 增加的成本超过了节省的成本）；install-smoke Docker 构建（32-vCPU 队列时间增加的成本超过了节省的成本）                                                                                                                                                                                                                                                                                                                     |
+| `blacksmith-16vcpu-ubuntu-2404`  | `check-lint`（对 CPU 足够敏感，8 vCPU 的成本高于节省的时间）；install-smoke Docker 构建（32-vCPU 排队时间成本高于节省的时间）                                                                                                                                                                                                                                                                                                                     |
 | `blacksmith-16vcpu-windows-2025` | `checks-windows`                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
-| `blacksmith-6vcpu-macos-latest`  | `openclaw/openclaw` 上的 `macos-node`；fork 回退到 `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                  |
-| `blacksmith-12vcpu-macos-latest` | `openclaw/openclaw` 上的 `macos-swift`；fork 回退到 `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                 |
+| `blacksmith-6vcpu-macos-latest`  | `openclaw/openclaw` 上的 `macos-node`；分叉仓库回退到 `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                  |
+| `blacksmith-12vcpu-macos-latest` | `openclaw/openclaw` 上的 `macos-swift`；分叉仓库回退到 `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                 |
 
 ## 本地等效命令
 
@@ -117,23 +117,27 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac
 
 ## 完整发布验证
 
-`Full Release Validation` 是用于“发布前运行所有内容”的手动总括工作流。它接受分支、标签或完整提交 SHA，使用该目标分派手动 `CI` 工作流，为仅发布相关的插件/包/静态/Docker 证明分派 `Plugin Prerelease`，并为安装烟测、包验收、Docker 发布路径套件、live/E2E、OpenWebUI、QA Lab 一致性、Matrix 和 Telegram lane 分派 `OpenClaw Release Checks`。当提供已发布包规范时，它还可以运行发布后的 `NPM Telegram Beta E2E` 工作流。
+`Full Release Validation` 是“发布前运行所有内容”的手动总控工作流。它接受分支、标签或完整提交 SHA，使用该目标调度手动 `CI` 工作流，调度 `Plugin Prerelease` 以提供仅发布所需的插件/软件包/静态/Docker 证明，并调度 `OpenClaw Release Checks` 以执行安装冒烟、软件包验收、Docker 发布路径套件、live/E2E、OpenWebUI、QA Lab parity、Matrix 和 Telegram 通道。当提供已发布的软件包规格时，它还可以运行发布后的 `NPM Telegram Beta E2E` 工作流。
 
-`release_profile` 控制传入发布检查的 live/提供商覆盖范围：
+参见[完整发布验证](/zh-CN/reference/full-release-validation)，了解阶段矩阵、精确的工作流作业名称、配置差异、构件和聚焦重跑句柄。
 
-- `minimum` 保留最快的 OpenAI/core 发布关键 lane。
-- `stable` 添加稳定提供商/后端集合。
-- `full` 运行广泛的建议提供商/媒体矩阵。
+`release_profile` 控制传入发布检查的 live/提供商覆盖范围。手动发布工作流默认使用 `stable`；仅在你明确需要宽泛的建议性提供商/媒体矩阵时才使用 `full`。
 
-总括工作流会记录已分派的子运行 ID，最终的 `Verify full validation` 作业会重新检查当前子运行结论，并为每个子运行追加最慢作业表。如果某个子工作流重新运行后变绿，只需重新运行父验证器作业，即可刷新总括结果和时间摘要。
+- `minimum` 保留最快的 OpenAI/核心发布关键通道。
+- `stable` 添加稳定的提供商/后端集合。
+- `full` 运行宽泛的建议性提供商/媒体矩阵。
 
-对于恢复，`Full Release Validation` 和 `OpenClaw Release Checks` 都接受 `rerun_group`。发布候选版本使用 `all`，仅普通完整 CI 子项使用 `ci`，每个发布子项使用 `release-checks`，也可以在总括工作流上使用更窄的分组：`install-smoke`、`cross-os`、`live-e2e`、`package`、`qa`、`qa-parity`、`qa-live` 或 `npm-telegram`。这样可以在聚焦修复后将失败发布箱的重新运行限制在边界内。
+总控会记录已调度的子运行 ID，最终的 `Verify full validation` 作业会重新检查当前子运行结论，并为每个子运行追加最慢作业表。如果某个子工作流重跑后变绿，只需重跑父验证器作业来刷新总控结果和耗时摘要。
 
-`OpenClaw Release Checks` 使用可信工作流引用将所选引用解析一次为 `release-package-under-test` tarball，然后将该构件传递给 live/E2E 发布路径 Docker 工作流和包验收分片。这样可以让发布箱之间的包字节保持一致，并避免在多个子作业中重复打包同一个候选版本。
+对于恢复，`Full Release Validation` 和 `OpenClaw Release Checks` 都接受 `rerun_group`。发布候选版使用 `all`，仅普通完整 CI 子项使用 `ci`，仅插件预发布子项使用 `plugin-prerelease`，每个发布子项使用 `release-checks`，或在总控上使用更窄的组：`install-smoke`、`cross-os`、`live-e2e`、`package`、`qa`、`qa-parity`、`qa-live` 或 `npm-telegram`。这样在聚焦修复后，失败的发布盒子重跑可以保持有界。
+
+`OpenClaw Release Checks` 使用受信任的工作流 ref，将所选 ref 一次性解析为 `release-package-under-test` tarball，然后将该构件传给 live/E2E 发布路径 Docker 工作流和软件包验收分片。这会让各发布盒子使用一致的软件包字节，并避免在多个子作业中重新打包同一个候选项。
+
+针对 `ref=main` 和 `rerun_group=all` 的重复 `Full Release Validation` 运行会取代较旧的总控。父监视器在父项被取消时，会取消它已经调度的任何子工作流，因此较新的 main 验证不会排在陈旧的两小时发布检查运行后面。发布分支/标签验证和聚焦重跑组保持 `cancel-in-progress: false`。
 
 ## Live 和 E2E 分片
 
-发布 live/E2E 子项保留广泛的原生 `pnpm test:live` 覆盖范围，但它通过 `scripts/test-live-shard.mjs` 作为命名分片运行，而不是一个串行作业：
+发布 live/E2E 子项保留宽泛的原生 `pnpm test:live` 覆盖范围，但它通过 `scripts/test-live-shard.mjs` 以命名分片运行，而不是一个串行作业：
 
 - `native-live-src-agents`
 - `native-live-src-gateway-core`
@@ -147,55 +151,55 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac
 - `native-live-extensions-xai`
 - 拆分的媒体音频/视频分片和提供商过滤的音乐分片
 
-这在保持相同文件覆盖范围的同时，让较慢的 live 提供商失败更容易重新运行和诊断。聚合 `native-live-extensions-o-z`、`native-live-extensions-media` 和 `native-live-extensions-media-music` 分片名称仍然可用于手动一次性重新运行。
+这样在保持相同文件覆盖范围的同时，也让缓慢的 live 提供商失败更容易重跑和诊断。聚合的 `native-live-extensions-o-z`、`native-live-extensions-media` 和 `native-live-extensions-media-music` 分片名称仍可用于手动一次性重跑。
 
-原生 live 媒体分片在 `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04` 中运行，该镜像由 `Live Media Runner Image` 工作流构建。该镜像预装 `ffmpeg` 和 `ffprobe`；媒体作业只在设置前验证二进制文件。将 Docker 支撑的 live 套件保留在普通 Blacksmith 运行器上，容器作业并不适合启动嵌套 Docker 测试。
+原生 live 媒体分片在 `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04` 中运行，该镜像由 `Live Media Runner Image` 工作流构建。该镜像预装 `ffmpeg` 和 `ffprobe`；媒体作业只会在设置前验证这些二进制文件。将 Docker 支持的 live 套件保留在普通 Blacksmith 运行器上，容器作业不是启动嵌套 Docker 测试的合适位置。
 
-Docker 支撑的 live 模型/后端分片会为每个所选提交使用单独的共享 `ghcr.io/openclaw/openclaw-live-test:<sha>` 镜像。live 发布工作流会构建并推送该镜像一次，然后 Docker live 模型、Gateway 网关、CLI 后端、ACP bind 和 Codex harness 分片会使用 `OPENCLAW_SKIP_DOCKER_BUILD=1` 运行。如果这些分片各自独立重新构建完整源 Docker 目标，则说明发布运行配置错误，并会在重复镜像构建上浪费墙钟时间。
+Docker 支持的 live 模型/后端分片会为每个所选提交使用单独的共享 `ghcr.io/openclaw/openclaw-live-test:<sha>` 镜像。live 发布工作流会构建并推送该镜像一次，然后 Docker live 模型、按提供商分片的 Gateway 网关、CLI 后端、ACP bind 和 Codex harness 分片会使用 `OPENCLAW_SKIP_DOCKER_BUILD=1` 运行。Gateway 网关 Docker 分片携带显式的脚本级 `timeout` 上限，低于工作流作业超时，因此卡住的容器或清理路径会快速失败，而不是消耗整个发布检查预算。如果这些分片独立重建完整源码 Docker 目标，则说明发布运行配置错误，并会在重复镜像构建上浪费实际时间。
 
-## 包验收
+## 软件包验收
 
-当问题是“这个可安装的 OpenClaw 包作为产品是否可用？”时，使用 `Package Acceptance`。它不同于普通 CI：普通 CI 验证源代码树，而包验收通过用户在安装或更新后执行的同一个 Docker E2E harness 来验证单个 tarball。
+当问题是“这个可安装的 OpenClaw 软件包作为产品是否可用？”时，使用 `Package Acceptance`。它不同于普通 CI：普通 CI 验证源码树，而软件包验收通过用户安装或更新后会执行的同一套 Docker E2E harness 来验证单个 tarball。
 
 ### 作业
 
-1. `resolve_package` 检出 `workflow_ref`，解析一个包候选，写入 `.artifacts/docker-e2e-package/openclaw-current.tgz`，写入 `.artifacts/docker-e2e-package/package-candidate.json`，将两者作为 `package-under-test` 构件上传，并在 GitHub 步骤摘要中打印来源、工作流引用、包引用、版本、SHA-256 和 profile。
-2. `docker_acceptance` 使用 `ref=workflow_ref` 和 `package_artifact_name=package-under-test` 调用 `openclaw-live-and-e2e-checks-reusable.yml`。可复用工作流会下载该构件，验证 tarball 清单，在需要时准备包摘要 Docker 镜像，并针对该包运行所选 Docker lane，而不是打包工作流检出内容。当某个 profile 选择多个目标 `docker_lanes` 时，可复用工作流会先准备一次包和共享镜像，然后将这些 lane 扇出为并行的目标 Docker 作业，并使用唯一构件。
-3. `package_telegram` 可选调用 `NPM Telegram Beta E2E`。当 `telegram_mode` 不是 `none` 时运行；如果 Package Acceptance 解析了包，则安装同一个 `package-under-test` 构件；独立 Telegram 分派仍可安装已发布的 npm 规范。
-4. `summary` 会在包解析、Docker 验收或可选 Telegram lane 失败时使工作流失败。
+1. `resolve_package` 会检出 `workflow_ref`，解析一个包候选项，写入 `.artifacts/docker-e2e-package/openclaw-current.tgz`，写入 `.artifacts/docker-e2e-package/package-candidate.json`，将两者作为 `package-under-test` 工件上传，并在 GitHub 步骤摘要中打印来源、工作流 ref、包 ref、版本、SHA-256 和 profile。
+2. `docker_acceptance` 会以 `ref=workflow_ref` 和 `package_artifact_name=package-under-test` 调用 `openclaw-live-and-e2e-checks-reusable.yml`。可复用工作流会下载该工件，验证 tarball 清单，在需要时准备 package-digest Docker 镜像，并针对该包运行选定的 Docker lane，而不是打包工作流检出内容。当某个 profile 选择了多个目标 `docker_lanes` 时，可复用工作流会先准备一次包和共享镜像，然后将这些 lane 扇出为并行的目标 Docker 作业，并使用唯一工件。
+3. `package_telegram` 可选调用 `NPM Telegram Beta E2E`。当 `telegram_mode` 不是 `none` 时它会运行；如果包验收已解析出一个包，它会安装同一个 `package-under-test` 工件；独立的 Telegram 分发仍可安装已发布的 npm spec。
+4. 如果包解析、Docker 验收或可选 Telegram lane 失败，`summary` 会使工作流失败。
 
 ### 候选来源
 
-- `source=npm` 仅接受 `openclaw@beta`、`openclaw@latest`，或精确的 OpenClaw 发布版本，例如 `openclaw@2026.4.27-beta.2`。用它执行已发布 beta/稳定版验收。
-- `source=ref` 会打包受信任的 `package_ref` 分支、标签或完整提交 SHA。解析器会获取 OpenClaw 分支/标签，验证选定提交可从仓库分支历史或发布标签到达，在分离的工作树中安装依赖，并用 `scripts/package-openclaw-for-docker.mjs` 打包。
-- `source=url` 下载 HTTPS `.tgz`；必须提供 `package_sha256`。
-- `source=artifact` 从 `artifact_run_id` 和 `artifact_name` 下载一个 `.tgz`；`package_sha256` 可选，但对外共享的构件应提供它。
+- `source=npm` 仅接受 `openclaw@beta`、`openclaw@latest`，或精确的 OpenClaw 发布版本，例如 `openclaw@2026.4.27-beta.2`。将它用于已发布 beta/稳定版验收。
+- `source=ref` 会打包受信任的 `package_ref` 分支、标签或完整 commit SHA。解析器会获取 OpenClaw 分支/标签，验证所选 commit 可从仓库分支历史或发布标签到达，在分离 worktree 中安装依赖，并用 `scripts/package-openclaw-for-docker.mjs` 打包。
+- `source=url` 会下载 HTTPS `.tgz`；必须提供 `package_sha256`。
+- `source=artifact` 会从 `artifact_run_id` 和 `artifact_name` 下载一个 `.tgz`；`package_sha256` 是可选的，但对于外部共享的工件应提供。
 
-保持 `workflow_ref` 和 `package_ref` 分离。`workflow_ref` 是运行测试的受信任工作流/测试框架代码。`package_ref` 是 `source=ref` 时会被打包的源提交。这样，当前测试框架就能验证较旧的受信任源提交，而不运行旧的工作流逻辑。
+请将 `workflow_ref` 和 `package_ref` 分开。`workflow_ref` 是运行测试的受信任工作流/harness 代码。`package_ref` 是在 `source=ref` 时被打包的源 commit。这样，当前测试 harness 就能验证较旧的受信任源 commit，而无需运行旧的工作流逻辑。
 
-### 套件配置
+### 套件 profile
 
 - `smoke` — `npm-onboard-channel-agent`、`gateway-network`、`config-reload`
 - `package` — `npm-onboard-channel-agent`、`doctor-switch`、`update-channel-switch`、`upgrade-survivor`、`published-upgrade-survivor`、`bundled-channel-deps-compat`、`plugins-offline`、`plugin-update`
 - `product` — `package` 加上 `mcp-channels`、`cron-mcp-cleanup`、`openai-web-search-minimal`、`openwebui`
 - `full` — 带 OpenWebUI 的完整 Docker 发布路径分块
-- `custom` — 精确的 `docker_lanes`；当 `suite_profile=custom` 时必需
+- `custom` — 精确的 `docker_lanes`；当 `suite_profile=custom` 时必填
 
-`package` 配置使用离线插件覆盖范围，因此已发布包验证不会受实时 ClawHub 可用性约束。可选的 Telegram 车道会在 `NPM Telegram Beta E2E` 中复用 `package-under-test` 构件，同时保留已发布 npm 规格路径用于独立调度。
+`package` profile 使用离线插件覆盖，因此已发布包验证不会被实时 ClawHub 可用性阻塞。可选 Telegram lane 会在 `NPM Telegram Beta E2E` 中复用 `package-under-test` 工件，同时为独立分发保留已发布 npm spec 路径。
 
-发布检查使用 `source=ref`、`package_ref=<release-ref>`、`workflow_ref=<release workflow ref>`、`suite_profile=custom`、`docker_lanes='bundled-channel-deps-compat plugins-offline'` 和 `telegram_mode=mock-openai` 调用 Package Acceptance。发布路径 Docker 分块覆盖重叠的包/更新/插件车道；Package Acceptance 保留基于构件原生的内置渠道兼容、离线插件和 Telegram 证明，并针对同一个已解析的包 tarball。跨 OS 发布检查仍覆盖特定 OS 的新手引导、安装器和平台行为；包/更新产品验证应从 Package Acceptance 开始。Windows 打包和安装器全新车道还会验证已安装包能从原始绝对 Windows 路径导入浏览器控制覆盖。OpenAI 跨 OS agent-turn 冒烟测试在设置时默认使用 `OPENCLAW_CROSS_OS_OPENAI_MODEL`，否则使用 `openai/gpt-5.4-mini`，因此安装和 Gateway 网关证明保持快速且确定。
+发布检查会以 `source=ref`、`package_ref=<release-ref>`、`workflow_ref=<release workflow ref>`、`suite_profile=custom`、`docker_lanes='bundled-channel-deps-compat plugins-offline'` 和 `telegram_mode=mock-openai` 调用包验收。发布路径 Docker 分块会覆盖重叠的包/更新/插件 lane；包验收则针对同一个已解析包 tarball 保留原生工件的内置渠道兼容、离线插件和 Telegram 证明。跨 OS 发布检查仍会覆盖特定于 OS 的新手引导、安装器和平台行为；包/更新产品验证应从包验收开始。Windows 打包版和安装器全新 lane 还会验证已安装包可以从原始 Windows 绝对路径导入 browser-control override。OpenAI 跨 OS 智能体回合 smoke 在设置时默认使用 `OPENCLAW_CROSS_OS_OPENAI_MODEL`，否则使用 `openai/gpt-5.4-mini`，因此安装和 Gateway 网关证明保持快速且确定。
 
 ### 旧版兼容窗口
 
-Package Acceptance 对已发布包有有界的旧版兼容窗口。到 `2026.4.25` 为止的包，包括 `2026.4.25-beta.*`，可以使用兼容路径：
+包验收为已发布包提供有界的旧版兼容窗口。直到 `2026.4.25` 的包（包括 `2026.4.25-beta.*`）可以使用兼容路径：
 
-- `dist/postinstall-inventory.json` 中已知的私有 QA 条目可以指向 tarball 省略的文件；
-- 当包未暴露 `gateway install --wrapper` 标志时，`doctor-switch` 可以跳过其持久化子用例；
-- `update-channel-switch` 可以从 tarball 派生的假 git 夹具中修剪缺失的 `pnpm.patchedDependencies`，并可以记录缺失的持久化 `update.channel`；
-- 插件冒烟测试可以读取旧版安装记录位置，或接受缺失的 marketplace 安装记录持久化；
-- `plugin-update` 可以允许配置元数据迁移，同时仍要求安装记录和不重装行为保持不变。
+- `dist/postinstall-inventory.json` 中的已知私有 QA 条目可能指向 tarball 省略的文件；
+- 当包未暴露 `gateway install --wrapper` 标志时，`doctor-switch` 可以跳过该持久化子用例；
+- `update-channel-switch` 可以从 tarball 派生的 fake git fixture 中剪除缺失的 `pnpm.patchedDependencies`，并可以记录缺失的持久化 `update.channel`；
+- 插件 smoke 可以读取旧版安装记录位置，或接受缺少 marketplace 安装记录持久化；
+- `plugin-update` 可以允许配置元数据迁移，同时仍要求安装记录和不重新安装行为保持不变。
 
-已发布的 `2026.4.26` 包也可以对已经发货的本地构建元数据戳文件发出警告。后续包必须满足现代契约；相同条件会失败，而不是警告或跳过。
+已发布的 `2026.4.26` 包也可能对已发货的本地构建元数据 stamp 文件发出警告。后续包必须满足现代契约；相同条件会失败，而不是警告或跳过。
 
 ### 示例
 
@@ -238,111 +242,111 @@ gh workflow run package-acceptance.yml \
   -f docker_lanes='install-e2e plugin-update'
 ```
 
-调试失败的包验收运行时，从 `resolve_package` 摘要开始，确认包来源、版本和 SHA-256。然后检查 `docker_acceptance` 子运行及其 Docker 构件：`.artifacts/docker-tests/**/summary.json`、`failures.json`、车道日志、阶段计时和重新运行命令。优先重新运行失败的包配置或精确 Docker 车道，而不是重新运行完整发布验证。
+调试失败的包验收运行时，先查看 `resolve_package` 摘要，以确认包来源、版本和 SHA-256。然后检查 `docker_acceptance` 子运行及其 Docker 工件：`.artifacts/docker-tests/**/summary.json`、`failures.json`、lane 日志、阶段计时和重运行命令。优先重运行失败的包 profile 或精确 Docker lane，而不是重运行完整发布验证。
 
-## 安装冒烟测试
+## 安装 smoke
 
-独立的 `Install Smoke` 工作流通过自己的 `preflight` 作业复用同一个范围脚本。它将冒烟覆盖拆分为 `run_fast_install_smoke` 和 `run_full_install_smoke`。
+独立的 `Install Smoke` 工作流会通过自己的 `preflight` 作业复用同一个范围脚本。它将 smoke 覆盖拆分为 `run_fast_install_smoke` 和 `run_full_install_smoke`。
 
-- **快速路径**会在拉取请求触及 Docker/包表面、内置插件包/manifest 变更，或 Docker 冒烟作业覆盖的核心插件/渠道/Gateway 网关/插件 SDK 表面时运行。仅源代码的内置插件变更、仅测试编辑和仅文档编辑不会预留 Docker worker。快速路径会构建一次根 Dockerfile 镜像，检查 CLI，运行 agents delete shared-workspace CLI 冒烟测试，运行容器 gateway-network e2e，验证内置扩展构建参数，并在 240 秒聚合命令超时内运行有界内置插件 Docker 配置（每个场景的 Docker 运行单独限时）。
-- **完整路径**为夜间计划运行、手动调度、workflow-call 发布检查，以及确实触及安装器/包/Docker 表面的拉取请求保留 QR 包安装和安装器 Docker/更新覆盖。在完整模式下，install-smoke 会准备或复用一个目标 SHA GHCR 根 Dockerfile 冒烟镜像，然后将 QR 包安装、根 Dockerfile/Gateway 网关冒烟测试、安装器/更新冒烟测试，以及快速内置插件 Docker E2E 作为独立作业运行，避免安装器工作被阻塞在根镜像冒烟测试之后。
+- **快速路径**会在拉取请求触及 Docker/包表面、内置插件包/manifest 变更，或 Docker smoke 作业会执行的核心插件/渠道/Gateway 网关/插件 SDK 表面时运行。仅源码的内置插件变更、仅测试编辑和仅文档编辑不会预留 Docker worker。快速路径会构建一次根 Dockerfile 镜像，检查 CLI，运行智能体删除共享工作区 CLI smoke，运行容器 `gateway-network` e2e，验证内置扩展构建参数，并在 240 秒聚合命令超时下运行有界的内置插件 Docker profile（每个场景的 Docker 运行单独设置上限）。
+- **完整路径**会为夜间定时运行、手动分发、workflow-call 发布检查，以及确实触及安装器/包/Docker 表面的拉取请求保留 QR 包安装和安装器 Docker/更新覆盖。在完整模式下，install-smoke 会准备或复用一个目标 SHA 的 GHCR 根 Dockerfile smoke 镜像，然后将 QR 包安装、根 Dockerfile/Gateway 网关 smoke、安装器/更新 smoke，以及快速内置插件 Docker E2E 作为独立作业运行，这样安装器工作不会排在根镜像 smoke 之后等待。
 
-`main` 推送（包括合并提交）不会强制完整路径；当变更范围逻辑会在推送上请求完整覆盖时，工作流会保留快速 Docker 冒烟测试，并将完整安装冒烟测试留给夜间或发布验证。
+`main` 推送（包括 merge commit）不会强制走完整路径；当变更范围逻辑会在推送上请求完整覆盖时，工作流会保留快速 Docker smoke，并把完整安装 smoke 留给夜间或发布验证。
 
-慢速 Bun 全局安装 image-provider 冒烟测试由 `run_bun_global_install_smoke` 单独控制。它会在夜间计划和发布检查工作流中运行，手动 `Install Smoke` 调度也可以选择启用它，但拉取请求和 `main` 推送不会运行。QR 和安装器 Docker 测试保留各自面向安装的 Dockerfile。
+较慢的 Bun 全局安装 image-provider smoke 由 `run_bun_global_install_smoke` 单独门控。它会在夜间计划和发布检查工作流中运行，手动 `Install Smoke` 分发可以选择启用它，但拉取请求和 `main` 推送不会运行。QR 和安装器 Docker 测试保留各自以安装为重点的 Dockerfile。
 
 ## 本地 Docker E2E
 
-`pnpm test:docker:all` 会预构建一个共享实时测试镜像，将 OpenClaw 打包一次为 npm tarball，并构建两个共享 `scripts/e2e/Dockerfile` 镜像：
+`pnpm test:docker:all` 会预构建一个共享 live-test 镜像，将 OpenClaw 打包一次为 npm tarball，并构建两个共享的 `scripts/e2e/Dockerfile` 镜像：
 
-- 用于安装器/更新/插件依赖车道的裸 Node/Git runner；
-- 一个功能镜像，将同一个 tarball 安装到 `/app`，用于普通功能车道。
+- 一个裸 Node/Git runner，用于安装器/更新/插件依赖 lane；
+- 一个功能镜像，将同一个 tarball 安装到 `/app`，用于常规功能 lane。
 
-Docker 车道定义位于 `scripts/lib/docker-e2e-scenarios.mjs`，规划器逻辑位于 `scripts/lib/docker-e2e-plan.mjs`，runner 只执行选定计划。调度器使用 `OPENCLAW_DOCKER_E2E_BARE_IMAGE` 和 `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE` 为每条车道选择镜像，然后用 `OPENCLAW_SKIP_DOCKER_BUILD=1` 运行车道。
+Docker lane 定义位于 `scripts/lib/docker-e2e-scenarios.mjs`，planner 逻辑位于 `scripts/lib/docker-e2e-plan.mjs`，runner 只执行所选 plan。调度器会通过 `OPENCLAW_DOCKER_E2E_BARE_IMAGE` 和 `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE` 为每个 lane 选择镜像，然后以 `OPENCLAW_SKIP_DOCKER_BUILD=1` 运行 lane。
 
 ### 可调参数
 
 | 变量                                   | 默认值  | 用途                                                                                          |
 | -------------------------------------- | ------- | --------------------------------------------------------------------------------------------- |
-| `OPENCLAW_DOCKER_ALL_PARALLELISM`      | 10      | 普通车道的主池槽位数。                                                                        |
-| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10      | 提供商敏感尾池槽位数。                                                                        |
-| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT`       | 9       | 并发实时车道上限，避免提供商限流。                                                            |
-| `OPENCLAW_DOCKER_ALL_NPM_LIMIT`        | 10      | 并发 npm 安装车道上限。                                                                       |
-| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT`    | 7       | 并发多服务车道上限。                                                                          |
-| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000    | 车道启动之间的错峰，避免 Docker daemon 创建风暴；设为 `0` 表示不交错。                        |
-| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`  | 7200000 | 每条车道的兜底超时（120 分钟）；选定实时/尾部车道使用更紧的上限。                            |
-| `OPENCLAW_DOCKER_ALL_DRY_RUN`          | 未设置  | `1` 会打印调度器计划而不运行车道。                                                            |
-| `OPENCLAW_DOCKER_ALL_LANES`            | 未设置  | 逗号分隔的精确车道列表；跳过清理冒烟测试，以便智能体复现单个失败车道。                       |
+| `OPENCLAW_DOCKER_ALL_PARALLELISM`      | 10      | 普通 lane 的主池 slot 数。                                                                    |
+| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10      | 对提供商敏感的 tail-pool slot 数。                                                           |
+| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT`       | 9       | 并发 live lane 上限，避免提供商限流。                                                         |
+| `OPENCLAW_DOCKER_ALL_NPM_LIMIT`        | 10      | 并发 npm install lane 上限。                                                                  |
+| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT`    | 7       | 并发多服务 lane 上限。                                                                        |
+| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000    | lane 启动之间的错峰时间，以避免 Docker daemon 创建风暴；设为 `0` 表示不做错峰。              |
+| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`  | 7200000 | 每个 lane 的兜底超时（120 分钟）；选定的 live/tail lane 使用更严格的上限。                   |
+| `OPENCLAW_DOCKER_ALL_DRY_RUN`          | unset   | `1` 会打印调度器 plan，而不运行 lane。                                                        |
+| `OPENCLAW_DOCKER_ALL_LANES`            | unset   | 逗号分隔的精确 lane 列表；跳过清理 smoke，以便智能体复现一个失败 lane。                      |
 
-比其有效上限更重的车道仍可从空池启动，然后独占运行，直到释放容量。本地聚合会预检 Docker，移除陈旧的 OpenClaw E2E 容器，输出活跃车道 Status，持久化车道计时以用于最长优先排序，并默认在首次失败后停止调度新的池化车道。
+重于其有效上限的 lane 仍可从空池启动，然后独占运行直到释放容量。本地聚合会预检查 Docker，移除陈旧的 OpenClaw E2E 容器，输出活跃 lane Status，持久化 lane 计时以进行最长优先排序，并且默认在首次失败后停止调度新的池化 lane。
 
-### 可复用实时/E2E 工作流
+### 可复用 live/E2E 工作流
 
-可复用实时/E2E 工作流会询问 `scripts/test-docker-all.mjs --plan-json` 需要哪个包、镜像类型、实时镜像、车道和凭证覆盖。`scripts/docker-e2e.mjs` 随后将该计划转换为 GitHub 输出和摘要。它会通过 `scripts/package-openclaw-for-docker.mjs` 打包 OpenClaw，下载当前运行的包构件，或从 `package_artifact_run_id` 下载包构件；验证 tarball 清单；在计划需要已安装包车道时，通过 Blacksmith 的 Docker 层缓存构建并推送带包摘要标签的裸/功能 GHCR Docker E2E 镜像；并复用提供的 `docker_e2e_bare_image`/`docker_e2e_functional_image` 输入或现有的包摘要镜像，而不是重新构建。Docker 镜像拉取会使用有界的 180 秒单次尝试超时进行重试，因此卡住的 registry/cache 流会快速重试，而不是消耗大部分 CI 关键路径。
+可复用的 live/E2E 工作流会询问 `scripts/test-docker-all.mjs --plan-json` 需要哪些包、镜像类型、live 镜像、lane 和凭据覆盖范围。随后 `scripts/docker-e2e.mjs` 会把该计划转换为 GitHub 输出和摘要。它会通过 `scripts/package-openclaw-for-docker.mjs` 打包 OpenClaw，下载当前运行的包构件，或从 `package_artifact_run_id` 下载包构件；验证 tarball 清单；在计划需要包安装 lane 时，通过 Blacksmith 的 Docker 层缓存构建并推送带有包摘要标签的 bare/functional GHCR Docker E2E 镜像；并复用提供的 `docker_e2e_bare_image`/`docker_e2e_functional_image` 输入或已有的包摘要镜像，而不是重新构建。Docker 镜像拉取会按每次尝试 180 秒的有界超时重试，因此卡住的 registry/cache 流会快速重试，而不是消耗 CI 关键路径的大部分时间。
 
 ### 发布路径分块
 
-发布 Docker 覆盖会使用较小的分块作业并设置 `OPENCLAW_SKIP_DOCKER_BUILD=1`，这样每个分块只拉取所需的镜像类型，并通过同一个加权调度器执行多条车道：
+发布 Docker 覆盖范围会运行更小的分块作业，并设置 `OPENCLAW_SKIP_DOCKER_BUILD=1`，因此每个分块只拉取它需要的镜像类型，并通过同一个加权调度器执行多个 lane：
 
 - `OPENCLAW_DOCKER_ALL_PROFILE=release-path`
 - `OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h | bundled-channels`
 
-当前发布版 Docker 分块为 `core`、`package-update-openai`、`package-update-anthropic`、`package-update-core`、`plugins-runtime-plugins`、`plugins-runtime-services`、`plugins-runtime-install-a` 到 `plugins-runtime-install-h`、`bundled-channels-core`、`bundled-channels-update-a`、`bundled-channels-update-discord`、`bundled-channels-update-b` 和 `bundled-channels-contracts`。聚合的 `bundled-channels` 分块仍可用于手动一次性重跑，`plugins-runtime-core`、`plugins-runtime` 和 `plugins-integrations` 仍是聚合的插件/运行时别名。`install-e2e` 通道别名仍是两个提供商安装器通道的聚合手动重跑别名。`bundled-channels` 分块运行拆分后的 `bundled-channel-*` 和 `bundled-channel-update-*` 通道，而不是串行的一体化 `bundled-channel-deps` 通道。
+当前发布 Docker 分块包括 `core`、`package-update-openai`、`package-update-anthropic`、`package-update-core`、`plugins-runtime-plugins`、`plugins-runtime-services`、从 `plugins-runtime-install-a` 到 `plugins-runtime-install-h`、`bundled-channels-core`、`bundled-channels-update-a`、`bundled-channels-update-discord`、`bundled-channels-update-b` 和 `bundled-channels-contracts`。聚合的 `bundled-channels` 分块仍可用于手动一次性重新运行，`plugins-runtime-core`、`plugins-runtime` 和 `plugins-integrations` 也仍作为聚合的插件/运行时别名。`install-e2e` lane 别名仍是两个提供商安装器 lane 的聚合手动重新运行别名。`bundled-channels` 分块运行拆分后的 `bundled-channel-*` 和 `bundled-channel-update-*` lane，而不是串行的全合一 `bundled-channel-deps` lane。
 
-当完整发布路径覆盖请求需要时，OpenWebUI 会并入 `plugins-runtime-services`，并且只有在仅 OpenWebUI 的调度中才保留独立的 `openwebui` 分块。内置渠道更新通道会针对临时 npm 网络故障重试一次。
+当完整发布路径覆盖范围请求 OpenWebUI 时，OpenWebUI 会并入 `plugins-runtime-services`，并且只为仅 OpenWebUI 的调度保留独立的 `openwebui` 分块。内置渠道更新 lane 会针对临时 npm 网络失败重试一次。
 
-每个分块都会上传 `.artifacts/docker-tests/`，其中包含通道日志、耗时、`summary.json`、`failures.json`、阶段耗时、调度器计划 JSON、慢通道表，以及逐通道重跑命令。工作流 `docker_lanes` 输入会针对已准备好的镜像运行所选通道，而不是运行分块作业，这让失败通道调试被限制在一个有针对性的 Docker 作业内，并为该运行准备、下载或复用包工件；如果所选通道是实时 Docker 通道，则目标作业会在本地构建实时测试镜像以用于该次重跑。生成的逐通道 GitHub 重跑命令会在这些值存在时包含 `package_artifact_run_id`、`package_artifact_name` 和已准备镜像输入，因此失败通道可以复用失败运行中的确切包和镜像。
+每个分块都会上传 `.artifacts/docker-tests/`，其中包含 lane 日志、计时、`summary.json`、`failures.json`、阶段计时、调度器计划 JSON、慢 lane 表以及每个 lane 的重新运行命令。工作流 `docker_lanes` 输入会针对准备好的镜像运行所选 lane，而不是运行分块作业，这会把失败 lane 调试限定在一个有针对性的 Docker 作业内，并为该次运行准备、下载或复用包构件；如果所选 lane 是 live Docker lane，则有针对性的作业会为该次重新运行在本地构建 live-test 镜像。生成的每个 lane GitHub 重新运行命令会在这些值存在时包含 `package_artifact_run_id`、`package_artifact_name` 和准备好的镜像输入，因此失败的 lane 可以复用失败运行中的确切包和镜像。
 
 ```bash
 pnpm test:docker:rerun <run-id>      # download Docker artifacts and print combined/per-lane targeted rerun commands
 pnpm test:docker:timings <summary>   # slow-lane and phase critical-path summaries
 ```
 
-定时的实时/E2E 工作流每天运行完整发布路径 Docker 套件。
+定时 live/E2E 工作流每天运行完整的发布路径 Docker 套件。
 
 ## 插件预发布
 
-`Plugin Prerelease` 是成本更高的产品/包覆盖，因此它是一个由 `Full Release Validation` 或显式操作员调度的独立工作流。普通拉取请求、`main` 推送以及独立的手动 CI 调度会保持该套件关闭。它会在八个扩展工作器之间均衡内置插件测试；这些扩展分片作业一次最多运行两个插件配置组，每个组使用一个 Vitest 工作器和更大的 Node 堆，因此导入密集型插件批次不会创建额外的 CI 作业。
+`Plugin Prerelease` 是成本更高的产品/包覆盖范围，因此它是一个独立工作流，由 `Full Release Validation` 或显式操作员调度。普通拉取请求、`main` 推送和独立手动 CI 调度不会开启该套件。它会在八个插件工作器之间均衡内置插件测试；这些插件分片作业一次最多运行两个插件配置组，每组一个 Vitest 工作器，并使用更大的 Node 堆，因此导入负载较重的插件批次不会创建额外的 CI 作业。仅发布 Docker 预发布路径会把有针对性的 Docker lane 分成小组批处理，以避免为一到三分钟的作业保留数十个运行器。
 
-## QA Lab
+## QA 实验室
 
-QA Lab 在主智能作用域工作流之外有专用 CI 通道。
+QA 实验室在主智能范围化工作流之外有专用 CI lane。
 
-- `Parity gate` 工作流会在匹配的 PR 变更和手动调度时运行；它会构建私有 QA 运行时，并比较模拟的 GPT-5.5 和 Opus 4.6 智能体包。
-- `QA-Lab - All Lanes` 工作流每晚在 `main` 上运行，也可手动调度；它会将模拟一致性门、实时 Matrix 通道，以及实时 Telegram 和 Discord 通道作为并行作业展开。实时作业使用 `qa-live-shared` 环境，Telegram/Discord 使用 Convex 租约。
+- `Parity gate` 工作流会在匹配的 PR 更改和手动调度时运行；它构建私有 QA 运行时，并比较 mock GPT-5.5 和 Opus 4.6 agentic 包。
+- `QA-Lab - All Lanes` 工作流会在 `main` 上每晚运行，也会在手动调度时运行；它会把 mock parity gate、live Matrix lane，以及 live Telegram 和 Discord lane 作为并行作业展开。Live 作业使用 `qa-live-shared` 环境，Telegram/Discord 使用 Convex 租约。
 
-发布检查使用确定性的模拟提供商和模拟限定模型（`mock-openai/gpt-5.5` 和 `mock-openai/gpt-5.5-alt`）运行 Matrix 和 Telegram 实时传输通道，因此渠道契约会与实时模型延迟和常规提供商插件启动隔离。实时传输 Gateway 网关会禁用记忆搜索，因为 QA 一致性会单独覆盖记忆行为；提供商连通性由单独的实时模型、原生提供商和 Docker 提供商套件覆盖。
+发布检查会使用确定性的 mock 提供商和 mock 限定模型（`mock-openai/gpt-5.5` 和 `mock-openai/gpt-5.5-alt`）运行 Matrix 和 Telegram live 传输 lane，因此渠道契约会与 live 模型延迟和普通提供商插件启动隔离开。Live 传输 Gateway 网关会禁用记忆搜索，因为 QA parity 会单独覆盖记忆行为；提供商连接性由单独的 live 模型、原生提供商和 Docker 提供商套件覆盖。
 
-Matrix 在定时和发布门中使用 `--profile fast`，只有在检出的 CLI 支持时才额外添加 `--fail-fast`。CLI 默认值和手动工作流输入仍为 `all`；手动 `matrix_profile=all` 调度始终会将完整 Matrix 覆盖分片为 `transport`、`media`、`e2ee-smoke`、`e2ee-deep` 和 `e2ee-cli` 作业。
+Matrix 在定时和发布门禁中使用 `--profile fast`，并且只在检出的 CLI 支持时添加 `--fail-fast`。CLI 默认值和手动工作流输入仍为 `all`；手动 `matrix_profile=all` 调度始终会把完整 Matrix 覆盖范围分片为 `transport`、`media`、`e2ee-smoke`、`e2ee-deep` 和 `e2ee-cli` 作业。
 
-`OpenClaw Release Checks` 还会在发布批准前运行发布关键的 QA Lab 通道；其 QA 一致性门会将候选包和基线包作为并行通道作业运行，然后将两个工件下载到一个小型报告作业中，用于最终一致性比较。
+`OpenClaw Release Checks` 也会在发布批准前运行发布关键的 QA 实验室 lane；它的 QA parity gate 会把候选包和基线包作为并行 lane 作业运行，然后把两个构件下载到一个小型报告作业中进行最终 parity 比较。
 
-不要把 PR 落地路径放到 `Parity gate` 后面，除非变更确实触及 QA 运行时、模型包一致性，或一致性工作流拥有的表面。对于常规渠道、配置、文档或单元测试修复，应将其视为可选信号，并遵循作用域化 CI/检查证据。
+不要把 PR 落地路径置于 `Parity gate` 之后，除非更改确实触及 QA 运行时、模型包 parity，或 parity 工作流拥有的表面。对于普通渠道、配置、文档或单元测试修复，请将其视为可选信号，并遵循范围化 CI/检查证据。
 
 ## CodeQL
 
-`CodeQL` 工作流有意作为窄范围的第一遍安全扫描器，而不是完整仓库扫描。每日、手动和非草稿拉取请求守护运行会扫描 Actions 工作流代码以及风险最高的 JavaScript/TypeScript 表面，并使用高置信度安全查询，筛选高/严重 `security-severity`。
+`CodeQL` 工作流有意作为狭窄的第一轮安全扫描器，而不是完整仓库扫描。每日、手动和非草稿拉取请求守护运行会扫描 Actions 工作流代码，以及风险最高的 JavaScript/TypeScript 表面，并使用筛选到高/严重 `security-severity` 的高置信度安全查询。
 
-拉取请求守护保持轻量：它只会针对 `.github/actions`、`.github/codeql`、`.github/workflows`、`packages` 或 `src` 下的变更启动，并运行与定时工作流相同的高置信度安全矩阵。Android 和 macOS CodeQL 不包含在 PR 默认项中。
+拉取请求守护保持轻量：它只会在 `.github/actions`、`.github/codeql`、`.github/workflows`、`packages` 或 `src` 下发生更改时启动，并运行与定时工作流相同的高置信度安全矩阵。Android 和 macOS CodeQL 不属于 PR 默认项。
 
 ### 安全类别
 
 | 类别                                              | 表面                                                                                                                                   |
 | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
-| `/codeql-security-high/core-auth-secrets`         | 认证、密钥、沙箱、cron 和 Gateway 网关基线                                                                                             |
+| `/codeql-security-high/core-auth-secrets`         | 认证、密钥、沙箱、cron 和 gateway 基线                                                                                                 |
 | `/codeql-security-high/channel-runtime-boundary`  | 核心渠道实现契约，以及渠道插件运行时、Gateway 网关、插件 SDK、密钥、审计触点                                                           |
-| `/codeql-security-high/network-ssrf-boundary`     | 核心 SSRF、IP 解析、网络守卫、web-fetch 和插件 SDK SSRF 策略表面                                                                       |
-| `/codeql-security-high/mcp-process-tool-boundary` | MCP 服务器、进程执行帮助器、出站投递和智能体工具执行门                                                                                 |
-| `/codeql-security-high/plugin-trust-boundary`     | 插件安装、加载器、清单、注册表、运行时依赖暂存、源码加载和插件 SDK 包契约信任表面                                                      |
+| `/codeql-security-high/network-ssrf-boundary`     | 核心 SSRF、IP 解析、网络防护、web-fetch 和插件 SDK SSRF 策略表面                                                                       |
+| `/codeql-security-high/mcp-process-tool-boundary` | MCP 服务器、进程执行辅助工具、出站投递和智能体工具执行门禁                                                                             |
+| `/codeql-security-high/plugin-trust-boundary`     | 插件安装、加载器、清单、registry、运行时依赖暂存、源码加载和插件 SDK 包契约信任表面                                                    |
 
 ### 平台特定安全分片
 
-- `CodeQL Android Critical Security` — 定时 Android 安全分片。在工作流完整性检查接受的最小 Blacksmith Linux 运行器上手动构建 Android 应用以供 CodeQL 使用。上传到 `/codeql-critical-security/android` 下。
-- `CodeQL macOS Critical Security` — 每周/手动 macOS 安全分片。在 Blacksmith macOS 上手动构建 macOS 应用以供 CodeQL 使用，从上传的 SARIF 中过滤掉依赖构建结果，并上传到 `/codeql-critical-security/macos` 下。它保持在每日默认项之外，因为即使在干净状态下，macOS 构建也会主导运行时间。
+- `CodeQL Android Critical Security` — 定时 Android 安全分片。在 workflow sanity 接受的最小 Blacksmith Linux 运行器上为 CodeQL 手动构建 Android 应用。上传到 `/codeql-critical-security/android` 下。
+- `CodeQL macOS Critical Security` — 每周/手动 macOS 安全分片。在 Blacksmith macOS 上为 CodeQL 手动构建 macOS 应用，从上传的 SARIF 中过滤掉依赖构建结果，并上传到 `/codeql-critical-security/macos` 下。它保留在每日默认项之外，因为即使在干净状态下，macOS 构建也会主导运行时间。
 
-### Critical Quality 类别
+### 关键质量类别
 
-`CodeQL Critical Quality` 是对应的非安全分片。它只在较小的 Blacksmith Linux 运行器上，对窄范围高价值表面运行错误严重性、非安全 JavaScript/TypeScript 质量查询。它的拉取请求守护有意小于定时配置：非草稿 PR 只会针对智能体命令/模型/工具执行与回复调度代码、配置架构/迁移/IO 代码、认证/密钥/沙箱/安全代码、核心渠道与内置渠道插件运行时、Gateway 网关协议/服务器方法、记忆运行时/SDK 粘合层、MCP/进程/出站投递、提供商运行时/模型目录、会话诊断/投递队列、插件加载器、插件 SDK/包契约，或插件 SDK 回复运行时变更，运行匹配的 `agent-runtime-boundary`、`config-boundary`、`core-auth-secrets`、`channel-runtime-boundary`、`gateway-runtime-boundary`、`memory-runtime-boundary`、`mcp-process-runtime-boundary`、`provider-runtime-boundary`、`session-diagnostics-boundary`、`plugin-boundary`、`plugin-sdk-package-contract` 和 `plugin-sdk-reply-runtime` 分片。CodeQL 配置和质量工作流变更会运行全部十二个 PR 质量分片。
+`CodeQL Critical Quality` 是对应的非安全分片。它只在较小的 Blacksmith Linux 运行器上，对狭窄的高价值表面运行错误严重级别、非安全 JavaScript/TypeScript 质量查询。它的拉取请求守护有意小于定时配置：非草稿 PR 只会为智能体命令/模型/工具执行和回复调度代码、配置 schema/迁移/IO 代码、认证/密钥/沙箱/安全代码、核心渠道和内置渠道插件运行时、gateway 协议/服务器方法、记忆运行时/SDK 胶水、MCP/进程/出站投递、提供商运行时/模型目录、会话诊断/投递队列、插件加载器、插件 SDK/包契约，或插件 SDK 回复运行时更改运行匹配的 `agent-runtime-boundary`、`config-boundary`、`core-auth-secrets`、`channel-runtime-boundary`、`gateway-runtime-boundary`、`memory-runtime-boundary`、`mcp-process-runtime-boundary`、`provider-runtime-boundary`、`session-diagnostics-boundary`、`plugin-boundary`、`plugin-sdk-package-contract` 和 `plugin-sdk-reply-runtime` 分片。CodeQL 配置和质量工作流更改会运行全部十二个 PR 质量分片。
 
 手动调度接受：
 
@@ -350,40 +354,40 @@ Matrix 在定时和发布门中使用 `--profile fast`，只有在检出的 CLI
 profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary
 ```
 
-窄配置是用于单独运行一个质量分片的教学/迭代钩子。
+狭窄配置是用于单独运行一个质量分片的教学/迭代钩子。
 
-| 类别                                                    | 表面                                                                                                                                                           |
-| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `/codeql-critical-quality/core-auth-secrets`            | 凭证、密钥、沙箱、cron 和 Gateway 网关安全边界代码                                                                                                  |
-| `/codeql-critical-quality/config-boundary`              | 配置 schema、迁移、规范化和 IO 契约                                                                                                         |
-| `/codeql-critical-quality/gateway-runtime-boundary`     | Gateway 网关协议 schema 和服务器方法契约                                                                                                              |
-| `/codeql-critical-quality/channel-runtime-boundary`     | 核心渠道和内置渠道插件实现契约                                                                                                  |
-| `/codeql-critical-quality/agent-runtime-boundary`       | 命令执行、模型/提供商分发、自动回复分发与队列，以及 ACP 控制平面运行时契约                                               |
-| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP 服务器和工具桥接、进程监管辅助工具，以及出站投递契约                                                                        |
-| `/codeql-critical-quality/memory-runtime-boundary`      | Memory 主机 SDK、memory 运行时门面、memory 插件 SDK 别名、memory 运行时激活粘合层，以及 memory doctor 命令                                    |
-| `/codeql-critical-quality/session-diagnostics-boundary` | 回复队列内部机制、会话投递队列、出站会话绑定/投递辅助工具、诊断事件/日志包表面，以及会话 doctor CLI 契约 |
-| `/codeql-critical-quality/plugin-sdk-reply-runtime`     | 插件 SDK 入站回复分发、回复载荷/分块/运行时辅助工具、渠道回复选项、投递队列，以及会话/线程绑定辅助工具             |
-| `/codeql-critical-quality/provider-runtime-boundary`    | 模型目录规范化、提供商凭证和设备发现、提供商运行时注册、提供商默认值/目录，以及 web/search/fetch/embedding 注册表    |
-| `/codeql-critical-quality/ui-control-plane`             | 控制 UI 启动、本地持久化、Gateway 网关控制流，以及任务控制平面运行时契约                                                          |
-| `/codeql-critical-quality/web-media-runtime-boundary`   | 核心 Web 抓取/搜索、媒体 IO、媒体理解、图像生成，以及媒体生成运行时契约                                                    |
-| `/codeql-critical-quality/plugin-boundary`              | 加载器、注册表、公共表面，以及插件 SDK 入口点契约                                                                                             |
-| `/codeql-critical-quality/plugin-sdk-package-contract`  | 已发布包侧插件 SDK 源码和插件包契约辅助工具                                                                                      |
+| 类别                                                    | 表面                                                                                                                                                               |
+| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `/codeql-critical-quality/core-auth-secrets`            | 凭证、密钥、沙箱、cron 和 Gateway 网关安全边界代码                                                                                                                |
+| `/codeql-critical-quality/config-boundary`              | 配置架构、迁移、规范化和 IO 契约                                                                                                                                   |
+| `/codeql-critical-quality/gateway-runtime-boundary`     | Gateway 网关协议架构和服务器方法契约                                                                                                                              |
+| `/codeql-critical-quality/channel-runtime-boundary`     | 核心渠道和内置渠道插件实现契约                                                                                                                                     |
+| `/codeql-critical-quality/agent-runtime-boundary`       | 命令执行、模型/提供商分发、自动回复分发和队列，以及 ACP 控制平面运行时契约                                                                                        |
+| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP 服务器和工具桥接、进程监督辅助工具，以及出站投递契约                                                                                                          |
+| `/codeql-critical-quality/memory-runtime-boundary`      | 记忆宿主 SDK、记忆运行时门面、记忆插件 SDK 别名、记忆运行时激活粘合代码，以及记忆 Doctor 命令                                                                     |
+| `/codeql-critical-quality/session-diagnostics-boundary` | 回复队列内部机制、会话投递队列、出站会话绑定/投递辅助工具、诊断事件/日志包表面，以及会话 Doctor CLI 契约                                                        |
+| `/codeql-critical-quality/plugin-sdk-reply-runtime`     | 插件 SDK 入站回复分发、回复载荷/分块/运行时辅助工具、渠道回复选项、投递队列，以及会话/线程绑定辅助工具                                                          |
+| `/codeql-critical-quality/provider-runtime-boundary`    | 模型目录规范化、提供商凭证和设备发现、提供商运行时注册、提供商默认值/目录，以及 Web/搜索/抓取/嵌入注册表                                                        |
+| `/codeql-critical-quality/ui-control-plane`             | 控制 UI 引导、本地持久化、Gateway 网关控制流，以及任务控制平面运行时契约                                                                                          |
+| `/codeql-critical-quality/web-media-runtime-boundary`   | 核心 Web 抓取/搜索、媒体 IO、媒体理解、图像生成和媒体生成运行时契约                                                                                               |
+| `/codeql-critical-quality/plugin-boundary`              | 加载器、注册表、公共表面和插件 SDK 入口点契约                                                                                                                     |
+| `/codeql-critical-quality/plugin-sdk-package-contract`  | 已发布包侧插件 SDK 源码和插件包契约辅助工具                                                                                                                       |
 
-质量与安全保持分离，这样质量发现就可以被排期、度量、禁用或扩展，而不会掩盖安全信号。只有在窄配置文件具备稳定运行时和稳定信号之后，才应将 Swift、Python 和内置插件 CodeQL 扩展作为有作用域或分片的后续工作加回。
+质量与安全保持分离，这样质量发现项可以被调度、度量、禁用或扩展，而不会模糊安全信号。Swift、Python 和内置插件 CodeQL 扩展只应在窄配置文件具备稳定运行时和信号后，作为有范围或分片的后续工作加回。
 
 ## 维护工作流
 
 ### 文档智能体
 
-`Docs Agent` 工作流是一个事件驱动的 Codex 维护通道，用于让现有文档与最近落地的变更保持一致。它没有纯定时计划：`main` 上一次成功的非 bot push CI 运行可以触发它，手动分发也可以直接运行它。当 `main` 已经前移，或者过去一小时内已经创建过另一个未跳过的 Docs Agent 运行时，workflow-run 调用会跳过。运行时，它会审查从上一个未跳过的 Docs Agent 源 SHA 到当前 `main` 的提交范围，因此一次每小时运行可以覆盖自上次文档处理以来累积的所有 main 变更。
+`Docs Agent` 工作流是一个事件驱动的 Codex 维护通道，用于让现有文档与最近落地的更改保持一致。它没有纯定时计划：`main` 上成功的非机器人 push CI 运行可以触发它，手动分发也可以直接运行它。当 `main` 已经继续推进，或过去一小时内已经创建了另一个未跳过的 Docs Agent 运行时，工作流运行调用会跳过。运行时，它会审查从上一个未跳过的 Docs Agent 源 SHA 到当前 `main` 的提交范围，因此一次每小时运行可以覆盖自上次文档处理以来积累的所有 main 更改。
 
 ### 测试性能智能体
 
-`Test Performance Agent` 工作流是一个事件驱动的 Codex 维护通道，用于处理慢测试。它没有纯定时计划：`main` 上一次成功的非 bot push CI 运行可以触发它，但如果当天 UTC 已经有另一个 workflow-run 调用运行过或正在运行，它会跳过。手动分发会绕过这个每日活动门禁。该通道会构建完整套件分组 Vitest 性能报告，让 Codex 只做保留覆盖率的小型测试性能修复，而不是大范围重构，然后重新运行完整套件报告，并拒绝会降低通过基线测试数量的变更。如果基线存在失败测试，Codex 只能修复明显失败，并且 agent 后的完整套件报告必须通过，之后才会提交任何内容。当 `main` 在 bot push 落地前前移时，该通道会 rebase 已验证的补丁，重新运行 `pnpm check:changed`，并重试 push；存在冲突的过期补丁会被跳过。它使用 GitHub 托管的 Ubuntu，因此 Codex action 可以保持与 docs agent 相同的 drop-sudo 安全姿态。
+`Test Performance Agent` 工作流是一个事件驱动的 Codex 维护通道，用于处理慢速测试。它没有纯定时计划：`main` 上成功的非机器人 push CI 运行可以触发它，但如果当天 UTC 已经有另一个工作流运行调用已运行或正在运行，它会跳过。手动分发会绕过该每日活动门禁。该通道会构建全套分组 Vitest 性能报告，让 Codex 只做小型且保持覆盖率的测试性能修复，而不是大范围重构，然后重新运行全套报告，并拒绝会减少通过基线测试数量的更改。如果基线存在失败测试，Codex 只能修复显而易见的失败，并且智能体后的全套报告必须通过后才会提交任何内容。当机器人 push 落地前 `main` 前进时，该通道会 rebase 已验证的补丁，重新运行 `pnpm check:changed`，并重试 push；冲突的过期补丁会被跳过。它使用 GitHub 托管的 Ubuntu，因此 Codex action 可以保持与文档智能体相同的 drop-sudo 安全姿态。
 
 ### 合并后的重复 PR
 
-`Duplicate PRs After Merge` 工作流是一个手动维护者工作流，用于落地后的重复项清理。它默认 dry-run，并且只有在 `apply=true` 时才会关闭明确列出的 PR。在变更 GitHub 之前，它会验证已落地 PR 已合并，并且每个重复项都有共享的引用 issue 或重叠的变更 hunk。
+`Duplicate PRs After Merge` 工作流是用于落地后重复项清理的手动维护者工作流。它默认 dry-run，并且只有在 `apply=true` 时才会关闭明确列出的 PR。在变更 GitHub 之前，它会验证已落地 PR 已合并，并且每个重复项要么有共享的引用 issue，要么有重叠的变更 hunk。
 
 ```bash
 gh workflow run duplicate-after-merge.yml \
@@ -394,25 +398,25 @@ gh workflow run duplicate-after-merge.yml \
 
 ## 本地检查门禁和变更路由
 
-本地变更通道逻辑位于 `scripts/changed-lanes.mjs`，并由 `scripts/check-changed.mjs` 执行。这个本地检查门禁在架构边界方面比宽泛的 CI 平台范围更严格：
+本地变更通道逻辑位于 `scripts/changed-lanes.mjs`，并由 `scripts/check-changed.mjs` 执行。该本地检查门禁对架构边界的要求比宽泛的 CI 平台范围更严格：
 
-- 核心生产变更会运行核心生产和核心测试 typecheck，以及核心 lint/guard；
-- 仅核心测试变更只运行核心测试 typecheck 和核心 lint；
-- 插件生产变更会运行插件生产和插件测试 typecheck，以及插件 lint；
-- 仅插件测试变更会运行插件测试 typecheck 和插件 lint；
-- 公共插件 SDK 或插件契约变更会扩展到插件 typecheck，因为插件依赖这些核心契约（Vitest 插件扫描仍然是显式测试工作）；
-- 仅发布元数据的版本号提升会运行定向版本/配置/根依赖检查；
-- 未知根目录/配置变更会故障安全地进入所有检查通道。
+- 核心生产更改运行核心生产和核心测试类型检查，以及核心 lint/guard；
+- 仅核心测试更改只运行核心测试类型检查以及核心 lint；
+- 插件生产更改运行插件生产和插件测试类型检查，以及插件 lint；
+- 仅插件测试更改运行插件测试类型检查以及插件 lint；
+- 公共插件 SDK 或插件契约更改会扩展到插件类型检查，因为插件依赖这些核心契约（Vitest 插件扫测仍然是显式测试工作）；
+- 仅发布元数据的版本 bump 运行有针对性的版本/配置/根依赖检查；
+- 未知的根/配置更改会故障安全地进入所有检查通道。
 
-本地变更测试路由位于 `scripts/test-projects.test-support.mjs`，并且有意比 `check:changed` 更便宜：直接测试编辑会运行自身，源码编辑优先使用显式映射，然后是同级测试和导入图依赖项。共享群组聊天室投递配置是显式映射之一：对群组可见回复配置、源回复投递模式或消息工具系统提示词的变更，会通过核心回复测试以及 Discord 和 Slack 投递回归测试路由，这样共享默认值变更会在第一次 PR push 前失败。只有当变更足够 harness-wide，以至于廉价映射集合不是可信代理时，才使用 `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`。
+本地变更测试路由位于 `scripts/test-projects.test-support.mjs`，并且有意比 `check:changed` 更便宜：直接测试编辑会运行自身，源码编辑优先使用显式映射，然后是同级测试和导入图依赖项。共享群组房间投递配置是显式映射之一：对群组可见回复配置、源回复投递模式或消息工具系统提示的更改，会通过核心回复测试以及 Discord 和 Slack 投递回归，因此共享默认值更改会在第一个 PR push 前失败。只有当更改涉及足够广的 harness 范围，导致廉价映射集不再是可信代理时，才使用 `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`。
 
 ## Testbox 验证
 
-从仓库根目录运行 Testbox，并且对宽泛证明优先使用新预热的 box。在复用、过期或刚刚报告异常大同步的 box 上花费慢门禁之前，先在 box 内运行 `pnpm testbox:sanity`。
+从仓库根目录运行 Testbox，并优先为宽泛证明使用新预热的 box。在把慢速门禁花到一个复用、过期或刚报告异常大同步的 box 上之前，先在该 box 内运行 `pnpm testbox:sanity`。
 
-当所需根文件（例如 `pnpm-lock.yaml`）消失，或者 `git status --short` 显示至少 200 个已跟踪删除时，完整性检查会快速失败。这通常意味着远程同步状态不是 PR 的可信副本；停止该 box 并预热一个新的，而不是调试产品测试失败。对于有意的大规模删除 PR，请为该完整性运行设置 `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1`。
+当所需根文件（例如 `pnpm-lock.yaml`）消失，或 `git status --short` 显示至少 200 个已跟踪删除时，完整性检查会快速失败。这通常意味着远程同步状态不是 PR 的可信副本；停止该 box 并预热一个新的，而不是调试产品测试失败。对于有意的大规模删除 PR，请为该次完整性检查设置 `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1`。
 
-`pnpm testbox:run` 也会终止在同步阶段停留超过五分钟且没有同步后输出的本地 Blacksmith CLI 调用。设置 `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0` 可禁用该保护，或者为异常大的本地 diff 使用更大的毫秒值。
+`pnpm testbox:run` 还会终止本地 Blacksmith CLI 调用，如果它在同步阶段停留超过五分钟且没有同步后输出。设置 `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0` 可禁用该 guard，或者为异常大的本地 diff 使用更大的毫秒值。
 
 ## 相关
 

docs/zh-CN/reference/RELEASING.md

@@ -1,153 +1,146 @@
 ---
 read_when:
     - 正在查找公开发布渠道定义
-    - 运行发布验证或包验收
+    - 运行发布验证或软件包验收
     - 查找版本命名和发布节奏
-summary: 发布通道、操作员检查清单、验证盒、版本命名和发布节奏
+summary: 发布通道、操作员检查清单、验证框、版本命名和节奏
 title: 发布策略
 x-i18n:
-    generated_at: "2026-04-30T21:58:00Z"
+    generated_at: "2026-05-01T02:24:12Z"
     model: gpt-5.5
     provider: openai
-    source_hash: 2270223edb41f3c3731ad44fd6f8c8876e9908933bb61eddd350e344e0160121
+    source_hash: bb56568bf860ba9eae47df71c5c1ebefe9eb9ae05ac4706dbb425772ff6cdcaa
     source_path: reference/RELEASING.md
     workflow: 16
 ---
 
 OpenClaw 有三个公开发布通道：
 
-- stable：带标签的发布版本，默认发布到 npm `beta`，或在明确请求时发布到 npm `latest`
+- stable：带标签的版本，默认发布到 npm `beta`，或在明确请求时发布到 npm `latest`
 - beta：预发布标签，发布到 npm `beta`
-- dev：`main` 的移动最新头部
+- dev：`main` 的移动头部
 
 ## 版本命名
 
-- stable 发布版本：`YYYY.M.D`
+- 稳定版版本：`YYYY.M.D`
   - Git 标签：`vYYYY.M.D`
-- stable 修正发布版本：`YYYY.M.D-N`
+- 稳定修正版版本：`YYYY.M.D-N`
   - Git 标签：`vYYYY.M.D-N`
-- beta 预发布版本：`YYYY.M.D-beta.N`
+- Beta 预发布版本：`YYYY.M.D-beta.N`
   - Git 标签：`vYYYY.M.D-beta.N`
-- 不要对月份或日期补零
-- `latest` 表示当前已提升的 stable npm 发布版本
+- 不要给月份或日期补零
+- `latest` 表示当前已推广的稳定版 npm 发布
 - `beta` 表示当前 beta 安装目标
-- stable 和 stable 修正发布版本默认发布到 npm `beta`；发布操作员可以明确指定 `latest`，或稍后提升已验证的 beta 构建
-- 每个 stable OpenClaw 发布版本都会同时交付 npm 包和 macOS 应用；
-  beta 发布版本通常先验证并发布 npm/package 路径，除非明确请求，否则
-  mac 应用的构建/签名/公证会保留给 stable
+- 稳定版和稳定修正版默认发布到 npm `beta`；发布操作员可以明确指定 `latest`，或稍后推广已审定的 beta 构建
+- 每个稳定版 OpenClaw 发布都会同时交付 npm 包和 macOS 应用；
+  beta 发布通常先验证并发布 npm/package 路径，除非明确请求，否则
+  mac 应用构建/签名/公证仅保留给稳定版
 
 ## 发布节奏
 
-- 发布按 beta 优先推进
-- stable 仅在最新 beta 通过验证后跟进
-- 维护者通常从基于当前 `main` 创建的 `release/YYYY.M.D` 分支切出发布，
-  因此发布验证和修复不会阻塞 `main` 上的新开发
-- 如果 beta 标签已推送或发布并且需要修复，维护者会切出下一个
+- 发布先经过 beta
+- 只有在最新 beta 验证通过后才进入稳定版
+- 维护者通常从当前 `main` 创建的 `release/YYYY.M.D` 分支切出发布，
+  这样发布验证和修复不会阻塞 `main` 上的新开发
+- 如果 beta 标签已经推送或发布并且需要修复，维护者会切出下一个
   `-beta.N` 标签，而不是删除或重新创建旧 beta 标签
-- 详细发布流程、批准、凭证和恢复说明仅限维护者使用
+- 详细发布流程、审批、凭证和恢复说明仅限维护者使用
 
 ## 发布操作员检查清单
 
-此检查清单是发布流程的公开形态。私有凭证、
+此检查清单描述发布流程的公开形态。私有凭证、
 签名、公证、dist-tag 恢复和紧急回滚细节保留在
 仅限维护者使用的发布运行手册中。
 
-1. 从当前 `main` 开始：拉取最新内容，确认目标提交已推送，
-   并确认当前 `main` CI 足够稳定，可以从它创建分支。
-2. 使用 `/changelog` 基于真实提交历史重写顶部 `CHANGELOG.md` 小节，
-   保持条目面向用户，提交它，推送它，并在创建分支前再次 rebase/pull。
+1. 从当前 `main` 开始：拉取最新代码，确认目标提交已推送，
+   并确认当前 `main` CI 足够绿色，可以从它创建分支。
+2. 使用 `/changelog` 根据真实提交历史重写顶部 `CHANGELOG.md` 章节，
+   保持条目面向用户，提交它、推送它，并在创建分支前再次 rebase/pull。
 3. 查看
    `src/plugins/compat/registry.ts` 和
-   `src/commands/doctor/shared/deprecation-compat.ts` 中的发布兼容性记录。仅在升级路径仍被覆盖时移除过期兼容性，
-   或记录为什么有意继续保留它。
-4. 从当前 `main` 创建 `release/YYYY.M.D`；不要直接在 `main` 上执行常规发布工作。
-5. 为预期标签提升每个必需版本位置，然后运行
-   本地确定性预检：
+   `src/commands/doctor/shared/deprecation-compat.ts` 中的发布兼容性记录。只有在升级路径仍被覆盖时才移除过期兼容性，
+   或记录为什么有意继续保留。
+4. 从当前 `main` 创建 `release/YYYY.M.D`；不要直接在 `main` 上做常规发布工作。
+5. 为目标标签更新每个必需的版本位置，然后运行本地确定性预检：
    `pnpm check:test-types`、`pnpm check:architecture`、
    `pnpm build && pnpm ui:build` 和 `pnpm release:check`。
-6. 以 `preflight_only=true` 运行 `OpenClaw NPM Release`。在标签存在之前，
+6. 运行 `OpenClaw NPM Release`，并设置 `preflight_only=true`。在标签存在之前，
    允许使用完整的 40 字符发布分支 SHA 进行仅验证预检。
    保存成功的 `preflight_run_id`。
-7. 使用 `Full Release Validation` 为发布分支、标签或完整提交 SHA
-   启动所有预发布测试。这是四个大型发布测试箱的唯一手动入口点：
-   Vitest、Docker、QA Lab 和 Package。
-8. 如果验证失败，在发布分支上修复，并重新运行能证明修复的最小失败
-   文件、通道、workflow 作业、包配置、提供商或模型允许列表。
-   仅当变更表面使先前证据过时时，才重新运行完整总入口。
-9. 对于 beta，标记 `vYYYY.M.D-beta.N`，使用 npm dist-tag `beta` 发布，然后针对已发布的 `openclaw@YYYY.M.D-beta.N`
+7. 使用 `Full Release Validation` 为发布分支、标签或完整提交 SHA 启动所有预发布测试。
+   这是四个大型发布测试箱的唯一手动入口点：Vitest、Docker、QA Lab 和 Package。
+8. 如果验证失败，在发布分支上修复，并重新运行能够证明修复的最小失败文件、通道、工作流作业、包配置、提供商或模型允许列表。
+   只有在变更范围使先前证据过时时，才重新运行完整总入口。
+9. 对于 beta，打标签 `vYYYY.M.D-beta.N`，使用 npm dist-tag `beta` 发布，然后针对已发布的 `openclaw@YYYY.M.D-beta.N`
    或 `openclaw@beta` 包运行发布后包验收。如果已推送或已发布的 beta 需要修复，
    切出下一个 `-beta.N`；不要删除或重写旧 beta。
-10. 对于 stable，仅在已验证的 beta 或发布候选版本具备所需验证证据后继续。
-    stable npm 发布通过 `preflight_run_id` 复用成功的
-    预检产物；stable macOS 发布就绪还需要 `main` 上有打包好的
-    `.zip`、`.dmg`、`.dSYM.zip` 和更新后的
-    `appcast.xml`。
-11. 发布后，运行 npm 发布后验证器；在需要发布后渠道证据时，运行可选的独立
-    已发布 npm Telegram E2E；
-    在需要时进行 dist-tag 提升；根据完整匹配的 `CHANGELOG.md` 小节创建 GitHub 发布/预发布说明；
-    并执行发布公告步骤。
+10. 对于稳定版，只有在已审定的 beta 或候选发布具备所需验证证据后才继续。
+    稳定版 npm 发布通过 `preflight_run_id` 复用成功的预检工件；稳定版 macOS 发布就绪还要求
+    打包的 `.zip`、`.dmg`、`.dSYM.zip` 和更新后的
+    `appcast.xml` 位于 `main` 上。
+11. 发布后，运行 npm 发布后验证器；在需要发布后渠道证明时，可选运行独立的
+    已发布 npm Telegram E2E；按需进行 dist-tag 推广；根据完整匹配的
+    `CHANGELOG.md` 章节生成 GitHub release/prerelease 说明；并执行发布公告步骤。
 
 ## 发布预检
 
-- 在发布预检前运行 `pnpm check:test-types`，确保测试 TypeScript 仍在更快的本地 `pnpm check` 门禁之外得到覆盖
+- 在发布预检前运行 `pnpm check:test-types`，确保测试 TypeScript 在更快的本地 `pnpm check` 门禁之外仍被覆盖
 - 在发布预检前运行 `pnpm check:architecture`，确保更广泛的导入循环和架构边界检查在更快的本地门禁之外保持绿色
-- 在 `pnpm release:check` 前运行 `pnpm build && pnpm ui:build`，确保打包验证步骤所需的 `dist/*` 发布产物和 Control UI 包存在
-- 在发布批准前运行手动 `Full Release Validation` 工作流，以从一个入口点启动所有预发布测试盒。它接受分支、标签或完整提交 SHA，分发手动 `CI`，并分发 `OpenClaw Release Checks`，覆盖安装烟测、包验收、Docker 发布路径套件、live/E2E、OpenWebUI、QA Lab 对齐、Matrix 和 Telegram 通道。仅在包已发布且也应运行发布后 Telegram E2E 时提供 `npm_telegram_package_spec`。当私有证据报告应证明验证与已发布的 npm 包匹配、但不强制运行 Telegram E2E 时，提供 `evidence_package_spec`。示例：
+- 在 `pnpm release:check` 前运行 `pnpm build && pnpm ui:build`，确保预期的 `dist/*` 发布产物和 Control UI bundle 已存在，可用于 pack 验证步骤
+- 在发布批准前运行手动 `Full Release Validation` 工作流，以便从一个入口点启动所有预发布测试盒。它接受分支、标签或完整提交 SHA，派发手动 `CI`，并派发 `OpenClaw Release Checks`，用于安装烟测、package acceptance、Docker 发布路径套件、live/E2E、OpenWebUI、QA Lab parity、Matrix 和 Telegram lane。只有在包已发布且也应运行发布后 Telegram E2E 时，才提供 `npm_telegram_package_spec`。当私有证据报告应证明验证匹配已发布的 npm 包、但不强制运行 Telegram E2E 时，提供 `evidence_package_spec`。
+  示例：
   `gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D`
-- 当你希望在发布工作继续进行时，为包候选项获得旁路证明，请运行手动 `Package Acceptance` 工作流。对 `openclaw@beta`、`openclaw@latest` 或精确发布版本使用 `source=npm`；使用 `source=ref`，通过当前 `workflow_ref` harness 打包可信的 `package_ref` 分支/标签/SHA；对带有必需 SHA-256 的 HTTPS tarball 使用 `source=url`；或对另一个 GitHub Actions 运行上传的 tarball 使用 `source=artifact`。该工作流会将候选项解析为 `package-under-test`，针对该 tarball 复用 Docker E2E 发布调度器，并可使用 `telegram_mode=mock-openai` 或 `telegram_mode=live-frontier` 针对同一个 tarball 运行 Telegram QA。
+- 当你希望在发布工作继续进行时为包候选版本获取旁路证明，请运行手动 `Package Acceptance` 工作流。对 `openclaw@beta`、`openclaw@latest` 或精确发布版本使用 `source=npm`；使用 `source=ref` 通过当前 `workflow_ref` harness 打包受信任的 `package_ref` 分支/标签/SHA；对带有必需 SHA-256 的 HTTPS tarball 使用 `source=url`；或对另一个 GitHub Actions 运行上传的 tarball 使用 `source=artifact`。该工作流会将候选项解析为 `package-under-test`，复用 Docker E2E 发布调度器来针对该 tarball 运行，并可使用 `telegram_mode=mock-openai` 或 `telegram_mode=live-frontier` 针对同一个 tarball 运行 Telegram QA。
   示例：`gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product -f telegram_mode=mock-openai`
-  常用配置：
-  - `smoke`：安装/渠道/智能体、Gateway 网关网络和配置重载通道
-  - `package`：面向原生产物的包/更新/插件通道，不包含 OpenWebUI 或 live ClawHub
-  - `product`：包配置加上 MCP 渠道、cron/子智能体清理、OpenAI web 搜索和 OpenWebUI
+  常用 profile：
+  - `smoke`：安装/渠道/智能体、Gateway 网关网络和配置重载 lane
+  - `package`：不含 OpenWebUI 或 live ClawHub 的产物原生 package/update/plugin lane
+  - `product`：package profile 加 MCP 渠道、cron/subagent 清理、OpenAI web 搜索和 OpenWebUI
   - `full`：带 OpenWebUI 的 Docker 发布路径分块
   - `custom`：用于聚焦重跑的精确 `docker_lanes` 选择
-- 当你只需要发布候选项的完整常规 CI 覆盖时，直接运行手动 `CI` 工作流。手动 CI 分发会绕过变更范围限定，并强制运行 Linux Node 分片、内置插件分片、渠道契约、Node 22 兼容性、`check`、`check-additional`、构建烟测、文档检查、Python Skills、Windows、macOS、Android 和 Control UI i18n 通道。
+- 当你只需要发布候选版本的完整常规 CI 覆盖时，直接运行手动 `CI` 工作流。手动 CI 派发会绕过 changed 作用域，并强制运行 Linux Node 分片、内置插件分片、渠道契约、Node 22 兼容性、`check`、`check-additional`、构建烟测、文档检查、Python Skills、Windows、macOS、Android 和 Control UI i18n lane。
   示例：`gh workflow run ci.yml --ref release/YYYY.M.D`
-- 验证发布遥测时运行 `pnpm qa:otel:smoke`。它通过本地 OTLP/HTTP 接收器运行 QA-lab，并验证导出的 trace span 名称、有界属性，以及内容/标识符脱敏，无需 Opik、Langfuse 或其他外部收集器。
+- 验证发布遥测时运行 `pnpm qa:otel:smoke`。它通过本地 OTLP/HTTP receiver 演练 QA-lab，并验证导出的 trace span 名称、有界属性以及内容/标识符脱敏，而无需 Opik、Langfuse 或其他外部 collector。
 - 每次打标签发布前运行 `pnpm release:check`
 - 发布检查现在在单独的手动工作流中运行：
   `OpenClaw Release Checks`
-- `OpenClaw Release Checks` 还会在发布批准前运行 QA Lab mock 对齐门禁、快速 live Matrix 配置和 Telegram QA 通道。live 通道使用 `qa-live-shared` 环境；Telegram 还使用 Convex CI 凭证租约。当你希望并行获取完整 Matrix 传输、媒体和 E2EE 清单时，请使用 `matrix_profile=all` 和 `matrix_shards=true` 运行手动 `QA-Lab - All Lanes` 工作流。
-- 跨 OS 安装和升级运行时验证是公开 `OpenClaw Release Checks` 和 `Full Release Validation` 的一部分，它们会直接调用可复用工作流 `.github/workflows/openclaw-cross-os-release-checks-reusable.yml`
-- 这种拆分是有意的：保持真实 npm 发布路径短、确定且专注于产物，同时让较慢的 live 检查待在自己的通道中，避免它们拖慢或阻塞发布
-- 携带密钥的发布检查应通过 `Full Release Validation` 分发，或从 `main`/发布工作流 ref 分发，以便工作流逻辑和密钥保持受控
-- `OpenClaw Release Checks` 接受分支、标签或完整提交 SHA，只要解析出的提交可从 OpenClaw 分支或发布标签到达
-- `OpenClaw NPM Release` 仅验证预检也接受当前完整 40 字符工作流分支提交 SHA，无需已推送标签
+- `OpenClaw Release Checks` 还会在发布批准前运行 QA Lab mock parity 门禁，以及快速 live Matrix profile 和 Telegram QA lane。live lane 使用 `qa-live-shared` 环境；Telegram 也使用 Convex CI 凭证租约。当你希望并行获取完整 Matrix 传输、媒体和 E2EE 清单时，使用 `matrix_profile=all` 和 `matrix_shards=true` 运行手动 `QA-Lab - All Lanes` 工作流。
+- 跨操作系统安装和升级运行时验证是公开 `OpenClaw Release Checks` 和 `Full Release Validation` 的一部分，它们会直接调用可复用工作流 `.github/workflows/openclaw-cross-os-release-checks-reusable.yml`
+- 这种拆分是有意的：保持真实 npm 发布路径短小、确定且以产物为中心，同时让较慢的 live 检查留在自己的 lane 中，避免拖慢或阻塞发布
+- 带密钥的发布检查应通过 `Full Release Validation` 派发，或从 `main`/release 工作流 ref 派发，以便工作流逻辑和密钥保持受控
+- `OpenClaw Release Checks` 接受分支、标签或完整提交 SHA，只要解析后的提交可从 OpenClaw 分支或发布标签访问
+- `OpenClaw NPM Release` 的仅验证预检也接受当前完整 40 字符工作流分支提交 SHA，而不要求已推送标签
 - 该 SHA 路径仅用于验证，不能提升为真实发布
-- 在 SHA 模式下，工作流仅为包元数据检查合成 `v<package.json version>`；真实发布仍需要真实发布标签
-- 两个工作流都将真实发布和提升路径保留在 GitHub 托管 runner 上，而非变更性的验证路径可以使用更大的 Blacksmith Linux runner
-- 该工作流会使用 `OPENAI_API_KEY` 和 `ANTHROPIC_API_KEY` 工作流密钥运行
-  `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache`
-- npm 发布预检不再等待单独的发布检查通道
-- 批准前运行 `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`（或匹配的 beta/修正版标签）
-- npm 发布后运行
-  `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D`
-  （或匹配的 beta/修正版版本），以在新的临时前缀中验证已发布 registry 安装路径
-- beta 发布后运行 `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live`，使用共享租约 Telegram 凭证池，针对已发布 npm 包验证已安装包新手引导、Telegram 设置和真实 Telegram E2E。本地维护者的一次性运行可以省略 Convex 变量，并直接传入三个 `OPENCLAW_QA_TELEGRAM_*` 环境变量凭证。
-- 维护者可以通过手动 `NPM Telegram Beta E2E` 工作流，从 GitHub Actions 运行相同的发布后检查。它刻意仅限手动运行，不会在每次合并时运行。
-- 维护者发布自动化现在使用先预检再提升：
+- 在 SHA 模式下，工作流只会为包元数据检查合成 `v<package.json version>`；真实发布仍需要真实发布标签
+- 两个工作流都将真实发布和提升路径保留在 GitHub-hosted runner 上，而非变更性验证路径可以使用更大的 Blacksmith Linux runner
+- 该工作流会使用 `OPENAI_API_KEY` 和 `ANTHROPIC_API_KEY` 工作流密钥运行 `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache`
+- npm 发布预检不再等待单独的发布检查 lane
+- 批准前运行 `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`（或匹配的 beta/correction 标签）
+- npm 发布后运行 `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D`（或匹配的 beta/correction 版本），以在新的临时 prefix 中验证已发布 registry 安装路径
+- beta 发布后运行 `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live`，使用共享租约 Telegram 凭证池，针对已发布 npm 包验证已安装包的新手引导、Telegram 设置和真实 Telegram E2E。本地维护者的一次性运行可以省略 Convex 变量，并直接传入三个 `OPENCLAW_QA_TELEGRAM_*` 环境凭证。
+- 维护者可以通过手动 `NPM Telegram Beta E2E` 工作流从 GitHub Actions 运行相同的发布后检查。它有意仅支持手动运行，不会在每次合并时运行。
+- 维护者发布自动化现在使用先预检、后提升：
   - 真实 npm 发布必须通过成功的 npm `preflight_run_id`
-  - 真实 npm 发布必须从与成功预检运行相同的 `main` 或 `release/YYYY.M.D` 分支分发
-  - 稳定 npm 发布默认使用 `beta`
-  - 稳定 npm 发布可以通过工作流输入显式目标为 `latest`
-  - 基于令牌的 npm dist-tag 变更现在位于 `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`，出于安全原因，因为 `npm dist-tag add` 仍需要 `NPM_TOKEN`，而公开仓库保持仅 OIDC 发布
-  - 公开 `macOS Release` 仅用于验证；当标签只存在于发布分支但工作流从 `main` 分发时，设置 `public_release_branch=release/YYYY.M.D`
-  - 真实私有 Mac 发布必须通过成功的私有 Mac `preflight_run_id` 和 `validate_run_id`
-  - 真实发布路径会提升已准备好的产物，而不是再次重新构建它们
-- 对于像 `YYYY.M.D-N` 这样的稳定修正版本，发布后验证器还会检查从 `YYYY.M.D` 到 `YYYY.M.D-N` 的同一临时前缀升级路径，确保发布修正不会静默地让较旧的全局安装停留在基础稳定载荷上
-- npm 发布预检默认失败关闭，除非 tarball 同时包含 `dist/control-ui/index.html` 和非空 `dist/control-ui/assets/` 载荷，避免再次发布空的浏览器 dashboard
-- 发布后验证还会检查已发布 registry 安装是否在根 `dist/*` 布局下包含非空内置插件运行时依赖。若某个发布缺失或包含空的内置插件依赖载荷，发布后验证器会失败，且该发布不能提升到 `latest`。
-- `pnpm test:install:smoke` 还会对候选更新 tarball 强制执行 npm pack `unpackedSize` 预算，因此安装器 e2e 会在发布路径发布前捕获意外的包体膨胀
-- 如果发布工作触及 CI 规划、插件计时 manifest 或插件测试矩阵，请在批准前重新生成并审查 `.github/workflows/plugin-prerelease.yml` 中由规划器拥有的 `plugin-prerelease-extension-shard` 矩阵输出，确保发布说明不会描述过时的 CI 布局
-- 稳定 macOS 发布就绪性还包括更新器表面：
-  - GitHub 发布必须最终包含打包后的 `.zip`、`.dmg` 和 `.dSYM.zip`
-  - `main` 上的 `appcast.xml` 必须在发布后指向新的稳定 zip
-  - 打包后的应用必须保留非调试 bundle id、非空 Sparkle feed URL，以及不低于该发布版本规范 Sparkle 构建下限的 `CFBundleVersion`
+  - 真实 npm 发布必须从与成功预检运行相同的 `main` 或 `release/YYYY.M.D` 分支派发
+  - stable npm 发布默认使用 `beta`
+  - stable npm 发布可以通过工作流输入显式目标为 `latest`
+  - 基于 token 的 npm dist-tag 变更现在位于 `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml` 中以保证安全，因为 `npm dist-tag add` 仍需要 `NPM_TOKEN`，而公开 repo 保持仅 OIDC 发布
+  - 公开 `macOS Release` 仅用于验证；当标签只存在于 release 分支但工作流从 `main` 派发时，设置 `public_release_branch=release/YYYY.M.D`
+  - 真实私有 mac 发布必须通过成功的私有 mac `preflight_run_id` 和 `validate_run_id`
+  - 真实发布路径会提升已准备好的产物，而不是再次重建它们
+- 对于 `YYYY.M.D-N` 这样的 stable 修正发布，发布后验证器还会检查从 `YYYY.M.D` 到 `YYYY.M.D-N` 的相同临时 prefix 升级路径，确保发布修正不会悄悄把较旧的全局安装留在基础 stable payload 上
+- 除非 tarball 同时包含 `dist/control-ui/index.html` 和非空的 `dist/control-ui/assets/` payload，否则 npm 发布预检会失败关闭，避免再次发布空的浏览器 dashboard
+- 发布后验证还会检查已发布 registry 安装是否在根 `dist/*` 布局下包含非空的内置插件运行时依赖。缺失或包含空的内置插件依赖 payload 的发布会让 postpublish 验证器失败，且不能提升到 `latest`。
+- `pnpm test:install:smoke` 还会对候选更新 tarball 强制执行 npm pack `unpackedSize` 预算，因此 installer e2e 会在发布路径前捕获意外的 pack 膨胀
+- 如果发布工作触及 CI 规划、插件时序 manifest 或插件测试矩阵，请在批准前重新生成并审查 `.github/workflows/plugin-prerelease.yml` 中由 planner 拥有的 `plugin-prerelease-extension-shard` 矩阵输出，避免发布说明描述过时的 CI 布局
+- stable macOS 发布就绪性还包括 updater surface：
+  - GitHub release 最终必须包含打包好的 `.zip`、`.dmg` 和 `.dSYM.zip`
+  - 发布后，`main` 上的 `appcast.xml` 必须指向新的 stable zip
+  - 打包后的 app 必须保留非 debug bundle id、非空 Sparkle feed URL，以及不低于该发布版本规范 Sparkle build floor 的 `CFBundleVersion`
 
 ## 发布测试盒
 
-`Full Release Validation` 是操作员从一个入口点启动所有预发布测试的方式。从可信的 `main` 工作流 ref 运行它，并将发布分支、标签或完整提交 SHA 作为 `ref` 传入：
+`Full Release Validation` 是操作员从一个入口点启动所有预发布测试的方式。从受信任的 `main` 工作流 ref 运行它，并将发布分支、标签或完整提交 SHA 作为 `ref` 传入：
 
 ```bash
 gh workflow run full-release-validation.yml \
@@ -155,21 +148,22 @@ gh workflow run full-release-validation.yml \
   -f ref=release/YYYY.M.D \
   -f provider=openai \
   -f mode=both \
-  -f release_profile=full \
+  -f release_profile=stable \
   -f evidence_package_spec=openclaw@YYYY.M.D-beta.N
 ```
 
-该工作流会解析目标 ref，使用 `target_ref=<release-ref>` 分发手动 `CI`，分发 `OpenClaw Release Checks`，并在设置 `npm_telegram_package_spec` 时，可选地分发独立的发布后 Telegram E2E。随后 `OpenClaw Release Checks` 会展开运行安装烟测、跨 OS 发布检查、live/E2E Docker 发布路径覆盖、带 Telegram 包 QA 的 Package Acceptance、QA Lab 对齐、live Matrix 和 live Telegram。完整运行只有在 `Full Release Validation` 摘要显示 `normal_ci` 和 `release_checks` 成功，且任何可选 `npm_telegram` 子项成功或被有意跳过时才可接受。最终验证器摘要会包含每个子运行的最慢作业表，因此发布经理无需下载日志即可看到当前关键路径。
-子工作流会从运行 `Full Release Validation` 的可信 ref 分发，通常是 `--ref main`，即使目标 `ref` 指向较旧的发布分支或标签。不存在单独的 Full Release Validation 工作流 ref 输入；通过选择工作流运行 ref 来选择可信 harness。
+该工作流会解析目标 ref，使用 `target_ref=<release-ref>` 派发手动 `CI`，派发 `OpenClaw Release Checks`，并在设置 `npm_telegram_package_spec` 时可选派发独立的发布后 Telegram E2E。随后 `OpenClaw Release Checks` 会扇出安装烟测、跨操作系统发布检查、live/E2E Docker 发布路径覆盖、带 Telegram package QA 的 Package Acceptance、QA Lab parity、live Matrix 和 live Telegram。只有当 `Full Release Validation` 摘要显示 `normal_ci` 和 `release_checks` 成功，并且任何可选的 `npm_telegram` 子项成功或被有意跳过时，完整运行才可接受。最终验证器摘要会为每个子运行包含最慢 job 表，因此发布经理无需下载日志即可查看当前关键路径。
+请参阅 [完整发布验证](/zh-CN/reference/full-release-validation)，了解完整阶段矩阵、精确工作流 job 名称、stable 与 full profile 差异、产物以及聚焦重跑句柄。
+子工作流会从运行 `Full Release Validation` 的受信任 ref 派发，通常为 `--ref main`，即使目标 `ref` 指向较旧的 release 分支或标签也是如此。不存在单独的 Full Release Validation workflow-ref 输入；通过选择工作流运行 ref 来选择受信任 harness。
 
-使用 `release_profile` 选择 live/提供商覆盖范围：
+使用 `release_profile` 选择 live/provider 覆盖宽度：
 
 - `minimum`：最快的发布关键 OpenAI/core live 和 Docker 路径
-- `stable`：minimum 加上用于发布批准的稳定提供商/后端覆盖
-- `full`：stable 加上广泛的咨询类提供商/媒体覆盖
+- `stable`：minimum 加用于发布批准的 stable provider/backend 覆盖
+- `full`：stable 加广泛的 advisory provider/media 覆盖
 
-`OpenClaw Release Checks` 使用可信工作流 ref 将目标 ref 解析一次为 `release-package-under-test`，并在发布路径 Docker 检查和 Package Acceptance 中复用该产物。这会让所有面向包的测试盒使用相同字节，并避免重复构建包。
-当设置了 repo/org 变量时，跨 OS OpenAI 安装烟测使用 `OPENCLAW_CROSS_OS_OPENAI_MODEL`，否则使用 `openai/gpt-5.4-mini`，因为此通道是在证明包安装、新手引导、Gateway 网关启动和一次 live 智能体轮次，而不是对最慢的默认模型做基准测试。更广泛的 live 提供商矩阵仍是模型特定覆盖的位置。
+`OpenClaw Release Checks` 使用受信任的工作流 ref 将目标 ref 一次性解析为 `release-package-under-test`，并在发布路径 Docker 检查和 Package Acceptance 中复用该产物。这让所有面向包的测试盒使用相同字节，并避免重复构建包。
+当 repo/org 变量已设置时，跨操作系统 OpenAI 安装烟测使用 `OPENCLAW_CROSS_OS_OPENAI_MODEL`，否则使用 `openai/gpt-5.4-mini`，因为该 lane 证明的是包安装、新手引导、Gateway 网关启动和一次 live 智能体回合，而不是 benchmark 最慢的默认模型。更广泛的 live provider 矩阵仍然是模型特定覆盖的位置。
 
 根据发布阶段使用这些变体：
 
@@ -200,22 +194,22 @@ gh workflow run full-release-validation.yml \
   -f npm_telegram_provider_mode=mock-openai
 ```
 
-不要在一次聚焦修复后的首次重跑中使用完整总控流程。如果某个检查箱失败，请使用失败的子工作流、作业、Docker 通道、软件包 profile、模型提供商或 QA 通道作为下一次证明。只有当修复改动了共享发布编排，或让先前的全检查箱证据过期时，才再次运行完整总控流程。总控流程的最终验证器会重新检查记录的子工作流运行 ID，因此在子工作流成功重跑后，只需重跑失败的 `Verify full validation` 父作业。
+不要把完整总括流程作为聚焦修复后的第一次重跑。如果某个检查项失败，请使用失败的子 workflow、作业、Docker lane、包 profile、模型提供商或 QA lane 作为下一次证明。只有当修复改动了共享发布编排，或使先前的全检查项证据过期时，才再次运行完整总括流程。总括流程的最终验证器会重新检查已记录的子 workflow run ID，因此在某个子 workflow 成功重跑后，只需重跑失败的 `Verify full validation` 父作业。
 
-对于有界恢复，向总控流程传入 `rerun_group`。`all` 是真正的发布候选运行，`ci` 只运行普通 CI 子项，`plugin-prerelease` 只运行仅发布用的插件子项，`release-checks` 运行每个发布检查箱，更窄的发布分组包括 `install-smoke`、`cross-os`、`live-e2e`、`package`、`qa`、`qa-parity`、`qa-live`，以及在提供独立软件包 Telegram 通道时的 `npm-telegram`。
+对于有界恢复，将 `rerun_group` 传给总括流程。`all` 是真正的发布候选运行，`ci` 只运行普通 CI 子项，`plugin-prerelease` 只运行仅发布用的插件子项，`release-checks` 运行每个发布检查项，更窄的发布分组包括 `install-smoke`、`cross-os`、`live-e2e`、`package`、`qa`、`qa-parity`、`qa-live`，以及在提供独立包 Telegram lane 时的 `npm-telegram`。
 
 ### Vitest
 
-Vitest 检查箱是手动 `CI` 子工作流。手动 CI 会有意绕过 changed 作用域，并为发布候选强制运行普通测试图：Linux Node 分片、内置插件分片、渠道契约、Node 22 兼容性、`check`、`check-additional`、构建 smoke、文档检查、Python Skills、Windows、macOS、Android，以及 Control UI i18n。
+Vitest 检查项是手动 `CI` 子 workflow。手动 CI 会有意绕过变更范围，并强制对发布候选运行普通测试图：Linux Node 分片、内置插件分片、渠道契约、Node 22 兼容性、`check`、`check-additional`、构建 smoke、文档检查、Python Skills、Windows、macOS、Android 和 Control UI i18n。
 
-使用这个检查箱回答“源码树是否通过了完整普通测试套件？”它不同于发布路径的产品验证。需要保留的证据：
+用这个检查项回答“源代码树是否通过了完整普通测试套件？”它不等同于发布路径的产品验证。需要保留的证据：
 
-- `Full Release Validation` 摘要，其中显示已分发的 `CI` 运行 URL
-- `CI` 在确切目标 SHA 上通过
+- 显示已派发 `CI` 运行 URL 的 `Full Release Validation` 摘要
+- 精确目标 SHA 上绿色通过的 `CI` 运行
 - 调查回归时 CI 作业中失败或缓慢的分片名称
-- 当一次运行需要性能分析时，保留 Vitest 时间产物，例如 `.artifacts/vitest-shard-timings.json`
+- 当某次运行需要性能分析时，保留 `.artifacts/vitest-shard-timings.json` 等 Vitest 计时 artifact
 
-仅当发布需要确定性的普通 CI，但不需要 Docker、QA Lab、live、cross-OS 或软件包检查箱时，才直接运行手动 CI：
+仅当发布需要确定性的普通 CI，而不需要 Docker、QA Lab、live、跨 OS 或包检查项时，才直接运行手动 CI：
 
 ```bash
 gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D
@@ -223,50 +217,50 @@ gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D
 
 ### Docker
 
-Docker 检查箱位于 `OpenClaw Release Checks` 中，通过 `openclaw-live-and-e2e-checks-reusable.yml` 执行，另有发布模式的 `install-smoke` 工作流。它通过打包后的 Docker 环境验证发布候选，而不只是源码级测试。
+Docker 检查项通过 `openclaw-live-and-e2e-checks-reusable.yml` 存在于 `OpenClaw Release Checks` 中，并包含发布模式的 `install-smoke` workflow。它通过打包后的 Docker 环境验证发布候选，而不是只运行源代码级测试。
 
-发布 Docker 覆盖范围包括：
+发布 Docker 覆盖包括：
 
-- 完整安装 smoke，并启用较慢的 Bun 全局安装 smoke
-- 按目标 SHA 准备/复用根 Dockerfile smoke 镜像，QR、root/gateway 和 installer/Bun smoke 作业作为独立 install-smoke 分片运行
-- 仓库 E2E 通道
+- 启用慢速 Bun 全局安装 smoke 的完整 install smoke
+- 按目标 SHA 准备/复用根 Dockerfile smoke 镜像，并将 QR、root/Gateway 网关 和 installer/Bun smoke 作业作为独立 install-smoke 分片运行
+- 仓库 E2E lane
 - 发布路径 Docker 分块：`core`、`package-update-openai`、`package-update-anthropic`、`package-update-core`、`plugins-runtime-plugins`、`plugins-runtime-services`、`plugins-runtime-install-a`、`plugins-runtime-install-b`、`plugins-runtime-install-c`、`plugins-runtime-install-d`、`plugins-runtime-install-e`、`plugins-runtime-install-f`、`plugins-runtime-install-g`、`plugins-runtime-install-h`、`bundled-channels-core`、`bundled-channels-update-a`、`bundled-channels-update-discord`、`bundled-channels-update-b` 和 `bundled-channels-contracts`
-- 请求时在 `plugins-runtime-services` 分块内提供 OpenWebUI 覆盖
-- 将内置渠道依赖通道拆分到 channel-smoke、update-target 和 setup/runtime 契约分块，而不是一个大型 bundled-channel 作业
-- 拆分内置插件安装/卸载通道，从 `bundled-plugin-install-uninstall-0` 到 `bundled-plugin-install-uninstall-23`
+- 请求时，在 `plugins-runtime-services` 分块中覆盖 OpenWebUI
+- 将内置渠道依赖 lane 拆分到 channel-smoke、update-target 和 setup/runtime contract 分块，而不是一个大型内置渠道作业
+- 拆分内置插件安装/卸载 lane，从 `bundled-plugin-install-uninstall-0` 到 `bundled-plugin-install-uninstall-23`
 - 当发布检查包含 live 套件时，覆盖 live/E2E 提供商套件和 Docker live 模型
 
-重跑前先使用 Docker 产物。发布路径调度器会上传 `.artifacts/docker-tests/`，其中包含通道日志、`summary.json`、`failures.json`、阶段耗时、调度器计划 JSON 和重跑命令。对于聚焦恢复，请在可复用 live/E2E 工作流上使用 `docker_lanes=<lane[,lane]>`，而不是重跑所有发布分块。生成的重跑命令会在可用时包含先前的 `package_artifact_run_id` 和已准备的 Docker 镜像输入，因此失败通道可以复用同一个 tarball 和 GHCR 镜像。
+重跑前先使用 Docker artifact。发布路径调度器会上传 `.artifacts/docker-tests/`，其中包含 lane 日志、`summary.json`、`failures.json`、阶段计时、调度器计划 JSON 和重跑命令。对于聚焦恢复，请在可复用 live/E2E workflow 上使用 `docker_lanes=<lane[,lane]>`，而不是重跑所有发布分块。生成的重跑命令会在可用时包含先前的 `package_artifact_run_id` 和已准备的 Docker 镜像输入，因此失败 lane 可以复用同一个 tarball 和 GHCR 镜像。
 
 ### QA Lab
 
-QA Lab 检查箱也是 `OpenClaw Release Checks` 的一部分。它是智能体行为和渠道级发布门禁，独立于 Vitest 和 Docker 软件包机制。
+QA Lab 检查项也是 `OpenClaw Release Checks` 的一部分。它是智能体行为和渠道级发布门禁，独立于 Vitest 和 Docker 包机制。
 
-发布 QA Lab 覆盖范围包括：
+发布 QA Lab 覆盖包括：
 
-- mock parity gate，使用 agentic parity pack 比较 OpenAI 候选通道与 Opus 4.6 基线
+- mock parity gate，使用 agentic parity pack 将 OpenAI 候选 lane 与 Opus 4.6 baseline 进行比较
 - 使用 `qa-live-shared` 环境的快速 live Matrix QA profile
-- 使用 Convex CI 凭证租约的 live Telegram QA 通道
-- 当发布遥测需要显式本地证明时运行 `pnpm qa:otel:smoke`
+- 使用 Convex CI 凭证租约的 live Telegram QA lane
+- 当发布遥测需要明确本地证明时运行 `pnpm qa:otel:smoke`
 
-使用这个检查箱回答“发布在 QA 场景和 live 渠道流程中行为是否正确？”批准发布时，请保留 parity、Matrix 和 Telegram 通道的产物 URL。完整 Matrix 覆盖仍可作为手动分片 QA-Lab 运行使用，而不是默认的发布关键通道。
+用这个检查项回答“发布在 QA 场景和 live 渠道流程中的行为是否正确？”批准发布时，请保留 parity、Matrix 和 Telegram lane 的 artifact URL。完整 Matrix 覆盖仍可作为手动分片 QA-Lab 运行使用，而不是默认的发布关键 lane。
 
-### 软件包
+### 包
 
-软件包检查箱是可安装产品门禁。它由 `Package Acceptance` 和解析器 `scripts/resolve-openclaw-package-candidate.mjs` 支撑。解析器会将候选归一化为 Docker E2E 消费的 `package-under-test` tarball，验证软件包清单，记录软件包版本和 SHA-256，并让工作流 harness ref 与软件包源码 ref 保持分离。
+Package 检查项是可安装产品门禁。它由 `Package Acceptance` 和解析器 `scripts/resolve-openclaw-package-candidate.mjs` 支撑。解析器会将候选归一化为 Docker E2E 使用的 `package-under-test` tarball，验证包清单，记录包版本和 SHA-256，并将 workflow harness ref 与包源 ref 分开。
 
 支持的候选来源：
 
-- `source=npm`：`openclaw@beta`、`openclaw@latest`，或确切的 OpenClaw 发布版本
+- `source=npm`：`openclaw@beta`、`openclaw@latest` 或精确的 OpenClaw 发布版本
 - `source=ref`：使用选定的 `workflow_ref` harness 打包受信任的 `package_ref` 分支、标签或完整提交 SHA
 - `source=url`：下载 HTTPS `.tgz`，并要求提供 `package_sha256`
-- `source=artifact`：复用另一次 GitHub Actions 运行上传的 `.tgz`
+- `source=artifact`：复用另一个 GitHub Actions 运行上传的 `.tgz`
 
-`OpenClaw Release Checks` 使用 `source=ref`、`package_ref=<release-ref>`、`suite_profile=custom`、`docker_lanes=bundled-channel-deps-compat plugins-offline` 和 `telegram_mode=mock-openai` 运行 Package Acceptance。发布路径 Docker 分块覆盖重叠的安装、更新和插件更新通道；Package Acceptance 则保留 artifact-native 的内置渠道兼容性、离线插件 fixture，以及针对同一已解析 tarball 的 Telegram 软件包 QA。它是 GitHub 原生替代方案，用来替代之前大多数需要 Parallels 的 package/update 覆盖。Cross-OS 发布检查对于特定 OS 的新手引导、安装器和平台行为仍然重要，但 package/update 产品验证应优先使用 Package Acceptance。
+`OpenClaw Release Checks` 使用 `source=ref`、`package_ref=<release-ref>`、`suite_profile=custom`、`docker_lanes=bundled-channel-deps-compat plugins-offline` 和 `telegram_mode=mock-openai` 运行 Package Acceptance。发布路径 Docker 分块会覆盖重叠的安装、更新和插件更新 lane；Package Acceptance 会针对同一个已解析 tarball 保留 artifact 原生的内置渠道兼容性、离线插件 fixture 和 Telegram 包 QA。它是 GitHub 原生替代方案，用于替代过去大多数需要 Parallels 的包/更新覆盖。跨 OS 发布检查对于 OS 特定的新手引导、安装器和平台行为仍然重要，但包/更新产品验证应优先使用 Package Acceptance。
 
-旧版 package-acceptance 宽容策略有意设置了时间边界。到 `2026.4.25` 为止的软件包可以对已经发布到 npm 的元数据缺口使用兼容路径：tarball 中缺少私有 QA 清单条目、缺少 `gateway install --wrapper`、tarball 派生的 git fixture 中缺少补丁文件、缺少持久化的 `update.channel`、旧版插件安装记录位置、缺少 marketplace 安装记录持久化，以及 `plugins update` 期间的配置元数据迁移。已发布的 `2026.4.26` 软件包可能会对已经交付的本地构建元数据 stamp 文件发出警告。后续软件包必须满足现代软件包契约；相同缺口会导致发布验证失败。
+旧版 package-acceptance 宽容性有意设置了时间窗口。到 `2026.4.25` 为止的包可以针对已经发布到 npm 的元数据缺口使用兼容路径：tarball 中缺失的私有 QA 清单条目、缺失的 `gateway install --wrapper`、由 tarball 派生的 git fixture 中缺失的补丁文件、缺失的持久化 `update.channel`、旧版插件安装记录位置、缺失的 marketplace 安装记录持久化，以及 `plugins update` 期间的配置元数据迁移。已发布的 `2026.4.26` 包可以对已经发布的本地构建元数据 stamp 文件给出警告。之后的包必须满足现代包契约；这些相同缺口会导致发布验证失败。
 
-当发布问题涉及实际可安装软件包时，使用更宽的 Package Acceptance profile：
+当发布问题涉及实际可安装包时，使用更广的 Package Acceptance profile：
 
 ```bash
 gh workflow run package-acceptance.yml \
@@ -277,60 +271,58 @@ gh workflow run package-acceptance.yml \
   -f suite_profile=product
 ```
 
-常见软件包 profile：
+常见包 profile：
 
-- `smoke`：快速软件包安装/渠道/智能体、Gateway 网关网络和配置热重载通道
-- `package`：不带 live ClawHub 的安装/更新/插件软件包契约；这是 release-check 默认值
-- `product`：`package` 加 MCP 渠道、cron/subagent 清理、OpenAI web 搜索和 OpenWebUI
+- `smoke`：快速包安装/渠道/智能体、Gateway 网关网络和配置热重载 lane
+- `package`：无 live ClawHub 的安装/更新/插件包契约；这是 release-check 默认值
+- `product`：`package` 加上 MCP 渠道、cron/subagent 清理、OpenAI web 搜索和 OpenWebUI
 - `full`：带 OpenWebUI 的 Docker 发布路径分块
-- `custom`：用于聚焦重跑的确切 `docker_lanes` 列表
+- `custom`：用于聚焦重跑的精确 `docker_lanes` 列表
 
-对于软件包候选 Telegram 证明，请在 Package Acceptance 上启用 `telegram_mode=mock-openai` 或 `telegram_mode=live-frontier`。该工作流会把已解析的 `package-under-test` tarball 传入 Telegram 通道；独立 Telegram 工作流仍接受已发布 npm 规格，用于发布后检查。
+对于包候选 Telegram 证明，在 Package Acceptance 上启用 `telegram_mode=mock-openai` 或 `telegram_mode=live-frontier`。该 workflow 会将已解析的 `package-under-test` tarball 传入 Telegram lane；独立 Telegram workflow 仍接受已发布的 npm spec 用于发布后检查。
 
-## NPM 工作流输入
+## NPM workflow 输入
 
 `OpenClaw NPM Release` 接受这些由操作者控制的输入：
 
-- `tag`：必需的发布标签，例如 `v2026.4.2`、`v2026.4.2-1` 或 `v2026.4.2-beta.1`；当 `preflight_only=true` 时，也可以是当前完整 40 字符工作流分支提交 SHA，用于仅验证的 preflight
-- `preflight_only`：`true` 表示仅验证/构建/打包，`false` 表示真实发布路径
-- `preflight_run_id`：真实发布路径必需，这样工作流会复用成功 preflight 运行准备好的 tarball
-- `npm_dist_tag`：发布路径的 npm 目标标签；默认是 `beta`
+- `tag`：必需的发布标签，例如 `v2026.4.2`、`v2026.4.2-1` 或 `v2026.4.2-beta.1`；当 `preflight_only=true` 时，也可以是当前完整 40 字符 workflow 分支提交 SHA，用于仅验证的 preflight
+- `preflight_only`：`true` 表示只验证/构建/打包，`false` 表示真实发布路径
+- `preflight_run_id`：真实发布路径必需，以便 workflow 复用成功 preflight 运行中准备好的 tarball
+- `npm_dist_tag`：发布路径的 npm 目标标签；默认值为 `beta`
 
 `OpenClaw Release Checks` 接受这些由操作者控制的输入：
 
-- `ref`：要验证的分支、标签或完整提交 SHA。带 Secret 的检查要求解析后的提交可从 OpenClaw 分支或发布标签到达。
+- `ref`：要验证的分支、标签或完整提交 SHA。带 secret 的检查要求解析出的提交可从 OpenClaw 分支或发布标签到达。
 
 规则：
 
-- 稳定版和修正版标签可以发布到 `beta` 或 `latest`
+- Stable 和 correction 标签可以发布到 `beta` 或 `latest`
 - Beta 预发布标签只能发布到 `beta`
-- 对于 `OpenClaw NPM Release`，只有在 `preflight_only=true` 时才允许完整提交 SHA 输入
+- 对于 `OpenClaw NPM Release`，只有在 `preflight_only=true` 时才允许输入完整提交 SHA
 - `OpenClaw Release Checks` 和 `Full Release Validation` 始终仅用于验证
-- 真实发布路径必须使用 preflight 期间使用的同一个 `npm_dist_tag`；工作流会在发布继续前验证该元数据
+- 真实发布路径必须使用 preflight 期间使用的同一个 `npm_dist_tag`；workflow 会在发布继续之前验证该元数据
 
-## 稳定版 npm 发布序列
+## Stable npm 发布序列
 
-切稳定版 npm 发布时：
+切 stable npm 发布时：
 
 1. 使用 `preflight_only=true` 运行 `OpenClaw NPM Release`
-   - 在标签存在之前，你可以使用当前完整工作流分支提交 SHA，对 preflight 工作流进行仅验证的 dry run
-2. 对普通 beta-first 流程选择 `npm_dist_tag=beta`，只有在你有意直接发布稳定版时才选择 `latest`
-3. 当你想从一个手动工作流获得普通 CI 加 live prompt cache、Docker、QA Lab、Matrix 和 Telegram 覆盖时，在发布分支、发布标签或完整提交 SHA 上运行 `Full Release Validation`
-4. 如果你有意只需要确定性的普通测试图，则改为在发布 ref 上运行手动 `CI` 工作流
+   - 在标签存在之前，你可以使用当前完整 workflow 分支提交 SHA，对 preflight workflow 进行仅验证的 dry run
+2. 对普通 beta-first 流程选择 `npm_dist_tag=beta`，或者仅在你有意直接发布 stable 时选择 `latest`
+3. 当你希望通过一个手动 workflow 获得普通 CI 加 live prompt cache、Docker、QA Lab、Matrix 和 Telegram 覆盖时，在发布分支、发布标签或完整提交 SHA 上运行 `Full Release Validation`
+4. 如果你明确只需要确定性的普通测试图，请改为在发布 ref 上运行手动 `CI` workflow
 5. 保存成功的 `preflight_run_id`
-6. 使用 `preflight_only=false`、相同的 `tag`、相同的 `npm_dist_tag` 和已保存的 `preflight_run_id` 再次运行 `OpenClaw NPM Release`
-7. 如果发布落在 `beta` 上，请使用私有 `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml` 工作流，将该稳定版本从 `beta` 提升到 `latest`
-8. 如果发布有意直接发布到 `latest`，并且 `beta` 应立即跟随同一个稳定构建，请使用同一个私有工作流将两个 dist-tag 都指向稳定版本，或让它的计划自修复同步稍后移动 `beta`
+6. 再次运行 `OpenClaw NPM Release`，并使用 `preflight_only=false`、相同的 `tag`、相同的 `npm_dist_tag` 和已保存的 `preflight_run_id`
+7. 如果发布落在 `beta`，使用私有 `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml` workflow 将该 stable 版本从 `beta` 提升到 `latest`
+8. 如果发布有意直接发布到 `latest`，并且 `beta` 应立即跟随同一个 stable 构建，请使用同一个私有 workflow 将两个 dist-tag 都指向 stable 版本，或让它的定时自愈同步稍后移动 `beta`
 
-dist-tag 变更位于私有仓库中是出于安全考虑，因为它仍然需要 `NPM_TOKEN`，而公共仓库保持仅使用 OIDC 发布。
+dist-tag 变更位于私有仓库中，这是出于安全考虑，因为它仍然需要 `NPM_TOKEN`，而公共仓库保持仅 OIDC 发布。
 
-这让直接发布路径和 beta-first 提升路径都保持有文档记录，并且对操作者可见。
+这样可以让直接发布路径和 beta-first 提升路径都被记录在文档中，并且对操作者可见。
 
-如果维护者必须回退到本地 npm 身份验证，请只在专用 tmux 会话中运行任何 1Password
-CLI（`op`）命令。不要直接从主智能体 shell 调用 `op`；将它保留在 tmux 中，可以让提示、
-警报和 OTP 处理保持可观察，并防止重复的主机警报。
+如果维护者必须回退到本地 npm 身份验证，请只在专用 tmux 会话内运行任何 1Password CLI（`op`）命令。不要直接从主智能体 shell 调用 `op`；将它保留在 tmux 内，可以让提示、警报和 OTP 处理可观察，并防止重复的主机警报。
 
-## 公开参考
+## 公开参考资料
 
 - [`.github/workflows/full-release-validation.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/full-release-validation.yml)
 - [`.github/workflows/package-acceptance.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/package-acceptance.yml)

docs/zh-CN/reference/full-release-validation.md

@@ -0,0 +1,147 @@
+---
+read_when:
+    - 运行或重新运行完整发布验证
+    - 比较稳定版和完整版发布验证配置文件
+    - 调试发布验证阶段失败
+summary: 完整发布验证阶段、子工作流、发布配置档案、重新运行句柄和证据
+title: 完整发布验证
+x-i18n:
+    generated_at: "2026-05-01T02:24:08Z"
+    model: gpt-5.5
+    provider: openai
+    source_hash: ef87c4b54ed8e4834d5417f8be80b99e7d9c9476caefe0581b0864b07bcc4e1a
+    source_path: reference/full-release-validation.md
+    workflow: 16
+---
+
+`Full Release Validation` 是发布验证总入口。它是预发布验证的唯一手动入口点，但大多数工作发生在子工作流中，因此失败的机器可以在不重新启动整个发布流程的情况下重跑。
+
+从受信任的工作流引用运行它，通常是 `main`，并将发布分支、标签或完整提交 SHA 作为 `ref` 传入：
+
+```bash
+gh workflow run full-release-validation.yml \
+  --ref main \
+  -f ref=release/YYYY.M.D \
+  -f provider=openai \
+  -f mode=both \
+  -f release_profile=stable
+```
+
+子工作流使用受信任的工作流引用作为 harness，并使用输入 `ref` 作为待测候选版本。这样在验证较旧的发布分支或标签时，也能使用新的验证逻辑。
+
+## 顶层阶段
+
+| 阶段                  | 工作流作业名称                          | 子工作流                  | 证明内容                                                                                                                                                                                                                                                                                | 重跑句柄                                                         |
+| --------------------- | --------------------------------------- | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
+| 目标解析              | `Resolve target ref`                    | 无                        | 解析发布分支、标签或完整提交 SHA，并记录所选输入。                                                                                                                                                                                                                                      | 如果此项失败，重跑总入口。                                      |
+| Vitest 和常规 CI      | `Run normal full CI`                    | `CI`                      | 针对目标引用的手动完整 CI 图，包括 Linux Node 通道、内置插件分片、渠道合约、Node 22 兼容性、`check`、`check-additional`、构建 smoke、文档检查、Python Skills、Windows、macOS、Control UI i18n，以及通过总入口运行的 Android。 | `rerun_group=ci`                                                 |
+| 插件预发布            | `Run plugin prerelease validation`      | `Plugin Prerelease`       | 仅发布时运行的插件静态检查、智能体式插件覆盖、完整扩展批量分片，以及插件预发布 Docker 通道。                                                                                                                                                                                            | `rerun_group=plugin-prerelease`                                  |
+| 发布检查              | `Run release/live/Docker/QA validation` | `OpenClaw Release Checks` | 安装 smoke、跨 OS 包检查、live/E2E 套件、Docker 发布路径分块、Package Acceptance、QA Lab parity、live Matrix，以及 live Telegram。                                                                                                                                                        | `rerun_group=release-checks` 或更窄的 release-checks 句柄        |
+| 发布后 Telegram       | `Run post-publish Telegram E2E`         | `NPM Telegram Beta E2E`   | 当设置了 `npm_telegram_package_spec` 时，可选的已发布包 Telegram 验证。                                                                                                                                                                                                                  | `rerun_group=npm-telegram`                                       |
+| 总入口验证器          | `Verify full validation`                | 无                        | 重新检查已记录的子运行结论，并附加来自子工作流的最慢作业表。                                                                                                                                                                                                                            | 在重跑失败子项并转绿后，仅重跑此作业。                          |
+
+对于 `ref=main` 和 `rerun_group=all`，较新的总入口会取代较旧的总入口。当父级被取消时，它的监控器会取消已经分派的任何子工作流。发布分支和标签验证运行默认不会互相取消。
+
+## 发布检查阶段
+
+`OpenClaw Release Checks` 是最大的子工作流。它会解析一次目标，并在包或面向 Docker 的阶段需要时准备共享的 `release-package-under-test` artifact。
+
+| 阶段                | 工作流作业名称                                          | 后端工作流或作业                              | 测试内容                                                                                                                                                                                                                 | 重跑句柄                                                   |
+| ------------------- | ------------------------------------------------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------- |
+| 发布目标            | `Resolve target ref`                                    | 无                                            | 验证所选引用、可选的预期 SHA、profile、重跑组，以及聚焦的 live 套件过滤器。                                                                                                                                              | 重跑 `release-checks`。                                    |
+| 包 artifact         | `Prepare release package artifact`                      | 无                                            | 打包或解析一个候选 tarball，并上传 `release-package-under-test`，供下游面向包的检查使用。                                                                                                                                | 重跑受影响的包、跨 OS 或 live/E2E 组。                    |
+| 安装 smoke          | `Run install smoke`                                     | `Install Smoke`                               | 完整安装路径，包含根 Dockerfile smoke 镜像复用、QR 包安装、根和 Gateway 网关 Docker smoke、安装器 Docker 测试、Bun 全局安装 image-provider smoke，以及快速内置插件 Docker E2E。                                         | `rerun_group=install-smoke`                                |
+| 跨 OS               | `cross_os_release_checks`                               | `OpenClaw Cross-OS Release Checks (Reusable)` | 在 Linux、Windows 和 macOS 上，针对所选提供商和模式运行全新安装与升级通道，使用候选 tarball 加基线包。                                                                                                                   | `rerun_group=cross-os`                                     |
+| 仓库和 live E2E     | `Run repo/live E2E validation`                          | `OpenClaw Live And E2E Checks (Reusable)`     | 由 `release_profile` 选择的仓库 E2E、live 缓存、OpenAI websocket 流式传输、原生 live 提供商和插件分片，以及 Docker 支持的 live 模型、后端和 Gateway 网关 harness。                                                        | `rerun_group=live-e2e`，可选搭配 `live_suite_filter`       |
+| Docker 发布路径     | `Run Docker release-path validation`                    | `OpenClaw Live And E2E Checks (Reusable)`     | 针对共享包 artifact 运行发布路径 Docker 分块。                                                                                                                                                                           | `rerun_group=live-e2e`                                     |
+| Package Acceptance  | `Run package acceptance`                                | `Package Acceptance`                          | artifact 原生内置渠道依赖兼容性、离线插件包 fixture，以及针对同一 tarball 的 mock-OpenAI Telegram 包验收。                                                                                                               | `rerun_group=package`                                      |
+| QA parity           | `Run QA Lab parity lane` 和 `Run QA Lab parity report`  | 直接作业                                      | 候选版本和基线的智能体式 parity 包，然后生成 parity 报告。                                                                                                                                                               | `rerun_group=qa-parity` 或 `rerun_group=qa`                |
+| QA live Matrix      | `Run QA Lab live Matrix lane`                           | 直接作业                                      | `qa-live-shared` 环境中的快速 live Matrix QA profile。                                                                                                                                                                   | `rerun_group=qa-live` 或 `rerun_group=qa`                  |
+| QA live Telegram    | `Run QA Lab live Telegram lane`                         | 直接作业                                      | 使用 Convex CI 凭证租约的 live Telegram QA。                                                                                                                                                                             | `rerun_group=qa-live` 或 `rerun_group=qa`                  |
+| 发布验证器          | `Verify release checks`                                 | 无                                            | 验证所选重跑组所需的 release-check 作业。                                                                                                                                                                                | 在聚焦的子作业通过后重跑。                               |
+
+## Docker 发布路径分块
+
+当 `live_suite_filter` 为空时，Docker 发布路径阶段会运行这些分块：
+
+| 分块                                                                                        | 覆盖范围                                                                |
+| ------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- |
+| `core`                                                                                      | 核心 Docker 发布路径冒烟运行线。                                        |
+| `package-update-openai`                                                                     | OpenAI 包安装和更新行为。                                               |
+| `package-update-anthropic`                                                                  | Anthropic 包安装和更新行为。                                            |
+| `package-update-core`                                                                       | 提供商中立的包和更新行为。                                              |
+| `plugins-runtime-plugins`                                                                   | 覆盖插件行为的插件运行时运行线。                                        |
+| `plugins-runtime-services`                                                                  | 由服务支持的插件运行时运行线；按请求包含 OpenWebUI。                    |
+| `plugins-runtime-install-a` through `plugins-runtime-install-h`                             | 为并行发布验证拆分的插件安装/运行时批次。                               |
+| `bundled-channels-core`                                                                     | 内置渠道 Docker 行为。                                                  |
+| `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b` | 内置渠道更新行为。                                                      |
+| `bundled-channels-contracts`                                                                | Docker 发布路径中的内置渠道契约检查。                                   |
+
+当只有一个 Docker 运行线失败时，在可复用的 live/E2E 工作流上使用有针对性的 `docker_lanes=<lane[,lane]>`。发布工件会在可用时包含按运行线划分的重跑命令，并带有包工件和镜像复用输入。
+
+## 发布配置档案
+
+`release_profile` 只控制发布检查中的 live/提供商覆盖广度。它不会移除常规完整 CI、插件预发布、安装冒烟、包验收、QA Lab 或 Docker 发布路径分块。
+
+| 配置档案  | 预期用途                          | 包含的 live/提供商覆盖范围                                                                                                                                                    |
+| --------- | --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `minimum` | 最快的发布关键冒烟检查。          | OpenAI/核心 live 路径、OpenAI 的 Docker live 模型、原生 Gateway 网关核心、原生 OpenAI Gateway 网关配置档案、原生 OpenAI 插件，以及 Docker live Gateway 网关 OpenAI。          |
+| `stable`  | 默认发布批准配置档案。            | `minimum` 加上 Anthropic、Google、MiniMax、后端、原生 live 测试工具集、Docker live CLI 后端、Docker ACP 绑定、Docker Codex harness，以及一个 OpenCode Go 冒烟分片。           |
+| `full`    | 广泛的咨询性扫描。                | `stable` 加上咨询性提供商、插件 live 分片，以及媒体 live 分片。                                                                                                               |
+
+## 仅 full 包含的补充项
+
+这些套件会被 `stable` 跳过，并由 `full` 包含：
+
+| 区域                             | 仅 full 覆盖范围                                                              |
+| -------------------------------- | ----------------------------------------------------------------------------- |
+| Docker live 模型                 | OpenCode Go、OpenRouter、xAI、Z.ai 和 Fireworks。                             |
+| Docker live Gateway 网关         | DeepSeek、Fireworks、OpenCode Go、OpenRouter、xAI 和 Z.ai 的咨询性分片。      |
+| 原生 Gateway 网关提供商配置档案  | Fireworks、DeepSeek、完整 OpenCode Go 模型分片、OpenRouter、xAI 和 Z.ai。     |
+| 原生插件 live 分片               | 插件 A-K、L-N、O-Z 其他、Moonshot 和 xAI。                                    |
+| 原生媒体 live 分片               | 音频、Google 音乐、MiniMax 音乐，以及视频组 A-D。                             |
+
+`stable` 包含 `native-live-src-gateway-profiles-opencode-go-smoke`；`full` 则使用更广泛的 OpenCode Go 模型分片。
+
+## 聚焦重跑
+
+使用 `rerun_group` 避免重复运行无关的发布环境：
+
+| 句柄                | 范围                                              |
+| ------------------- | ------------------------------------------------- |
+| `all`               | 所有完整发布验证阶段。                            |
+| `ci`                | 仅手动完整 CI 子项。                              |
+| `plugin-prerelease` | 仅插件预发布子项。                                |
+| `release-checks`    | 所有 OpenClaw 发布检查阶段。                      |
+| `install-smoke`     | 从安装冒烟到发布检查。                            |
+| `cross-os`          | 跨 OS 发布检查。                                  |
+| `live-e2e`          | 仓库/live E2E 和 Docker 发布路径验证。            |
+| `package`           | 包验收。                                          |
+| `qa`                | QA 奇偶性加 QA live 运行线。                      |
+| `qa-parity`         | 仅 QA 奇偶性运行线和报告。                        |
+| `qa-live`           | 仅 QA live Matrix 和 Telegram。                   |
+| `npm-telegram`      | 仅可选的发布后 Telegram E2E。                     |
+
+当一个 live 套件失败时，将 `live_suite_filter` 与 `rerun_group=live-e2e` 搭配使用。有效的过滤器 ID 定义在可复用的 live/E2E 工作流中，包括 `docker-live-models`、`live-gateway-docker`、`live-gateway-anthropic-docker`、`live-gateway-google-docker`、`live-gateway-minimax-docker`、`live-gateway-advisory-docker`、`live-cli-backend-docker`、`live-acp-bind-docker` 和 `live-codex-harness-docker`。
+
+## 需要保留的证据
+
+保留 `Full Release Validation` 摘要作为发布级索引。它链接子运行 ID，并包含最慢作业表。遇到失败时，先检查子工作流，然后重跑上方最小的匹配句柄。
+
+有用的工件：
+
+- 来自 `OpenClaw Release Checks` 的 `release-package-under-test`
+- `.artifacts/docker-tests/` 下的 Docker 发布路径工件
+- 包验收的 `package-under-test` 和 Docker 验收工件
+- 每个 OS 和套件的跨 OS 发布检查工件
+- QA 奇偶性、Matrix 和 Telegram 工件
+
+## 工作流文件
+
+- `.github/workflows/full-release-validation.yml`
+- `.github/workflows/openclaw-release-checks.yml`
+- `.github/workflows/openclaw-live-and-e2e-checks-reusable.yml`
+- `.github/workflows/plugin-prerelease.yml`
+- `.github/workflows/install-smoke.yml`
+- `.github/workflows/openclaw-cross-os-release-checks-reusable.yml`
+- `.github/workflows/package-acceptance.yml`