UI
This commit is contained in:
@@ -1,85 +1,48 @@
|
||||
# Trainings-Session-Tracker 2.0
|
||||
# Training 3.0
|
||||
|
||||
Mobiler Session-Tracker für veröffentlichte Pläne des boehmitools-Plugins `trainingsplan`.
|
||||
Schlanke mobile Ansicht fuer Plaene aus dem Plugin `trainingsplan`.
|
||||
|
||||
## Datenaufteilung
|
||||
Das Plugin verwaltet keine Sessions mehr. Es gibt keine Wochen, kein Tracking,
|
||||
keine Ergebnisfelder, keine KI-Analyse und keine Vorschlaege. Angezeigt werden
|
||||
nur:
|
||||
|
||||
- Trainingstage
|
||||
- Warm-up
|
||||
- Cool-down
|
||||
- Uebungen des Tages
|
||||
- aktuelle Progression pro Uebung
|
||||
|
||||
## Datenzugriff
|
||||
|
||||
Gelesen und geschrieben werden die Plan-JSON-Dateien aus:
|
||||
|
||||
```text
|
||||
data/trainingstracker/
|
||||
├── sessions/<Plan-Dateiname>.json
|
||||
├── analyses/<Plan-Dateiname>/
|
||||
│ ├── index.json
|
||||
│ ├── state.json
|
||||
│ ├── week-01.json
|
||||
│ ├── week-02.json
|
||||
│ └── overall.json
|
||||
└── proposals/<Plan-Dateiname>.json
|
||||
data/trainingsplan/plans/
|
||||
```
|
||||
|
||||
Die Sessiondatei enthält ausschließlich Profil-, Wochenstatus- und Sessiondaten. Prompts, KI-Antworten und Jobstatus liegen vollständig getrennt.
|
||||
|
||||
## Genau eine Analyse pro Bereich
|
||||
|
||||
Für jede Woche gibt es höchstens eine Datei `week-NN.json`, für den Gesamtplan genau eine `overall.json`. Eine neue Auswertung überschreibt die vorherige Datei. Es gibt keine Analysehistorie und keine Versionierung von KI-Auswertungen. Ältere Zeitstempeldateien werden beim ersten Lesen auf dieses Modell reduziert; erhalten bleibt nur die zuvor als aktuell markierte Auswertung.
|
||||
|
||||
Unveränderte Daten werden über einen Hash erkannt und lösen keinen neuen OpenAI-Aufruf aus. Der Hash berücksichtigt unter anderem:
|
||||
|
||||
- veröffentlichte Planrevision,
|
||||
- Plan- und Vertragsversion,
|
||||
- Prompt- und Antwortschemaversion,
|
||||
- Modell,
|
||||
- Normalisierungsversion,
|
||||
- Sessiondaten und Wochenstatus.
|
||||
|
||||
## Sessiondaten und Konfliktschutz
|
||||
|
||||
Der Browser speichert nur die aktuell bearbeitete Session als Patch. Eine Revisionsnummer verhindert, dass ein älterer Browser-Tab neuere Daten überschreibt.
|
||||
|
||||
Jede Session merkt `plan_id` und `plan_revision`. Alte positionsbasierte Einträge wie `d1-r0-e0` werden beim Öffnen automatisch den neuen stabilen Übungs-IDs zugeordnet und beim nächsten Speichern migriert.
|
||||
|
||||
Sessionstatus:
|
||||
Die einzige fachliche Schreiboperation ist:
|
||||
|
||||
```text
|
||||
planned → in_progress → stopped/completed
|
||||
stopped → in_progress
|
||||
completed → in_progress
|
||||
PATCH /api/plans/<plan>/exercises/<exercise>/current
|
||||
```
|
||||
|
||||
Übungsstatus:
|
||||
Body:
|
||||
|
||||
- offen,
|
||||
- erledigt,
|
||||
- teilweise,
|
||||
- übersprungen mit optionalem Grund.
|
||||
```json
|
||||
{
|
||||
"current_progression_id": "progression-high-plank"
|
||||
}
|
||||
```
|
||||
|
||||
Nicht enthalten sind RIR/RPE, Technikbewertung oder unterschiedliche Gewichte pro Satz.
|
||||
Die Aenderung wird direkt in `config` und `draft` des Plans geschrieben und ist
|
||||
damit die neue Wahrheit fuer App und Editor.
|
||||
|
||||
## Plan- und progressionsabhängige Ergebnisfelder
|
||||
## Vertrag
|
||||
|
||||
Der Tracker liest das Ergebnisformat zunächst aus der gewählten Progressionsstufe, danach aus der Übung. So kann eine Squat-Progression zunächst Sekunden mit optionalem Gewicht und später Wiederholungen oder Gewicht plus Wiederholungen verlangen.
|
||||
```text
|
||||
plan_schema: 5
|
||||
training_contract: 4
|
||||
```
|
||||
|
||||
Alte Freitextergebnisse bleiben lesbar. Eindeutige Werte werden in strukturierte Felder übernommen, unklare Angaben nicht erfunden.
|
||||
|
||||
## Wochenabschluss
|
||||
|
||||
Eine Woche kann ausdrücklich als laufend oder abgeschlossen markiert werden. Eine laufende Woche erzeugt eine Zwischenanalyse, eine geschlossene Woche eine Abschlussanalyse. Wird der Wochenstatus oder eine Session geändert, gilt die bestehende Analyse als veraltet. Die nächste manuelle Auswertung überschreibt sie.
|
||||
|
||||
## Progressionsanalyse
|
||||
|
||||
Wochen werden einzeln analysiert. Die Gesamtanalyse verwendet nur aktuelle Wochenzusammenfassungen und lokale Aggregate, nicht erneut sämtliche Rohsessions.
|
||||
|
||||
Der veröffentlichte Plan ist bindend. Bei Tabata bleiben Arbeitszeit, Pause, Rundenzahl und Satzlogik unverändert. Die KI erhält lokal berechnete Variantencluster und soll deren Faktoren nicht selbst neu erfinden.
|
||||
|
||||
Planvorschläge werden strukturiert mit `exercise_id`, `progression_id` und `step_id` nach `data/trainingstracker/proposals/` geschrieben. Der Planeditor zeigt sie als Prüfpostfach an und verändert den Plan niemals automatisch.
|
||||
|
||||
## Robuste Analysejobs
|
||||
|
||||
Der Jobstatus wird vor dem API-Aufruf gespeichert. Eine Prozess- und Dateisperre verhindert parallele Jobs für denselben Plan. Ein Heartbeat verlängert die Job-Lease. Nach einem Prozessabbruch läuft die Sperre zeitnah ab, auch nach einem Browser-Reload oder Containerneustart.
|
||||
|
||||
## Übungsbibliothek und FAQ
|
||||
|
||||
Die planbezogene `exercise_catalog` ist die primäre Quelle für Bewegungscluster, Varianten und Faktoren. Die FAQ zeigt diese Planbibliothek sowie die transparenten Fallback-Tabellen. Dynamische Übungen werden als Referenz-Reps, Holds als Referenzsekunden und externe Lasten als kg·Reps beziehungsweise kg·s ausgewertet.
|
||||
|
||||
## Oberflächenzustand
|
||||
|
||||
Der letzte Tab, die Woche, der Tag und die ausgewählte Analyse bleiben pro Trainingsplan im Browser erhalten.
|
||||
Uebungen enthalten `progressions` und `current_progression_id`. Tagesuebungen
|
||||
referenzieren nur noch `exercise_id`.
|
||||
|
||||
Reference in New Issue
Block a user