Version. 0.3 (corrects v0.2 — see below) Date. 2026-07-05 Status. Scoped, ready for build brief. Not built. Repos. loomworks-engine, loomworks.
v0.2 assumed audio should be captured and stored automatically for every voice-dictation session. Operator reconsideration: in a voice-first interface, most utterances are minor and do not warrant permanent audio storage — automatic storage for every capture is waste. Corrected design: recording still runs during dictation (so the audio exists if wanted), but storage becomes an explicit Operator choice made at confirm time, not automatic. This is an Operator-authority point, not just an efficiency one — per the seed's "the system surfaces and signals; the Operator approves," deciding whether to keep a recording is exactly the kind of state transition the Operator should control, not one the system should apply automatically to everything.
The live-dictation path (browser mic → live transcription → sent as text) keeps only the transcript — no audio, nothing to verify against if the transcription is wrong. For content where accuracy matters (e.g. capturing an account from an Indigenous Tribe Elder), there is no way to check the original speech after the fact.
MediaRecorder alongside the existing Web Speech API during live dictation, capturing a real audio Blob for the session — this part is unchanged from v0.2.source_mode: "voice" + source_file_id).source_mode: "voice" is present, which now depends on the Operator's choice at confirm time.No conflict — this correction is directly required by Operator-authority: "the system surfaces and signals; the Operator approves." Automatic storage for every capture would have been the category error the seed names; the two-button design puts the decision where it belongs.
Unifying the two voice-capture mechanisms into one (considered and rejected in v0.2, unchanged). Any change to the file-upload voice path, which already works correctly.