# MVP_COMPROMISES.md — What we are deliberately simplifying

This file tracks the compromises we are making to finish a real, runnable MVP without
forgetting what is missing afterward.

## Product compromises

- **Single user only.** No profiles, account system, sharing, or multi-athlete support.
- **One fixed 4-day template.** The app does not generate a split or choose exercises
  from a broad database.
- **One-minute rests everywhere.** The supplied rest differences are normalized to 1
  minute for the MVP.
- **One goal context.** The MVP is for hypertrophy and continuous progress during a lean
  bulk or maintenance phase.
- **Today tab first.** Plan, Progress, Research, and richer coach views are deferred
  until the daily loop works.
- **No fancy UI polish yet.** The interface should be usable and clear, not custom or
  highly styled.

## Training-engine compromises

- **Classic straight sets only.** Supersets, drop sets, rest-pause, myo-reps, circuits,
  and other advanced set structures are deferred.
- **No automatic substitutions yet.** Exercise equipment and availability are not in the
  schema yet.
- **No pain substitutions yet.** The deterministic engine can remove exercises that hit
  a painful muscle, but it does not yet choose replacement exercises.
- **MVP exercise muscle tags.** Exercise-to-muscle mappings are fixed for the current
  template and should be reviewed/refined later.
- **Simple time compression.** The engine reduces sets for short sessions, but it does
  not yet estimate true exercise duration, warm-up time, or transition cost.
- **Simple readiness adaptation.** The engine reduces sets/RIR from a weighted score,
  but soreness is still inferred from free text and stress/mood share one field.
- **Simple load increments.** Double progression uses fixed +1 kg jumps for all
  exercises. Later, increments should vary by exercise, equipment, available plates, and
  whether the movement is compound or isolation.
- **Incomplete progression gating.** Double progression now moves reps before load, but
  the MVP progression rule still checks reps and latest load only. Target RIR, form
  quality, pain severity, and exercise-specific edge cases are follow-up decisions.
- **No periodization yet.** Deloads, mesocycles, volume landmarks, and planned up/down
  weeks are out of scope for the MVP.

## Parser compromises

- **The parser is not the coach.** It extracts structured check-in data and asks
  follow-up questions; it does not make training decisions.
- **Multi-round clarification over one-shot perfection.** The small model proposes
  structured follow-up questions, and deterministic cleanup removes obvious duplicates,
  already-answered questions, and unsupported activity/body-area follow-ups.
- **Local development uses Ollama.** This is fast and useful locally. Hugging Face
  Spaces use a GGUF llama.cpp backend so CPU deployment does not rely on slow PyTorch
  Transformers generation.
- **Acceptance fixtures are test coverage, not product proof.** They help catch obvious
  regressions, but real value still comes from logged sessions.

## Persistence compromises

- **Local JSON default.** The app defaults to local JSON so it can run fully locally
  without cloud dependency. Hugging Face Dataset storage is optional deployment
  persistence enabled by environment variables.
- **Minimal history first.** We only store completed date, day number, exercise id, set
  number, actual reps, actual load, and optional RPE/notes before adding richer
  analytics.
- **No sync/conflict handling.** Single-user MVP means no concurrent edits or merge
  logic.

## Hackathon compromises

- **Backyard AI proof over breadth.** Real logged use, a precise parser job, and a
  deterministic engine matter more than many features.
- **Small-model badge only if it does not break the spine.** Tiny/local model work is
  valuable, but the daily training loop comes first.
- **Research-reader and fine-tuning are stretch.** They stay out until check-in →
  session → log → next session works end to end.