MVP_COMPROMISES.md

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.