CR-2026-146 — Retain Audio for Live-Dictation Voice Captures

Version: 0.5 (corrects v0.4 — see below)
Status: Scoped, ready for a follow-on build brief. v0.1–v0.3 already built and merged.
Repos: loomworks-engine, loomworks

Correction from v0.4: Confirmed by code trace and by a real test (Operator spoke deliberately unintelligible words): when Web Speech either fails outright (no result at all) or produces empty/garbled text on the silence timer, the current code has no path that surfaces the captured audio to the Operator. Two failure sub-cases, both confirmed in code:

Sub-case A — Web Speech errors out (e.g. cannot recognize the language at all). The recorder keeps running; when the Operator dismisses the error, the recording is explicitly discarded, unresolved.
Sub-case B — Web Speech produces only empty/non-verbal fragments. The panel silently closes with no visual signal. The recorder keeps recording invisibly in the background until the next mic click or the component unmounts.

In neither case is a held item created, and in neither case can the Operator ever hear what was actually recorded. This directly defeats the purpose CR-2026-146 was built for: for content where transcription may fail (an unfamiliar accent, a rare or indigenous language the recognizer cannot handle), the original audio is exactly what's needed to judge whether real, meaningful speech occurred that the system simply could not interpret — and it is the case most likely to be silently lost today.

Second finding: capture may stop mid-speech, not just fail to transcribe

Operator observation: the recording is tied to Web Speech's own lifecycle (dictationRecorder.stop() is only called from Web Speech's own event handlers). If Web Speech gets confused mid-utterance and aborts or resets, the recording may stop with it — before the person finishes speaking. This means the audio itself could be truncated, not just missing a transcript. If true, "keep the audio" would only preserve a partial capture, not the full utterance.

This must be confirmed by code trace before the fix is scoped — does MediaRecorder actually stop when Web Speech aborts mid-recognition, or does it keep running independently until the session genuinely ends? The answer determines whether the fix is only "surface a Replay option on failure" or also "decouple the recorder's lifecycle from Web Speech's confusion-driven resets, so capture continues even when transcription stumbles."

Fix

When live dictation ends without a usable transcript (either failure sub-case), do not silently discard the recording or leave it running invisibly. Surface the failure to the Operator with a Replay option on the captured audio — the same in-memory-Blob playback mechanism as v0.4's pre-confirm Replay — so the Operator can listen and judge: was this meaningful speech the system couldn't transcribe, or genuinely nothing worth keeping. The Operator decides from there (e.g. discard, or manually type what was meant while keeping the audio as the original record).

If the second finding above is confirmed (capture truncates mid-speech), the fix must also ensure the full utterance is captured regardless of Web Speech's confusion — the recorder should not depend on Web Speech staying confident throughout.

Seed check

No conflict. Directly required by Operator-authority: the system must surface what happened, not silently discard or hide it, and the Operator approves what happens next.

Out of scope

Any change to Web Speech's own recognition accuracy (out of this project's control). The two-button confirm design and post-confirm Replay (v0.3, unaffected).