- Updated app version to 0.8.104, reflecting recent improvements in combination exercise handling. - Enhanced the CombinationMethodProfileEditor to support structured slot timing profiles without requiring JSON input from trainers. - Introduced quick ratio presets for circuit and interval training methods, improving user experience in setting up training profiles. - Updated documentation and changelog to reflect new features and integration details. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
5.4 KiB
Kombinations‑Ablaufprofil — Zeitmodell, Archetyp‑Vorgaben, Umsetzung
Zweck: Fach-/Technik-Brücke zwischen Wunschbild („kein Nutzer‑JSON“, globale und slotbezogene Eckwerte, Archetyp‑Strukturen) und bestehendem Speicher method_profile (JSON) + planning_method_profile auf Planungszeilen.
Bezüge: .claude/docs/functional/Shinkan Trainingsmodule Kombinationsuebungen Spezifikation V2.md (§ 6.3 / § 8.3); Frontend CombinationMethodProfileEditor, combinationMethodProfileUi.js; Archetyp‑IDs siehe Backend COMBINATION_ARCHETYPE_IDS / Frontend COMBINATION_ARCHETYPE_OPTIONS.
1. Grundprinzipien
| Prinzip | Beschreibung |
|---|---|
| Kein Pflicht‑JSON für Trainer | Alle trainertypischen Pflegepfade nur über geführte Felder + Archetyp‑Vorschlagsknöpfe. |
| JSON bleibt Transport | Persistenz geschieht weiter in method_profile / Kopie in planning_method_profile; kanonische Schlüssel werden hier und in Codekommentaren festgehalten. |
| Archetyp = Struktur + Defaults | Wechsel des Archetyps soll (optional/togglebar) Grundwerte oder typische Relationen vorbelegen können — keine stillen Überschreibungen ohne Hinweis. |
free_method_block = Maximale Freiheit |
Entspricht „maximaler Konfiguration“: alle relevanten Timing‑Dimensionen über UI, insbesondere pro Slot; keine impliziten stationären Constraints. |
2. Kanonisches Zeit‑Schema (timing_schema)
Empfohlene Versionierung im Objekt:
timing_schema: 1— sobald neue globale/strukturierte Felder aktiv genutzt werden (Pilot; UI kann ohne Migration starten durch parallele Schlüssel).
2.1 Globalebene (method_profile)
| Feld (Pilot) | Semantik |
|---|---|
timing_schema |
1 wenn Block unten aktiv |
intro_sec oder bestehend block_intro_sec |
einmalige Einführung/Demo am Block |
rounds (bzw. bei Intervallen interval_rounds — Angleich später) |
komplette Durchläufe des Musters |
Planned totals nur berechnete Anzeige in UI, optional persistiert z. B. planned_total_duration_min_hint später |
Relationen Zwischen Arbeit und Pause können als Schnellwahl gesetzt werden (kein eigener Persist‑Erzwing‑Typ nötig), indem konkrete Sekunden geschrieben werden.
2.2 Slots (slot_profiles_v1)
Array synchron zu slot_index; fehlende Einträge = „nicht gefüllt / aus globalen Eckdaten ableiten wo sinnvoll“.
Objekt‑Shape (Sekunden, ganze Zahlen ≥ 0):
{
"slot_index": 0,
"load_sec": 40,
"consecutive_reps": 1,
"intra_rep_rest_sec": 10,
"transition_after_sec": 15
}
| Feld | Bedeutung |
|---|---|
load_sec |
Belastungsdauer „an der Station“. |
consecutive_reps |
Übungen hintereinander ohne Wechsel zu neuem Stationsinhalt („oft 1“). |
intra_rep_rest_sec |
Pause zwischen diesen Folge‑Wiederholungen. |
transition_after_sec |
Pause / Wechsel zur nächsten Station oder zum nächsten logischen Block. |
Hinweis: Bestehende Archetyp‑„flachen“ Schlüssel (work_seconds, transition_seconds, …) werden schrittweise nicht zerstört, sondern Slots ergänzen; Konvergenz (eine Darstellung zu v1) kann Phase 4 sein.
3. Archetyp → typische Schnellwahl (Überblicks‑Matrix)
| Archetyp | Globale Schnellwahl (Beispiele) | Slots |
|---|---|---|
circuit_rotate_time |
Arbeit; Rotation „≈ Arbeit“ oder „Pause 2/3 Arbeit“ bezogen auf Rund‑Pausen/Rotation wo im UI dokumentiert | sinnvoll ab timing_schema geführt |
time_domain_interval |
Pause = Arbeit; Pause = 2/3 Arbeit (auf rest_seconds↔work_seconds) |
optional |
sequence_linear |
Einführung + grobe Sek./Station | slot_profiles_v1 priorisiert |
circuit_all_parallel |
Erklärzeit, gemeinsamer Start | Slots optional |
pair_superset |
Wechsel A↔B, Arbeit je Seite (+ später erweiterbar) | 2‑Slot‑Fokus |
free_method_block |
alle globalen Slots optional | Pfad für maximale Flex |
station_parcour |
Reihenfolge frei‑Flag bestehend | pro Station Verweilen sinnvoll |
Pyramidal (später): neue Archetyp‑ID pyramid_interval o. ä. oder Flag pyramid_recovery_rule mit Regelwerk „Pause abhängig von letzter Belastung“ — explizit out of scope bis Regeln feststehen.
4. UX‑Normen
- Trainingsplanung (
plannerMode): keine Roh‑JSON‑Oberfläche. - Übungsformular: Roh‑JSON nur wenn
allowExpertJson === true(Default false; später z. B. Superadmin/Dev). - Coaching‑Ansicht: nur wirksame Zahlen aus Snapshot/Katalog darstellen, mittelfristig Labels statt Schlüsseln.
5. Phasen (Implementierung)
| Phase | Inhalt |
|---|---|
| 1 (jetzt) | Slot‑Zeilen‑UI über slot_profiles_v1; Schnellwahl‑Ratios für circuit_rotate_time + time_domain_interval; plannerMode ohne JSON; allowExpertJson default false |
| 2 | Beim Archetypwechsel optionales Modal „Archetyp‑Vorlage anwenden?“ mit nicht‑destruktivem Merge |
| 3 | Geplante Gesamtzeit konsistent rechnerisch (Summe Slots × Runden + Global) mit Transparenz in UI |
| 4 | Konsolidierung flacher Schlüssel → timing_schema v1‑only im Editor |
| 5 | Pyramide / adaptive Recovery |
Pflege: Änderungen an Schlüsseln oder Phasen hier und in Anhang A der Fachspez mitziehen.