Code Review: StemDeck — LUME Stage 1 (sample-locked 4-stem playback)

> Meta-review (6-pass parallel + adversarial contrarian round) of commit `c3559889` > on branch `feat/femto-only-bar`, repo `Comp-Core`. > Reviewed files (NEW code only): > - `core/audio-media/cc-echelon/crates/audio-engine/src/stem_deck.rs` (963 lines) > - `core/audio-media/cc-echelon/crates/audio-engine/examples/stem_deck.rs` (167 lines) > Surrounding crate (`loader.rs`, `param_control.rs`, `fx.rs`, `lib.rs`) read for primitive-usage judgement only; findings are scoped to StemDeck. - **Findings**: 21 total — **2 Critical**, **6 High**, **9 Medium**, **4 Low** - **Cross-Cutting Patterns**: (1) `render()` is treated as real-time-safe but is not — it does heavyweight per-sample work and can be driven into pathological states; (2) the API has no guard against being driven into silently-wrong states by a Stage 2 consumer (`StemConductor`); (3) no validation that the four stems of a "set" are actually consistent (length, content); (4) `f32`-as-`usize` casts saturate/truncate silently across the transport math. - **Overall Health**: Solid, well-documented, well-tested **functional core** with a genuinely good sample-locked-playhead design and strong analytic tests. **Not yet real-time-safe** and **not yet misuse-resistant** — both are blocking for the stated downstream use (audio-callback rendering + `StemConductor` driving the API). The bugs are real and concentrated in two areas: `render()` RT-safety and transport/loop edge cases. None are security-exploitable in the classic sense (local file inputs only), but several cause audible failure or silent drift. | ID | Description | File:Line | Fix | |----|-------------|-----------|-----| | **X1** | `render()` is documented and intended as an audio-callback path, but it is **not real-time-safe**: it runs `FilterFx`/`DelayFx`/`ReverbFx` `process_sample` per sample with `tan()`/`exp()`-class math and modulo ring-buffer indexing inline, calls `out.fill(0.0)` on the whole block, and re-evaluates branch-heavy loop logic every frame. On a real Demucs set (4 stems, full reverb = 8 comb + 4 allpass per channel) this is a large, unbounded-by-set-size per-block cost with no headroom guarantee. If `render()` is called directly from the CPAL callback it will glitch under load. | `stem_deck.rs:568-630` | Decide the contract explicitly. Either (a) document that `render()` runs on a **worker thread feeding `ChannelReceiver<RenderBatch>`** (the pattern `lib.rs:259-300` `RingCallback` already establishes — the callback only does a `copy_from_slice`), and state that in the doc-comment; or (b) if it truly runs in-callback, pre-compute filter coefficients on parameter change (not per sample) and bound worst-case cost. Right now the doc-comment claims callback use without meeting callback constraints. This is the single most im