Best possible solution:

Keep the shared deferred-delete integration, then land it after redacted Telegram Desktop proof shows the replacement reasoning preview appearing before the prior preview is removed, with no stale bubble or visible jump.

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

Yes, at source level. Current main marks a streamed reasoning preview for rotation and then discards its message id through forceNewMessage() when the next reasoning segment starts, matching the linked issue's orphaned-preview report.

Is this the best way to solve the issue?

Yes. Reusing the existing Telegram deferred-delete repositioning primitive is the narrowest maintainable fix and avoids creating a second cleanup lifecycle; only real-client behavior proof remains missing.

AGENTS.md: found and applied where relevant.

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

Label changes:

• add merge-risk: 🚨 message-delivery: The patch changes visible Telegram preview ownership and deletion timing, so real-client proof is needed to exclude stale, missing, or wrongly removed reasoning messages.
• 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: Only mock-based test output is provided; add a redacted after-fix Telegram Desktop recording, transcript, or runtime logs, then update the PR body to trigger re-review or ask a maintainer to comment @clawsweeper re-review.
• add mantis: telegram-visible-proof: Mantis should capture Telegram visible proof. The PR changes visible reasoning-preview placement and cleanup and can be directly demonstrated in a short Telegram Desktop recording.

Label justifications:

• P2: This is a bounded Telegram preview-lifecycle regression affecting a specific reasoning-stream transition rather than core availability.
• merge-risk: 🚨 message-delivery: The patch changes visible Telegram preview ownership and deletion timing, so real-client proof is needed to exclude stale, missing, or wrongly removed reasoning messages.
• 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: Only mock-based test output is provided; add a redacted after-fix Telegram Desktop recording, transcript, or runtime logs, then update the PR body to trigger re-review or ask a maintainer to comment @clawsweeper re-review.
• mantis: telegram-visible-proof: Mantis should capture Telegram visible proof. The PR changes visible reasoning-preview placement and cleanup and can be directly demonstrated in a short Telegram Desktop recording.

PR surface:

Source -4, Tests +31. Total +27 across 2 files.

What I checked:

• Current main remains affected: Current main sets splitReasoningOnNextStream at reasoning end, then calls forceNewMessage() before resetting the lane when the next reasoning segment begins; this drops the prior preview id without deleting that preview. (extensions/telegram/src/bot-message-dispatch.ts:2695, f68af6484665)
• Patch uses the canonical lifecycle primitive: The PR replaces the direct reasoning-lane force rotation with a shared helper that invokes rotateToNewMessageDeferringDelete() before resetting lane state. (extensions/telegram/src/bot-message-dispatch.ts:1290, e60a700a27d4)
• Deferred cleanup contract: The reused primitive captures the superseded message id, resets the stream generation, and schedules detached deletion with a minimum delay; it also marks in-flight first sends so late stale previews are deleted. (extensions/telegram/src/draft-stream.ts:670, f68af6484665)
• Primitive regression coverage: Existing tests verify that a replacement message is sent before the old preview is deleted, that rotation with no live message is harmless, and that an in-flight superseded first send is cleaned up. (extensions/telegram/src/draft-stream.test.ts:408, f68af6484665)
• Dispatcher regression coverage: The new test models two reasoning segments separated by onReasoningEnd and verifies repositioning occurs before the replacement update, the direct force path is not used, and the replacement receives a new message id. (extensions/telegram/src/bot-message-dispatch.test.ts:4895, e60a700a27d4)
• Feature-history provenance: Commit 3932f4abb45c introduced the deferred-delete repositioning primitive specifically to prevent Telegram delete-then-repost viewport jumps; the associated merged PR was fix(telegram): distinguish and render streamed reasoning/commentary progress lanes #98907. (extensions/telegram/src/draft-stream.ts:670, 3932f4abb45c)

Likely related people:

• Peetiegonzalez: Authored the current-main commit that introduced and tested the Telegram post-new-then-delete-old repositioning primitive reused by this PR. (role: introduced deferred-delete behavior; confidence: high; commits: 3932f4abb45c; files: extensions/telegram/src/draft-stream.ts, extensions/telegram/src/draft-stream.test.ts, extensions/telegram/src/bot-message-dispatch.ts)
• steipete: Was assigned this PR and force-pushed the current reasoning-lane integration, and has substantial recent history in the central Telegram dispatcher path. (role: recent implementation reviser; confidence: high; commits: e60a700a27d4, 3f402f2c4856; files: extensions/telegram/src/bot-message-dispatch.ts, extensions/telegram/src/bot-message-dispatch.test.ts)
• obviyus: Recently maintained Telegram draft-stream rendering and transport behavior adjacent to the lifecycle primitive used here. (role: recent adjacent contributor; confidence: medium; commits: f48ff25b3be3, e8b142feb117; files: extensions/telegram/src/draft-stream.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.

• reviewed 2026-07-02T07:41:01.811Z sha feb0dbc :: needs real behavior proof before merge. :: none