openclaw - 💡(How to fix) Fix Media preflight: carry transcript state into downstream media-understanding to avoid duplicate audio STT [1 participants]

Summary

Channel-level audio preflight helpers can transcribe an inbound voice note before the normal reply pipeline runs, but that transcript state is not carried into downstream applyMediaUnderstanding / attachment selection. As a result, the same inbound audio can be transcribed again on the normal media-understanding path.

Why this matters

• duplicates STT cost and latency for one inbound voice note
• can produce different transcript text between command parsing / preflight body rewrite and the later prompt media pass
• affects multiple channels that use the same preflight pattern, not just WhatsApp

Current structural limitation

Today the preflight call uses a temporary context or temporary attachment state, while the downstream media-understanding path recreates fresh attachments from string fields on MsgContext.

That means attachment-local flags such as alreadyTranscribed do not survive into the later pass.

Scope

This appears to be shared across channels that do preflight audio transcription before reply dispatch, including:

• WhatsApp
• Telegram
• Discord

Possible fixes

Any of the following would give channels a real way to express "audio already transcribed":

1. let applyMediaUnderstanding accept pre-supplied attachment state
2. persist an explicit already-transcribed marker on MsgContext and honor it during attachment normalization / selection
3. let downstream media-understanding skip audio STT when a trusted preflight transcript is already present on context

Notes

This issue is intentionally about the shared SDK / media-understanding seam, not about any one channel-specific preflight implementation.