4.1 KiB
Trainings-Session-Tracker 2.0
Mobiler Session-Tracker für veröffentlichte Pläne des boehmitools-Plugins trainingsplan.
Datenaufteilung
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
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:
planned → in_progress → stopped/completed
stopped → in_progress
completed → in_progress
Übungsstatus:
- offen,
- erledigt,
- teilweise,
- übersprungen mit optionalem Grund.
Nicht enthalten sind RIR/RPE, Technikbewertung oder unterschiedliche Gewichte pro Satz.
Plan- und progressionsabhängige Ergebnisfelder
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.
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.