[mindfn]

为什么

Phase 4（#200）合入后在 alpha 自测（develop_base 900d87835，CLI_TIMEOUT_MS=60000，让 codex-sol 执行 sleep 150）。超时本身符合设计：距最后一次输出 120 秒时成员被停下，R 为 failed / timeout，诊断 silenceDurationMs=120001。但对话底部多出一行「Error: 响应超时：2 分钟没有任何输出，已停止。」，还推送了一条「猫猫出错了」。

原因：超时的成员在串行 route 里没有 done，在并行 route 里 done 不带 errorCode。QueueProcessor 找不到这个成员的成功凭据，只能走抛异常的兜底路径，广播一条不带 messageId 的最终 error，web 把它显示成单独一行。provider 失败不会这样，因为它的 done 带着 PROVIDER_EXECUTION_FAILED，QueueProcessor 直接据此把条目记为失败。

做了什么

• route-serial：超时成员的收尾块里，没有 done 时补一个 errorCode 为 timeout 的 done（MEMBER_TIMEOUT_REASON）。
• route-parallel：超时成员的 done 在没有 errorCode 时带上 timeout。
• 两边都和 provider 失败的收尾方式一致，QueueProcessor 走已有的 done-errorCode 路径记失败，不再抛异常，也不再多广播一条 error。
• 测试：1398-phase4-member-timeout-stop 的 assertTimedOutMember 增加断言：超时成员的最后一个 done 带 errorCode === 'timeout'，并且失败事件在 done 之前。串行和并行都覆盖。
• 文档：F117「J4 实现」补两条：本次 alpha 自测补丁；CLI 接入实际按 2× 顺延（Codex CLI 空等时每 60 秒约 400ms CPU，超过 F118 存活探针 50ms/60s 的「忙」门槛）。门槛这次不改，另议。

alpha 复验（修复后，同一配置）

• codex-sol 执行 sleep 150：R …000001-3a50e1ac 为 failed / timeout，诊断 silenceDurationMs=120002、processAlive=true、lastEventType=tool_use。界面上是一条「响应超时：2 分钟没有任何输出，已停止。」加「回复失败。」，底部不再有单独的 Error 行。
• 随后再 @ codex-sol，正常回复「在」（R …000004-e1b24cb7 completed）。
• F222 的「问题检测」卡片（触发类型「猫猫响应超时」）照常出现：这是 F222 为「超过 60 秒没有可见输出的失败」设计的 a2a_timeout 信号，和本修复无关。

验证

• 运行实例自己的构建流程加全量公开 API 测试（一次性 Redis，以 Phase 4 那次候选运行为基线）：进行中，结果补在评论里。
• 合入前还需 kimi 复审。

回退兼容

只是给 done 补上了已有字段 errorCode 的一个取值；回退后回到 #200 的行为（多出那一行 Error），数据格式不变。

[宪宪/claude-opus-5-5🐾]

🤖 Generated with Claude Code

[mindfn]

验证结果（736721560，develop_base 900d87835 之上）

照运行实例自己的构建流程跑（/tmp/f117-p4fix-verify.sh，一次性 Redis 127.0.0.1:6777）：

• 构建：pnpm install --frozen-lockfile、shared、MCP、API、web next build 全部通过。
• API 公开测试全量（6 个分片）：和 Phase 4 那次的候选运行（e6dd56d77，即 F117 Phase 4：每个成员只有一个超时，到时按停止处理（J1 + J4，KD-22、KD-24） #200）对比，用例数、通过数完全一致：23431 个用例，通过 23326，失败 2，跳过 103。
  • 两条既有失败（Frontend timeout logic (source verification) 里的 useAgentMessages.ts clears timeout on done with isFinal）Phase 3 那次就有，与本 PR 无关。
  • 名单上多出一条：f295-active-execution-resource 的「isolates overlapping project resources…」，断言 maxBuildersAcrossKeys === 2 实得 1。这个测试只等 10ms 就要求第二个项目的请求已进入 builder，6 个分片并行时来不及；同一棵树上单独跑 5 次都是 3/3 通过。本 PR 没碰 F295。判断为负载下的时序抖动，不算新增失败。
  • Phase 4 那次多出的 api-instance-lease（同样是负载抖动）这次通过。
• Phase 4 专项：1398-phase4-member-output-timeout、1398-phase4-member-timeout-stop（含本 PR 新增的 done 断言）全部通过。

[宪宪/claude-opus-5-5🐾]