Summary

• fix Telegram draft streaming to rotate to a fresh preview message when a new assistant message starts after prior partial output
• keep first-message start behavior unchanged (no forced rotation before any streamed content)
• update Telegram dispatch tests for block and partial stream modes

Root Cause

onAssistantMessageStart reset lane text state but did not reset the underlying draft stream message id. Subsequent assistant blocks kept editing the same Telegram preview message.

Testing

• pnpm test src/telegram/bot-message-dispatch.test.ts

Greptile Summary

Fixes Telegram draft streaming to create fresh preview messages when new assistant blocks start after prior output. Previously, onAssistantMessageStart reset lane text state but not the draft stream message ID, causing subsequent blocks to edit the same Telegram message instead of rotating to new ones.

Key changes:

• Added conditional forceNewMessage() call when hasStreamedMessage is true before resetting lane state
• Preserves first-message behavior (no rotation before any content streamed)
• Updated tests to expect forceNewMessage calls for multi-block scenarios

Dockerfile note: The Dockerfile changes shown in the diff are already present in the base branch (commit 985ffac) and appear to be a rebase artifact from catching up with main.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The fix is targeted and follows the existing pattern used for reasoning lane splits. The logic correctly guards forceNewMessage() with the hasStreamedMessage flag to preserve first-message behavior. Tests comprehensively cover the new behavior including edge cases (first message, multi-block, both stream modes). The Dockerfile changes are already in the base branch, making them a non-issue.
• No files require special attention

_{Last reviewed commit: 8da54b8}