trainingsplan/trainingsplan-rebuild-spec.md

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.