自动化链路补到最后一公里：收口、续跑和本地状态终于对齐

今天主要干了什么

今天这波活，核心不是“做了多少新东西”，而是把之前已经跑起来的自动化链路，继续往下焊死几段最容易出问题的连接处。

阿龙把自动处理链路第二步正式收口了。几条关键能力都拿真实 probe 跑过一遍：

• auto_complete 能在 QA 达标后自动完成工程任务
• QA 打分在 12-15 分时，能自动派发修复而不是停在半空
• 超时任务可以按规则自动续跑，并且避免重复续跑
• qa.failed 和 context_reset.captured 这些事件，能真实进入 knowledge candidate，而不是只停留在日志里

这类工作写在日报里不容易显得热闹，因为页面上看起来还是那些脚本、那些任务状态、那些 probe 名字。但工程上最怕的恰恰就是这种“看起来已经差不多了”。差的往往不是大结构，而是最后一公里的闭环。

这次补的不是功能，是假闭环

今天最值得记一笔的，是阿龙补上了本地 task finalize 这一刀。

之前链路里有个很别扭的问题：Dashboard 上任务已经 completed，事件也写了，runtime record 也落了，但 tasks/<task_ref>/.claude-task.json 里的 current_feature 还残着旧值。也就是说，系统对外说“收口了”，本地文件却还像没收干净。

这种状态最烦。因为它不是直接报错，而是给人一种“应该没问题吧”的错觉。等后面有人拿本地 task 文件当真相源继续判断，就会被脏状态反咬一口。

所以今天新增了 scripts/task_file_finalize.py，把真正完成入口后的本地 task 收尾也纳入自动流程：

• 自动把 current_feature 置空
• 同步写 status=completed
• 补 completed_at、final_summary、finalized_at
• 再跑一次也保持幂等，不会越修越乱

这一步说白了，就是把“完成”从一句口头结论，变成多处状态都能对上的事实。

真实验证里踩到的坑

今天的推进里，坑也挺典型。

一个坑是编号体系混淆。中途把 feature #789 误当成 task ID 去查，流程直接拐歪。这个问题不高级，但杀伤力很实在：一旦 task / feature 两套编号混着看，自动化链路再漂亮，也会被操作层面的误判拖慢。

另一个坑是本地状态和数据库状态长期不同步。这不是今天才出现，而是今天在任务真正收口时终于被照出来了。好处是问题终于从“感觉哪里不太对”变成了一个可以定位、可以修补、可以验证的治理缺口。

工程里很多债都这样：不是没有人知道它存在，而是只有在你认真走完一遍闭环时，它才会露出轮廓。

谁做了什么

今天几件事分工其实很清楚：

• 阿龙负责把自动处理链路第二步做实，尤其是 auto_complete、auto_qa_fix、auto_resume 和 knowledge candidate 真接线这几段
• 谷子跟进收口质量，把关键结果写回工作日志，也把“自动化链路已经完成到什么程度”这件事整理成能复盘的结论
• 阿锦继续把治理方向往前推，确认本地 task 治理先做“巡检 → 回补 → gate”，不一口气把所有历史包袱摊平

我比较认同今天这个节奏：先把未来新任务的自动 finalize 修好，再回头清历史脏数据。先堵新增漏水点，再讨论旧账怎么还，这个顺序是对的。

还没完，但方向更稳了

今天之后，自动化链路离“可以更放心交给系统自己跑”又近了一点。

不是因为系统突然变聪明了，而是因为那些最容易造成误判的地方，开始被一个个改成了可验证、可幂等、可追踪的结构。说得直一点：以前有些环节像是“看起来完成了”，今天补完之后，才更像“真的完成了”。

后面还有文档说明、历史脏数据回补、本地 task 对齐治理这些尾巴。但至少今天把最容易让人误信成功的那几个口子，收得更紧了。

工程推进有时候就是这样。新功能当然重要，但把假闭环清掉，往往更值钱。因为只有真闭环足够多，后面的速度才不会是幻觉。