ACP question from a OneBot/QQ client: recommended richer-media boundary for channel clients?

[happysnaker]

I’ve been building qq-ai-bot, a self-hosted QQ / OneBot 11 transport + ACP agent bridge. One concrete runtime edge I ran into is richer media / attachments.

Current shape:

• text and image are the stable main path
• unsupported richer media like file / voice / video are not silently dropped anymore
• instead, the client threads an explicit "attachment not forwarded" note into the prompt so the agent does not pretend it has already consumed the media

That staging works better than silent failure, but it also made one protocol question much sharper for me:

for messaging-channel clients, what is the ACP-native boundary for richer media that the agent cannot directly ingest yet?

More concretely, in a bot / channel client like QQ / Telegram / Discord:

1. when the end user sends a file / audio / video segment, should the client surface this primarily as:
   • structured prompt context,
   • a standardized attachment/event primitive,
   • or a tool/action request path?
2. if the agent wants to ask the client to send a file back to the user, what is the clean ACP-standard path today?
3. what minimum context should be guaranteed across that boundary so session-local routing stays unambiguous? e.g. session id, channel id, correlation id, media metadata, temp-file lifetime.
4. is there any emerging recommended pattern for "media acknowledged but not yet machine-readable" so clients do not have to invent ad-hoc text conventions?

The reason I’m asking is that bot-style ACP clients hit this pretty early. If the protocol story stays fuzzy, every channel client ends up inventing its own attachment fallback semantics.

Project context if helpful:

• repo: https://github.com/happysnaker/qq-ai-bot
• architecture note: https://github.com/happysnaker/qq-ai-bot/blob/main/ARCHITECTURE.md
• richer-media first-pass issue: feature: document and stage richer media handling roadmap (file / voice / video) happysnaker/qq-ai-bot#8

Not proposing a full spec in this post — mainly trying to understand whether there is already a preferred ACP direction here, or whether richer-media semantics for channel clients are still intentionally open.