Update
This commit is contained in:
@@ -1,107 +1,96 @@
|
||||
# Trainingsplan- & Rezept-Editor 2.0
|
||||
# Trainingsplan-Backend
|
||||
|
||||
Der Editor verwaltet Trainingspläne und Rezeptsammlungen innerhalb von boehmitools. Trainingspläne sind zugleich die verbindliche Datenquelle für den `trainingstracker`.
|
||||
Dieses Plugin ist nur noch das Eintragebackend fuer Trainingsplaene.
|
||||
|
||||
## Planlebenszyklus
|
||||
Es verwaltet:
|
||||
|
||||
Jede Plandatei enthält eine veröffentlichte Fassung und einen bearbeitbaren Entwurf:
|
||||
- Plaene
|
||||
- Uebungen in einer zentralen Uebungsbibliothek
|
||||
- Trainingstage
|
||||
- Warm-up und Cool-down pro Trainingstag
|
||||
- Uebungen, die an Trainingstagen hinterlegt sind
|
||||
|
||||
```json
|
||||
{
|
||||
"plan_id": "phase-1",
|
||||
"revision": 4,
|
||||
"published_revision": 2,
|
||||
"config": {},
|
||||
"draft": {}
|
||||
}
|
||||
```
|
||||
Nicht mehr enthalten sind PDF-Erzeugung, Rezeptsammlungen, Progressionen,
|
||||
Planvorschlaege, Analyse-/ChatGPT-Anbindungen und Farbdefinitionen fuer eine
|
||||
Ausgabeoberflaeche.
|
||||
|
||||
- **Entwurf speichern** erhöht die Bearbeitungsrevision, verändert aber nicht den vom Tracker gelesenen Plan.
|
||||
- **Plan prüfen** validiert IDs, Progressionsbezüge, Ergebnisschemata und feste Intervalle.
|
||||
- **Entwurf veröffentlichen** erzeugt eine neue veröffentlichte Planrevision.
|
||||
- Bereits dokumentierte Sessions speichern die Planrevision, nach der sie ausgeführt wurden.
|
||||
- Vor dem Ersetzen einer Plandatei wird atomisch geschrieben und ein Backup unter `data/trainingsplan/backups/` angelegt.
|
||||
- Gleichzeitige Bearbeitungen werden über eine Revisionsprüfung erkannt und nicht still überschrieben.
|
||||
## Datenvertrag
|
||||
|
||||
## Stabiler Datenvertrag
|
||||
|
||||
Trainingspläne verwenden:
|
||||
Trainingsplaene verwenden:
|
||||
|
||||
```text
|
||||
schema_version: 3
|
||||
contract_version: 2
|
||||
schema_version: 4
|
||||
contract_version: 3
|
||||
```
|
||||
|
||||
Phasen, Tage, Rotationen, Übungsplatzierungen, Bewegungen, Progressionen und Progressionsstufen besitzen dauerhafte IDs. Beim Verschieben im Editor bleiben diese IDs erhalten.
|
||||
|
||||
Progressionsstufen sind Objekte und keine parallelen Text-/Schema-Arrays mehr:
|
||||
Eine Plan-Config ist bewusst flach:
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "step-squat-hold-...",
|
||||
"name": "Deep Squat Hold",
|
||||
"phase_id": "phase-start-...",
|
||||
"movement_cluster": "knee_dominant",
|
||||
"factor": 1.0,
|
||||
"result_schema": {
|
||||
"mode": "seconds",
|
||||
"weight_mode": "optional",
|
||||
"laterality": "bilateral",
|
||||
"sides_mode": "same"
|
||||
}
|
||||
"schema_version": 4,
|
||||
"contract_version": 3,
|
||||
"plan_id": "basis-plan",
|
||||
"meta": {
|
||||
"title": "Basis-Plan"
|
||||
},
|
||||
"exercises": [
|
||||
{
|
||||
"id": "exercise-squat",
|
||||
"name": "Squat",
|
||||
"cue": "Sauber und kontrolliert"
|
||||
}
|
||||
],
|
||||
"days": [
|
||||
{
|
||||
"id": "day-1",
|
||||
"num": 1,
|
||||
"name": "Tag 1",
|
||||
"warmup": { "items": ["Gelenke mobilisieren"] },
|
||||
"cooldown": { "items": ["Locker auslaufen"] },
|
||||
"exercises": [
|
||||
{
|
||||
"id": "day-exercise-1",
|
||||
"exercise_id": "exercise-squat",
|
||||
"sets": 3,
|
||||
"reps": "8-12"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Dadurch reisen Stufenname, Eingabeformat und Analysefaktor immer gemeinsam.
|
||||
## API
|
||||
|
||||
## Ergebniserfassung
|
||||
- `GET /api/plans`
|
||||
- `POST /api/plans`
|
||||
- `GET /api/plans/<plan>`
|
||||
- `POST /api/plans/<plan>`
|
||||
- `POST /api/plans/<plan>/publish`
|
||||
- `POST /api/plans/<plan>/rename`
|
||||
- `DELETE /api/plans/<plan>`
|
||||
- `GET /api/plans/<plan>/exercises`
|
||||
- `POST /api/plans/<plan>/exercises`
|
||||
- `PATCH /api/plans/<plan>/exercises/<exercise>`
|
||||
- `DELETE /api/plans/<plan>/exercises/<exercise>`
|
||||
- `GET /api/plans/<plan>/days`
|
||||
- `POST /api/plans/<plan>/days`
|
||||
- `PATCH /api/plans/<plan>/days/<day>`
|
||||
- `DELETE /api/plans/<plan>/days/<day>`
|
||||
- `POST /api/plans/<plan>/days/<day>/exercises`
|
||||
- `PATCH /api/plans/<plan>/days/<day>/exercises/<item>`
|
||||
- `DELETE /api/plans/<plan>/days/<day>/exercises/<item>`
|
||||
|
||||
Eine Übung besitzt ein Standardformat. Jede Progressionsstufe kann es überschreiben.
|
||||
Der alte aktive Config-Zugriff bleibt fuer einfache Clients erhalten:
|
||||
|
||||
Priorität im Tracker:
|
||||
- `GET /api/config`
|
||||
- `POST /api/config`
|
||||
- `GET /api/default`
|
||||
- `POST /api/reset`
|
||||
|
||||
```text
|
||||
manuelle Anpassung der aktuellen Session
|
||||
→ Schema der gewählten Progressionsstufe
|
||||
→ Standard der Übung
|
||||
→ automatische Erkennung als Fallback
|
||||
```
|
||||
## Migration
|
||||
|
||||
Unterstützt werden Wiederholungen, Sekunden, Minuten, keine Zahl, optionales oder verpflichtendes Gewicht sowie gemeinsame oder getrennte Seitenwerte.
|
||||
|
||||
## Tabata und feste Intervalle
|
||||
|
||||
Das Trainingsformat wird ausdrücklich gespeichert:
|
||||
|
||||
```json
|
||||
{
|
||||
"mode": "tabata",
|
||||
"fixed_interval": true,
|
||||
"work_seconds": 20,
|
||||
"rest_seconds": 10,
|
||||
"rounds": 8,
|
||||
"rounds_scope": "block"
|
||||
}
|
||||
```
|
||||
|
||||
`rounds` bezeichnet Intervalle pro Block. Bei acht Intervallen und vier Übungen entstehen zwei Durchgänge pro Übung. Eine zusätzlich im Rotationstitel angegebene Satzanzahl wird damit multipliziert. Ist die Intervallzahl nicht gleichmäßig durch die Übungszahl teilbar, meldet die Validierung einen Hinweis und verlangt eine feste Wertezahl im Ergebnisschema.
|
||||
|
||||
## Übungsbibliothek und Analysefaktoren
|
||||
|
||||
Aus den Übungen und Progressionen wird eine planbezogene `exercise_catalog` erzeugt. Sie enthält stabile Bewegungs-IDs, Cluster, Varianten, Ergebnisschemata und Faktoren. Diese Angaben haben im Tracker Vorrang vor Namens- und Regex-Erkennung.
|
||||
|
||||
## Prüfung und Tracker-Vorschau
|
||||
|
||||
Der Tab **Prüfung & Vorschläge** zeigt:
|
||||
|
||||
- Validierungsfehler und Hinweise,
|
||||
- das vom Tracker erwartete Ergebnisformat pro Übung,
|
||||
- stufenabhängige Überschreibungen,
|
||||
- die berechneten Durchgänge fester Intervallblöcke,
|
||||
- strukturierte KI-Vorschläge aus dem Tracker mit stabilen Ziel-IDs.
|
||||
|
||||
Vorschläge werden niemals automatisch in den Plan geschrieben. Über **Ziel im Entwurf öffnen** springt der Editor anhand der stabilen IDs direkt zur betroffenen Übung oder Progression. Nach der manuellen Änderung kann der Vorschlag als übernommen oder abgelehnt markiert werden.
|
||||
|
||||
## Kompatibilität
|
||||
|
||||
Ältere Pläne werden beim Laden in das neue Schema überführt. Fehlende Ergebnisschemata erhalten dabei einmalig explizite, im Editor korrigierbare Migrationswerte. Die veröffentlichten Beispielpläne liegen bereits in Version 3 vor. Rezeptsammlungen bleiben vom Trainingsvertrag unberührt.
|
||||
Aeltere Trainingsplaene werden beim Laden auf den flachen Vertrag reduziert.
|
||||
Uebungen aus alten Rotationen werden in die Uebungsbibliothek uebernommen und
|
||||
als Tagesuebungen referenziert. Warm-up und Cool-down werden aus den bisherigen
|
||||
Tages- oder `prepost`-Feldern uebernommen.
|
||||
|
||||
Reference in New Issue
Block a user