docs/v2: DJ prompt optimisation (DSPy/GEPA), RunPod vs Runware, taste-dynamics measures

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K6897PWcUEwHiqZMcVnNF6

docs/v2/NOTES-FROM-POC.md

@@ -92,6 +92,44 @@ section is the iOS lessons; they apply to any client). Nothing here is decided u
   people names from tags; check persona text on save; report button on shared content; per-station explicit
   setting (hard rules stay on). Venice is permissive, so the guard has to be ours.
 
+## DJ prompt optimisation: DSPy / GEPA (proposed, not started)
+
+- Treat the DJ as a DSPy program: station context + taste + recent reactions -> the sheet (strict schema). The
+  instructions to optimise are the next-track prompt, the break prompt, `MODE_BRIEF` and persona framing.
+- **GEPA** fits because it learns from *textual* feedback via reflection on traces, and gandora has lots of it
+  (typed reactions, timed emojis, keeps/skips). It keeps a Pareto frontier of instructions, which matches
+  per-station taste (an ASMR-best prompt and a freestyle-best prompt both survive).
+- Dataset: exported station histories (sheets + the reactions that followed; `stats.html` EXPORT JSON has most of it).
+- Metric, two layers: (1) cheap checks: schema valid, avoid-list respected, no real artist/person names, variety
+  vs recent tracks; (2) an LLM judge for "does this sheet follow from these reactions", whose reasoning is the
+  feedback text GEPA reflects on. Human keep rate stays the final arbiter (judges can be gamed).
+- Run offline in Python against the same Venice models via the worker; promote winners as pinned Langfuse prompt
+  versions (V2) or port back into the DJ prompt code (POC). Hold out stations; A/B on keep rate before switching.
+
+## Renderer economics: Runware vs self-hosted (RunPod), 22 Oct
+
+- Per 2-min turbo track: Runware $0.0045; RunPod serverless roughly the same when warm, worse with cold starts
+  (~30–60 s loading ~9 GB of weights); an always-on 4090 pod (~$0.34/hr community, ~$245/mo) only beats Runware
+  above ~75 tracks/hr sustained. XL roughly doubles both sides.
+- Functionality is the real difference: Runware has text2music, reference audio, repaint/extend, strength,
+  variations; self-hosting adds LoRAs, stems/extract/lego/complete, full planner-LM and sampler control.
+- Plan: Runware stays default. RunPod pod by the hour for LoRA training; a RunPod/Modal serverless endpoint only for
+  renders that need a LoRA or stems, selected by the worker from the sheet (e.g. `lora: "..."`).
+
+## Taste dynamics: measurement ideas (research, not product yet)
+
+- **Forward vs time-reversed training:** retrain the brain on a station's reactions in reverse order and compare
+  predictions; the gap = path dependence (how much is recency vs a stable summary).
+- **Signed area of the taste path** (Lévy area of c(t), the station centroid over time): antisymmetric under time
+  reversal, so it separates a consistent drift/turn (non-zero) from wandering (cancels) and collapse to a default
+  (little area). Cheap enough to show as a curl indicator on the TASTE view.
+- **Telephone loop:** sheet -> render -> (future) audio embedding -> DJ reads it back -> next sheet. Station drift
+  splits into noise (diffusive), attractor (collapse to generic, a bug) and holonomy (direction-dependent turn,
+  maybe a feature). Reversing loop order flips holonomy but not the other two.
+- Context: a math thread on holonomy / Berry phase across embedding-space charts (xRAG projector as a transition
+  map; loop products of Procrustes maps between embedding models as discrete holonomy). Explainer video:
+  `teahubxyz/media` -> `manim/transition-map-narrated.mp4`.
+
 ## POC housekeeping that affects V2
 
 - **The module split is done on the `split` branch** (ES modules, no build step: `app.js core.js covers.js dj.js