Finance lens

Most fitness apps swap exercises by name. A real injury filter has to swap by anatomy. The medial epicondyle is the origin of the flexor-pronator group, so tricep extensions and gripping under load aggravate it, but biceps curls don't load that joint at all because the biceps brachii inserts at the radial tuberosity. The right answer is to swap the right movements and leave the rest alone. A 25-tag movement-pattern taxonomy makes the filter anatomy-correct rather than name-correct, and the entire week's plan recomputes the moment an injury is toggled on or off.

Engineering lens

Each exercise is tagged into one of 25 movement patterns (grip_load, valgus_elbow, tricep_extension_extreme, deep_knee_flexion_load, etc.). Each of 5 injury types declares a {pattern: severity} map plus per-pattern swap targets, reduction cues, and force-drop overrides. Filter logic scores each plan exercise against the union of active injuries with strict drop > swap > reduce > cue precedence. Active injuries persist in SQLite, toggle live via POST /injuries/{name}, and the filter re-runs on every /programme/today and /programme/week fetch, instant recompute, instant revert.

Finance lens

When the coach answers a question, it cites which articles it pulled from. The knowledge base is curated, articles across training, nutrition, recovery, and programming, chunked by heading. Retrieval is hybrid: keyword search catches literal phrasing, semantic search catches conceptual matches, and the two are fused so the right passage surfaces whether the user typed the exact term or paraphrased it.

Engineering lens

27 wiki articles chunked into ~229 sections, embedded with sentence-transformers/all-MiniLM-L6-v2 (384-dim, on-device, free), stored as BLOB in SQLite. Retrieval fuses FTS5 BM25 + numpy cosine via reciprocal-rank: α/(60+bm25_rank) + (1-α)/(60+vec_rank). Originally targeted sqlite-vec but Python 3.13's framework build can't load extensions, so I pivoted to a numpy linear scan, sub-millisecond over ~150 chunks at this corpus size. The coach prompt is a single template with user_context (live state: today's macros, last six sets, weight EMA, readiness, active injuries) plus retrieved chunks, routed through OpenRouter to Gemini or Claude with [topic §heading] citations enforced by the system prompt.

Finance lens

Every training day surfaces a structured warmup card before the workout: cardio, dynamic mobility (no static stretches, they measurably cut force output), activation work for the muscles that protect today's primary lift, and a specific %-of-working ramp on the first compound. Each section carries a one-line rationale and a citation, so the user can see why each block is there rather than treating the warmup as ritual.

Engineering lens

WARMUP_BLOCKS is a dict keyed by workout name, each value a list of section objects (section, duration, rationale, items). The PreSession response carries an optional sections[] field; the React PreSessionCard renders the structured form when present, flat-list fallback otherwise. Mobility recommendations are dynamic-only, Behm 2016 meta-analysis shows static stretching ≥30 s pre-lift impairs force output 5–8%. Specific ramp uses %-of-working sets per Israetel/Nippard guidance and stays sub-maximal, because post-activation potentiation (Wilson 2013) requires it.

Finance lens

Two recurring decisions are automated. First, phase-correct programming: a 12-week plan has three phases, training and rest days have different targets, and today's numbers are computed from today's date, no manual reconfiguration. Second, outdoor cardio scheduling: the system scores the next 7 days of weather and surfaces the best contiguous 4-hour block per day, with a calorie estimate calibrated to the actual ride hardware (a heavy bikeshare bike burns 10–15% more than a personal road bike at the same speed).

Engineering lens

PHASES array keyed by (weeks_tuple, train_kcal, rest_kcal, protein_g). current_phase(today) returns the right row by week-of-cycle; macros_for_today does a deterministic 30/25/45 split (protein-locked, fat 25% of kcal, rest as carbs) and the Today summary auto-flips at midnight. Weather scorer hits Open-Meteo's free hourly forecast cached 30 min, scoring each daylight hour 0–100 (peak at 18°C, penalised by precip > 10%, wind > 12 km/h, temp drift), then sliding-window finds the best 4-hour contiguous block per day. Calorie estimate uses the ACSM formula MET × kg × 3.5 / 200, calibrated for the actual hardware in use.

Finance lens

The whole system runs on a laptop. The phone connects over the same WiFi to log workouts, meals, and weights. No cloud, no $20/month database, no app store. The PWA installs to the home screen and looks like a native app, but the perimeter is the network, not auth. If the WiFi works, the system works. The original architectural plan was Supabase + cloud hosting; the design call ($0 cost is the constraint, but the laptop can't stay on 24/7) landed on this laptop-as-server / phone-as-client design instead.

Engineering lens

Single FastAPI process bound to 0.0.0.0:8003, two SQLite databases (KB + app data), Bonjour macbook.local for phone discovery, localStorage offline write-queue with auto-flush on /health ping every 30 s and on online/focus events. PWA via manifest.webmanifest so the phone can "Add to Home Screen." Mid-build catastrophe: the work was being silently written to a shell sandbox overlay that didn't persist, caught it, salvaged 27 wiki articles by HTTP-dumping the running backend to disk, rebuilt on real disk, and shipped. The kind of failure mode you only learn about by hitting it.