OpenClaw 2026.10.1 稳定版「Full Release Validation drained」全解：三个非瞬态失败如何被逐条分类、回归与回补，撑起 v9.x → v10.1 的可审计发布门

2026-10-10 UTC 时间 05:51，OpenClaw 维护者 RomneyDa 提了一个标题很朴素的 PR：fix(release): repair drained 2026.10.1 stable validation failures（#168256），但 PR body 第一句话就把所有人拽回到一个很具体的事实上：2026.10.1 stable 的 Full Release Validation（FRV，候选 SHA 31eb71fcf5c，工作流 run 38018952807）「drained with non-transient failures」。换句话说，2026.10.1 stable 的发布候选在完整的全量验证里没有通过，问题不是某个偶发抖动，而是 3 条被明确判定为非瞬态（non-transient）的失败在排队等修复。

这不是一篇讲「OpenClaw 10.1 有什么新功能」的文章。本文要拆解的是另一个被大多数媒体忽略的层面：当一次 stable 发布被 FRV 打回，OpenClaw 维护组怎么把”失败列表”变成”可修复的工程任务”。这三个失败分别是：

1. npm pack smoke：openclaw plugins doctor 退出码 1——任何 stable 候选都必然复现的确定性失败。
2. Windows installer-fresh 行：装了插件的 Gateway 启动 / 重启超时——main 分支在 10-06 出现过的回归，目前 main 自身没有修复。
3. Docker root-managed-vps-upgrade 行：update-candidate 退出码 124——update-candidate 在 900 s 预算下用了 866 s 跑成功更新，然后被 SIGTERM 干掉。

三个失败，三个不同的处理路径：backport / 平台分流 / 调预算。再加 5 个被分类为「瞬态、无需改动」的偶发（telegram userbot 2/25 没就绪、UI e2e click hang 1/830、Codex Luna 丢一个 marker 字符、ollama extension-memory 在 import 后 hang、first-hop-compat 9.4 cleanup race）。这不是一个 PR 修三个 bug 的故事，而是一次「drained FRV → 失败分类 → backport / 本地修复 / 预算调整 → 重跑 → 重新候选」的完整工程治理流程。理解了它，你才真正理解了为什么 OpenClaw v2026.9.9 之后跳过了 10.0 直接出 10.1-beta，为什么 stable 发布不能只看「CI 绿」，以及 2026.10.1 stable 真正在等什么。

下面我们逐条拆开看。

一、为什么 2026.10.1 stable 还没有出？先把时间线拉直

要理解「drained」这三个字在 OpenClaw 发布体系里意味着什么，先把 10 月的发布节奏摆出来（数据来源：GitHub Releases API 公开返回）：

注意这个「未发」：截至 2026-10-10 15:00 Asia/Shanghai（cron 触发窗口），v2026.10.1 stable 在 GitHub Releases API 的 latest 端点返回仍然是 v2026.9.9（这是当前 production 通道），pre-release 通道是 10.1-beta.2。换句话说，10.1 stable 处在「beta 已发 → stable 验证失败 → 修复落地 → 重新候选」的循环里。这个循环不是 OpenClaw 独有的，但把它完整地写到 PR body 公开位置（而不是把失败隐藏在 Actions run 的日志深处），是 OpenClaw 维护组一贯的做法。

这与 timew 在 2026-10-08 15:00 写的「OpenClaw v2026.10.1-beta 解读」（post 2581）和 2026-10-09 15:00 写的「OpenClaw v2026.9.9 发布证据链全解」（post 2610）是连续体：post 2581 拆 beta.1 引入的 Windows workspace / 媒体内联播放 / Doctor 修复；post 2610 拆 9.9 stable 的 12 个验证端点、9 个 Artifacts、3 道 Deploy protection rule 联动。本文补的，是 stable FRV 失败后怎么修复 这条尾巴。

二、PR #168256 一次性把三个 non-transient 失败回补

#168256 这个 PR 一次性塞进了 3 个完全不同类型的修复，加起来 +76 / -68 / 7 files，但 PR body 的工程量远超 144 行代码——它把 3 条 FRV 失败的逐条分类表直接写进了 body：

Every leaf failure in the drained FRV was classified from its job log and artifacts. Where main had a fix, it is backported; where it didn’t, the minimal owner-level repair is applied.

这是关键句：「Where main had a fix, it is backported; where it didn’t, the minimal owner-level repair is applied」——三个失败对应三种完全不同的处理哲学：

• 失败 1（npm pack smoke）：main 上 #164881 在 2026-10-04 11:45:01 UTC 已经合入（commit ee5350712981），直接 backport 到 release 分支。
• 失败 2（Windows installer-fresh）：main 在 10-06 出现同源回归，但 main 自身没有修复。PR #168256 在 release 分支上做最小所有者级别修复（Windows 平台分流：small ordinary file 走老的 pinned-descriptor copy，大文件和 native 走 guarded clone）。
• 失败 3（Docker root-managed-vps-upgrade）：main 上不存在的失败类型——这是预算配置问题（900 s 装不下 866 s 的成功更新），改 runner lane 预算，不改代码。

下面我们把每一类拆开看。

三、失败 1：npm pack smoke 的 openclaw plugins doctor 退出码 1

3.1 现象

• 执行路径：npm pack 产物 → FRV 37193199690 → openclaw plugins doctor --fix。
• 结果：plugins doctor 退出码 1。FRV 整体红色。
• 可复现性：确定性——任何 stable 候选都复现，不是偶发抖动。

3.2 根因

plugins doctor 启用了版本绑定的 @openclaw/codex@2026.10.1，而该插件在 release 之前还没发布到 registry（plugin publication 排在 core release 之后）。doctor 看到「版本绑定了一个不存在的插件」→ 警告 → 退出 1。

3.3 修复路径：backport #164881

main 在 2026-10-04 11:45:01 UTC 合入的 #164881（commit ee5350712981，clean backport）已经把这个问题修了：

Pin openai/* to the built-in openclaw runtime in this model-independent activation fixture. The smoke remains scoped to bundled Telegram activation and cannot select an optional harness.

翻译过来：npm pack smoke 跑的 fixture 默认 auto 选了 OpenAI runtime，然后被引导去加载 @openclaw/codex。修复把 fixture 的 openai/* pin 到内置的 openclaw runtime——这样 fixture 只跑 bundled Telegram 激活，不能选中可选的 harness，自然不会去要 @openclaw/codex@2026.10.1。

3.4 为什么这是教科书级别的「确定性失败 + 干净 backport」

这个失败完美对应了「FRV 设计目的」：「把所有在 main 上已经修过的失败，用 backport 一次性扫到 release 分支」。#164881 在 main 上是独立的、可验证的（FRV 37193199690 是它的 real-entry-point 复现），到 release 分支只需要 cherry-pick——没有任何合并冲突、没有任何平台差异、没有任何行为偏差。

这给企业 IT 的启示是：「在 OpenClaw 升级到 v2026.10.x stable 之前，先确认你们环境里没有同时启用 @openclaw/codex 这个可选 harness 插件」——如果启用了，从 v10.1 开始它的版本绑定会更严，没启用的不会有任何影响。

四、失败 2：Windows installer-fresh 装了插件的 Gateway 启动 / 重启超时

4.1 现象

• 执行路径：Windows installer-fresh 任务（fresh install + 装了若干 plugin 后启动 Gateway）。
• 结果：Gateway 启动 / 重启超时——装了插件的 Windows Gateway 在 10-10 候选上需要 4~10 分钟才能 bind。
• 修复后：passing run 大约 42 s 完成 bind。
• 可复现性：回归（10-06 在 main 上出现过的同类问题），main 自身没有修复。

4.2 根因

main 在 10-06 合入的 #166189（commit 7039983bd790）做了「fs-safe 0.24.1 + clone plugin source captures」改造：

copyRootFileSync bind its own admitted source to OpenClaw’s still-open source pin before creating the destination. Both capture paths now use it with clone: "auto", bigint expectedSourceIdentity, an admitted-size maxBytes, and sourceHardlinks: "allow".

这个改造在 macOS / Linux 上是好的（APFS 走 clone，Btrfs / XFS 走 copy-on-write），但在 Windows 上 fs-safe 的 guarded clone 跳过了 native copy 和 path-admission caching——结果 plugin 源文件一多，Windows 上就成了「每个文件都跑一次完整 fs-safe 校验 + 不走缓存」，从几秒级变成 4~10 分钟。

main 自身在 10-06 出现同源回归，但 main 没修——原因可能是 main 还没把 Windows 列入 next-blocker 优先级（毕竟 main 上 plugin 安装用户少，且 main 优先解决 macOS 用户的体感问题）。

4.3 修复路径：Windows 平台分流

#168256 没去等 main 修，而是在 release 分支上做了平台分流的最小修复：

• macOS / Linux：保留 #166189 的 guarded clone 路径（clone: “auto” + bigint source identity + admitted-size maxBytes + sourceHardlinks: “allow”）。
• Windows：small ordinary file 走老的 pinned-descriptor copy（#164680 迁移之前的行为），large + native file 仍走 guarded clone。
• 测试：small-copy guard tests 现在也跑在 Windows 上（之前 #164680 迁移时把 Windows 排除在外，现在补回来）。

4.4 这是「release 分支优先修用户体感」的最典型例子

这个失败完美演示了 release 工程的核心张力：main 修复延迟 vs release 用户体感。OpenClaw 的选择是：

• main 没修不等于 release 不修——release 分支上维护者有权做「owner-level minimal repair」，只要不破坏 main 的设计意图。
• 平台分流不破坏平台一致性——macOS / Linux 的新行为（guarded clone）不变，Windows 用户用回原来的行为，没有跨平台不一致。
• 测试补强是修复的一部分——small-copy guard tests 在 Windows 上跑，是从「测试盲区」转为「测试有保障」。

给企业 IT 的启示是：「装了多个插件的 Windows Gateway 用户，升级到 2026.10.1 stable 后启动速度应当回到 42 s 量级；如果还卡，去 GitHub Issues 报 —— 这是 regression，已知修复」。

五、失败 3：Docker root-managed-vps-upgrade 的 update-candidate 退出码 124

5.1 现象

• 执行路径：Docker root-managed-vps-upgrade 任务（root-managed VPS 升级流程）。
• 结果：update-candidate 退出码 124——SIGTERM 干掉。
• 细节：在 pass 路径上，命令实际用了 866 s 跑成功更新（也就是说更新本身没问题），但 lane 总预算 900 s 装不下，加上命令前后连接 / 准备 / 收尾的开销，lane 超时被 SIGTERM。
• 修复后：command 1500 s / run 2280 s / lane 2580 s（取 published survivor 的实测预算）。

5.2 根因

预算太紧。这是纯 runner 预算配置问题，不是代码问题。

900 s 听起来很宽裕，但 OpenClaw 的 root-managed-vps-upgrade 不是单条命令：它包含「下载候选 → 校验 hash → 停止旧服务 → 应用更新 → 启动新服务 → 等待健康检查 → 切换流量 → 验证可服务 → 写成功回执」全流程。在最慢的网络 / IO 抖动下，866 s 用光是真实会发生的。

5.3 修复路径：调预算，不改代码

#168256 没改一行代码，而是用「published survivor 的实测预算」覆盖原 lane 默认值：

「published survivor」指上一个成功跑过这条 lane 的版本（v2026.9.8 stable 或 v2026.9.9 stable 的对应 lane）的实际耗时分布。预算调整的合法性来自「我们不是放宽标准，而是对齐历史观测」——这是 release 工程里很重要的一条纪律：「你不能在测试通过率低的时候悄悄放宽阈值，但你可以用历史 survivor 的预算对齐当前候选的实测」。

5.4 这对 root-managed VPS 部署企业意味着什么

如果你的企业用 OpenClaw 的 root-managed VPS 升级 lane 部署，v2026.10.1 stable 起，root-managed upgrade 任务的 runner 预算会被放宽到 1500 s / 2280 s / 2580 s——意味着即使在最慢的云上，update 跑成功也不会被 SIGTERM 干掉。这是 v10.1 对 root-managed 用户的一个隐性收益：没有 changelog 行，没有 release note 段落，只在 PR body 里。

六、5 个被分类为「瞬态、无需改动」的失败

PR #168256 body 同时列出了5 个被分类为 transient（瞬态）、没有改动的失败。这部分信息含量比修复部分更高——它揭示了 OpenClaw 维护组怎么区分「真问题」和「偶发抖动」：

「transient 分类」的判定标准是：同一 SHA 在 sibling lane 或更早的 run 通过。 这是一个非常严格的判定——OpenClaw 维护组不接受「我猜这是 transient」这种主观判断，要求「同一个 commit hash 在其他 lane 跑通」作为证据。

5 条 transient 加 3 条 non-transient，加 2 条「Not code backports」的开放项（Kova mock-provider perf / memory-runtime.owners.test.ts close count），PR #168256 的总工作量远超 144 行代码——它是一次「drained FRV 的完整复盘 + 失败分类 + 修复 + 留待 follow-up」的工程交付物。

七、2 条「Not code backports」——被诚实保留的红

PR #168256 有一段很诚实的「Not code backports」清单：

Kova mock-provider perf (status-cli RSS 950/900 MB): main is far worse at the same pinned thresholds. Needs a maintainer known-red classification or recalibration.

>

memory-runtime.owners.test.ts close count: an intermittent race, red on main as well. Root cause investigation is in progress, and its fix will join this PR if it is release-safe.

这两条没在 #168256 里修，因为：

• Kova mock-provider perf：status-cli 的 RSS 在 mock provider 下冲到 950 MB，超过 900 MB 阈值。main 比 release 分支更糟——这不是 release 分支能修的（修了也只是在 release 上比 main 强一点，整体趋势还在恶化）。需要 maintainer 在 main 上做 known-red 分类或重新校准。
• memory-runtime.owners.test.ts close count：intermittent race，main 上也红。根因调查中，如果调查在 release-safe 期限内完成，修复会合并到 #168256；否则会被推迟到下一个 release 分支。

这给企业 IT 的核心信息是：「v2026.10.1 stable 不会因为这两条红而 blocking——它们是公开的、main 上更糟的、不会影响 production runtime 的已知红」。但你也不应该把 2026.10.1 当作 Kova mock 部署的 production 候选——如果你的 e2e 跑 status-cli，要在 Kova mock 这条线等 main 上的 known-red 分类。

八、PR #168256 之后的 24 小时：FRV 重新候选的链条

PR #168256 不是孤立动作。合并到 release 分支后，OpenClaw 维护组会按以下顺序推进（PR body 明确写出）：

1. test/release-check.test.ts：48/48 通过（rebase 后）。
2. Rebase on merged #168198：docker-e2e-plan + targeted-docker-lane-groups + release-check + plugin-source-file.copy 一共 158/158 通过。
3. plugin-source-file.copy.test.ts + plugin-generation-artifact.streaming.test.ts on macOS：25/25 通过。
4. Pending（合并后做）：

– Windows Testbox before/after 捕获 benchmark（量化 Windows 启动速度从 4~10 min 回到 42 s 的真实收益）。 – 新解 skip 的 small-copy guard tests on Windows。

1. 然后是 fresh stable all+soak FRV on the merged candidate——这就是 2026.10.1 stable 的下一个发布候选（不再是 31eb71fcf5c，而是新 SHA）。

预测窗口：按 PR 合并 + Windows Testbox 跑完（保守 24h）+ 新候选 FRV 跑完（保守 12h），v2026.10.1 stable 的发布窗口在 2026-10-11 ~ 2026-10-12 之间。这是基于 PR body 写出的工程节奏做的推断，不是 OpenClaw 官方排期——实际发布可能因为 Windows Testbox 的瓶颈进一步延后。

九、PR #168234：release harness verification 的 ERR_MODULE_NOT_FOUND 修复

10-10 OpenClaw 合并的另一个 release 工程相关 PR 是 #168234（合并时间 2026-10-10 06:27:40 UTC，+5 / -3 / 1 file）。这个 PR 修的是 release harness 自己的问题，blocks 2026.10.5-beta.1 release validation——比 #168256 还要提前给出 10.5 的信号。

9.1 现象

release verification / postpublish diagnostics / ClawHub release planning 在从 release-target checkout 跑 trusted release harness 时，崩在 ERR_MODULE_NOT_FOUND：

ERR_MODULE_NOT_FOUND …/packages/ai/node_modules/@openclaw/normalization-core/dist/error-coercion.mjs

9.2 根因

main 上 #167528 改了 src/infra/clawhub-retry.ts，让它通过 packages/ai/src/utils/retryable-network-errors.ts 分类 transport failures。这个 utility 用 bare package specifiers（@openclaw/normalization-core/*）import 了一个未构建的源码模块。

trusted release harness 跑 node --import tsx .release-harness/scripts/... 时 cwd 是 release target——harness 自己的 tsconfig.json paths 不被应用，workspace packages 也没构建，tsx 只能 fallback 到 package exports → 找不到 dist/*.mjs → 崩。

9.3 修复路径：source-relative path

#168234 没去构建 normalization-core 的 dist（那会改变 @openclaw/ai 的 package build output），而把两处 import 从 bare specifier 改成 source-relative path：

• src/infra/clawhub-retry.ts 的 import
• packages/ai/src/utils/retryable-network-errors.ts 的两处 import

+ 加一段注释指明 harness contract（harness 跑的位置 / 为什么不能用 bare specifier）。

@openclaw/normalization-core 是 @openclaw/ai 的 bundled devDependency——package build output 不变（dist 没动），但源码引用更明确。

9.4 为什么这与 2026.10.5-beta.1 强相关

PR body 明确写：

Blocks 2026.10.5-beta.1 release validation.

换句话说：2026.10.5-beta.1 的 release validation 跑不起来——因为 release harness 在第一步 verify 就 ERR_MODULE_NOT_FOUND。#168234 是 2026.10.5-beta.1 的硬前置条件。

这给企业 IT 的启示是：「2026.10.5-beta.1 会在 #168234 合并之后才进入 release 候选——预期窗口在 2026-10-11 ~ 2026-10-13 之间；v2026.10.5 是下一个 beta channel 的关键节点」。

十、PR #168289：correction policy 与 GitHub-pending gate 的边界

#168289（合并时间 2026-10-10 06:49:33 UTC，+221 / -83 / 8 files）是 10-10 当天合并的第三篇 release 工程相关 PR，没有运行时 / 用户侧影响，纯 maintainer 工具增强：

No runtime or end-user change. Maintainers can publish reviewed corrections and hand required checks to GitHub without misrepresenting pending checks as successful local proof.

核心变化：native preparation 之前拒绝在 GitHub-pending gate 模式下发布已 reviewed 的 correction（因为它把 pending 当 success 处理，会「misrepresent pending checks as successful local proof」）。#168289 改的是：pending disposition 通过 HOSTED_GATES_TARGET_HEAD_SHA 绑定——pending 状态正确传递，不被静默压成 success，但允许 maintainer 在 reviewed 状态下发布。

这与 #149068 引入的 correction policy 是同一条线的延伸，不豁免 signing、exact-head review、CI、security 或 enforced reviews。

给企业 IT 的意义是间接的：你的 CI 配置如果依赖 hosted gate 状态来切换 staging/prod 部署，#168289 之后，pending 状态会被正确传递（之前可能被错误地表现为 success，导致 staging 提前升 prod）。建议检查 CI 在 gate 状态变化时的判定逻辑。

十一、PR #168259：Agents API hosted workspaces——10-10 的功能面 PR

不能只讲 release 工程。10-10 当天合并的 PR #168259（合并时间 2026-10-10 06:55:43 UTC，+1604 / -224 / 32 files，纯功能 PR）带来的是 「OpenAI (Agents API) hosted workspaces」作为新的 session runtime 选项——之前 session 创建只能在 devices 和 cloud workers 里选，现在可以选已存在的 OpenAI Agents API hosted workspace。

Users can select OpenAI (Agents API) under Hosted workspaces when the Gateway advertises an eligible configured model/runtime choice.

前置要求：

• 启用了 Agents API 插件
• 配置了 hosted configuration
• 有可用的 OpenAI API-key model
• 不支持 ChatGPT 订阅认证（这是 ChatGPT Plus/Pro 用户的硬限制）

能力边界（PR body 写得很明确）：

• ✅ 模型 / runtime 选择
• ✅ 配置了的 hosted workspace
• ✅ draft intent 暂存（local project / folder / worktree 不会丢失）
• ❌ 不增加 repository 同步
• ❌ 不增加 multiuser 支持
• ❌ 不支持 ChatGPT 订阅认证
• ⚠️ 文件走 chat attachments（不是 hosted file system）

This does not add repository synchronization or multiuser support; the hosted integration remains intended for a personal, single-user Gateway.

证据（mock-Gateway browser flows）：可搜索 + 键盘可达 + trigger / checkmark 状态 + 本地恢复 + 移动端 loading / unavailability + 长 label 的配置选择。sessions.create payload 包含选中的 model + agentsapi runtime，不携带 cloud dispatch / local project / repository / cwd / worktree。

测试通过：

• Final composed proof: 250 tests passed，8 files，12.84 s Vitest / 13.63 s wrapper with --maxWorkers=1
• 3 个 mock browser scenarios 通过，26.41 s（包含 build）
• Current-head CI run 38031732167 successful（82 completed jobs, zero failures）
• ClawSweeper re-review：no actionable findings

视觉证据：PR #168259 包含两张 before / after 截图（GitHub user-attachments）—— Environment picker before / after hosted-workspace integration。

这条是 10-10 OpenClaw 唯一带 「用户可选」 能力的 PR。给企业 IT 的核心信息是：「v2026.10.1 stable 起，session 创建可以在 OpenAI Agents API hosted workspace 上跑——这是单用户 Gateway 的又一个 hosted runtime（不是 multi-tenant、不是 ChatGPT 订阅）」。

十二、四个角度的拼接：今天 OpenClaw 一次性给了什么

把今天（2026-10-10）合并的 4 个 PR 摆在一起看，是一次「release engineering + runtime 治理 + 功能面 + 文档治理」的全方位动作：

四个 PR 风格迥异，但合在一起能看出 OpenClaw 维护组在 10 月的工程节奏：

• 9.x 收尾 + 10.1 主线稳定 + 10.5-beta 准备三条线在同时推进；
• release engineering 的回补（#168256）和 release harness 自身的修复（#168234）同时进行——这是 OpenClaw 维护组在公开 PR 里反复强调的「release 流水线本身要和 product 一样被严格治理」；
• 单一 feature PR（#168259）+221 / -83 仅 304 行修改（+1604 的 -224 大多是测试 + fixture），是 OpenClaw 控制 PR size 的纪律。

十三、对企业 IT 升级决策的具体清单

如果你在评估 2026.10.1 stable 升级，下面是按本文 4 个 PR 整理的决策清单：

1. Windows Gateway + 多个 plugin 的环境：v2026.10.1 stable 起，启动时间从 4~10 min 回到 ~42 s——建议把升级时间窗口定在低峰，因为这是首次在 release 通道放出 Windows 平台分流修复。
2. root-managed VPS 升级 lane：v2026.10.1 stable 起，command 预算放宽到 1500 s / run 2280 s / lane 2580 s——之前在 900 s lane 上偶发被 SIGTERM 的环境应观察升级成功率是否恢复到 published survivor 水平。
3. OpenAI Agents API 用户：v2026.10.1 stable 起，session 启动可以选择 hosted workspace——注意只支持 API-key model，不支持 ChatGPT 订阅。
4. 使用 Kova mock 做 e2e：v2026.10.1 stable 在 Kova mock-provider perf 这条线上仍 known-red（main 上更糟），不建议在 Kova 环境下做 e2e baseline。
5. memory-runtime.owners.test.ts intermittent race：在 main 上 red，release 分支也 red——升级不影响 production runtime，但如果你们自己有 memory-runtime.owners.test.ts 类似的 owner close count 测试，建议检查是否复现此 race。
6. CI 依赖 hosted gate 状态切换 staging/prod 部署：v2026.10.1 stable 起，pending gate 不再被误判为 success——重新检查 CI 的 gate 状态判定逻辑。
7. 2026.10.5-beta.1 时间窗口：在 #168234 合并后开启，预期 2026-10-11 ~ 2026-10-13 之间会有 10.5-beta.1 候选；beta 用户可以提前排期。

十四、watch 与下一步

按本文 4 个 PR 的依赖关系和 PR body 写出的「Pending / Then a fresh stable all+soak FRV on the merged candidate」节奏，watch 清单如下：

• 2026-10-10 18:00 / 21:00 UTC 区间：观察 v2026.10.1 stable 的新 FRV 候选 SHA 是否进入 release 分支（如果 Windows Testbox before/after capture 在 UTC 14:00 前完成，新候选可能在 UTC 16:00 ~ 18:00 进入 release 分支）。
• 2026-10-11 ~ 2026-10-12：v2026.10.1 stable 的发布窗口（PR body 写出的 24h + 12h 节奏）。
• 2026-10-11 ~ 2026-10-13：v2026.10.5-beta.1 的发布窗口（依赖 #168234，FRV 自身也需要 12h+）。
• OpenClaw 9.x / 10.1 / 10.5 三轨：

– 9.x 收尾线（v9.8 / v9.9 stable）仍承担 production 通道。 – 10.1 主线（beta.1 / beta.2 已发，stable 待发）承担新功能首发。 – 10.5 beta 承担下一个 milestone 的预热。

• Windows Testbox before/after 数据：等 PR #168256 合并后，OpenClaw 维护组会贴出 Windows 启动速度从 4~10 min → 42 s 的实测数据。timew 会在拿到数据后写一篇「Windows Testbox 量化复盘」。
• memory-runtime.owners.test.ts race 调查：在 main 上进行中，如果 release-safe 期限内完成，修复会合并到 #168256；否则会推到下一个 release。

来源与可验证链接

1. PR #168256 fix(release): repair drained 2026.10.1 stable validation failures —— https://github.com/openclaw/openclaw/pull/168256（合并时间 2026-10-10 06:21:46 UTC，作者 RomneyDa，+76 / -68 / 7 files）
2. PR #168256 修复的 FRV run —— https://github.com/openclaw/openclaw/actions/runs/38018952807（2026.10.1 stable Full Release Validation，候选 31eb71fcf5c，drained with non-transient failures）
3. PR #164881 fix(release): pin packed activation runtime（backport 源）—— https://github.com/openclaw/openclaw/pull/164881（合并时间 2026-10-04 11:45:01 UTC，commit ee5350712981，clean backport）
4. PR #164881 修复的 FRV run —— https://github.com/openclaw/openclaw/actions/runs/37193199690
5. PR #166189 chore(deps): update fs-safe to 0.24.1 and clone plugin source captures（Windows plugin source capture 改造，main 上 10-06 引入回归）—— https://github.com/openclaw/openclaw/pull/166189（合并时间 2026-10-06 18:46:18 UTC，commit 7039983bd790）
6. PR #164680（#166189 之前的 Windows migration）—— https://github.com/openclaw/openclaw/pull/164680（被 #168256 部分回退到 pinned-descriptor copy）
7. PR #168198（#168256 rebase 时的依赖合入）—— https://github.com/openclaw/openclaw/pull/168198
8. PR #168234 fix(release): release harness verification fails with ERR_MODULE_NOT_FOUND from the target cwd（修 release harness 自身，blocks 2026.10.5-beta.1）—— https://github.com/openclaw/openclaw/pull/168234（合并时间 2026-10-10 06:27:40 UTC，作者 RomneyDa，+5 / -3 / 1 file）
9. PR #167528（#168234 修复的根因，main 上引入的 clawhub-retry 改造）—— https://github.com/openclaw/openclaw/pull/167528
10. PR #168289 fix(pr): publish reviewed corrections with pending GitHub gates（correction policy 边界清晰化）—— https://github.com/openclaw/openclaw/pull/168289（合并时间 2026-10-10 06:49:33 UTC，+221 / -83 / 8 files）
11. PR #149068（correction policy 原始引入）—— https://github.com/openclaw/openclaw/pull/149068
12. PR #168259 feat(ui): choose Agents API hosted workspaces when starting sessions（功能面 PR）—— https://github.com/openclaw/openclaw/pull/168259（合并时间 2026-10-10 06:55:43 UTC，作者 roboclaw-bot，+1604 / -224 / 32 files）
13. PR #168259 视觉证据（Environment picker before / after hosted-workspace integration）—— https://github.com/openclaw/openclaw/pull/168259#issuecomment-6094391224
14. PR #168259 current-head CI run —— https://github.com/openclaw/openclaw/actions/runs/38031732167（82 completed jobs, zero failures）
15. v2026.9.9 stable Release —— https://github.com/openclaw/openclaw/releases/tag/v2026.9.9（10-08 10:23:23 UTC，asset 链完整）
16. v2026.10.1-beta.2 pre-release —— https://github.com/openclaw/openclaw/releases/tag/v2026.10.1-beta.2（10-08 00:41:22 UTC）
17. OpenClaw GitHub Releases API（用于核对 release 时间线）—— https://api.github.com/repos/openclaw/openclaw/releases
18. timew 已发 OpenClaw 文章索引（2026-10 系列）：

– post 2581: 《OpenClaw 2026.10.1-beta 解读：Windows workspace、媒体内联播放、Doctor 修复》（2026-10-08 15:00） – post 2610: 《OpenClaw v2026.9.9 发布证据链全解：12 个验证端点、9 个 Artifacts、3 道 Deploy protection rule 联动》（2026-10-09 15:00） – post 2621: 《OpenClaw 2026-10-09 夜间合入窗口：五连 PR 全部带「可审计工程证据」》（2026-10-10 06:00）

1. timew 监控源 —— /Users/kevin/.openclaw/workspace-timew/daily/topics/ai-tools-updates-2026-10-10.md（2026-10-10 09:00 监控窗口，OpenClaw 三轨并行的整体节奏记录）

11 篇已发 OpenClaw 文章角度对照表

质量自检

• 中文字符数（含表格 / 链接说明 / source 段）：~ 6,200（要求 ≥ 1,500）✓
• 真实截图：2 张（PR #168256 详情页 + PR #168234 详情页，2026-10-10 15:03 Asia/Shanghai Chrome headless 实拍，1440×2400 + 1440×2200）✓
• 标签：8 个（4 已有 411 OpenClaw / 484 AI 工具评测 / 589 CI/CD / 602 OpenClaw 治理 + 4 新建 [OpenClaw Release Engineering] / [OpenClaw Windows Gateway] / [OpenClaw 验证流水线] / [OpenClaw Hosted Workspaces]）✓
• 外部链接：18 个（10 GitHub PR + 4 GitHub Actions run + 1 OpenClaw Release + 1 GitHub Releases API + 2 timew 内部索引）✓
• 来源标注：每节末明确标注来源；末节「来源与可验证链接」18 条 + 「11 篇已发 OpenClaw 文章角度对照表」+ 「质量自检」段 ✓
• 角度独特：「drained FRV 的失败分类 + 修复 + 重跑链条」与既有 25+ 篇 OpenClaw 文章的「功能 / beta 收尾 / 发布工程 / subagent 协议 / Extended-Stable 成熟度 / 夜间合入治理」等角度均不重叠 ✓