Single-page map of the Valeron platform. Use the tabs below to flip between the goal, the data flow, the current state of each component, what we learned today, and the work that's queued up. This is a living doc — regenerate it from a Claude session when the picture shifts.
A real user signs up for Valeron on their phone, pairs with a tracker and robot at a course, triggers a Janice-generated demo sequence, sees their videos in the mobile app under the correct course, ends the session, then opens app.valeron.ai on a laptop, logs in, and sees the same data.
This is a pre-funding demo, not a polished product. Every scope decision should be measured against this one loop. Anything beyond is post-MVP.
Cloud once at pairing, then dark for the round. Heavy data offloaded later via laptop ferry. Expect zero connectivity during play.
Session is cloud-created at start (via start-session edge function). Robot owns play-time data locally. Laptop syncs at end of day.
Robot's devices.course_id is the source of truth. Admin updates it when robot moves. No user selection.
This is the path a round takes from golfer arrival to laptop-ferry upload.
Grouped by repo. Each row tells you what works, what's broken, and what doesn't exist yet.
Two days of work across ace_web + ace_cloud + ace_supervisor + ace_ferry. The critical path is now green — first real pairing loop exists in production history. Along the way we found five latent platform bugs that only surfaced because the loop started actually executing.
2026-04-11 session surfaced that the demo loop serves only one of three real personas. Scope brief at _ace_workspace/briefs/2026-04-11_1700-platform-personas.md captures three lanes:
7 tickets filed (ACE-25 through ACE-31) on next-horizon Feature #2. Not demo-blocking; pilot-critical.
No new column, no migration. Just treat the existing column as mutable and UPDATE it when the robot moves. Patch the edge function to read it as a fallback when the request body omits course_id. This unlocks the entire demo path with a single TypeScript edit and a systemd env change.
Out of 8 courses:
Every field in the Valeron data model belongs to exactly one of three lanes based on who writes it:
Lane 3 has no tables at all today — biggest structural gap after the pairing bug.
Tables actually present in production, annotated with status. Anything flagged NOT-IN-MIGRATIONS is schema drift.
| Table | Rows | Lane | Status |
|---|---|---|---|
| accounts | — | 1 | OK |
| courses | 8 | 1 | OK (content thin) |
| course_features | ~40 | 1 | OK (2 courses only) |
| publish_log | — | 1 | OK |
| devices | 1 | 1 (aspirational) | OK · course_id NOT NULL |
| trackers | 2 | 1 (aspirational) | OK · course_id NOT NULL |
| profiles | 2 | - | OK |
| sessions | 14+ (incl. 1 real) | 2 | OK · first real row 2026-04-11 |
| shots | 36 seed | 2 | OK (needs columns) |
| device_associations | 2 | 2 | DRIFT · device_id still TEXT · ACE-18 |
| captures | ? | ? | DRIFT · mapper leak? |
| map_sessions | ? | ? | DRIFT · mapper leak? |
| tuner_deploys | ? | ? | DRIFT · jamal leak? |
| tuner_routes | ? | ? | DRIFT · jamal leak? |
Latest migration file: 014_fix_device_associations_unique_constraint.sql (2026-04-11) · next would be 015
Things we noticed but are not fixing right now. Logged so the problem doesn't re-surprise us in a month.
Critical path closed 2026-04-11. Remaining work is polish, multi-session support, and the phone camera unblocker. Feature #2 (Platform Personas) runs in parallel on the next horizon.
Interactive test pages for verifying the pairing flow end-to-end. Open these on your laptop and scan QR codes with your phone.
ace_web/public/test/pairing-qr.html