调研类长任务写长文档稳定超时、整轮产出全丢；并频繁出现意义不明的「文件变更未完整记录」卡片

**客户端版本**: 0.1.35
**反馈类型**: bug

---

两个问题，都在同一类任务里遇到（深度调研 + 产出一份很长的 Markdown 文档）。Agent = Claude Code、模型 = Opus 5、思考强度 = 超高。

## 现象

**A. 写长文档时稳定超时，整轮产出全丢。** 调研部分已经做完，一到要把文档写出来就卡死超时；手动重试照样超时，可稳定复现。失败前这一轮已花掉 $5.57，上下文只到 27%，不像是 context 溢出。关键条件看起来是单次 tool_use 的 input 特别大（整份文档当 Write 的 content），而不是对话本身长。

**B. 频繁出现「本条消息的文件变更未完整记录」卡片，意义不明。** 卡片内容：标题「本条消息的文件变更未完整记录」+ `+0 -0` + 警告行「仅记录了可精确捕获的部分变更」+ 右侧「审查」按钮。它现在经常出现（不限于 A 那个失败任务，但在那个任务里反复出现多次）。作为用户完全看不懂：不知道哪些变更没记上、为什么没记上、点「审查」会看到什么、需不需要我做事。而且 `+0 -0` 与「未完整记录」并排，读起来自相矛盾：既像说没有改动，又像说改动没记全。

## 复现步骤

1. 新建对话，选 Claude Code / Opus 5 / 超高。
2. 发一个需要大量外部检索 + 阅读本地代码资产、最后要求「给我一份完整的可落地方案」的深度调研任务（我这边是研究 UE Lyra 的 3C/动画体系，对照本地 Godot 项目出移植方案）。
3. 等模型调研完、开始用 Write 写那份长文档。
4. 失败后再发一句「方案没有成功写出来，尝试重新撰写」。

B 的卡片不需要特定步骤，日常用就会反复碰到。

## 期望行为

1. 写长文档不应该把整轮打死，更不应该在同一条路上确定性地反复失败。
2. 自动重连不该对「重试必然重现」的失败白烧 5 次，应早点交回用户并给可操作建议。
3. 已完成的调研产出不该整轮蒸发。就算最终写文件失败，也希望把已产出内容留在会话里可复制，或引导模型改成分多段小块写入。
4. 那张卡片要么说清楚「什么没记上、为什么、我该做什么」，要么在没有实际信息量时（`+0 -0`）干脆不要出现。现在这样只是在聊天流里制造噪声和不安。

## 实际行为

A 的时间线（有截图）：

1. 模型 thinking 显示它在规划分块写：`I'm deciding how to write a large document in pieces to avoid hitting tool call limits. I'll start with a Write operation for t...`
2. 随后长时间静默：状态栏 `正在生成... 2m 10s · ↓ 1 tokens`——两分多钟只收到 1 个 token。
3. 报 `The operation timed out.`，触发自动重连：`重新连接中 1/5 The operation timed out.`
4. 重连同样超时，最终 `重新连接未成功 The operation timed out.`
5. B 的卡片就夹在这个过程里反复出现，`+0 -0`。Write 确实从未落地，几十分钟的调研产出全部丢失，只能从零重发。

## 代码侧线索（自查，未验证是否就是成因）

- `API Error: The operation timed out.` 这个形态仓库里已有固件：`packages/maker-core/src/agents/claude-code/__tests__/translator-error-result.test.ts:279`（assistant error envelope，`error: 'unknown'`）。但两份 networkish 白名单都没收录这条文案：`packages/maker-core/src/agents/shared/network-error.ts:50` 与 `apps/desktop/src/renderer/utils/networkError.ts:42` 里只有 `Request timed out`。`isInterruptedTurnError`（`apps/desktop/src/main/maker-ipc/interruptedTurnAutoResume.ts:104`）是白名单制，`sdkError='unknown'` 又过不了 `isStreamTruncationError` 要求的 `server_error` 门。本次 UI 确实出了「重新连接中 1/5」，实际命中的可能是 `api_retry` 分支合成的 `(connection error, retry N/M)` 文案；两条路径信号不一致，值得一起看。
- 超时预算分层：`env-builder.ts:392`（`CLAUDE_STREAM_IDLE_TIMEOUT_MS=300000`、`API_TIMEOUT_MS=900000`）+ `claude-code/index.ts:420` 的 maker 侧 watchdog。`↓ 1 tokens / 2m10s` 更像是上游在生成超大 tool_use input 期间长时间不吐 chunk，撞上 cc-code 内置的 300s inactivity watchdog → 降级非流式 → 非流式请求再超时。若属实，「一次 Write 写一整份长文档」本身就会稳定撞预算。
- `interruptedTurnAutoResume.ts` 的额度模型是「有实质产出就重置计数」，而本场景每次重试都是零产出，5 次退避（约 61s）注定跑满，期间用户只看到转圈。
- 关于 B：我在 `origin/main` 当前代码里 **grep 不到**「未完整记录」/「可精确捕获」这两串文案（各语言 locale 和源码都搜过），所以无法引用它的触发条件。需要维护者先定位这张卡片是哪个版本/分支引入的。右侧「审查」按钮对应的应是右侧边栏的审查面板（locale key `sidebar.tabs.kinds.review`）。
---
**版本区域**: CN
**OS**: win32 x64 (10.0.26200)
**界面语言**: zh-CN

Start with packages/maker-core/src/agents/claude-code/__tests__/translator-error-result.test.ts and the timeout and retry paths in packages/maker-core/src/agents/shared/network-error.ts, apps/desktop/src/renderer/utils/networkError.ts, interruptedTurnAutoResume.ts, env-builder.ts, and claude-code/index.ts. Reproduce the long Write timeout, then locate the source of the file-change card since its wording is absent from origin/main. Done means the timeout and retry behavior are explained or corrected, completed output is not silently lost, and the card is actionable or suppressed when it reports +0 -0.

Written by the indexing model from the issue text.