# Trainingsplan - Neubau-Spezifikation

Ziel fuer den Agenten: einen selbstgehosteten Trainingsverlaufs-Tracker von NULL neu bauen.
Nicht den alten Code reparieren. Das Konzept verstehen und besser umsetzen.
Es gibt KEINen bestehenden Code gestern. Alles folgt dieser Beschreibung + Wahrnehmung bei Bedarf.

## Auftrag

Baue eine schlanke Web-App fuer den taeglichen Gang ins Fitnessstudio.
Eine Person, ein Server, keine Cloud. Fokus: mit minimaler Reibung erfassen,
was trainiert wurde, und ueber Wochen erkennen, ob man staerker wird.

Aktivitaeten: **Gym (Kraft)**, **Laufen**, **Radfahren**. Die App lebt auf dem Server
(daten liegen serverseitig auf der Platte, nicht im Browser-Cache).

## Wichtigste Prinzipien (nicht verhandelbar)

1. **Konfiguration statt Code.** Der Trainingsplan (Uebungen, Saeetze, Reps, Gewichte,
   Maschinen, Erklaerungen) liegt in einer Config-Datei (`config.json`). Keine
   Uebungsliste hart im Code. Ein Nicht-Programmierer aendert den Plan in der Config.
2. **Serverseitige Persistenz.** Daten in SQLite. Mehrere Sessions am Tag, editierbarer
   und loeschbarer Verlauf. Ueberlebt Neustart.
3. **Zustand strikt isolieren.** Eine Aenderung in Uebung A fasst nie Uebung B an.
   Keine flachen Kopien, keine globalen Re-Builds. Jedes Set hat einen stabilen Identifier.
4. **Kein Datenverlust.** Waehrend des Tippens keine Re-Renders, die Fokus/Cursor killen.
   Leer eingeben = leer, nicht 0. Eingaben werden erst gespeichert, wenn's Sinn ergibt.
5. **Keine Geister-Eintraege.** Es entsteht kein Verlaufseintrag, solange keine Session
   wirklich gestartet oder explizit gespeichert wurde.
6. **Sichtbare Einheiten.** Ueberall "kg", "km", "min" sichtbar, nie nackte Zahlen.
7. **Sets modular.** Pro Uebung Anzahl und Gewicht der Saeetze konfigurierbar,
   auch einzelne Sets individuell (z.B. Set-Array mit Gewicht/Reps je Set).
   Hinzufuegen/Entfernen von Sets im UI moeglich.
8. **Portabel + Docker.** Laeuft per `python3` (nur Standardbibliothek) und als Docker-
   Container. Daten-Verzeichnis per Environment-Variable (`TRAINING_STATE_DIR`).
   Bestehende Daten- und Repo-Config nicht zerstoeren.

## Funktionalitaet (vollstaendig)

### Heutige Ansicht
- Zyklus Push/Pull/Legs (oder frei konfigurierbar in der Config).
- Jede Uebung als Liste ihrer Saeetze.
- Pro Satz: **Set-Nummer (klickbar als Abhak-Status), Gewicht, Reps** als Eingabe.
- Eingabe als **eine zusammengehoerige Box**: Zahl links, Einheit ("kg"/"reps") als
  festes Suffix rechts IN derselben Box. Klick auf die ganze Box fokussiert den Input.
- **Set-Kette**: Set 3 waehlen aktiviert 1..3 (keine Luecken). Deaktivieren faengt
  rueckwaerts. Klick auf Set darf Gewicht/Reps nie veraendern.
- **Reset-Satz**: Knopf setzt das Set auf das Gewicht des letzten abgeschlossenen Tages
  (set-spezifisch, heutige in-Arbeit-Session zaehlt nicht).
- **Fragezeichen-Icon** neben jedem Uebungsnamen: oeffnet Overlay mit Text-Erklaerung
  der Uebung + der passenden Maschine. (Text reicht, kein Bild.)
- Optionale Notiz pro Session.

### Session-Lebenszyklus
- "Session starten" / "Session speichern". Mehrere Sessions am Tag erlaubt.
- Start- und Endzeit. Nach "abschliessen" erscheint die Session SOFORT im Verlauf
  (ohne Seiten-Reload).
- Solange keine Session gestartet, passiert nichts im Verlauf (kein Geist).

### Verlauf
- Abgeschlossene Sessions mit Datum + Zeit von-bis.
- **Inline bearbeiten unter dem Verlauf**: Datum, Start/Ende aenderbar; Workout-Eintraege
  (Gewicht/Reps bzw. Cardio-Felder) direkt aenderbar; Session loeschbar.
- Bearbeiten-Tab bleibt im Verlauf, blutet nicht in die Heutige-Ansicht.

### Statistik
- Pro Uebung die Steigerung ueber die Zeit (bestes Gewicht je Termin,
  Differenz zur ersten Messung).

### Export / Import
- Kompletter Stand als JSON und als CSV raus und rein (fuer Back-ups und
  Tabellen-Auswertung). Format klar allabelt.

### Cardio (Laufen / Radfahren)
- Feld-Templates aus der Config (Distanz, Dauer, Pace, Puls, Hoehenmeter).
- Einheiten aus der Config (km, min, min/km, bpm, m).

## Maschinen / Trainingspraeferenz

- Trainiert mit Freihanteln UND Maschinen, tendenziell eher Maschine (Technogym).
- **Bizeps bevorzugt am Kabelturm.**
- Der Plan soll die fehlenden Standard-Maschinen abdecken (Technogym Selection-Linie
  als Referenz: Chest Press, Pectoral, Shoulder Press, Lat Machine, Low Row, Reverse
  Fly, Leg Press, Leg Curl, Leg Extension, Calf, Arm Curl/Preacher, Glute/Hip Thrust
  u.a.) inkl. der Preacher-(Arm Cavlier)-Maschine.
- Das sind Richtwerte, kein Muss: Welche Maschinen im Studio wirklich stehen,
  kann beim Training angepasst werden - Config, nicht Code.

## Design

We-geilektung, KEIN Detail-Diktat: Nutzbarkeit hat Vorrang. Eine Regel, die die
Software unbrauchbar macht, wird gebrochen und begruendet.

- Harte Kanten: 0px Radius, klare 2px-Border, dunkler Grund.
- Flache Farben, ein Akzent, keine Verlaeufe, kein Glow, kein Glassmorphism.
- Kein Inter/Roboto-Systemstack als einzige Schrift unreflektiert.
- Bewusste Typo/Hierarchie ueber Abstand und Gewicht statt "alles gleich".
- Zustaende (Hover/Mouse/Focus/Active) mitdenken.
- Keine Emojis als Icons, keine rohen Unicode-Pfeile in Labels, keine Em-Dashes als
  Stilmittel.
- Kompakt, kein "zentrierter Hero + 3 Karten"-SaaS-Skelett.
- **WICHTIG**: nicht ueberstilisiert designen. Es fehlt Feinarbeit - simpel, klar,
  benutzbar. Design gibt die Richtung, macht die App nicht zerbrechlich.

## Technischer Rahmen (Empfehlung, nicht zwingend)

- Frontend: eine HTML-Datei Struktur, eine CSS-Datei, eine JS-Datei (kein Framework).
- Backend: `python3` mit Standardbibliothek (`http.server`) als JSON-API + statische
  Dateien. SQLite fuer die Daten. Kein Inline-Script/Style in HTML - Klassen + CSS.
- Dockerfile + docker-compose (CasaOS-tauglich: Daten-Verzeichnis als echter Ordner).

## Abgeben

Code + kurze README (was es kann, wie starten, wie den Plan in der Config aendern).
Getestet und lauffaehig, nicht nur beschrieben.