Best possible solution:

Land the producer-boundary fix after maintainer review, green focused checks, and real Telegram proof showing non-rich progress previews render as formatted standard HTML while rich mode still uses rich messages.

Do we have a high-confidence way to reproduce the issue?

Yes. Current main is source-reproducible: progress-mode dispatch always passes a richMessage preview even when the account is configured for non-rich standard Telegram transport.

Is this the best way to solve the issue?

Yes. Fixing the producer boundary is the narrowest maintainable path because draft-stream already supports both standard HTML text and explicit rich-message transports, so adding another downstream fallback would preserve the wrong contract.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 8aaf937bc045.

Label changes:

• add P2: The PR fixes a bounded Telegram progress-preview contract bug with limited channel-specific blast radius.
• add rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body lists tests and autoreview but no after-fix real Telegram proof for the visible progress-preview behavior. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
• add mantis: telegram-visible-proof: Mantis should capture Telegram visible proof. This changes visible Telegram progress-preview formatting, which a short Telegram Desktop or bot-to-bot recording can demonstrate directly.

Label justifications:

• P2: The PR fixes a bounded Telegram progress-preview contract bug with limited channel-specific blast radius.
• rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body lists tests and autoreview but no after-fix real Telegram proof for the visible progress-preview behavior. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
• mantis: telegram-visible-proof: Mantis should capture Telegram visible proof. This changes visible Telegram progress-preview formatting, which a short Telegram Desktop or bot-to-bot recording can demonstrate directly.

PR surface:

Source +9, Tests -28. Total -19 across 2 files.

What I checked:

• PR diff changes the progress preview producer boundary: The branch adds a richMessages parameter to renderTelegramProgressDraftPreview, returns { text: html, parseMode: "HTML" } when false, and preserves buildTelegramRichHtml only for rich mode. (extensions/telegram/src/bot-message-dispatch.ts:467, 1bf927ac4078)
• Current main always produces a rich preview for progress drafts: On current main, renderTelegramProgressDraftPreview always returns a richMessage payload, regardless of the selected account's richMessages setting. (extensions/telegram/src/bot-message-dispatch.ts:467, 8aaf937bc045)
• Standard stream text already uses Telegram HTML when rich messages are off: The existing dispatch renderer uses renderTelegramHtmlText plus parseMode: "HTML" when telegramCfg.richMessages !== true, so the PR aligns progress previews with the non-rich stream contract. (extensions/telegram/src/bot-message-dispatch.ts:906, 8aaf937bc045)
• Draft stream supports standard HTML transport with plain fallback: normalizeTelegramDraftTransportPreview maps parseMode: "HTML" into standard text transport, and send/edit paths pass parse_mode: "HTML" with a plain-text fallback on Telegram HTML parse errors. (extensions/telegram/src/draft-stream.ts:91, 8aaf937bc045)
• Existing config contract treats rich messages as explicit opt-in: Telegram config UI text states rich messages default to false because some current Telegram clients render them as unsupported, and channel action contract tests advertise rich text only when enabled. (extensions/telegram/src/config-ui-hints.ts:65, 8aaf937bc045)
• Maintainer Telegram review note requires live proof for streaming changes: The Telegram maintainer note says behavior PRs touching transport or streaming need real Telegram proof, preferably bot-to-bot QA or an equivalent live Telegram probe. (.agents/maintainer-notes/telegram.md:35, 8aaf937bc045)

Likely related people:

• obviyus: Prior merged history includes the rich HTML message work and progress-draft rendering changes that this PR adjusts, beyond authorship of this branch. (role: rich-message and progress-draft feature owner; confidence: high; commits: da92615816b6, 663fabbe30eb, 42dcf7075f2d; files: extensions/telegram/src/bot-message-dispatch.ts, extensions/telegram/src/draft-stream.ts, extensions/telegram/src/rich-message.ts)
• NianJiuZst: Authored the merged opt-in rich-message default restoration that established the current richMessages: false contract this PR follows. (role: default rich-message gating contributor; confidence: medium; commits: a375d6c84963; files: extensions/telegram/src/bot-message-dispatch.ts, extensions/telegram/src/draft-stream.ts, extensions/telegram/src/config-ui-hints.ts)
• vincentkoc: Recent merged commits touched Telegram command progress detail behavior and adjacent bot-message-dispatch tests in the same surface. (role: recent Telegram progress and dispatch test contributor; confidence: medium; commits: 5e329f40656a, d4fb49f3c495, 3d05da9a5483; files: extensions/telegram/src/bot-message-dispatch.test.ts, extensions/telegram/src/bot-message-dispatch.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.