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
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:
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.
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."
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.
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.
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).