Stage 2 — Compound Synthesis (Sequential, Linear)

Stage 2 — Compound Synthesis (Sequential, Linear)

> Output of Evo3 Stage 2 for LUME creative engine maturation.
> 6 paths from Stage 1 (A bridge-first, B director-first, C pod-first, D reel-first, E maximalist, F minimalist) compounded into one ranked plan.
> Sequential rule: Step 1 starts from ground truth; Steps 2-8 each inherit ALL prior steps and resolve conflicts explicitly.

---

Step 1 — Ground truth (no inheritance)

Anchor in stage0-research.md, not in any path. Five claims from Stage 0 are load-bearing for Stage 2:

1. The music engine is deployed, not undefined. (stage0 §C.6, §C.8.) Echelon-Rust → SAN-MLX (135K params, V5 weights, 5,408 real pairs, val loss 0.028) → AudioEngine.swift (2110 lines, AVF + Rust-FFI hybrid). Zero MusicGen/AudioCraft/Riffusion installs anywhere. The gap is integration bridges, not training. This invalidates memory §2's Phase A/B/C framing.
2. Three competing AI directors exist with no canonical owner. (stage0 §A.4/A.5/A.9, Top-3-facts #1.) `MotionMixDirector` (macOS multicam hub), `MotionMixLiveDirector` (iOS show-runner overlay), `StageView/Services/{GeminiLiveService,PhotoshootDirector}` (iPad performer-facing). All three are actively maintained.
3. Universal sled does not exist; pod is K11-locked. (stage0 §E, Top-3-facts #3.) `lume-pod.scad` and `pod_compute_sled` only have K11_VESA_PITCH=75 holes, K11-bottom-fan-intake/K11-top-fan-exhaust grid, K11-USB-A cable channels. Mac mini M4 has zero mounting points. Memory's "3hr port" estimate is wrong; it's a 1-2 day rewrite due to fan topology differences.
4. Wave 8 is shipped (6 commits) but not pushed. Mac1 main has `da8d1478`/`c5194f92`/`2a6e6b25`/`95387a02`/`8139a931`/`8fb6fe75`. K11 NSSM services live and reboot-survival proven. Mocopi-pro in mail; iPad LUMM fallback is the demo skeleton. (stage0 §A.1, §B.1.)
5. Production-system constraint applies. Memory §7b clarification: "Codex briefings going forward must label this as a production system so future agents don't treat it as throwaway scaffolding." This shapes the don't-touch list and forbids "good enough" handwavy work.

Don't-touch list (verified, must propagate to every Codex briefing):
- Wave 8 wire format magics: `LUME` (0x4C554D45), `LUMD` (0x4C554D44), `LUMF` (0x4C554D46), `LUMM` (0x4C554D4D), `LUMC`. Byte-for-byte pinned via `tests/test_wire_format_golden.py`.
- 21 Unity component public APIs — additive only, no field renames or signature changes.
- K11 NSSM service definitions (`install-services.ps1`) — runtime args may be flagged but service registration stays untouched.
- Wave 8 commits not-pushed — Mohamed pushes manually after Mac4 verification.
- LUMF wire format `audio_pub.py:send_lumf` byte order (golden-bytes test on Mac1).

---

Step 2 — Music-gen pipeline decision (resolves Path A vs F vs the chain prompt's framing)

Conflict: Path A (ship 3 bridges), Path F (ship 1 bridge), the chain prompt asks for "Phase A symbolic / B fine-tune / C bespoke."

Resolution: The chain prompt's phases are wrong by construction because they assume music gen is greenfield. Stage 0 §C.6 proves it isn't. Reframe the phases:

• Phase A (now, this week) = ship-bridge-now. Bridge (a) PCM→LUMF goes live. The deployed Echelon-SAN-AudioEngine becomes the visible audio source for Unity. This is what the chain prompt's "Phase A (immediate, no training): symbolic music — feed the 7 OSC channels into Strudel patterns" should have said — except the engine is richer than Strudel patterns alone.
• Phase B (weeks 2-4) = condition-on-OSC-channels. Bridges (b) OSC→ParamMapper and (c) SAN→Strudel close the feedback loop. Unity's 7-channel motion vector starts modulating SAN's pattern decisions. The 7 OSC channels become real conditioning inputs, not display-only.
• Phase C (month 2+) = fine-tune-SAN-on-stems-when-stems-located. SAN already trains in MLX (5,408 pairs at val loss 0.028). The "stems we already have" the user mentioned are on HD1 (`/Volumes/HD1/training-phrases/device_captures/` per stage0 §C.7), currently unmounted. Phase C = mount HD1, expand training pairs, retrain to V6. No new ML stack needed — same MLX pipeline.

First bridge to ship: (a) PCM → LUMF. Justifications:
- It is the only bridge with public artifact value: a reel hears the engine's audio. Bridges (b) and (c) are invisible in the artifact.
- It produces immediate visual co-reactivity in Unity — Unity's existing audio-driven visuals (LumeAudioFftReceiver) start reacting to the dancer's actual music instead of synthetic K11 audio.
- It is independent of director consolidation, CAD, and HD1. None of those gate it.
- It is the same code as Path D's `AudioCaptureWriter.swift` with one extra consumer (UDP broadcast). One pane builds both, used by reel pane and by visual pane.

This decision sets the priority for Stage 2's pane plan.

---

Step 3 — Director sprawl resolution (resolves Path B vs accept-and-defer)

Conflict: Path B says partition into 3 named roles now; Paths A/D/F say defer until reel ships; Path E says give it its own pane.

Resolution: Partition by role, not consolidate by code, BUT do it as a documentation-first move not a refactor. The protocol spec lands this week; the multicam-server WS bus and FFI schema crate slot in over the following 2-3 weeks. Three reasons:

1. Without a written role partition, the 3 directors keep diverging and the next Codex pane to touch any of them re-derives the question. Path B is right that this is load-bearing.
2. A code-level consolidation (one director) is the wrong move — each director is solving a different problem (multicam session authority, on-set show runner, performer voice loop). The sprawl is a misnamed feature, not a bug.
3. A protocol spec without code is cheap (~1 day) and immediately useful. It documents the partition, it's the artifact every Codex pane references, and it gates the eventual Rust/FFI work.

So this Stage 2 step ships `director-protocol.md` only (Path B's commit 1, doc portion). Multicam-server `director_bus.rs` + `DirectorBusServer.swift` + `DirectorBusClient.swift` (Path B commits 2-3) are scheduled for Wave 9, after the bridges and reel ship. A Stage 3 backlog item with explicit dates.

---

Step 4 — Mac4-vs-K11 stance (resolves Path C vs F)

Conflict: Path C says rewrite the sled this week; Path F says K11 stays in pod, defer to Wave 9.

Resolution: K11 ships verified first, Mac4 mirror is in-flight in parallel but not blocking. Three reasons:

1. K11 is already in production. NSSM services live, Femto Bolt connected, reboot-survival proven (memory §1 + stage0 §B.1). Pulling K11 to put Mac4 in the pod for a reel-ship-week is unnecessary risk.
2. Universal sled CAD work is independent of software work. Path C's commits 1+3 (CAD rewrite + Mac4 launchd plists) don't touch the runtime path. They land in their own pane and don't gate the reel.
3. Mirror as goal stays correct. The user's clarification (memory §7b) says mirror, not replace. Mirror means both — K11 stays as the verified production box, Mac4 becomes the parallel mirror. Path F's "K11 only" is too austere; Path C's "mirror first" is too eager.

Hours estimate refined from Stage 1's "1-2 days":
- CAD rewrite (lume-config.scad consts + pod_compute_sled refactor + vent grid): 6-8 hours. OpenSCAD is fast for someone who knows the codebase; the slow part is validating Mac mini M4 footprint dims (need iFixit teardown read or physical caliper measurement = +2 hours).
- Mac4 launchd plists (3 services, mirror of K11 pattern): 2-3 hours. Pattern exists at `launchagents/synthpub-mac5.plist`; copy + parameterize.
- Camera TCC grants for Femto Bolt on Mac4 (Terminal + Unity Editor + Python venv): 1 hour. One-time but historical Mac4 blocker per memory §7b.
- USB hub + wheel verification + cable test: 2 hours.
- One test print of macOS sled on Elegoo Max + ASA: 5 hours print time + 1 hour fitting.

Total: 17-22 hours of focused work = ~3 working days for one Codex pane in parallel with the reel-ship pane. NOT in the demo critical path; verifies as a side track.

---

Step 5 — Pane plan (resolves Path E maximalist vs Path F 3-pane)

Conflict: Path E wants 7 panes; Path F wants 3. Memory §4 lists 7 candidates.

Resolution: 5 panes, ordered by dependency and reel-criticality. Path E's 7 is too wide (R5 Mohamed-bandwidth risk); Path F's 3 leaves too much on the table (the bridges (b) and (c) are 2-3 day work each, perfectly suited to a parallel pane that doesn't gate the reel).

The 5 panes (final ranked, dependency-ordered):

Deferred / merged into existing panes (per Path F's pruning logic):
- Director protocol spec → folded into P3 as a doc-only deliverable (`director-protocol.md`) since P3 is the docs/push pane. The Rust+FFI implementation goes to Wave 9 backlog.
- Diffusion / training → killed for this cycle. Memory §4 marked it "(optional)"; agreed.
- HD1 mount + Phase C SAN retrain → backlog for Wave 9.
- FirstDate token rotation → backlog (security hygiene, Mohamed handles).
- mocopi-pro activation → wait for mail (out-of-band, no pane).

This gives Mohamed 3 reel-critical panes to focus on (P1, P2, P3) and 2 parallel non-blocking panes (P4, P5) that can run alongside without pulling attention.

---

Step 6 — Coordination protocol (resolves Path E's coordination tax)

Path E correctly identified that 5+ panes need a coordination layer. Stage 2 adopts E's three mechanisms scaled to 5 panes:

1. `[home-path]` — JSON file lists each pane: id, focus, working dir, current task, last-commit-sha, status. Each pane writes its row at session start and on every commit. Registry is read by the daily synth.
2. NUMU events on every commit. Already wired per chain prompt's evo3_hooks.py reference. Other panes see commits in real-time.
3. Daily `/sync-panes` synth (10 min cost). Reads registry + NUMU stream + git logs across the 5 working dirs, emits 1-page Markdown digest. Mohamed runs once per evening. Catches collision before code lands.

Pre-commit don't-touch hook: enforces the don't-touch list at git layer (Wave 8 wire format magics + Unity component public APIs + NSSM .ps1 + push-to-origin gate). Lands in P3's first commit so all subsequent panes inherit it.

---

Step 7 — Reel production plan (resolves Path D's specifics)

The reel from P2 needs concrete pinning. Stage 2's production plan:

• Concept: 30s vertical reel. Title card "MOVE IN LIGHT." Three looks (3 outfits from new clothes), three motion concepts, three Unity LUME shots layered behind.
• Capture media:
• Stills: 8-12 per look × 3 looks = 24-36 stills via ShootView's existing `MainShootView.swift` + `RemoteControlView.swift` (solo shoot capable).
• Motion clip: 1 per look, 10-15s each, captured via MotionMix iPhone with iPad LUMM fallback for skeleton (mocopi-pro is in mail).
• LUME visual: Unity scene recording via `record-unity-reel.sh` — NVENC on K11 (DX12) for 30s. Captures the bar display's actual 1920×440 framing.
• Audio: MotionMixApp's Echelon → SAN → AudioEngine output, captured via P1's `AudioCaptureWriter.swift` running on iPhone during the motion-capture session. WAV stereo 48kHz/16-bit. The music IS the dancer.
• Composite: ShootView's `ReelBuilderView.swift`. Transitions: `dissolve`, `wiperight`, `circlecrop` (verified ffmpeg in stage0 §A.8).
• Platform: Instagram Reels primary + TikTok cross-post. Brand voice from MEMORY.md "Diomande Creative Content Strategy" (no em dashes, no AI-isms, terse).
• Deadline: post by 2026-05-09 EOD. Production wraps 2026-05-08; 2026-05-09 = composite + caption + post.
• Fallback: if SAN-driven audio sounds bad on listen, fallback to a Strudel-real pattern render captured via the same AudioCaptureWriter (still engine-driven). If both fail, last-resort licensed track from `[home-path] FX/` — documented as last-resort.

---

Step 8 — Production-system constraint propagation

Per memory §7b clarification, every Codex pane briefing in Stage 3 must include:

• "Treat as PRODUCTION SYSTEM. Don't break what ships." as a leading line.
• The verified don't-touch list (verbatim from Step 1).
• Mohamed runs all destructive operations manually — no `git push`, no `launchctl unload && load`, no `nssm remove` from any Codex pane.
• Verification before declaration — a pane that says "done" must include a verified runtime check (test pass, packet inspector seen pkt rate, F2 panel screenshot, etc.).
• Production-grade error handling — no try/except: pass; no TODO comments without an issue ID; no print statements that could leak in prod.

---

Synthesis verdict (compound output)

Path F's discipline applied to Path A's first bridge, Path B's documentation-first protocol, Path C's parallel hardware track, Path D's concrete reel artifact, Path E's coordination protocol scaled to 5 panes.

The compound plan ships three things in 7 days:
1. Bridge (a) PCM→LUMF live and verified (P1).
2. One reel posted to Instagram + TikTok (P2).
3. Wave 8 pushed to origin (P3).

In parallel with two non-blocking tracks:
4. Bridges (b)+(c) and director protocol doc (P4).
5. Universal sled CAD + Mac4 launchd plists (P5).

Single dependency edge: P2 depends on P1's `AudioCaptureWriter`. All other panes are independent. P1+P3 commit on day 1; P2 photoshoots on day 3-4; P4+P5 run independently throughout.

The first bridge is (a). The first pane is P1. The first commit is `LumfPublisher.swift`.

Stage 3 (Master Plan) operationalizes this into specific tasks, dependencies, and validation criteria.