# Deliberation: general — Gemini 3 Pro (Preview)

**Date**: 2026-03-18 12:16
**Model**: Gemini 3 Pro (Preview)
**Type**: general
**Artifact**: ## Cloud Download for Export — Draft Proposal  ### Problem Cloud tracks cannot be included in DAW ex

---

Here is the critique of the Cloud Download for Export proposal.

### Analysis & Critique

**1. Is the analysis correct and well-supported?**
The core analysis identifies the correct gap: `MixExporter` skips cloud tracks because it only handles local paths. The proposed solution (download-before-export) is logically sound for an MVP. However, the proposal is too optimistic about file system mechanics and network reliability.

**2. Errors, Gaps, and Unsupported Conclusions:**

*   **Assumption on File Extensions:** The proposal assumes "File extensions can be inferred from the URL path." This is risky. Modern CDNs or signed URLs often obscure extensions (e.g., `.../stream?id=123`). If you save a file without an extension or the wrong one, AVFoundation or the target DAW (Audition/Bitwig) may fail to read it.
    *   *Correction:* You must read the `Content-Type` header or `Content-Disposition` header from the response if the URL path extension is missing or generic.
*   **Concurrency limits:** The architecture sketch implies iterating cloud tracks in the exporter and calling `download` potentially in parallel (or serially, it's ambiguous). Streaming 50 cloud tracks simultaneously will choke the network or hit server rate limits (Nginx default config).
    *   *Correction:* Use a `TaskGroup` with a maximum concurrency limit (e.g., 4 concurrent downloads).
*   **Cache Invalidation:** The proposal suggests checking `~/Library/Caches/...` to see if the file exists. It does *not* address what happens if the cloud file has changed but the filename (trackId) remains the same.
    *   *Correction:* At minimum, check file size or `Last-Modified` headers against the local file, or accept that exports might be stale.

**3. What would you add, change, or challenge?**

*   **Handling "Unprotected" Files vs. Auth:** The context states "File-server routes... do NOT use with-user auth macro." However, `ChadMusicAPIClient` has `authHeaders`.
    *   **Challenge:** Even if *currently* unprotected, your `DownloadService` should support injecting `authHeaders` into the `URLRequest`. Do not build a service that assumes public access if the client already has auth capability. It prevents future breakage if server security is tightened.
*   **Export Failure Strategy:** The proposal adds a network dependency to the export process. If 1 out of 20 tracks fails to download, does the whole export fail?
    *   **Recommendation:** Implement a strict "all or nothing" policy for the critical export, or prompt the user: "3 files failed to download. Export valid files anyway?" The current proposal ignores this UX edge case.
*   **Temp vs. Cache:** Storing in `~/Library/Caches` implies persistence. If you do this, you need a cleanup policy. Otherwise, MixBoard effectively duplicates the user's cloud library on the obscure local disk over time.
    *   **Recommendation:** For an *Export* feature, prefer a temporary directory that is wiped after the export session, *unless* you specifically want to build an "Offline Mode" later. Don't conflate "Caching for Export" with "Offline Library."

**4. Check for Hallucinations:**

*   `ChadMusicAPIClient`: User provided context. **[VERIFIED]**
*   `MixExporter.copyAudioFiles`: User provided context. **[VERIFIED]**
*   `ChadTrack`: Plausible model name based on context. **[VERIFIED]**
*   Audition, Bitwig, REAPER: Real DAWs. **[VERIFIED]**
*   `UploadService`: User provided context. **[VERIFIED]**

No hallucinations detected.

### Specific Recommendations

1.  **Refine File Naming:** Do not rely solely on URL strings.
    ```swift
    // Pseudocode correction
    let response = try await session.data(for: request)
    let ext = response.suggestedFilename?.pathExtension ?? "wav" // Fallback essential
    ```
2.  **Add Cancellation:** The export UI likely has a "Cancel" button. Ensure the `DownloadService` tasks respect Swift cancellation (`Task.checkCancellation()`) so a cancelled export doesn't leave 500MB of phantom downloads running in the background.
3.  **Validate Downloaded file:** Before returning the URL, perform a quick `AVAsset(url: ...).isReadable` check. A 200 OK response could still result in a partial/corrupt file (e.g., 1kb HTML error page saved as .wav).

<details>
<summary>Session State</summary>

**Blocking findings**:
- **Ambiguous Requirements**: No failure policy defined (partial export vs. fail all).
- **Performance**: Missing concurrency limits on batch downloads.
- **Safety/Correctness**: Risky assumption on file extension inference from URL only.

**Advisory findings**:
- **Cleanup**: Lack of cache pruning strategy (disk bloat risk).
- **Robustness**: `DownloadService` should check `Content-Type`/`Content-Disposition`.
- **UX**: Need explicit "Cancel" handling in the download tasks.

**Decisions**:
- Proceed with `DownloadService` but scope it to *Export* specifically initially.
- Enforce auth capability in the download request even if server is currently open.

**Open Questions**: 
- Does `ChadTrack` metadata contain the file extension, or must it be derived strictly from the network response?
- What is the timeout policy for a large file download (e.g., 5 mins)?

**Key Entities**: 
- `DownloadService` (New)
- `MixExporter`
- `ChadMusicAPIClient`
- `URLSession`
</details>