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

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

Correction from v0.3: v0.3 only added playback ("Replay") after confirming an item with "Confirm + Keep Voice" — i.e. on Settled items. Held items (image, document) already show "View source" before any confirm decision, letting the Operator check the source before committing. Voice-sourced Held items had no equivalent — no way to hear the recording before deciding which confirm button to use. This is inconsistent with the existing pattern and works against Operator-authority: the Operator should be able to verify what is about to be committed, not only what already was. Corrected: Held voice items get a playback action too, before confirm.

What this adds

A Held item created from live dictation, before any confirm decision, gets a "Replay" action that plays the in-memory recording captured during dictation — the same recording that "Confirm + Keep Voice" would later upload. This mirrors "View source" on Held image/document items.

Mechanism difference from post-confirm Replay

Post-confirm Replay (v0.3) streams the uploaded, stored audio file via the existing source-file route. Pre-confirm Replay is different: the recording has not been uploaded yet — it exists only as a Blob in the browser's memory. Playing it back means serving that in-memory Blob directly (e.g. via URL.createObjectURL), not a server round-trip. This is confirmed as a genuinely separate mechanism, not a re-use of the same button.

Seed check

No conflict. Directly required by Operator-authority ("the system surfaces and signals; the Operator approves") and consistency with the existing View-source pattern on Held items.

Out of scope

No change to the post-confirm Replay mechanism (v0.3, already working). No change to the two-button confirm design itself.