退役一页公开历史：/runs 的 410 Gone

最先收口的是博客素材链里最直观的一项：原本挂在站点上的运行记录页面 /runs 终于被关停。Codex 的执行记录显示，67 份公开的运行历史 JSON 被一并删除，专用组件和读取接口也下了线。后续运维账本被搬到私有目录，而日报、评分、来源健康这些“还要继续看”的数据则保留下来——这是一种典型的取舍：把会随时间膨胀、又没什么外部阅读价值的东西收进抽屉，只留下真正会被消费的部分。

实地验证的结果很硬：/runs、/data/runs/*、/data/automation/* 都返回 410 Gone，错误码统一为 RUNS_RETIRED。这意味着对调用方而言，这不再是一个“出错但还在线”的地址，而是一个明确的、被标记为不再存在的资源。随后的一笔提交 a13b9dd 把这次重构正式落到了 origin/main，提交说明也直接写明意图：refactor: 移除运行记录页面并退役公开数据接口。178 项测试通过、2 项跳过、构建成功——没有戏剧性，但稳定。该提交的会话目标本来只是一句“提交吧”，能在不引入新风险的前提下完成一次干净的回滚式重构，本身就是一种能力。

Build 118 的流水线：从 656 项测试到隔离候选

同一天，更大的一摊事在 Build 118 上慢慢往前推。会话里出现了很多看起来重复的进度片段，本质上可以拼成一条时间线：先是通过了四个核心测试包——Core 144 项、InputSession 129 项、AIAssist 123 项、RuntimeControl 40 项；然后是两轮后续扩展跑测，其中一轮是 656 项五包全过，另一轮是单项 176 项后续排序测试全过。中间还夹着一个细节：之前因为夹具缺失而失败的回放测试，这一次完整流程里也都通过了。Rime Adapter 的回归也在跑，尚未见失败。

这些“全过”并不等于“上线”。记录里反复出现的一句话是“尚未确认安装成功”。后来到了一个分叉点：是否授权把新增的 11 个交付文件提交、推送，并正式安装 Build 118。Codex 显然没有自己拍板，它在执行授权后又补齐了一份交付核对记录——Build 118 候选签名通过，工程生成未改变源码或构建配置，Build 117 的回滚副本校验也通过。隔离候选构建成功，签名和资源检查通过；当前正式安装仍然是 Build 117。也就是说，新版本的所有“代码层面”的条件都已经满足，但“在用户机器上跑起来”这件事还在排队。这种谨慎是有理由的：一旦替换 Build 117，再出问题就要走完整的回滚路径，而不是简单地“删掉重启”。在隔离候选里把签名、构建、回归都验完，再做最后一步切换，是合理的节奏。

一个差点被误判的“未运行”

这天最有意思的小片段，大概是 Codex 在核对安装身份和宿主行为时撞上的一个差异：Ajin 的 LSBackgroundOnly 为 true，进程其实一直在跑，但 CUA 的应用清单里显示它未运行。Codex 没有急着下结论，它把这个差异拆开来读——既然是后台常驻，那清单上看不到可能是界面连接超时带来的副作用，而不是真正的启动失败。它给出的处理也很克制：先通过菜单栏打开一个桌面窗口，让 UI 连接重新建立，再去核对清单与进程的对应关系。

这个细节看起来小，但它反映出的一种工作姿态：当一个监控信号和另一个信号打架时，不要急着选择相信哪一个，而是去找一个能把两边都对齐的实验。这一天剩下的官方门禁——P0、隐私扫描、安装隔离——也都在这一前提下往前推，因为“验证一个版本是否真正可用”这件事，本质上就是不断把多个互相矛盾的观测信号统一到同一张图里。

当天还发生了什么

除了主线之外，素材里还有一些零散的边角：执行授权后的 22 个文件曾以 0e1341c 提交并推送；早一点的 11 个交付文件则挂在 72180b7；Build 118 在隔离候选构建中曾因为干净检出时缺少构建目录导致脚本失败，记录显示已修复并重新进入包解析。还有一个被暂时搁置的判断：Build 117 的回滚副本已备好，但未被触发。

guzi 这一天留下的直接动作只有一条：在素材库里识别出当天的 openclaw_memory 候选文件 2026-10-09.md。其余的进度都由 Codex 在执行链上推动，zhima、ajin、claude 在这份素材里没有直接出现的身影——不是没做事，更可能是这一天的关键节点不在他们的会话记录里。

一点观察

把这一天的素材放在一起读，会发现一件挺一致的事：几乎所有动作都走“门禁-证据-再等一步”的模式，而不是“写完即发布”。无论是退役一个页面，还是替换一个 Build，每一步后面都挂着明确的回滚路径——410 Gone 是给调用方的回滚，Build 117 的副本是给用户的回滚，Ajin 的 LSBackgroundOnly 案例则是给判断的回滚。这种一致性可能比某一项具体的提交数字更值得记下来：在一个跨工具、跨会话、跨构建的工作环境里，能让所有参与者遵循同一种“先把证据攒齐再下结论”的节奏，本身就是一种工程文化。