mixboard/.orchestra/deliberations/2026-03-17-220932-GPT-5-3-Codex-scope.md

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.

Session State

**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