Askeo Progression System

Roadmap & Status — Last updated: 2026-09-10

Done / Completed
Active — in progress
Waiting / Blocked
Not started
Deployed: 2026-09-16 23:29 UTC
Bullet key:
✓ Closed dot = completed item
○ Open circle = incomplete / waiting item
🔗 Amber box below phase = dependency / blocker
Validation Gate Production Readiness Checklist

Ship to testers and validate production readiness before App Store sale. TestFlight is the gate; this checklist is what makes it pass. This is not a development phase — it is the end-state target for the app.

Agent — ready
  • Build iOS app for TestFlight distribution
  • Upload build to App Store Connect
  • Invite internal testers via TestFlight
  • Collect feedback from testers
  • Optional: submit for external TestFlight review
Checklist
  • Stability: no crashes on launch, no broken flows, restarts preserve state
  • Backend production health: health/ready endpoints, structured logs, global exception handler, timeouts, frontend retry/backoff
  • Auth & data: stable auth, data export/account deletion flows
  • Exercise library & media: licensed exercise source/video, playable video modal, static exercise names
  • Workout builder: draft persists across tab switches, cancel exits without clearing
  • Coach/deterministic rules: recognizable exercise names, deterministic progression, plain-language transitions
  • Privacy & compliance: privacy policy URL if collecting data, lawyer review before paid release
  • Device-specific: test on real device, Xcode GUI push workflow works, Capacitor config correct
  • Maintenance: discuss whether to upgrade to dedicated IPv4 ($2/mo) to eliminate shared-IP rotation risk
🔗 TestFlight does not require App Review for internal testers. External testers do require a lightweight review. None of this requires App Store approval to start testing.
Active Phase 1 — Foundation

Exercise whitelist, basic workout generation, database models, frontend set logging. All shipped.

Completed
  • 99-exercise canonical whitelist (Title Case, tier 1–4)
  • Movement pattern classification (push/pull/squat/hinge/etc.)
  • ExerciseLibrary integration — 595/1318 matched
  • Workout generator with deterministic compound-first ordering
  • SetLog database model (weight, reps, effort, notes)
  • Frontend ActiveWorkoutScreen with set logging UI
  • RIR capture added to frontend + backend schema
  • Progression type assigned per exercise in generator
  • Deployed to askeo.fit
Gaps
  • Frontend now calls backend prescription API in ai_trainer mode
  • AlgorithmState persisted per exercise server-side
  • Progression transitions logged server-side
  • Transition history view in app
User must do
  • Set up Google auth in Google Cloud Console
  • Add VITE_GOOGLE_CLIENT_ID to frontend .env
  • Rebuild + redeploy frontend to device
  • Submit app to TestFlight / dev App Store for tester access
🔗 Enables everything below. Without SetLog, AlgorithmState, and RIR capture, no progression logic can run. Phase 1 agent work depends on these models being stable — they are.
Active Phase 2 — Linear Progression (Current)

For beginners. Add weight when all sets/reps completed. Collect RPE + RIR to calibrate per-user.

Agent — completed
  • Wire frontend → backend prescription API
  • Persist AlgorithmState per exercise server-side
  • Surface backend prescription errors to user in UI
  • 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
Agent — blocked by your data
  • Validate linear progression defaults against real RIR (needs 2–3 logged sessions)
User must do
  • Generate a workout and complete it
  • Log effort + RIR for every set
  • Do this for 2–3 sessions minimum
  • Note if weight feels too easy / too hard
🔗 Only one agent task remains, and it needs your data. Your 2–3 sessions unblock validation of linear progression defaults. All other Phase 2 agent tasks are complete.
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.
Waiting Phase 3 — Double Progression

Novice-to-intermediate. Work in rep range 3×8–12. Hit top → add weight → drop to bottom. Trigger based on RIR at top set.

Agent will build
  • Double progression engine in rules.py + rules.ts
  • Transition detector: linear → double (stall detection)
  • Rep-range management (8–12) with weight advance logic
  • AI coach message for transition explanation
User must do
  • Continue logging workouts normally
  • Algorithm auto-detects stall and switches you
  • AI explains the transition when it happens
  • No user intervention needed
🔗 Blocked by Phase 2 data. The stall-detection trigger needs your Phase 2 performance history (completion rates, RIR trends) to calibrate what "stall" means for you. Agent can't build Phase 3 until Phase 2 has enough data to define the transition threshold.
Waiting Phase 4 — Percentage-Based (5/3/1 or variant)

Intermediate+. Auto-selects 5/3/1 standard, BBB, FSL, or DUP based on goal, equipment, and performance patterns.

Agent will build
  • 5/3/1 engine: training max, week percentages, AMRAP set
  • Auto-program selector based on user profile + data
  • Training max adjustment rules (AMRAP performance)
  • Deload week logic (every 4th week)
  • AI coach transitions with plain-language explanation
User must do
  • Keep logging workouts
  • AI says "switching to 5/3/1, here's why"
  • No configuration needed
  • Can ask AI to explain any change
🔗 Blocked by Phase 3 completion + more data. The 5/3/1 engine needs a training max, which is calculated from your recent performance. That requires Phase 3 progression data (top-set performance, rep ranges hit). Agent can't build Phase 4 until Phase 3 is proven and training max can be estimated from your history.
Waiting Phase 5 — Recovery & Deload Intelligence

Detect overreaching, missed sessions, declining performance. Auto-trigger deload or volume reduction.

Agent will build
  • Deload trigger rules (consecutive high RPE, missed sessions, declining performance)
  • Recovery score calculation from recent set data
  • Volume adjustment logic for deload weeks
  • Pain/discomfort flag handling
User must do
  • Flag pain/discomfort when logging sets
  • AI proactively suggests deload when needed
  • No manual deload scheduling required
🔗 Blocked by Phase 4 data. Deload triggers need weeks of percentage-based training data (AMRAP performance, RPE trends, session frequency). Can't detect overreaching until there's a baseline to compare against. Depends on Phase 4 being active long enough to collect recovery signals.
Waiting Phase 6 — Advanced Autoregulation

Fine-grained per-user calibration: RIR interpretation, volume landmarks, weak-point specialization, periodization.

Agent will build
  • Per-user RIR calibration (learns reporting bias)
  • Volume landmark tracking (MRV, MAV, MEV)
  • Weak-point detection from lagging lifts
  • Custom accessory selection based on weaknesses
  • Training age / volume threshold tracking
User must do
  • Continue logging sets consistently
  • More data → better personalization
  • AI occasionally explains adaptations
🔗 Blocked by all prior phases. Per-user calibration needs months of data across all progression stages. Weak-point detection requires performance comparisons across movement patterns. This is the long-term payoff for consistent logging.

How Data Flows

You generate workout → You log sets + RIR → Backend stores SetLog → rules.ts computes next prescription → AI explains the change

Frontend holds state in memory. Backend stores SetLogs. Prescription API and AlgorithmState persistence are deployed; remaining Phase 1 work is validation and verification against your real workout data.

Bottom line: Agent can build everything in parallel, but each phase needs validation from your real-world data before the next phase starts. Your logging is the critical path — it gates every transition.