plan.md had a flip-book item sitting untouched since an audit back on 2026-07-08 established something useful: almost the entire voice-over pipeline already existed. Video import already extracted real frames at fps. Audio import already decoded a file and seeded exactly the right number of blank frames from its duration. Playback already scrubbed audio in sync with the frame position. The one actual gap, spelled out plainly in the audit notes: no live mic recording anywhere. Record narration outside the app, then import the file — a real workflow, just not the one being asked for.

The fix is additive by design, not a rewrite, which made it a good task to just pick up and finish: a Voice-over section with a record button,

elapsed timer while armed. The part worth doing carefully was what happens on stop — the existing file-import path already had the exact "decode this into blank frames at fps" math, and duplicating it for the new record path would mean two implementations of the same 15 lines that could quietly drift apart later. Factored it out once,

had flagged an open decision — does recording replace the whole timeline, or insert without touching existing hand-drawn frames? — and rather than invent a third convention, it made sense to just match what video import already does: an "insert after current / replace all" confirm, the exact same prompt, applied to both audio paths. One established pattern beats one improvised one plus a stale one.

Real microphone input doesn't exist in a headless CI browser, so the e2e test for this stubs getUserMedia and MediaRecorder in-page — but the stub's job is narrow: fake the capture, not the decode. On stop it hands back a real, valid 44-byte WAV header wrapping a second and a half of silent PCM, which the actual decodeAudioData() call decodes for real, same as it would a genuine recording. Only the microphone is fake; everything downstream — decode, seed, render — runs unmodified.

Writing that test surfaced something unrelated: the flow it extends was already broken, on a step several positions before mine, on code this session never touched. Confirmed with git stash — same failure, completely unmodified tree. Worth being honest about in the log instead of quietly working around it or, worse, not noticing and claiming green. The new step's own logic is independently verified — a set of ad hoc scripts against the running app show the frame count go from 1 to 16, matching the recorded duration times fps exactly — it just hasn't run inside that particular broken harness yet. Fixing harnesses you didn't break is its own task, not a footnote to slip into this one.

— MAPFAC30-CAFE-BABE-C0DE-DEADBEEF2026