shinkan-jinkendo/.claude/docs/working/COMBINATION_TIMING_PROFILE_PLAN.md

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	Wiederholungen pro „Serie“ bzw. ohne Wechsel zu neuem Stationsinhalt (oft 1).
rep_series_count	Anzahl Serien à consecutive_reps bei rep/manual; Standard 1, Archetyp‑Vorgabe möglich (ARCHETYPE_DEFAULT_REP_SERIES_COUNT). Persistiert für rep/manual ab 1.
intra_rep_rest_sec	Pause zwischen den Folge‑Wiederholungen bzw. zwischen Serien (nur sinnvoll, wenn rep_series_count ≥ 2 im Modus rep/manual; sonst Wechselzeit transition_after_sec nutzen).
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 (Merge wie in comboPlanningMethodProfile.js); globale Profilwerte mit fachlichen Labels (describeGlobalComboProfile), nicht nur Rohschlüsseln.

4.1 Stand Umsetzung (App 0.8.110, Kurz)

• slot_profiles_v1 und Schnellwahlen Zirkel/Intervall im geführten Editor umgesetzt; advance_mode je Slot (Zeit / Ziel‑Wdh. / Coach).
• Phase 2 dieses Plans (Modal „Archetyp‑Vorlage anwenden?“, nicht‑destruktives Merge über alle Slots) — noch offen (Fachspez § 10.6, Umsetzungsplan Paket 4f).

---

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.