Askeo — Running Backlog

Current — what's happening now last updated: 2026-09-10

Bug fixes (just shipped)

Inline set editor in live workout (SortableExerciseCard.tsx) — tap "Edit" on completed set to edit weight/reps/effort inline
History screen effort field: was capped at /5, now /10
Backend parity deploy (343d9e7) — frontend and backend agree on progression seed

Current bugs to fix

Migrate existing ExerciseEntry.start_weight values from lbs to kg on backend (seeded data stored in lbs, frontend assumes kg → shows 254 instead of 115)
Audit all frontend weight display paths for consistent kg/lbs conversion (start_weight, draft prefill, getNextSetTarget(), coach prescription inputs, recap screens)
Backend should enforce canonical unit for start_weight and actual_weight (document whether kg or lbs is source of truth; migrate legacy data)
Coach Recap on Ready screen: fix session lookup so it finds last completed session of same template (currently returns empty even when completed session exists)
Coach Recap weight display: convert backend actual_weight from kg to lbs in PreWorkoutScreen before displaying (PostWorkoutScreen already does this correctly)
Coach message wording: change "This workout" to "Next workout" in all coaching messages (backend rules.py:198 and frontend rules.ts multiple locations)
Auto-update draft weight after logging a set to match coach prescription in ai_trainer mode (currently stays at logged weight instead of moving to recommended next weight)
Prevent reps_target=0 from propagating through template editor (TemplateEditorScreen.tsx:288 uses ?? 10 but ?? doesn't catch explicit 0; addSet initializes {reps: 0})

Phase 1 — Linear Progression: backend complete, validation pending user data

Basic progression engine wired up. Needs your workout data to validate defaults.

✓ Backend done

Wire frontend → backend prescription API (POST /api/rules/next-prescription)
Persist AlgorithmState per exercise server-side
Log ProgressionTransition on phase change
Add read endpoints: GET /api/rules/algorithm-state/{id}, GET /api/rules/transitions

✓ Frontend done

api.ts helpers for prescription, algorithm state, transitions
ActiveWorkoutScreen.tsx calls backend in ai_trainer mode with local fallback
Surface backend prescription errors to user in UI (via localStorage['askeo_error_log'])

○ Waiting — needs your data

Validate linear progression against real user data with RIR (blocked on user logging 2–3 sessions)

○ Agent — remaining

Add transition history view in app
pytest coverage for /api/rules/next-prescription side effects
Confirm AlgorithmState + ProgressionTransition rows created on phase change
End-to-end test: identical inputs → identical outputs unless RPE/RIR changes

What we're measuring: completion rate, RIR per set, effort per set, whether weight was increased automatically. This data tells us if the linear progression defaults are right for you.

Phase 2 — Rule Engine: Deterministic coaching scripts

Multiple progression types (double, linear, percentage, autoregulation, deload). Backend + frontend implementations.

Agent will build

Define canonical rule specification in one place: inputs, outputs, progression types, safety boundaries
Define standard fitness model schema consumed by all rule implementations
Determinism requirement: identical inputs → identical outputs unless user state changes
Additive-only gate: rules remain deterministic even as AI profile is layered on top in Phase 4

Backend

Implement canonical rule module in Python (FastAPI/Starlette)
Double progression: when all sets hit top rep band for target reps, increase weight next session; if miss, repeat
Linear progression: fixed increment per successful session; stall rule after N failures
Percentage / 1RM-based: compute working weight from stored or estimated 1RM; advance/regress based on completion quality
Periodization: weekly/mesocycle plan block hooks; scheduled deload week triggers reduced volume/intensity
Autoregulation (RPE/RIR): derive effective load and next-session prescriptions from reported RPE/RIR; allow micro-load/step back
Deloading: automatic deload trigger + manual deload with preserved rhythm
Backend computes next planned workout prescription from history + assigned rule script

Frontend / on-device

Port canonical rules to TypeScript for use inside the app
Active workout autoregulation runs locally with no network dependency
After each set completion, run autoregulation locally and update next set UI immediately
Capture RPE/RIR inputs inline during workout before moving to next set
Offline-first behavior: queue completed workout payload when offline, resume sync on reconnect
Preserve completed sets and local outputs through background/suspend without dependence on in-memory only state
No external network calls inside autoregulation during active workout
Deload/manual override path available locally if autoregulation suggests aggressive load

Frontend UX

Settings/defaults: user selects preferred rule script per exercise group or per workout
Exercise detail shows current rule-derived prescription: weight, reps, sets, rest, progression step, estimated 1RM
During active workout: show next prescribed set (adaptive to completed sets if autoregulated)
Post-workout: capture RPE and RIR inputs before completion so backend can compute next prescription
Template editor exposes rule-engine placement: default/static values vs dynamic prescriptions

○ Data model prerequisites

Capture required session data for rule engine: exercise_order, sets_target, reps_target, weight_target, rest_seconds, datetime_completed, rpe, rir
Confirm existing workout_end_summary / active workout POST payload carries enough state for progression rules to compute next workout
Define schema for rule_script / rule_assignment in Postgres (or extend settings payload) so a user/workout can be assigned a deterministic script

○ Verification

Unit tests for each rule type against synthetic session history
End-to-end test: user with known history receives correct next-session prescription
Confirm deterministic behavior: same input sequence always yields same next prescription unless RPE/RIR changes it
Verify backend and frontend implementations produce identical outputs on identical inputs

Phase 4 — AI Personalization Layer

AI doesn't replace scripts — it builds a user profile that modulates schema variables before scripts run. Voice coach, UI redesign, profile engine.

✓ Trainer-generated workout flow

Backend: POST /api/trainer/generate accepts questionnaire answers and returns a populated workout draft
Frontend: step-through questionnaire, one question per screen, progress indicator
Frontend: options shown as single-select tabs or multi-select chips; minimize typing
Section 1 — Training profile: Goal, Equipment, Primary Style, Additional Activities, Modality Mix, Location, Training History, Progression Method, Days/week, Minutes, Experience, Split Style, Limitations
Frontend: preface each section with "This is why we ask" context
Frontend: questionnaire shown on first login and available anytime from AI Trainer tab
Frontend: user picks "Trainer builds it" or "I'll build it myself"
Frontend: accepted generated workout persists as draft; user can tweak before saving
Frontend: re-run questionnaire available from AI Trainer tab to generate new workout
Backend: slot-based template system with 10 day templates
Backend: body_part_split rotation (chest/tris → back/bis → legs → shoulders → arms)
Backend: explicit progression_type overrides experience-based default

○ Remaining — trainer flow

Nutrition questionnaire and meal plan generation — separate future flow

Core model

Define standard fitness model schema shared by all users; Phase 2 deterministic scripts consume this schema
AI layer does not replace scripts; it builds a user-specific profile/key that modulates schema variables before scripts run
Scripts remain the constant execution layer; AI output is input normalization and profile calibration only

Additive-only gate

AI personalization is opt-in and additive only
If AI profile does not show verifiable improvement over deterministic baseline, default deterministic behavior remains the user-facing path
User can reset AI profile to default or disable AI personalization at any time

Live Workout Voice Coach

Add optional push-to-talk voice input during active workouts for hands-free logging and coaching
Scope during live workout: weight/reps/sets adjustments, RPE/form feedback, exercise swaps — same constraints as chat modify_workout
Optional TTS voice output so AI can speak confirmations and coaching cues without looking at screen
Text remains primary input and fallback; voice is additive only
UI: small mic button in ActiveWorkoutScreen; hold to talk, release to send; no always-on listening
Value prop: avoid phone pickup/manual logging mid-set; talk to coach like a real trainer would

AI Trainer UI Redesign

Redesign AiTrainerScreen.tsx to modern split-pane layout inspired by Claude/ChatGPT advanced mode
Desktop/tablet: left pane (~40%) for conversation, right pane (~60%) for context
Right pane surfaces referenced workouts, current prescription, draft previews, and session cards based on AI context
Mobile: single pane with tab or swipeable bottom sheet to toggle between Chat and Context
Inline cards in chat for referenced workouts/drafts; right pane shows detailed view
Typography, spacing, and bubble design updated to feel modern and intelligent, not legacy chatbot

AI profile engine

Collect user progress signals: adherence, completion rate, RPE/RIR trends, stall frequency, recovery indicators, workout consistency
Extract session feedback from AI coach chat: when user comments on how a workout felt vs last time, capture RPE, form quality, comparison, soreness, enjoyment, equipment issues as structured session metadata
Chat extraction flow: AI recognizes feedback intent → confirms summary to user → optionally writes to completed workout session metadata
Reuse extracted chat metadata in future generate_workout / modify_workout calls as progression signals
Skip redundant post-workout questionnaire when equivalent feedback already captured in chat
Design deterministic feature extraction from workout history so AI input is stable and reproducible
Choose local or backend AI profile generation:
- Option A: On-device lightweight model/profile generator runs offline after each workout
- Option B: Backend analyzes history and pushes updated profile key; frontend applies it locally
Profile outputs: calibrated starting 1RM estimate, progression sensitivity, volume tolerance, recovery multiplier, preferred RIR target, stress/fatigue adjustment

Integration + data & privacy

Planned workout → AI profile applied to schema → Phase 2 deterministic script computes prescription → on-device autoregulation runs during workout
Active workout autoregulation uses both the user's AI profile and live session feedback
Post-workout sync updates history, which may trigger AI profile recalculation on next run
Store AI profile per user in Postgres; version it so changes are auditable and reversible
No PII leaves device beyond workout history needed for backend profile generation; if local-only, profile never leaves device

○ Verification

Baseline: deterministic script without AI profile produces expected prescription
With AI profile: same script produces differentiated prescription based solely on profile differences
Profile stability: repeated runs on same history yield same profile unless new data changes it
User-facing: show which variables were adjusted by AI and why, with option to override manually