The script was cleaning Tauri's APP_ID dir
(~/Library/Application Support/com.debpalash.omnivoice-studio) but the
Python backend writes to ~/Library/Application Support/OmniVoice — a
separate hardcoded path in backend/core/config.py::get_app_data_dir().
Result: "🧹 Cleaning all OmniVoice data for fresh prod emulation" was
deleting an empty directory while the real user data (SQLite db, voice
profiles, dub jobs, outputs, logs) sat untouched. Developers running
desktop-prod thought they were testing a clean install path, but were
actually testing on accumulated state.
Fix: add a BACKEND_DATA variable and a 1b cleanup step targeting the
backend's actual data dir. Per platform:
- macOS: ~/Library/Application Support/OmniVoice
- Linux: ~/.omnivoice
- Windows: %APPDATA%/OmniVoice (not in this script; Windows uses .bat)
Surfaced while running `bun desktop-prod` for the first time today on a
clean tree — the .app launched fine but Settings showed a pre-existing
voice profile from a prior session, contradicting the "fresh" claim.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
