Summary

• Fix classification: Root-cause fix.
• Maintainer-ready confidence: High.
• Root cause: Telegram progress mode used the answer draft lane as the state owner for progress drafts, but visible tool-output paths could send later assistant-visible messages or artifacts without first clearing that active progress draft from the same lane.
• Why this is root-cause fix: The patch reuses the existing answer-lane progress clear/rotate lifecycle before visible tool output leaves the draft lane, so progress draft state is resolved at its source owner before later Telegram delivery.
• What did NOT change: This only changes the progress-mode visible tool-output ordering boundary; it does not change Telegram streaming configuration, final-answer delivery, draft throttling, media/send formatting, security, auth, secrets, network, or tool execution behavior.
• Fixes a Telegram progress-mode ordering hole where visible tool output or artifacts could be sent while the prior progress draft was still visible above them.
• Keeps progress drafts owned by the answer draft lane, but clears/rotates that draft before visible tool output leaves the draft lane.
• Success means progress/status bubbles are not stranded above later assistant-visible Telegram messages or artifacts in progress mode.
• Reviewers should focus on the progress-mode tool-output lifecycle in extensions/telegram/src/bot-message-dispatch.ts.

Linked context

Closes #90753

Related #77727, #80862, #79804, #82089

Was this requested by a maintainer or owner?

• No direct maintainer request. ClawSweeper kept the issue open and asked for focused Telegram progress-mode regression coverage plus direct proof that the progress bubble is not stranded above the final answer.

Real behavior proof (required for external PRs)

• Behavior or issue addressed: Telegram direct-chat channels.telegram.streaming.mode = "progress" could leave the progress/status draft above later assistant-visible output when visible tool output or artifacts were sent.
• Real environment tested: macOS 26.5, Node v24.15.0, pnpm 11.2.2, OpenClaw checkout 48bea40, real Telegram Desktop/App private chat with real bot @moongpbot, local OpenClaw gateway, and deterministic local OpenAI Responses mock provider.
• Exact steps or command run after this patch:

pnpm openclaw gateway --port 19879
# Telegram private chat stimulus:
/verbose on
clean exec proof 1840
# Regression tests:
node scripts/run-vitest.mjs extensions/telegram/src/bot-message-dispatch.test.ts src/channels/progress-draft-compositor.test.ts

• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output):

2026-06-14T20:06:11.285+08:00 [gateway] ready
2026-06-14T20:06:12.551+08:00 [telegram] [default] starting provider (@moongpbot)
2026-06-14T20:06:13.873+08:00 [telegram] [diag] isolated polling ingress started

2026-06-14T20:09:06.704+08:00 [telegram] Inbound message telegram:<redacted-chat-id> -> @moongpbot (direct, 21 chars)
2026-06-14T20:09:11.801+08:00 [telegram] sendRichMessage ok chat=<redacted-chat-id> message=36
2026-06-14T20:09:13.576+08:00 [telegram] outbound send ok accountId=default chatId=<redacted-chat-id> messageId=37 operation=sendRichMessage deliveryKind=text chunkCount=1

Mock OpenAI provider request chain confirmed the real Telegram prompt drove an exec tool-call turn:

request #1: decision=exec-tool-call, hasTrigger=true, hasFunctionOutput=false, hasExec=true
request #2: decision=final-ok, hasTrigger=true, hasFunctionOutput=true, hasToolMarker=true, hasExec=true

Agent session output confirmed the tool and final model text were non-empty:

exec tool result: TELEGRAM_PROGRESS_TOOL_OUTPUT_OK
final assistant text: TELEGRAM_PROGRESS_CLEAN_OK no_stale_progress_bubble=true

• Observed result after fix: the contributor-run runtime path completed through a real Telegram inbound message, real local OpenClaw gateway processing, an exec tool call, and two Telegram outbound sends. However, the local Telegram Desktop visual capture showed blank bot bubbles, so I am not attaching it and I am not claiming this as clean Mantis-quality visual proof.
• What was not tested: the official maintainer Mantis/Crabbox Telegram proof was not run from this contributor environment, and I do not yet have a clean public screenshot/GIF showing the final Telegram UI without visual artifacts.
• Proof limitations or environment constraints: this is contributor-run live Telegram/runtime evidence plus focused tests; visual Telegram proof remains inconclusive because the local client showed blank bot bubbles despite non-empty session output.
• Before evidence (optional but encouraged): the focused visible-artifact regression failed before the round2 implementation with expected 13 to be less than 12, showing the draft clear happened after the Telegram send.

Tests and validation

Which commands did you run?

• Extension-specific contract test command: node scripts/run-vitest.mjs extensions/telegram/src/bot-message-dispatch.test.ts -t "clears progress drafts before durable verbose tool output"
• Extension-specific contract test command: node scripts/run-vitest.mjs extensions/telegram/src/bot-message-dispatch.test.ts -t "clears progress drafts before visible tool artifacts"
• Fresh regression command after live proof: node scripts/run-vitest.mjs extensions/telegram/src/bot-message-dispatch.test.ts src/channels/progress-draft-compositor.test.ts

Fresh regression output after live proof:

Test Files  1 passed (1)
Tests  120 passed (120)

Test Files  1 passed (1)
Tests  10 passed (10)

[test] passed 2 Vitest shards in 10.17s

What regression coverage was added or updated?

• Added clears progress drafts before durable verbose tool output in extensions/telegram/src/bot-message-dispatch.test.ts.
• Added clears progress drafts before visible tool artifacts in extensions/telegram/src/bot-message-dispatch.test.ts.
• The regressions cover progress mode, an active progress draft, visible tool text/artifact delivery, final answer delivery, and the ordering invariant that draft clear happens before Telegram delivery.

What failed before this fix, if known?

• The durable-text regression failed before the first production fix because answerDraftStream.clear() was invoked after the first durable deliverReplies() call.
• The visible-artifact regression failed before the round2 production fix because answerDraftStream.clear() was also invoked after the first visible artifact deliverReplies() call.

If no test was added, why not?

• A regression test was added.

Risk checklist

Did user-visible behavior change? (Yes/No)

• Yes. Telegram progress-mode users should no longer see a stale progress draft above later visible tool/final output in these visible tool-output paths.

Did config, environment, or migration behavior change? (Yes/No)

• No.

Did security, auth, secrets, network, or tool execution behavior change? (Yes/No)

• No.

What is the highest-risk area?

• Telegram progress-mode message lifecycle ordering when tool output becomes visible text or artifact output.

How is that risk mitigated?

• The change only reuses the existing progress-draft clear/rotate path before visible tool sends in progress mode, and the focused acceptance tests cover draft stream behavior, Telegram dispatch ordering, and progress draft composition.

Current review state

What is the next action?

• Ready for maintainer review after CI.

What is still waiting on author, maintainer, CI, or external proof?

• CI and maintainer review. Contributor-run live Telegram proof has been added; maintainer-only Mantis/Crabbox proof was not run from this contributor environment.

Which bot or reviewer comments were addressed?

• Addresses the ClawSweeper issue guidance requesting focused coverage for Telegram progress-mode ordering and proof that the progress draft is not stranded above later visible output.