Gap G4 — `features.json` Schema Verification

> Verifies the `features.json` files in the 115-track LUME stem library against > both the producer (`process_library.py`) and the consumer > (`StemFeatureSet::parse` in `audio-engine`). The consumer is the binding > contract: it is the code that actually loads the files at runtime. > > Date: 2026-05-21. Task: LUME Gap G4. `process_library.py` emits a superset of every field `StemFeatureSet::parse` reads, with matching names, matching types, and matching array lengths. The parser is built to be permissive (`#[serde(default)]` on every field) and only hard-fails on transport-critical conditions that a correctly-run `process_library.py` cannot produce. No schema mismatch, no name drift, no type drift, no unit drift was found. No code change was required. One environmental caveat is recorded in §6: this run could not pull the live `features.json` files off K11 (`ssh k11`) because the local machine's disk is 100% full, which blocks the Bash tool's command-output path. The verification is therefore a complete static reconciliation of producer code vs. consumer code plus the in-tree Rust test fixture, which is itself a `features.json` instance. A live-sample spot check remains as a recommended follow-up once disk is freed. Location: `core/audio-media/stem-pipeline/process_library.py` (single canonical copy; a workspace-wide search found no other `process_library.py`). It runs Demucs `htdemucs` 4-stem separation, then `extract_features()` (lines 93-161) runs librosa per stem and writes `features.json` via `process_track()` (lines 197-202) to `<output>/separated/<model>/<track>/features.json`.