Greptile Summary

This PR adds real-time tool/compaction status indicators to Feishu streaming cards and fixes duplicate streaming cards when a turn contains multiple tool calls. The statusLine variable is appended to the combined stream text during tool execution and cleared when the assistant message starts, which integrates cleanly with the existing buildCombinedStreamText logic. The deferred-close strategy (moving closeStreaming() from deliver(kind: "final") to onIdle) is the right approach for preventing duplicate cards.

Key changes:

• statusLine state variable + insertions in buildCombinedStreamText to display/clear status text
• Four new replyOptions callbacks: onToolStart, onAssistantMessageStart, onCompactionStart, onCompactionEnd
• deliver(kind: "final") now calls queueStreamingUpdate (snapshot mode) instead of closeStreaming() — card is only closed when onIdle fires

Issues found:

• The deferred-close change breaks at least six existing unit tests in reply-dispatcher.test.ts that assert streaming.close() is called immediately after deliver(kind: "final"), or count streaming instances under the old "close-on-final" model. The test file was not updated in this PR. The affected tests are: "uses streaming session for auto mode markdown payloads", "delivers distinct final payloads after streaming close", "skips exact duplicate final text after streaming close", "sends attachments after streaming final markdown replies", "streams reasoning content as blockquote before answer", "ignores empty reasoning payloads", and "deduplicates final text by raw answer payload". Each needs await options.onIdle?.() added after the final deliver call, and the "distinct final payloads" test needs its session-count assertion reworked to reflect the new merged-card behavior.

Confidence Score: 2/5

• The runtime logic is sound but the PR breaks the existing test suite — merging without fixing the tests would leave CI red.
• The implementation approach (statusLine variable, callback wiring, deferred close) is architecturally correct and the buildCombinedStreamText logic handles all status/thinking/answer combinations properly. However, the behavioral change from "close on final" to "close on idle" invalidates at least six existing unit tests that were not updated in this PR. The PR description explicitly directs reviewers to run those tests, yet they would currently fail. This is a blocking issue for merging.
• extensions/feishu/src/reply-dispatcher.test.ts — six tests need onIdle() calls added and the "distinct final payloads" test needs its assertion model updated to match the new merged-card behavior.

This is a comment left during a code review.
Path: extensions/feishu/src/reply-dispatcher.ts
Line: 398-402

Comment:
**Existing tests will break — test file not updated**

The behavioral change from "close on `final`" to "close only on `onIdle`" is correct for the stated goal, but the test file (`reply-dispatcher.test.ts`) was not updated to match. At least **six tests** assert that `streaming.close()` has been called (or that a session count reflects immediate closes) immediately after `deliver(kind: "final")` without a subsequent `onIdle()` call. These will all fail:

| Test | Breaking assertion |
|---|---|
| "uses streaming session for auto mode markdown payloads" (line 272) | `expect(streamingInstances[0].close).toHaveBeenCalledTimes(1)` — no `onIdle` called |
| "delivers distinct final payloads after streaming close" (line 299) | `expect(streamingInstances).toHaveLength(2)` — now only 1 session because first `final` no longer closes |
| "skips exact duplicate final text after streaming close" (line 323) | `expect(streamingInstances[0].close).toHaveBeenCalledTimes(1)` — no `onIdle` called |
| "sends attachments after streaming final markdown replies" (line 437) | `expect(streamingInstances[0].close).toHaveBeenCalledTimes(1)` — no `onIdle` called |
| "streams reasoning content as blockquote before answer" (line 516) | `expect(streamingInstances[0].close).toHaveBeenCalledTimes(1)` — no `onIdle` called |
| "ignores empty reasoning payloads" (~line 584) | `close.mock.calls[0][0]` will throw — `close` was never called |
| "deduplicates final text by raw answer payload" (line 598) | `expect(streamingInstances[0].close).toHaveBeenCalledTimes(1)` — no `onIdle` called |

Each of these tests needs to have `await options.onIdle?.()` inserted after the final `deliver` call to trigger the close. The "delivers distinct final payloads" test also needs its logic reworked to assert a single merged session instead of two independent ones.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: extensions/feishu/src/reply-dispatcher.ts
Line: 513-517

Comment:
**`onAssistantMessageStart` silently no-ops when streaming hasn't started**

`flushStreamingCardUpdate` only updates the card when `streaming?.isActive()` is true. If `onAssistantMessageStart` fires before any prior `onToolStart` (or `onReasoningStream`) has kicked off a streaming session — for example, the very first message of a turn — the call is silently dropped. The `statusLine = ""` mutation happens but the update is never pushed.

This is likely benign in practice (no card exists to update), but it differs from `onToolStart` and `onCompactionStart`, which both defensively call `startStreaming()` before flushing. Consider adding the same guard for consistency:

```ts
onAssistantMessageStart: streamingEnabled
  ? () => {
      statusLine = "";
      if (streaming?.isActive() || streamingStartPromise) {
        flushStreamingCardUpdate(buildCombinedStreamText(reasoningText, streamText));
      }
    }
  : undefined,
```

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: 4818ed1}

Closeout note from the Feishu streaming-card dedupe pass: #71523 now covers the duplicate-final-card part by deferring streaming close until idle.

I’m keeping this PR open because the tool/compaction status UI is a separate feature surface and was not landed by the canonical fix. Future review can focus this branch on that status behavior without re-litigating the duplicate final-card root cause.

The remaining status-line feature from this PR is now landed in #71542. Feishu streaming cards can show transient tool and compaction status, then clear that status before the final close so the completed card stays clean.

Closing this branch as superseded. Thanks for pushing the UX angle; the duplicate-final-card portion was handled by #71523 and the status behavior is now in the follow-up canonical PR.