# RTSport — Progress & Next Steps

**Date:** 2026-05-03 (updated 02:50 UTC)
**Author:** Daedalus
**Status:** Phase 0 → Phase 1 — Core interaction validated ✅

---

## 1. What's Been Built

### Documents
| File | Status | Notes |
|---|---|---|
| `docs/product-brief.md` | ✅ Done | Market research, competitive analysis, HIPAA/FERPA ruling, 4 competitors mapped, TAM $1.6B |
| `docs/contract.md` | ✅ Done | Schema v0.2 — school_id, milestones separate from events, severity/attention split, FERPA role matrix, design decisions log |
| `docs/roadmap.md` | ✅ Draft | 6 phases (Foundation → MVP → Beta → Cert → Launch → Growth), pricing tiers, certification sequencing, testing strategy, risk register |
| `shared/api-specs/rtsport-v0.3.yaml` | ✅ Done | 6 endpoints: dashboard, athlete+case combo, sideline entry POST, body parts, auth, roster |
| `shared/build-20260501/backend/` | ✅ Live | FastAPI + SQLite, all 8 endpoints tested and working |

### Backend API Status (v0.3)
| Endpoint | Method | Status | Notes |
|---|---|---|---|
| `POST /api/v1/auth/login` | Auth | ✅ Working | JWT with role + school_id |
| `GET /api/v1/dashboard/at` | Dashboard | ✅ Working | Stats + active cases |
| `GET /api/v1/athletes/{id}` | Athlete | ✅ Working | Athlete detail |
| `GET /api/v1/athletes/{id}/case` | Combo | ✅ Working | Athlete + case + milestones |
| `GET /api/v1/cases/{id}/timeline` | Timeline | ✅ Working | Events with FERPA filtering |
| `GET /api/v1/body-parts` | Reference | ✅ Working | 6 groups with icons |
| `POST /api/v1/events/sideline-entry` | Entry | ✅ Working | Creates case + event |
| `GET /api/v1/roster` | Roster | ✅ Working | Paginated athlete list |

**Server:** Running at `127.0.0.1:8001` (auto-reload enabled)
**Database:** SQLite with seed data (40 athletes, multiple cases, 3 sports)
**Test user:** `at@preble.k12.wi.us` / `testpass123`

### Frontend Mock (v0.2)
| View | Routes | Status | Notes |
|---|---|---|---|
| Landing index | `/rtsport/` | ✅ Live | Links to all views |
| AT Dashboard | `/rtsport/at` | ✅ Live | FAB + bottom sheet with 3-tap entry |
| **3-Tap Sideline Entry** | `/rtsport/at/sideline-entry` | ✅ **Live** | **Tap 1: Athlete (searchable) → Tap 2: Body part (categories + chips) → Tap 3: Severity + removed toggle → submit. Confirmation toast. Auto-reset.** |
| **Coach Dashboard** | `/rtsport/coach` | ✅ Live | Tonight's game alert, per-team roster with restriction tags |
| **Parent Dashboard** | `/rtsport/parent` | ✅ Live | Child selector, recovery plan phases, care team contacts |
| Shared Timeline | `/rtsport/timeline` | ✅ Live | Phase bar component, stakeholder visibility strip, event cards |
| Notifications | `/rtsport/notifications` | ✅ Live | In-app feed, iOS push previews, toast |
| CSS system | `rtsport.css` | ✅ Live | Design tokens, role colors (teal/amber/violet), mobile-first, dark mode |

### Infrastructure
| Item | Status | Notes |
|---|---|---|
| GitHub repo | ✅ Created | `NightKnight64/rtsport` — private, `main` branch, 3 commits |
| Live mock server | ✅ Serving | Via hoffdesk.com FastAPI (main_v2) at `/rtsport/*` |
| Shared docs | ✅ Created | `/shared/project-docs/rtsport/` — brief + roadmap |
| Blog post | ✅ Published | `the-joy-of-agentic-coding` — mentions RTSport as case study |

---

## 2. Honest Assessment

### What's Strong
- **Contract is clean.** School_id on everything. Clear separation of concerns. FERPA matrix is explicit. Socrates can start from this without ambiguity.
- **Visual direction is right.** The phase bar, role colors, shared timeline concept — these read correctly to anyone who's seen high school sports communication.
- **Docs are thorough.** More planning than most MVPs get. Pricing, certs, risks all thought through.
- **Backend is live.** All 8 endpoints working. Real data flowing. Frontend can integrate now.

### What's Weak
- **The 3-tap sideline entry exists now** (built May 3, validated by an LAT same night) ✅
- **Backend exists but frontend isn't wired to it.** The API is live but the HTML mock still uses hardcoded data. Integration is the next step.
- **No real user feedback.** Zero validation from an actual athletic trainer. We're building on assumptions.
- **No offline story.** On a sideline with no signal, the app shows nothing. This is a dealbreaker for AT adoption.
- **No onboarding flow.** How does a school sign up? Import rosters? Link parents? The mock assumes all data exists.

### The Metric That Matters

We have 3 commits and a live mock. That's a solid Week 1. But we're still in **document-land, not product-land.** The next task should produce something an LAT can tap on and get a response.

---

## 3. Next Steps (In Priority Order)

### ✅ COMPLETED (May 3)
- **Backend API v0.3** — All 8 endpoints working with real data
- **Database seeded** — 40 athletes, multiple cases, 3 sports
- **Auth working** — JWT with role-based access

### Step 1: Frontend-Backend Integration (Daedalus) ← CURRENT
Wire the existing HTML mock to the live API:
- Replace hardcoded dashboard data with `GET /api/v1/dashboard/at`
- Replace hardcoded athlete overlay with `GET /api/v1/athletes/{id}/case`
- Wire 3-tap entry form to `POST /api/v1/events/sideline-entry`
- Load body parts from `GET /api/v1/body-parts`

### Step 2: LAT Demo with Real Data (Matt)
Show the fully wired app to an athletic trainer:
- Log real entries
- See real data populate
- Get feedback on the complete flow

### Step 3: Onboarding Mock (Daedalus)
Three flat screens showing setup path:
1. **Add Your School** — Name, domain, sport list
2. **Upload Roster** — CSV format, drag-and-drop
3. **Invite Parents** — Email/SMS, bulk input

### Step 4: Phase 1 MVP Spec (Wadsworth + Board)
Define exact feature cut for MVP:
- What's in (core loop + basic auth + email notifications)
- What's out (offline, SSO, file attachments)
- Timeline and owner assignments

---

## 4. User Feedback — First Validation 🎯

**Source:** Matt showed the mock to a practicing athletic trainer.

**What they said:**
- ✅ Navigation was intuitive — positive feedback on the flow
- ✅ 3-tap entry worked as expected (search → body part → severity)

**No negatives noted yet** — this was a quick demo, not a structured session.

**Implication:** The core interaction pattern is validated. We move to Step 2 (wire athlete overlay to mock data) and Step 4 (structured LAT interview with the script).

```
Now → May 9:  Steps 1-2 (3-tap entry + wired overlay)     ← CORE INTERACTION
May 9 → 16:   Step 3 (onboarding mock)                     ← SETUP EXPERIENCE
May 16 → 23:  Step 4 (show to real LAT)                    ← FIRST VALIDATION
May 23 → Jun: Steps 5 (backend begins)                     ← SOCRATES
```

**Milestone:** By May 23, an LAT has tapped through the core flow and we have recorded feedback. We adjust or proceed based on what they say.

---

## 5. Open Questions

1. **Who is the first LAT we show this to?** Matt, do you know anyone? If not, cold outreach to Green Bay area school ATs.
2. **How do we handle the "demo data" vs "real data" question?** The mock uses fake athletes. When we show an LAT, do we let them imagine their own roster, or do we need a roster import by then?
3. **Offline-first — Phase 1 or Phase 2?** The contract assumes it. The mock ignores it. Decision needed on whether a ServiceWorker + IndexedDB cache is in the MVP or post-MVP.
4. **RTSport domain?** Currently at hoffdesk.com/rtsport/. Is rtsport.app or similar worth registering now?

---

*This document lives at `/shared/project-docs/rtsport/progress.md`.*  
*Next review: After Step 4 (first LAT validation).*