shinkan-jinkendo/.claude/docs/working/COMBINATION_TIMING_PROFILE_PLAN.md
Lars 435da7f17a
All checks were successful
Deploy Development / deploy (push) Successful in 40s
Test Suite / pytest-backend (push) Successful in 35s
Test Suite / lint-backend (push) Successful in 0s
Test Suite / build-frontend (push) Successful in 11s
Test Suite / playwright-tests (push) Successful in 56s
feat(version): bump to 0.8.104 and enhance combination exercise features
- 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>
2026-05-13 07:38:44 +02:00

5.4 KiB
Raw Blame History

KombinationsAblaufprofil — Zeitmodell, ArchetypVorgaben, Umsetzung

Zweck: Fach-/Technik-Brücke zwischen Wunschbild („kein NutzerJSON“, globale und slotbezogene Eckwerte, ArchetypStrukturen) und bestehendem Speicher method_profile (JSON) + planning_method_profile auf Planungszeilen.

Bezüge: .claude/docs/functional/Shinkan Trainingsmodule Kombinationsuebungen Spezifikation V2.md6.3 / §8.3); Frontend CombinationMethodProfileEditor, combinationMethodProfileUi.js; ArchetypIDs siehe Backend COMBINATION_ARCHETYPE_IDS / Frontend COMBINATION_ARCHETYPE_OPTIONS.


1. Grundprinzipien

Prinzip Beschreibung
Kein PflichtJSON für Trainer Alle trainertypischen Pflegepfade nur über geführte Felder + ArchetypVorschlagsknö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 TimingDimensionen über UI, insbesondere pro Slot; keine impliziten stationären Constraints.

2. Kanonisches ZeitSchema (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 PersistErzwingTyp 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“.

ObjektShape (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 FolgeWiederholungen.
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 (ÜberblicksMatrix)

Archetyp Globale Schnellwahl (Beispiele) Slots
circuit_rotate_time Arbeit; Rotation „≈ Arbeit“ oder „Pause 2/3 Arbeit“ bezogen auf RundPausen/Rotation wo im UI dokumentiert sinnvoll ab timing_schema geführt
time_domain_interval Pause = Arbeit; Pause = 2/3 Arbeit (auf rest_secondswork_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) 2SlotFokus
free_method_block alle globalen Slots optional Pfad für maximale Flex
station_parcour Reihenfolge freiFlag bestehend pro Station Verweilen sinnvoll

Pyramidal (später): neue ArchetypID pyramid_interval o. ä. oder Flag pyramid_recovery_rule mit Regelwerk „Pause abhängig von letzter Belastung“ — explizit out of scope bis Regeln feststehen.


4. UXNormen

  • Trainingsplanung (plannerMode): keine RohJSONOberfläche.
  • Übungsformular: RohJSON nur wenn allowExpertJson === true (Default false; später z.B. Superadmin/Dev).
  • CoachingAnsicht: nur wirksame Zahlen aus Snapshot/Katalog darstellen, mittelfristig Labels statt Schlüsseln.

5. Phasen (Implementierung)

Phase Inhalt
1 (jetzt) SlotZeilenUI über slot_profiles_v1; SchnellwahlRatios für circuit_rotate_time + time_domain_interval; plannerMode ohne JSON; allowExpertJson default false
2 Beim Archetypwechsel optionales Modal „ArchetypVorlage anwenden?“ mit nichtdestruktivem Merge
3 Geplante Gesamtzeit konsistent rechnerisch (Summe Slots × Runden + Global) mit Transparenz in UI
4 Konsolidierung flacher Schlüssel → timing_schema v1only im Editor
5 Pyramide / adaptive Recovery

Pflege: Änderungen an Schlüsseln oder Phasen hier und in Anhang A der Fachspez mitziehen.