From e9265ca2ab7dd3fe991b0f51370fc1f0815a30bb Mon Sep 17 00:00:00 2001 From: AI Agent Date: Mon, 5 Oct 2026 14:30:50 +0000 Subject: [PATCH] Aufgabenbeschreibung aus dem oeffentlichen Repo entfernen (bleibt lokal) Die Rebuild-Spec ist der interne Auftrag/Prompt und gehoert nicht ins public Repo. Datei bleibt im Arbeitsverzeichnis, per .gitignore ausgeschlossen. --- .gitignore | 7 ++- trainingsplan-rebuild-spec.md | 114 ---------------------------------- 2 files changed, 6 insertions(+), 115 deletions(-) delete mode 100644 trainingsplan-rebuild-spec.md diff --git a/.gitignore b/.gitignore index 0523177..add2336 100644 --- a/.gitignore +++ b/.gitignore @@ -14,4 +14,9 @@ server.log # Python __pycache__/ -*.pyc \ No newline at end of file +*.pyc +# interne Entwicklungstools, nicht oeffentlich +/tools/ + +# interne Aufgaben-/Prompt-Datei, nicht oeffentlich +/trainingsplan-rebuild-spec.md diff --git a/trainingsplan-rebuild-spec.md b/trainingsplan-rebuild-spec.md deleted file mode 100644 index 61c93fc..0000000 --- a/trainingsplan-rebuild-spec.md +++ /dev/null @@ -1,114 +0,0 @@ -# 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. \ No newline at end of file