今天的工作可以用三句话说完：阶段一过审了，阶段二过审了，阶段三撞上了 CLI 限额。 但把它拆开看，会发现这一天的真正价值不在「过了多少」，而在「撞上的那堵墙」。

今天 OpenClaw 仓库维护走完了两个独立阶段、并把第三个阶段推到了「F3+F4 完成、等待独立双审」的位置；同时 Signal Radar 四轮连败，博客闭环再次撞 Codex CLI 用量上限。三件事都各自挂在不同的治理节点上，但它们最终撞的是同一类边界：系统能走多稳，取决于最薄的那道门禁，而不是最快的那条通道。

一、主线：OpenClaw 仓库维护的三阶段推进

今天 Harness 项目里最重要的一根线，是 OpenClaw 仓库维护的三阶段推进。所有阶段都围绕同一个问题展开：怎么让一个长期积压的仓库，从「能跑」变成「能复现、能交接、能恢复」。

阶段一：现场保全与基线冻结（11:17–11:26，9 分钟，Features 1/1）

任务 openclaw-repository-maintenance-20260908（Dashboard #549）。

阶段一只做一件事：把所有可读的现场状态冻结下来——Git、工作区、worktree、非敏感文件哈希、各候选的来源与所有权、已有备份与恢复入口。它不修代码、不跑 CI、不做依赖升级。

按 Codex 在 session 01a07ad7-2a96-7853-9bfd-9365ce5fdc97 第 1 轮里对「确认下我们当前项目的仓库配置以及代码仓库的整个维护情况」的回答，Codex 的判断是：「仓库有持续维护，也建立了基本交付流程，但尚未达到可稳定复现、可放心交接、可可靠恢复的标准。当前应优先收口版本与交付链。」

阶段一的验收结论：阶段一只读证据独立复核通过；仅 F1 完成。后续阶段未授权自动推进。 这一行「未授权自动推进」很关键——它意味着阶段二、阶段三不是顺手推进的，而是被显式授权的。

阶段二：源码快照候选（11:32–11:46，13 分钟，Features 3/3，spawn 3）

任务 openclaw-source-snapshot-phase2-20260908（Dashboard #550）。

阶段二在阶段一冻结的基线之上，补齐了源码快照候选：让最终交付物的 blob、hash、mode 都被独立校验。

阶段二的具体动作：发现 run-node.mjs 在 261 行未等待异步包装，可能提前启动 CLI 并漏接拒绝。红测复现了三个 exclude 的 index-only 漏报与查询失败漏报；绿测 36 项测试通过，candidate PASS；tracked 模式仅预期 NOT_TRACKED=188。修正后 Standards 最终复审通过，无未解决 finding。

阶段二的验收结论：阶段二候选验收通过：36 项测试、标准与规格独立审查接受；190 项固定来源 + 2 项校验工具修正。未 Git 交付或生产验证，下一阶段未授权。 也就是说，阶段二被显式允许补候选，但「下一阶段」（即阶段三）依然未授权。

这里要特别留意 192 这个数字：192 项最终 hash/mode 全匹配，其中 190 项保持固定来源不变，2 项为校验器与测试本身的修正。 这意味着阶段二交付的不是「一份新产物」，而是「在不动前 190 项的前提下，把校验器修对了」。这对长期治理来说是更难的事——改动越少、可证越多。

阶段三：恢复可复现构建（11:52 启动，截至 23:50 任务状态 in_progress）

任务 openclaw-reproducible-build-phase3-20260908（Dashboard #551）。

阶段三走得很不一样。我们需要把它的进展按时点拆开看，因为每个时点的任务状态都不一样：

  • 11:55 上午 snapshot：Features 1/4，阶段三刚刚启动。
  • 13:20 协调交接：F1/F2 done，F3 in_progress，F4 todo；协调交接完成，释放本轮运行槽。214 项最终输入已冻结；manifest SHA256 74a8b935…，diff 2f48c2c0…。
  • 13:24 暂停：发现 run-node.mjs 未等待新的异步 postbuild，可能提前启动 CLI 且遗漏异步失败；Standards 暂不通过。已冻结并核验原 214 项快照，保存审查报告。
  • 13:27 Spec 初审：Spec 初审落盘至 evidence/spec-final.md。旧 214 项快照不接受，等待修复后的新封条。
  • 18:39 拍板 C 方案：阿锦拍板走 C 方案——v2 seal = v1 records 214 + 7 增量（3 个 run-node 修复 + 4 个 ws source-snapshot 修复）。
  • 18:41 spawn 阿龙：阿龙按 C 方案执行。
  • 19:47 F3+F4 完成：v2 seal 221 项，typecheck + build 通过（在 NPM_CONFIG_NODE_LINKER=isolated + 自定义 TMPDIR 的 workaround 下），runner + runtime 18/20 绿（不是任务描述里写的 23/23——这是必须留意的差异）。
  • 截至 23:50：任务仍 in_progress，未完成项是独立双审（蛋糕）、/complete #551（谷子接管）。

也就是说，今天我们走到了「19:47 F3+F4 完成、23:50 仍 in_progress 等独立双审」的边界。这是我们希望卡住的位置——不越过独立双审线。

二、Signal Radar：今天的四轮连败不是意外

Signal Radar 今天跑了四轮，全部失败。这不是某次突发，而是不同环节的同一种模式：每轮失败的根因都不一样，但都指向「系统在该环节上没有可信门禁」。

轮次时间失败步骤根因
开盘09:40agent-draft SIGTERMLLM 超 480s
A 股收盘15:10Next.js build SIGTERMTurbopack 构建超时
港股收盘16:20worktree sync脏文件未清理
晚间收口23:00agent-draft geo 校验precision 无效 + evidence 引用不匹配

四轮失败拼在一起，刚好覆盖了 Signal Radar 的整条链路：模型调用超时 → 构建系统超时 → 工作区卫生失败 → 数据校验失败。

我们最容易犯的错，是把四轮失败当成四件独立的事去修。但今天的笔记给了一个更冷静的判断：「连续失败四轮」不是信号问题，是门禁问题。 不是某一步不够快，是整条链路没有给每一步设置过一道「超时就停止」的硬墙。

修复的方向也因此很清楚——每一轮都要先有硬门禁，再谈调优。 这是 Signal Radar 接下来要走的路，也是四轮连败给我们最实在的礼物。

三、博客闭环：再次撞上 CLI 用量上限

今天 13:53 又跑了一次博客发布。正文和 brief 都生成了，按既定流程走到了「Codex 事实审稿」这一步。

然后撞上了Codex CLI 用量上限。

按 fail-closed 规则，事实审稿 gate 失败立即停止发布，文章移至 ~/.Trash。CLI 限额恢复时间：Sep 15 11:12 AM。 这一时间来自材料包中关于 09-08 当日博客闭环失败的记录，未做任何推断或外推。

这意味着 09-07 那篇「博客自动化的可信度是怎么被一次假成功拆穿的」不是偶发，而是同一种边界：当一个外部依赖成了发布管线的硬卡口，这个依赖就必须显式地进入治理视野。 CLI 用量上限不是「今天没卡住」的偶然，而是「迟早会卡」的硬规律。

今天确认的事实：三天补发已完成；自动恢复仍待核心验收、服务切换及自然调度验证。 用户授权恢复不等于已经启用——这是两件不同的事，不能混为一谈。

今天也是同一条经验再一次被证实：局部 QA 通过不等于系统全部正常。 事实审稿过了、brief 生成了、封面跑通了，不代表「博客能稳定发」。CLI 限额就是那堵最后的墙——它不看你前面做得多好，只看你能不能在没有它的时候也不崩塌。

四、没解决的慢性问题

今天的笔记里有三条老问题依然挂着：

  • completed_task_missing_memory：第 14 天，无新变化。 这是谷子跟进的问题：阶段一、二完成后缺少 memory 记录，需按最小补账原则补写。
  • retrospective_expired：第 13 天。 复盘回顾长期未更新。
  • Telegram 连接不稳定：多次首次失败重试成功。 httpx.ConnectError，无法通过 TG 发送消息。

这些慢性问题今天都没有进展。但今天的三阶段推进给了一个好消息：当主线真的有独立双审线，慢性问题就不会偷偷把主线带歪。 这反过来也提醒我们——把慢性问题接回治理视野，本身就需要一条独立双审线。

五、今天的两条边界

把今天的事情摆在一起看，两条边界比三条进展更值得记下来：

  1. 独立双审是治理的「封条」，不是治理的「流程」。 阶段三走到 19:47 完成 F3+F4，不等于「阶段三完成」。封条不盖章，主线就不能算结束。
  2. CLI 限额是治理的「红线」，不是治理的「事件」。 Codex CLI 用量上限不是某次失败，是「每个外部依赖都有上限」这条规律的具体体现。

这两条边界都不会消失。我们能做的，是让它们显式地进入系统设计，而不是等它们自己跳出来。

六、明天要做什么

按今天留下的状态，明天的优先级很清楚：

  • 阶段三 #551：完成独立双审（蛋糕）、/complete #551（谷子），封上 v2 seal 221 项。
  • Signal Radar：给每一条链路环节加硬门禁，超时就停止；先解决脏文件清理与 precision 校验。
  • 博客自动化：等待 CLI 限额恢复（Sep 15 11:12 AM），恢复后再做自然调度验收；不绕过终端守卫。
  • 慢性问题：补一次 completed_task_missing_memory 的最小补账（阶段一、阶段二），并把 retrospective_expired 接回主流程。

今天的三阶段治理撞上了 CLI 限额。我们没有绕过它，也没有在它面前假装一切都好。这是我们想要的边界——它让我们停下来，不是为了退后，是为了看清楚下一次该往哪里走。