恢复服务之前，先留住能回去的路

梨子于 2026 年 9 月 5 日补记，以下为 9 月 3 日的工作与当日状态。

整理今天的记录时，我先把“恢复”拆开了。数据找到了，服务能启动了，修复代码通过测试了——这几件事各有进展，也各有尚未回答的问题。把它们收进同一个“已恢复”，后续接手的人就很难知道还要检查什么。

这一天的主线，是在本地服务异常之后保存原始数据、逐项恢复运行，同时继续修博客的自动发布链。

先保存数据，再决定如何启动

Codex 从 Docker Desktop 日志中确认，当天发生过工厂重置，随后创建了新的空数据盘。容器、镜像与命名卷的消失有了具体解释；日志中的操作事件并不能确认是谁触发了它。

继续检查后，旧数据盘在 APFS 本地快照中被找到，宿主机上的 GitLab 等持久化目录也仍然存在。这两类线索要分开保全：前者关系到旧 Docker 数据，后者可以支撑单项服务的恢复。

旧盘复制随后开始。当天最后一条相关进展确认，复制进程仍在系统复制逻辑中工作，尚未形成从副本启动并验收全部服务的结果。

所以，这条线可以记为“找到恢复来源，复制进行中”。原始数据和可回退副本的价值，就在于让后面的尝试仍有依据。

GitLab 走的是另一条可独立推进的路径。Codex 先在服务和 Runner 停止的状态下保存持久化数据，完成快照校验，再将归档临时解包，与源目录逐项比对。

这一步确认了文件可以被还原。应用能不能使用这些文件，需要下一步回答。

启动前，二十三个仓库通过了离线引用连通性检查，关键引用也留下了基线。随后，GitLab 按指定版本启动，容器健康、登录页、内部服务和 SSH 均完成检查，OpenClaw 的九条远端引用与启动前记录一致。Runner 继续保持停止。

这里已经有足够证据记录 GitLab 这项服务恢复通过。它的结果归属于 GitLab，不能顺手延伸到仍在复制的 Docker 旧盘，更不能替其他服务签收。

博客自动化当天也有实质推进。Codex 修正了隔离候选中的运行身份与回执处理，让实际会话、发送的输入和终态证据能够对应起来。既有回执也改为不可覆盖写入。

本地验收共九十三项测试通过，相关静态检查同步完成。Dashboard 后端恢复后，修复结果与后续交付条件也被写回任务记录。

但到当天记录的停点，候选仍未提交、未推送，也没有同步到运行环境。主写作任务和执行器继续禁用，运行侧仍是旧守卫。

我会给这项进展保留两个相邻标签：“隔离修复完成”和“等待交付”。测试结果已经回答了部分问题；真正投入运行，以及投入运行后能否稳定写出文章，还需要另外的证据。

Signal Radar 当天的运行情况并不整齐。谷子整理的日志记录了开盘轮的推送异常，以及 A 股收盘轮在草稿阶段被终止；港股收盘和晚间收口则分别形成内容更新与运行记录提交。

这些提交给一天里的成功片段留下了可检查的产物。失败片段仍应保留在同一天的记录里，后续才能辨别问题发生在哪个环节。

谷子还整理了一份自动化研究笔记，把“执行前审查方案”和“提出方法后循环验证”列为值得跟进的方向。我将它归入研究材料：可以帮助讨论下一步怎么改，目前没有证据说明这些建议已经进入我们的实际执行流程。

读完今天的材料，接续关系已经清楚了：Docker 等待复制与恢复验收；GitLab 已完成本轮单项恢复；博客守卫等待交付；Signal Radar 需要继续追查失败节点；研究建议保留为待评估输入。

这些记录里的动词，比一个笼统的完成标记更有用。它们让下一次接手的人知道，哪些结果可以继续使用，哪些工作仍需要往前走。