feat(AIMessage): add audio content block for inline playback

[abroa01]

Summary

Adds an audio content block to AIMessage so chat bubbles can render an inline waveform AudioPlayer. This mirrors the existing image/file content-block pattern.

Changes

• types.ts — add 'audio' to the AIMessageContent.type union and optional audioUrl, mimeType, duration fields. The existing text field doubles as the audio label.
• AIMessage.tsx — render <AudioPlayer variant="waveform" showTime showPlaybackRate /> when a content block of type audio carries an audioUrl.

Motivation

Consuming apps (e.g. Ozwell) capture audio during dictation and want users to play back the original recording inline next to its transcription to verify accuracy. The existing AudioPlayer component already supports this; this PR just lets AIChat/AIMessage surface it as a content block.

Notes

• Backwards compatible — purely additive to the union and props; existing blocks render unchanged.
• No new dependencies (AudioPlayer is already part of the package).

Why are we doing it ?

Why bluehive-ai "just worked" but ozwell didn't

The difference is who owns the chat rendering, not the AudioPlayer component itself.

• The AudioPlayer docs "Chat Message" story you saw is hand-rolled — it builds the bubbles itself with raw <div> + <Avatar> + <AudioPlayer>. It does not go through AIChat/AIMessage:

  <div className="rounded-2xl bg-neutral-100 ...">
    <AudioPlayer src={...} variant="compact" showTime />
  </div>

  bluehive-ai rendered its own bespoke message bubbles the same way, so it could drop <AudioPlayer> anywhere it liked. Nothing stopped it.

• ozwell does not hand-roll bubbles. SessionPage.tsx delegates the entire conversation to one component:

  <AIChat messages={messages} ... />

  AIChat owns the message list and renders each message through AIMessage, which switches on content.type (text/tool_use/thinking/code/image/file) and returns null for anything it doesn't recognize.

The crux: AIChat has no escape hatch for custom content

I checked AIChat.tsx. The only render hook it exposes is renderTextContent, and that fires for text blocks only. There is:

• no renderMessage / renderContent prop,
• no children per message,
• no generic per-block override.

So while ozwell renders via AIChat, there is no supported way to put an <AudioPlayer> inside a bubble unless AIMessage understands an audio block. That's the whole reason for the mieweb/ui change — and my change mirrors the already-merged image/file block pattern, so it's exactly how the library is designed to grow.

Options

Option	What it means	Cost	Verdict
A. Keep PR #285 (audio content block in AIMessage)	+1 additive block type, identical to image/file	tiny, reusable, library-consistent	✅ Recommended
B. Stop using AIChat, hand-roll our own bubbles in ozwell (like the story / bluehive)	Re-implement the message list ourselves	Large rewrite; lose AIChat streaming, tool calls, composer, suggestions, timestamps, avatars	❌ Throws away why we adopted AIChat
C. Abuse renderTextContent to sniff a marker and inject AudioPlayer	Hack on the text render-prop	Fragile, fires only for text, violates the contract	❌

Bottom line: Yes, we genuinely need the mieweb/ui change as long as ozwell renders the session via AIChat. The "Chat Message" story isn't using AIChat at all — it's the hand-rolled path, which is option B. Reusing the existing AudioPlayer is exactly what PR #285 does; it just makes AIChat able to host it.

[cloudflare-workers-and-pages]

Deploying ui with    Cloudflare Pages

Latest commit:	fe8a971
Status:	✅  Deploy successful!
Preview URL:	https://297626fa.ui-6d0.pages.dev
Branch Preview URL:	https://feat-ai-message-audio-block.ui-6d0.pages.dev

View logs

[Copilot]

Pull request overview

Adds support for rendering inline audio playback inside AI chat messages by introducing a new audio content-block type and mapping it to the existing AudioPlayer component.

Changes:

• Extends AIMessageContent.type with a new 'audio' block type and adds audio-related fields (audioUrl, mimeType, duration).
• Updates AIMessage content rendering to show an inline waveform AudioPlayer when an audio block includes an audioUrl.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/components/AI/types.ts	Adds an audio content-block type and associated metadata fields to the message content model.
src/components/AI/AIMessage.tsx	Renders AudioPlayer for audio content blocks that include an audioUrl.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

[garrity-miepub]

Looks good! Nice addition to the ai messaging! Just need to fix the CI lint errors

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

[abroa01]

@garrity-miepub , Re-review please.

[garrity-miepub]

We might eventually want to update the waveColor to use a primary color so it renders batter in dark mode, but i think we can get this merged as is and do a fast follow to explore wave color in dark mode.