Aufgabenbeschreibung aus dem oeffentlichen Repo entfernen (bleibt lokal)
Image bauen und in die Registry schieben / build (push) Successful in 5s
Image bauen und in die Registry schieben / build (push) Successful in 5s
Die Rebuild-Spec ist der interne Auftrag/Prompt und gehoert nicht ins public Repo. Datei bleibt im Arbeitsverzeichnis, per .gitignore ausgeschlossen.
This commit is contained in:
AI-Agent committed
1 parent
b2b4a2e770
commit
e9265ca2ab
2 files changed
+6
-115
No files matched your search
+6
-1
@@ -14,4 +14,9 @@ server.log
|
|||||||
|
|
||||||
# Python
|
# Python
|
||||||
__pycache__/
|
__pycache__/
|
||||||
*.pyc
|
*.pyc
|
||||||
|
# interne Entwicklungstools, nicht oeffentlich
|
||||||
|
/tools/
|
||||||
|
|
||||||
|
# interne Aufgaben-/Prompt-Datei, nicht oeffentlich
|
||||||
|
/trainingsplan-rebuild-spec.md
|
||||||
@@ -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.
|
|
||||||
Reference in new issue
Block a user