# Deliberation: scope — GPT-5.3-Codex

**Date**: 2026-03-17 22:09
**Model**: GPT-5.3-Codex
**Type**: scope
**Artifact**: ## Shaped Brief: Cloud Upload from MixBoard  ### Problem MixBoard can browse and stream the chad-mus

---

## PM Scope Review (ruthless cut)

### Verdict
**v1 is too big for the stated appetite.**  
Current scope mixes: multipart ingestion, async job control, beets orchestration, dedup policy, progress UX, and infra config (Nginx/sudo/path mapping). That is not “medium.”

### Cut to smallest useful v1 (80% value)
Ship only:

1. **Single-file upload** (not multi-file) to `/api/upload`
2. **Authenticated** via `with-user` **[UNVERIFIED]**
3. Save to staging, run `beet import --move --quiet` in background
4. Return **job accepted** + minimal status endpoint (`queued|running|done|failed`)
5. Client shows:
   - upload byte progress
   - then indeterminate “Processing…”
   - final success/failure
6. Manual “Refresh library” button (no automatic rescan coupling in first cut)

This delivers core value: upload from MixBoard without SSH.

---

### What is under-scoped right now (will create expensive follow-up)
- **Duplicate semantics are weak** (`artist+title+duration`) and likely noisy **[CHECK THIS]**.  
  Either drop dedup from v1, or define exact source-of-truth (beets/plugins) **[UNVERIFIED]**.
- **Progress requirement is ambiguous**: upload progress vs server import progress.  
  Split explicitly or QA will fail acceptance.
- **Concurrency policy missing**: single-worker queue vs parallel imports.  
  For v1, force **single-worker**.

---

### Hidden dependencies likely to blow estimate
- Multipart parsing support in Woo/Clack **[UNVERIFIED]**
- Request body buffering behavior (memory risk for FLAC) **[UNVERIFIED]**
- Event-loop blocking if subprocess runs inline
- `sudo`/permissions between web process and `uploader` user **[UNVERIFIED]**
- Beets non-interactive behavior and duplicate handling **[UNVERIFIED]**
- Nginx `client_max_body_size` claim “default 1MB” **[CHECK THIS]** (common, but environment-specific)
- File ownership/cleanup in staging after import/failure

---

### Cheaper alternative nobody should ignore
For single-user personal setup, cheapest path may be:
- **Out-of-band file transfer** (Syncthing/rsync/SSHFS/watch folder), then
- MixBoard calls a tiny authenticated `/api/import-staging` trigger.

This avoids multipart parsing and large-body HTTP handling entirely.

---

### Hallucination detection
Specific claims needing verification:
- `ChadMusicAPIClient`, `CloudBrowserView`, `StreamingPlayer` names **[UNVERIFIED]**
- Existing `with-user` macro behavior **[UNVERIFIED]**
- chatikbot import pipeline details and `uploader` sudo flow **[UNVERIFIED]**
- “rescan thread” existence **[UNVERIFIED]**
- Woo multipart/body-stream characteristics **[UNVERIFIED]**
- Nginx default limit statement **[CHECK THIS]**

No clear fabricated entity detected, but many implementation details are unconfirmed.

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

**Blocking findings**: Ambiguous acceptance (progress definition, dedup definition); performance risk (event-loop blocking + large upload memory behavior); untestable requirement as written (dedup correctness without canonical source); scope violation vs appetite (too many cross-layer concerns in v1)  
**Advisory findings**: Cut multi-file; use single-worker queue; decouple auto-rescan from upload success; add staging cleanup policy; verify sudo/permissions and nginx limits early  
**Decisions**: Recommend redefining v1 to single-file + async job status + basic UI states; defer dedup and multi-file to v2 unless beets-native behavior is already proven  
**Open Questions**: Is dedup truly required in v1? Is there existing beets duplicate policy? Can Woo stream to disk safely? Who controls nginx/sudo config rollout?  
**Key Entities**: MixBoard, chad-music, Woo, Clack, Myway, SBCL, beets, `with-user`, `/api/upload`, `/api/rescan`, `ChadMusicAPIClient`, `CloudBrowserView`, `StreamingPlayer`, `server.lisp`, `config.lisp`, Enikesha

</details>