[Apageoflove]

关掉 MiniMax Code 再打开，之前发出去、还没等到回复的那条消息就卡在那儿了。消息还在聊天里，回复没有，页面上找不到能再发一次的地方，手动调 resume-pending 会被回一个 busy。用户除了重新打一遍没别的办法。

宿主在没有页面可见的时候可以随时停掉插件的 Node 进程，不通知也不回调，所以这算不上什么罕见的崩溃场景。进程停之前那条请求已经收下、标成了 processing，重启时 store 把它映射回 pending。可 pending 的意思是内存里那个队列会负责发它，队列已经跟进程一起没了，不会再有东西来捡。续跑那条路只认 held，页面的按钮也只对 held 画，几个口子一起堵上了。

复现是拿子进程跑到一半 SIGKILL，再打开同一个 dataDir。基线跑出来这样：

message after Store.init(): state=pending
agent runs after restart: 0
assistant replies: 0
POST /resume-pending -> busy / This message has started or its state has changed.

改完之后同一条探针最后一行变成 {"ok":true}，前面三行没动，它依然不会自己重放。

resumeHeld 原来只收 held，现在也收这种 pending，用的判据是重试路径本来就在用的那条：没有任何回复引用它，也没有落盘的助手占位，说明它从没到过宿主。队列里还活着的请求会被 this.has() 挡在外面，不会重复派发。页面跟着放宽，条件一致时画出本来就有的 Continue with follow-ups。至于为什么不干脆自动重放——进程停之前那一回合可能已经跑过工具了，要不要再发一次得用户自己定。

一开始我想得更省事，直接把 store 里的映射从 pending 改成 held，按钮和续跑就都自然生效了。结果砸了两条既有测试：客户端拿同一个 clientMessageId 重试的那条路只认 pending，而 held 会被 inbox 的闸门当成还有未解决的回合，请求把自己挡住了。所以映射一个字没动，只放宽续跑这一侧。

刚发出去的新消息也是 pending，按钮不能无条件画。这里拿 dispatchRevision 区分，它只在投递状态变化时才写，输入框刚创建的请求还没有这个字段。既有那条忙碌时不出现调整控件的测试照旧过。

两条新测试在未改的上游上都是红的，在切片上绿。引擎那条盯重启后不自动跑、显式续跑之后恰好跑一次且只产出一条回复；页面那条盯滞留请求有按钮、点下去真的发出 resume-pending，而刚发出的请求没有按钮。全量 413 条过，基线 411 条。版本号三处都到 0.7.27，README 补了一节。

真机上宿主的停止和重启时序我没跑，全是模块级探针加单元测试，真实浏览器里 SSE 的到达顺序也没测。群会话那条路只读了代码，没单独复现。还有一次全量运行偶发掉了一条 HTTP export 的历史遍历测试，跟这次改动无关，单独跑是过的，后面三次全量都干净。

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}