[P1] Import audio and preserve reusable clip assets in portable projects #19

Parent plan: #1
Priority / gate: P1 / M2
Requirement: F17 in the PRD
Design: Technical design
Depends on: #18

Outcome

Let users use a local WAV/MP3 file or frozen saved sound as an audio source and keep every dependent project portable and editable.

Scope

• Add local file selection/drop and a saved-sound source picker; never upload to a server or autoplay on selection.
• Preflight/decode required PCM 16-bit WAV and MP3 mono/stereo inputs, show format metadata, and support numeric/visual trim plus stereo average/left/right conversion.
• Enforce proposed 20 MiB/60-second input limits and retain a 1 ms–10 second mono Float32 excerpt at 44.1/48 kHz, with at most 480,000 samples. Bound decode allocation through reliable preflight or a bounded decoder.
• Create immutable hashed PCM assets with channel/trim/resampling provenance and explicit attenuation only when input peak exceeds 1. Keep sample assets outside the drawing-point budget.
• Freeze saved-pad rendered PCM before monitor gain; make asset ownership/reference cleanup preserve dependent project, saved-sound, draft, and undo references.
• Implement complete .sigint.zip project bundle export/import over the F09/F10 adapters, with project/manifest JSON and required PCM files. Preserve asset-free JSON compatibility.
• Use atomic state/storage replacement and revision/intent tokens; show progress and recoverable corrupt/unsupported/quota/missing-asset errors.

Acceptance criteria

• Required WAV/MP3 fixtures decode in current Chrome/Edge, Firefox, and actual Safari; source/target rates, mono/stereo choice, retained sample count, and excerpt timing are visible and correct.
• Stereo averaging and left/right selection match independent fixtures, including opposite-phase stereo cancellation; silence is never automatically boosted and non-finite decoded samples are rejected.
• Compressed-byte, preflight duration/channel, and actual decoded-frame checks enforce the declared limits without treating a post-decode check as protection against allocation.
• Choosing or canceling an import never starts audio or replaces active state with an obsolete result; native decode operations that cannot abort are serialized and their stale results released.
• Using a saved sound as a source captures its immutable pre-monitor clip without playing it; changing monitor volume or editing/deleting the original pad leaves dependent source samples unchanged.
• Bundles carry all required trimmed assets and reproduce the project in fresh browser storage without the original uploaded file or source pad.
• Bounded extraction rejects files over 32 MiB compressed/64 MiB extracted, more than 32 entries/eight assets, oversized JSON or PCM, unexpected/unsafe/duplicate paths, hash/schema errors, non-finite samples, and missing references while preserving the active project.
• A storage failure preserves prior projects/sounds; ref-aware cleanup cannot delete an asset still used by a saved snapshot or undo. Original 10 MiB asset-free JSON imports still work.
• Decode, extraction, cached clips, and render scratch allocations are included in the documented 128 MiB app-owned buffer budget; browser decoder overhead is measured separately.

Validation

Independent PCM/MP3 decode and sample-rate fixtures; corrupt/oversized/archive fixtures; rapid select/cancel and quota failures; source-pad update/delete/undo isolation; fresh-storage bundle round trips; and actual-browser decoder/resource measurements.

Boundaries

Live microphone capture, remote uploads, cloud sync, and arbitrary codec guarantees are deferred. Effect routing/rendering is F18; source reuse does not recursively execute another sound's project.

Implementation evidence

Bounded cancelable WAV/MP3 import, trim/channel conversion, immutable assets and validated portable bundles are implemented. Real Safari and three Playwright engines pass. Branded browser and full browser/decoder peak-memory qualification remain in #16.

Merged work: #26, #28, #29.

Validated CI run · Validation report. The report arrives with the final documentation PR; numerical/browser logs already exist. Release-wide human acceptance and the recorded performance/memory gaps remain explicit in #15 and #16.