# 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`