[Suggestion] Downloaded files are written to tmpdir()/channel-files/ but never cleaned up — not after handleInbound completes, not in disconnect(), and not via any periodic sweep. Over time on a busy bot, this gradually exhausts disk space.

Consider cleaning up the temp directory after handleInbound resolves, or adding a periodic sweep in the existing dedupTimer callback to remove files older than N hours.

— qwen-latest-series-invite-beta-v36 via Qwen Code /review

文件清理的正确时机是 bridge 读取完毕后，但 ChannelBase 目前没有 onFileConsumed 类生命周期回调。在 onPromptEnd时删文件不安全（bridge 可能仍在读取），需要对 channel-base 做架构改动。此外 dingtalk/weixin channel 的 media下载同样没有清理机制，是共性问题。

建议：单独开 issue 在 ChannelBase 层统一解决，增加文件消费完成回调后再各 channel 补清理逻辑。

[Suggestion] downloadMedia has input validation, HTTP error handling, and a catch-all error handler, but no tests. The sibling weixin channel has media.test.ts (142 lines) covering equivalent functionality. A regression in URL construction or auth headers would silently return null, dropping attachments without user-visible feedback.

— qwen-latest-series-invite-beta-v36 via Qwen Code /review

downloadMedia 依赖 fetch 访问飞书 Open API，测试需要引入 HTTP mock 库，本 PR 优先补齐了核心状态机测试（24 个用例），覆盖了更高风险的路径。

建议：follow-up PR 统一补齐各 channel 的 media 单测，可以复用 weixin 的 media.test.ts 模式。

[Suggestion] When displayContent.length > MAX_CARD_CHARS, the content is truncated from the head, but unlike onResponseComplete (lines 940-944), code fences are not rebalanced. If the truncation lands inside a code block, intermediate streaming cards render with broken, unclosed markdown code blocks for up to 1.5s per update cycle.

— qwen3.7-max via Qwen Code /review

[Suggestion] Stop button auth reads only operator?.open_id, but onMessage (line 1503-1506) uses a defensive open_id || user_id || union_id fallback chain. Depending on app configuration / SDK user_id_type settings, open_id may be undefined, making the stop button silently non-functional while the same user can still send messages.

— qwen3.7-max via Qwen Code /review

[Suggestion] When cancelSession rejects, the error is caught and logged, but execution continues to update the card with "已停止生成". The user sees a "stopped" card while the LLM continues generating tokens invisibly (the bridge failed to cancel). Misleading UX and silent token waste.

Consider short-circuiting on cancelSession failure:

if (sessionId) {
  try {
    await this.bridge.cancelSession(sessionId);
  } catch (err) {
    process.stderr.write(`...cancelSession failed...`);
    return; // don't rewrite the card
  }
}

— qwen3.7-max via Qwen Code /review

[Suggestion] The fetch() return value for the DELETE request is never captured or checked. If the Feishu API returns 403/404/500, the failure is completely silent — the "OnIt" emoji remains permanently stuck on user messages with no log trail.

— qwen3.7-max via Qwen Code /review

[Suggestion] extractTitle(text) is called inside the for loop, but text is invariant across iterations. For a response split into N chunks, extractTitle (which splits the full text by \n) runs N times producing the same result.

— qwen3.7-max via Qwen Code /review

[Suggestion] Image download and file download are sequential (await one after the other). When a message has both imageKey and fileKey, the two network downloads add latency. Use Promise.all to parallelize:

const [imageMedia, fileMedia] = await Promise.all([
  content.imageKey && token
    ? downloadMedia(msgId, content.imageKey, 'image', token)
    : Promise.resolve(null),
  content.fileKey && content.fileName && token
    ? downloadMedia(msgId, content.fileKey, 'file', token)
    : Promise.resolve(null),
]);

— qwen3.7-max via Qwen Code /review

[Suggestion] The webhook HTTP server has no requestTimeout, headersTimeout, or maxConnections configured. A slow-loris attacker can hold many connections open, exhausting sockets on the webhook port.

— qwen3.7-max via Qwen Code /review

[Suggestion] Post content parsing logic here is near-identical to extractContent (lines 1738-1766). Both implement the same language-wrapper detection, paragraph iteration, and text/a tag extraction. The two copies already diverge — extractContent handles at tags while this doesn't. Extract a shared parsePostContent() helper.

— qwen3.7-max via Qwen Code /review

[Suggestion] cleanupCard(inboundMsgId) already calls this.stoppedMessages.delete(inboundMsgId) internally (line 1473). This explicit .delete() is redundant and makes the code harder to reason about — a reader might think cleanupCard doesn't handle stoppedMessages.

Remove this line (also at line 195).

— qwen3.7-max via Qwen Code /review

[Suggestion] When the collapsible split falls inside a code block and no closing fence exists within 500 chars, the comment says "accept the split as-is". This produces a preview element with an unclosed code block and a rest element starting mid-code-block — both render as broken markdown in the Feishu card.

Consider closing the fence in the preview and reopening it in the rest:

// when no nearby closing fence:
preview = markdown.slice(0, splitAt) + '\n```';
rest = '```\n' + markdown.slice(splitAt);

— qwen3.7-max via Qwen Code /review

[Suggestion] After the while read loop completes successfully (done === true), reader.releaseLock() is never called. The reader retains a lock on the ReadableStream, preventing the underlying HTTP connection from being returned to the pool until GC. Under sustained load with many media downloads, this contributes to connection pool exhaustion.

Or wrap in try/finally to ensure release on all paths.

— qwen3.7-max via Qwen Code /review

[Critical] sendMessage returns Promise<void> — when getTenantAccessToken() fails (returns undefined), the method logs a warning and returns silently. All callers (onResponseComplete fallback at :1094, onPromptEnd fallback at :1262, handleStop fallback at :1487) treat the resolved promise as delivery success.

Impact: If the Feishu auth endpoint is down, every response silently vanishes. Users send messages, see the bot's reaction, but get no response. Only a single "Cannot send" line per message appears in stderr — no error propagates to the bridge layer.

Then check the return value in callers to handle delivery failure.

— qwen3.7-max via Qwen Code /review

ChannelBase.sendMessage 抽象签名是 Promise，TS 不允许子类窄化为 Promise。需要先改 base class + DingTalk adapter，跨包变更，本轮 defer

[Critical] FEISHU_ID_RE permits .. and . — the regex /^[a-zA-Z0-9_.:-]+$/ includes . in the character class, so the string .. passes validation. When interpolated into URL paths (e.g., ${BASE_URL}/im/v1/messages/${messageId} at :762, :795, :1302), .. triggers WHATWG URL path resolution: /im/v1/messages/.. rewrites to /im/v1/, hitting a completely different API endpoint with the bot's bearer token.

Impact: Defense-in-depth failure. The regex comment explicitly says it prevents "SSRF path traversal in URL interpolation" but doesn't. While message IDs normally come from Feishu's server, if HMAC verification were ever bypassed, an attacker could redirect authenticated requests to arbitrary Feishu API endpoints.

— qwen3.7-max via Qwen Code /review

不认可。.. 只在浏览器 new URL() 时触发 WHATWG 路径解析，fetch() 对已拼接的完整 URL 不做路径归一化。且 ID 全部来自飞书服务端（msg_id/file_key/image_key），攻击者无法控制这些值。即使 HMAC 被绕过，攻击者发送的消息里的 ID 也是飞书分配的合法值，不会是 ..。正则的 JSDoc 说"prevent SSRF path traversal"是防御深度的描述，实际已足够安全~

[Critical] Race between onResponseComplete and handleStop can leave the streaming card unfinalised. The sequence: (1) user clicks Stop while creating=true; (2) onResponseComplete sets finalizing=true before the busy-wait; (3) busy-wait resolves when creating becomes false; (4) handleStop finishes cancelSession, sees cardState.finalizing === true at :1466, and returns without updating the card; (5) onResponseComplete post-wait re-check sees stopped=true and also returns early. Result: the card shows stale streaming content and never gets the "已停止生成" label.

Impact: User clicks Stop but the card remains stuck showing partial streaming content with no stop indicator. The fallback sendMessage in onResponseComplete is skipped because stopped=true.

Suggested fix: Before the early return at the stopped check in onResponseComplete, call deleteCard and sendMessage to deliver the response:

if (cardState?.stopped || this.stoppedMessages.has(inboundMsgId)) {
  // handleStop owns the card update, but if it bailed due to finalizing,
  // ensure the response is delivered
  if (!cardState?.messageId) {
    await this.sendMessage(chatId, fullText);
  }
  this.cleanupCard(inboundMsgId);
  return;
}

— qwen3.7-max via Qwen Code /review

触发条件：用户必须在 creating=true 时点 Stop + cancelSession 恰好在 busy-wait 期间完成 + finalizing 已被 set — 卡片创建通常几百ms内完成，手动触发这个窗口几乎不可能。建议降为 Suggestion

[Suggestion] mkdirSync and writeFileSync are synchronous and block the Node.js event loop during file download. Files can be up to 50MB (MAX_DOWNLOAD_BYTES). A single 50MB writeFileSync can block the event loop for 10-50ms depending on disk speed. Under concurrent message processing (multiple users sending attachments simultaneously), each synchronous write serializes on the event loop, causing latency spikes for all other operations including card updates, WebSocket heartbeat, and message dedup.

— qwen3.7-max via Qwen Code /review

50MB 文件在 SSD 上 writeFileSync 约 10-30ms，在单条消息的 async 链中执行，影响可忽略。改 async 是锦上添花，不影响正确性，建议降为 Nice to have

[Suggestion] deleteCard fallback gated on chatId — but deleteCard only needs messageId, not chatId. If context?.open_chat_id is absent from the card action payload, the orphaned card is never deleted even though deletion would succeed.