fix: 文档去重防止 API 30MB 限制报错

[lishuceo]

Summary

• 话题内多条消息引用同一 PDF 时，每条消息独立下载并合并，导致相同文档重复累积超过 Anthropic API 30MB message size 限制（实际案例：同一 4.4MB PDF 被下载 8+ 次 → 36MB）
• 新增 deduplicateDocuments() 按 fileName 去重 + 20MB 总量上限，应用于 executeClaudeTask 和 executeDirectTask 两个历史合并点
• downloadHistoryFiles 增加按 fileKey 去重，避免重复下载同一文件

Test plan

• 6 个单元测试覆盖：去重、顺序保持、大小上限、空输入、bug 场景复现
• 全量测试通过（69/70 files, 1253/1254 tests — 1 个 pre-existing flaky memory test）

🤖 Generated with Claude Code

[claude]

Claude finished @lishuceo's task in 1m 13s —— View job

---

PR Review: fix: 文档去重防止 API 30MB 限制报错

• Check previous review comments — none found
• Read changed files and full context
• Analyze code for bugs, security, and architecture issues
• Post review summary

✅ Approved — solid fix with minor suggestions

Overall assessment: This PR correctly addresses a real production issue where duplicate PDFs in thread history could exceed the 30MB API limit. The fix is well-scoped — dedup by fileName at merge time, dedup by fileKey at download time, and a 20MB size cap as a safety net. The logic is sound and applied consistently to both executeClaudeTask and executeDirectTask.

Issues found (2 minor):

• 🟡 Dead fallback code (confidence: 90) — doc.fileName ?? doc.data.slice(0, 64) in deduplicateDocuments: fileName is required in the DocumentAttachment type, so the ?? branch is unreachable. See inline comment

• 🟡 Test copies production code (confidence: 80) — The test file re-implements deduplicateDocuments() locally instead of importing the real function. If production logic changes, tests could silently diverge. Consider extracting the function to a shared utility. See inline comment

What looks good:

• Current-message docs correctly prioritized over history docs (first-wins dedup)
• downloadHistoryFiles fileKey dedup prevents redundant downloads before they happen
• 20MB cap is conservative and leaves headroom for system prompt + images
• Test coverage is thorough with 6 cases including the exact bug scenario reproduction

[claude]

Claude finished @lishuceo's task in 1m 6s —— View job

---

PR Review: fix: 文档去重防止 API 30MB 限制报错 (re-review)

• Check previous review comments and resolve fixed issues
• Read updated source files
• Analyze changes for bugs, security, and architecture issues
• Post review summary

✅ Approved — no new issues, 2 previous suggestions still open

The diff is unchanged from the previous review. The core fix is solid and correctly addresses the production 30MB limit issue.

Previous issues (2, still open):

• 🟡 Dead fallback code (confidence: 90) — doc.fileName ?? doc.data.slice(0, 64) at event-handler.ts:1256: fileName is required in DocumentAttachment, making the ?? branch unreachable. Fix this →

• 🟡 Test copies production code (confidence: 80) — document-dedup.test.ts re-implements deduplicateDocuments() locally instead of importing the real function. If production logic changes, tests could silently diverge. Consider exporting it from a shared utility. Fix this →

Both are minor and non-blocking — the fix works correctly as-is.

[claude]

Claude finished @lishuceo's task in 51s —— View job

---

PR Review: fix: 文档去重防止 API 30MB 限制报错 (re-review after sync)

• Check previous review comments
• Read updated files and verify fixes
• Analyze for new issues
• Post review summary

✅ Approved — all previous issues fixed, no new issues

2 previous issues fixed:

• Dead fallback ?? doc.data.slice(0, 64) → now const key = doc.fileName directly
• Test re-implements production code → now imports deduplicateDocuments from event-handler.js

No new issues found. The implementation is clean:

• deduplicateDocuments() correctly exported and tested with 6 cases
• fileKey dedup in downloadHistoryFiles prevents redundant downloads
• Current-message docs correctly prioritized over history docs at both call sites
• 20MB cap provides safe headroom below the 30MB API limit