mixboard/.orchestra/deliberations/2026-03-18-120318-Gemini-3-Pro--Preview--challenge.md

Deliberation: challenge — Gemini 3 Pro (Preview)

Date: 2026-03-18 12:03 Model: Gemini 3 Pro (Preview) Type: challenge Artifact: ## Cloud Download Brief (Draft) ### Problem Cloud tracks in MixBoard playlists cannot be exported t

---

Here is a devil's advocate critique of the Cloud Download Brief.

1. Challenge: The "Download" vs. "Cache" Identity Crisis

You have framed this primarily as a "Download" feature with a goal of persistent storage ("Track model update"). I argue this is the wrong mental model for v1 and actually increases risk.

The premise risk: If you mark a cloud track as "downloaded" and update its filePath in SwiftData, the user (and the app) now treats it as a local file.

• What if the user deletes the file outside the app? The app thinks it has a local file but filePath is dead.
• What if the user wants to "remove download"? You now need UI to revert the Track state back to cloud-only.
• Copyright/Licensing: Hosting a "Download" button implies ownership. Caching for export implies a temporary technical necessity.

Alternative Framing: Treat this as Just-In-Time (JIT) Staging, not Library Downloading.

• Do not persist the file path to the Track model permanently.
• Download to a temporary staging folder during the export process.
• Pass these temp paths to the Exporter.
• Delete them when the export finishes (or fails).

This avoids the complex state management of "Hybrid" tracks (Cloud but Local) and side-steps the entire persistence question until Phase 2.

2. The Weakest Link: The "Transient" Data Model

The brief notes a massive tension: "ChadTrack is a transient Codable struct... while Export flow works with Playlist -> Track (SwiftData)."

You identified the risk, but you didn't identify the blocking implication.

• Scenario: A user is browsing the generic "Chad Music" tab (transient structs). They hit "Export Playlist."
• The Problem: There is no Playlist. There are no Track objects. You cannot attach a file path to a ChadTrack struct and expect it to work with the existing MixExporter logic that likely iterates over Track entities.
• The Risk: You are building a download engine for an entity (Track) that might not even exist for the items the user wants to export.

Required Verification: You must confirm if a ChadTrack is converted into a Track entity when added to a playlist. If not, the entire Exporter architecture needs refactoring to accept ChadTrack + URL tuples, not just Track objects.

3. Hallucination and Fact Checking

• ChadMusicAPIClient.streamURL(for:): You mention the user constructs an HTTP URL via this method.
  • Finding: [UNVERIFIED] verify this method serves files directly. If the API returns a presigned URL or requires a session token in the header, simple HTTP GET downloads via DownloadService will fail with 403 Forbidden.
• Track @Model: You cite isCloud, cloudStreamPath, and cloudTrackId fields.
  • Finding: [UNVERIFIED] Ensure these fields actually exist on the Track model. If Track was designed purely for local files (implied by the original limitation), these fields might be theoretical or missing.
• Audition, CueSheet, DAWProject, EDL, M3U: These are standard formats.
  • Finding: No hallucinations detected.

4. Alternative Scope: The "Offline Library" Trap

The brief suggests "Track model update — store cached file path so downloaded files persist across sessions."

Challenge: This significantly expands the scope from "Export" to "Offline Mode." If you persist the path:

1. The Player will try to play the local file instead of streaming. (Is the decoder ready for that?)
2. You are now responsible for disk space management. (Do you need a "Clear Cache" button?)
3. You change the source of truth for the audio.

Recommendation: Reject persistence for this slice. Download ONLY for the duration of the export.

5. Security & File System Risks

The brief mentions: "File naming: use server path structure, or flatten to trackId/filename?"

The Risk: Using server path structures blindly is a security vulnerability (Path Traversal). If the server dictates the filename and sends ../../etc/passwd, you have a problem. Better approach: Always generate a flattened, sanitized filename specifically for the export folder (e.g., UUID + extension). Do not trust the server's filename structure.

Summary

No specific blocking hallucinations found, but strict verification of the Track model schema is required.

Session State

**Blocking findings**: - **Ambiguous Requirements**: The relationship between transient `ChadTrack` and persistent `Track` in the context of Playlists is undefined. We cannot build an exporter bridge without knowing if the source object is a `Track` or `ChadTrack`. - **Scope Violation Risk**: Persisting the file path changes the feature from "Export Support" to "Offline Library," inviting high-maintenance state management issues. **Advisory findings**: - **Path Traversal Risk**: Do not use server-side directory structures for local file naming. - **Auth Assumption**: Verify `ChadMusicAPIClient` endpoints do not require headers for direct file downloads. - **[UNVERIFIED]** `ChadMusicAPIClient.streamURL(for:)` - **[UNVERIFIED]** `Track` model fields: `isCloud`, `cloudStreamPath`, `cloudTrackId` **Decisions**: - Recommend adjusting scope: **JIT Staging** instead of **Persistent Download**. Files exist only during the export lifecycle. **Open Questions**: - Does adding a `ChadTrack` to a Playlist instantiate a `Track` row in SwiftData? - Does the Player logic (`AVPlayer`) automatically prioritize a local `filePath` if it exists, or is it hardcoded to check `isCloud`? **Key Entities**: - `ChadTrack` (transient struct) - `Track` (SwiftData model) - `DownloadService` - `MixExporter`