Persist the dictation next to the transcript, and tap a message to compare them

[serge-ivo]

Follow-up to #281, which fixed the visibility of a turn in flight. This is about keeping the
dictation after the turn ends.

The ask

Tap a voice message and see what was captured live (the dictation), instead of only the final
transcript. Then the two can be compared.

Today the comparison is impossible, not just hidden

AgentMessage (agent-types.ts:1) carries:

role · content · channel · userId · toolCalls · toolResults · audioKey · createdAt

There is no field for the live transcript, and nothing client-side ever sends it — the partials
live in browser state and are overwritten by "Transcribing…" at end-of-turn. So for every voice
turn already in the thread, the dictation is gone. Asked "is anything missing from what I
said?", the honest answer is that the platform cannot tell.

Only two artefacts survive: the final transcript (the message) and the audio (audioKey → R2).

Proposal

1. Persist the dictation next to the transcript. One nullable field on the message — the last
partial at end-of-turn — sent alongside audioKey on the same request that already carries it. No
new transport, no new round trip.

2. Tap to switch the bubble between transcript and dictation. Double-tap already replays the
audio, so the gesture vocabulary becomes: read what was sent · read what was heard · hear what was
said. Only show the toggle where a dictation was actually stored, so old turns do not sprout a dead
affordance.

3. Flag divergence. Where the final transcript differs materially from the last partial, mark
it — that is the signal the user has been describing as "it is not capturing everything I say", and
right now it is invisible on both sides. A count of dropped words is enough; the detail is one tap
away.

Retrospective check, for turns already past

The audio is still there, so the question can be answered for existing messages by re-transcribing
voice-audio/:turnId and diffing against the stored content. Worth doing once as a diagnostic
over a real thread — if the recordings contain words the messages do not, that localises the loss
to transcription rather than to capture, and the reverse localises it to the VAD cutting the turn.

That is the measurement neither #281 nor this ticket can substitute for; both make the loss
visible going forward, but only re-transcription says what already went missing.

Cost and scope

• One nullable text column's worth of data per voice turn, bounded by the same size limits as the
  message content.
• Should respect the same retention as the audio — a dictation outliving its recording is odd, and
  clearing the chat already deletes the R2 blobs.
• No change to what is sent to the model. The dictation is a user-facing artefact, not context —
  feeding both versions to the LLM would be strictly worse.

Verification

• A voice turn stores both strings; a typed turn stores neither.
• Tapping toggles; double-tap still replays; a turn with no stored dictation shows no toggle.
• A deliberately clipped utterance shows a divergence flag.
• Clearing the chat removes dictation, transcript and audio together.

[serge-ivo]

Shipped in b09e50e.

Where the dictation lives: one nullable field on the message itself (AgentMessage.dictation), sent on the same request that already carries audioKey. Deliberately not modelled on audioKey — that is a pointer because audio is megabytes; a dictation is two sentences, so a key would only buy a fetch to read a string. It is not a fourth record of the turn either: living ON the message is what gives it the transcript's lifetime for free.

On clear: handleClearMessages deletes the msg: records and returns their audio ids so the route drops the matching R2 blobs. The dictation is part of the record, so it goes in that same delete — dictation, transcript and recording together, no second retention rule to keep in step, nothing to sweep, and no dictation that can outlive its recording.

Stored only where it says something: storedDictation (pure, tested) returns null when nothing was heard live (typed turn, or Whisper on iOS with no dictation gate) and when the two readings agree after normalising case and punctuation. A recovered turn stores nothing by construction — it goes to the composer, not the thread, so it never reaches the send path. Old turns and typed turns therefore sprout no toggle.

Divergence: dictationLoss is a multiset difference over normalised words (ordering is not evidence when two different engines produced the strings; a word heard three times and transcribed once is two words missing). The count shows whenever anything was lost; the warning icon only when dictationDiverged fires. Both are derived on read from the one stored string.

Gesture — the ticket's premise was stale. Double-tap does not replay any more: an onDoubleClick on the bubble hijacked double-click-to-select-a-word and blocked copying, so replay moved to an always-visible speaker button in the message header. Re-adding a bubble tap would have re-introduced exactly that. The toggle is a third labelled control: speaker = hear what was said · toggle = read what was heard · the bubble = read what was sent, and select it. README and platform-docs/voice.md corrected.

Not sent to the model (agent-think maps {role, content}).

Left open, on purpose:

• The Coder Co-pilot. Its turns persist to coding_timeline, so the same field there is a column + changes to lib/coding-timeline.ts and routes/coding.ts — the coding path, owned by another agent this session. useVoice already hands meta.dictation to every consumer; CodingTab drops it today.
• The retrospective re-transcription diagnostic over an existing thread. That is the measurement this ticket explicitly could not substitute for, and it is still the only thing that can say what already went missing.

CI status, stated plainly: no CI run verified this. GitHub Actions is in a declared major outage and the last 24 commits on main are unverified too. Verified locally instead — 4259 unit tests pass, full typecheck clean, size ratchet green, docs-drift green, biome adds no new diagnostic, and a new e2e case passes against a freshly built console with store/console/dist cleared first. The full Playwright run is 70 passed + 1 failure (browser runtime docs show the ProAgentStore runtime architecture) which reproduces identically on a clean checkout of HEAD and is unrelated.