chore: update documentation and enhance exercise progression graph details

- Updated CLAUDE.md to reflect the addition of exercise_progression_graphs in the backend routers. - Revised PROJECT_STATUS.md to document the current project status and recent milestones, including the implementation of the exercise progression graph feature. - Incremented versioning in DOMAIN_MODEL.md and DATABASE_SCHEMA.md to align with the latest migration updates. - Enhanced technical specifications in TRAINING_FRAMEWORK_SPEC.md to clarify the implementation details of the exercise progression graph and its integration with the training framework.
2026-05-05 08:30:48 +02:00 · 2026-05-05 08:30:48 +02:00 · f5895b6637
commit f5895b6637
parent ae6c089366
11 changed files with 208 additions and 109 deletions
--- a/.claude/docs/PROJECT_STATUS.md
+++ b/.claude/docs/PROJECT_STATUS.md
@ -1,31 +1,30 @@
 # Shinkan Jinkendo - Projekt-Status

-**Stand:** 2026-04-27  
-**Version (Code):** 0.7.9 (`backend/version.py`, APP_VERSION)  
-**DB-Schema-Version:** `20260427030`  
+**Stand:** 2026-04-30  
+**Version (Code):** 0.8.7 (`backend/version.py`, APP_VERSION)  
+**DB-Schema-Version:** `20260430034`  
 **Branch:** develop  

 ---

 ## Executive Summary

-**Aktueller Meilenstein:** Übungsvarianten Ende-zu-Ende (API, DB 030, Planung, UI) sowie Listen-Suche ohne Full-Page-Reload ✅
+**Aktueller Meilenstein:** **Progressionsgraph zwischen Übungen** (DB 032–034, API `exercise-progression-graphs`, UI Tabs + Formularblock) — **Zwischenstand**: linear/Reihen/Schwestern gut nutzbar; **parallele gleichwertige Alternativ‑„Pakete“** noch ohne dedizierte UX (**TRAINING_FRAMEWORK_SPEC.md** §4). Ausreichend, um mit **Trainingsplanung / Rahmen** (**CURR‑002 (2)**) weiterzuarbeiten.

 **Letzte dokumentierte Änderungen (April 2026):**

- ✅ Migration **030**: `training_unit_exercises.exercise_variant_id` (FK zu `exercise_variants`, ON DELETE SET NULL).
- ✅ **GET `/api/exercises?include_variants=true`** für Trainingsplanung und Übersichten.
- ✅ Varianten-**CRUD** + **Reorder**; Validierung in der Trainingsplanung (Variante gehört zur Übung).
- ✅ **Übungsliste**: Filter-Chips, Modal, `listFetching` statt Full-Page-Spinner, `<datalist>`-Titel aus Treffern.
- ✅ **Medien-Upload**: rollenbasierte Limits (Standard 50 MB, Admin bis 1024 MB, Env-Vars).
- ✅ **RichTextEditor**: Selection-Restore, Listen-Styling im Editor.
+- ✅ Migration **032–034**: `exercise_progression_graphs`, `exercise_progression_edges` inkl. **`notes`**, optionale Varianten-Endpunkte.
+- ✅ **`POST /api/exercise-progression-graphs/{id}/edges/sequence`** und **`…/edges/delete-batch`**.
+- ✅ **Übungsliste:** Tabs Liste · Progressionsgraphen; **Übung bearbeiten:** Block Progressionsgraph.
+- ✅ Zuvor geliefert: Varianten Ende-zu-Ende (030), Listen-Suche UX, Medien-Limits, RichText — siehe unten und Feature-Doc.

-**Referenz:** Ausführliche technische Liste → [`library/FEATURES_DELIVERED_2026-Q2.md`](library/FEATURES_DELIVERED_2026-Q2.md)
+**Referenz:** Ausführliche technische Liste → [`library/FEATURES_DELIVERED_2026-Q2.md`](library/FEATURES_DELIVERED_2026-Q2.md) · Zwischenstand Graph → [`technical/TRAINING_FRAMEWORK_SPEC.md`](technical/TRAINING_FRAMEWORK_SPEC.md)

 **Nächste Schritte (Auszug):**

-1. Prod-Deployment der Migrationen **020–030** und Smoke-Tests.
-2. Optional: Server-Autocomplete für Suche; Progressions-Serien als Blöcke (siehe Feature-Doc).
+1. **Trainingsplanungs-/Rahmenmodul** nach CURR‑002 (2), CURR‑009–013 (Graph bleibt unterstützend).
+2. Prod-Deployment Migrationen bis **034** und Smoke-Tests.
+3. Optional Backlog Graph: Alternativgruppen / bessere Visualisierung verzweigter Graphen.

 ---

@ -42,6 +41,7 @@
 | 023 | Skills Complete Import (69 Skills) | ✅ | 🔲 |
 | 028–029 | exercise_media / skills Stufen | ✅ | 🔲 |
 | **030** | **training_unit_exercises.exercise_variant_id** | ✅ | 🔲 |
+| **032–034** | **Progressionsgraph Übung→Übung** | ✅ | 🔲 |

 ---

@ -66,6 +66,7 @@ Die exakten Zahlen hängen von der Umgebung ab (siehe Admin/DB). Die Skills/Übu
 - [x] CRUD (Create, Read, Update, Delete)
 - [x] M:N Beziehungen (Focus Areas, Styles, Target Groups, Skills)
 - [x] **Varianten** (CRUD, Reorder, Voraussetzung) + Anzeige im Detail
+- [x] **Progressionsgraph zwischen Übungen** (Bibliotheks-Container, Kanten, Sequenz-Bulk, Varianten-Knoten — Zwischenstand, siehe TRAINING_FRAMEWORK_SPEC §4)
 - [x] Medien (Upload/Embed, rollenabhängige Größenlimits)
 - [x] Suche & Filter (Multi-Filter, Chips, Fokus beim Suchen)
 - [x] Exercise Blocks (Bausteine)
@ -121,7 +122,7 @@ Die exakten Zahlen hängen von der Umgebung ab (siehe Admin/DB). Die Skills/Übu

 ### Dev

-Branch `develop`; Migrations bis mindestens **030** auf dem aktuellen Entwicklungsstand; Details in `backend/version.py`.
+Branch `develop`; Migrations bis mindestens **034** auf dem aktuellen Entwicklungsstand; Details in `backend/version.py`.

 ### Prod

@ -133,15 +134,16 @@ Deployment der oben genannten Migrationen und Datenabgleich nach internem Prozes

 | Dokument | Pfad | Stand | Status |
 |----------|------|-------|--------|
-| Lieferliste Q2 2026 | `library/FEATURES_DELIVERED_2026-Q2.md` | 2026-04-27 | ✅ Neu |
+| Lieferliste Q2 2026 | `library/FEATURES_DELIVERED_2026-Q2.md` | 2026-04-30 | ✅ Aktualisiert (032–034) |
+| Trainingsrahmen (Zwischenstand Graph) | `technical/TRAINING_FRAMEWORK_SPEC.md` | 2026-04-30 | ✅ |
 | Anforderungen (Index) | `functional/SHINKAN_REQUIREMENTS.md` | 2026-04-27 | ✅ Neu |
-| Database Schema | `technical/DATABASE_SCHEMA.md` | 2026-04-27 | ✅ Aktualisiert (030) |
-| Domain Model | `functional/DOMAIN_MODEL.md` | 2026-04-27 | ✅ Referenz |
-| API Übungen | `technical/EXERCISES_API_SPEC.md` | 2026-04-27 | ✅ Aktualisiert (v1.3) |
-| Frontend Routing | `technical/EXERCISES_FRONTEND_ROUTING.md` | 2026-04-27 | ✅ Aktualisiert |
+| Database Schema | `technical/DATABASE_SCHEMA.md` | 2026-04-30 | ✅ Aktualisiert (034) |
+| Domain Model | `functional/DOMAIN_MODEL.md` | 2026-04-30 | ✅ Aktualisiert |
+| API Übungen | `technical/EXERCISES_API_SPEC.md` | 2026-04-30 | ✅ Ergänzt Progressions-API |
+| Frontend Routing | `technical/EXERCISES_FRONTEND_ROUTING.md` | 2026-04-30 | ✅ Ergänzt UI-Hinweise |
 | Search & Filter | `technical/SEARCH_FILTER_SPEC.md` | 2026-04-27 | ✅ Aktualisiert (Liste UX) |
 | Media Upload | `technical/MEDIA_UPLOAD_SPEC.md` | 2026-04-27 | ✅ Aktualisiert (Limits) |
-| Projektstatus | `PROJECT_STATUS.md` | 2026-04-27 | ✅ Diese Datei |
+| Projektstatus | `PROJECT_STATUS.md` | 2026-04-30 | ✅ Diese Datei |

 ---

@ -152,4 +154,4 @@ Deployment der oben genannten Migrationen und Datenabgleich nach internem Prozes

 ---

-**Letzte Aktualisierung:** 2026-04-27  
+**Letzte Aktualisierung:** 2026-04-30  
--- a/.claude/docs/functional/DOMAIN_MODEL.md
+++ b/.claude/docs/functional/DOMAIN_MODEL.md
@ -1,7 +1,7 @@
 # Shinkan Jinkendo - Fachliches Domänenmodell

-**Version:** 0.4.0  
-**Stand:** 2026-04-27 (Migration 023: Skills Complete Import)  
+**Version:** 0.4.1  
+**Stand:** 2026-04-30 (Migration 034: Progressionsgraph Übung→Übung; Skills weiterhin ab 023)  
 **Basis:** `shinkan_anforderungsdokument_entwurf.md` + Fähigkeitsmatrix

 ---
@ -458,6 +458,14 @@ skill_level_definitions (

 **Umsetzung (Trainingsplanung):** Ein Eintrag in `training_unit_exercises` kann optional eine konkrete Varianten-ID (`exercise_variant_id`, Migration 030) tragen; Bindung wird gegen die gewählte Übung validiert. Varianten werden über die Übungs-API verwaltet (`technical/EXERCISES_API_SPEC.md`).

+### Progressionsgraph zwischen Übungen (Zwischenstand, CURR‑002 Stufe 1)
+
+**Abgrenzung:** Zusätzlich zur Varianten-Reihe **innerhalb** einer Übung gibt es optional einen **Bibliotheks-Progressionsgraphen**: gerichtete Kanten zwischen **Übungen** (Knoten optional auf konkrete **Varianten** eingegrenzt). Gemeinsamer Kontainer pro Graph (`exercise_progression_graphs`); Kanten mit Typ z. B. Nachfolger oder Schwester.
+
+**Rolle:** **unterstützend** für Planung und spätere Rahmenprogramme — keine Pflicht, jeden Trainingsablauf als Graph zu modellieren (**CURR‑013**).
+
+**Fachliche Grenze aktuell:** Mehrere gleichwertige „Pakete“ paralleler Alternativen sind **modellierbar** (mehrere ausgehende Kanten), aber noch **nicht** über eine dedizierte „Alternativgruppe“ in der UI trivial pflegbar; siehe `technical/TRAINING_FRAMEWORK_SPEC.md` §4.
+
 ---

 ## Methodenbezug (§11.5)
--- a/.claude/docs/functional/TRAINING_CURRICULUM_AND_GOVERNANCE_CONCEPT.md
+++ b/.claude/docs/functional/TRAINING_CURRICULUM_AND_GOVERNANCE_CONCEPT.md
@ -1,7 +1,7 @@
 # Konzept: Trainingsplanung über Einheiten hinweg, Kurspläne, Governance, Assessments

 **Status:** Arbeitspapier (lebend)  
-**Stand:** 2026-04-29 (Schritt C Kernentscheide CURR‑009–013)  
+**Stand:** 2026-04-30 (CURR‑002 Stufe 1 Zwischenstand im Produkt; Rahmen CURR‑002 (2) als nächster Schritt)  
 **Zweck:** Erkenntnisse und **getroffene Entscheidungen** festhalten, um Spec- und Implementierungsdrift zu vermeiden.  
 **Kanons:** Bei Widersprüchen mit produktiven Specs zuerst diese Datei mit dem Team abstimmen; technische Details ergänzen später in `technical/`.

@ -28,8 +28,8 @@

 | Stufe | Inhalt | Status |
 |--------|--------|--------|
-| **1** | **Progressionsbezüge** zwischen Übungen **persistent speicherbar** (Progressionsbaum / -graph zwischen Übungseinheiten, nicht nur UI) | 📋 nächste fachliche + technische Ausarbeitung |
-| **2** | **Planungs-/Rahmenmodus:** Übungen (beliebig oder aus Progression) auf **mehrere** Session-Slots / Trainingseinheiten **verteilen**, **mehrere Ziele**; speicherbare Rahmen-Vorlage (CURR‑002 (2) i. V. m. **CURR‑010–013**) | nach Stufe 1 möglich, Logik bereits teils fachlich festgelegt |
+| **1** | **Progressionsbezüge** zwischen Übungen **persistent speicherbar** (Progressionsbaum / -graph zwischen Übungseinheiten, nicht nur UI) | ✅ **Zwischenstand im Produkt** (Migrationen 032–034, UI/API); UX für **parallele gleichwertige Alternativ‑Pakete** noch kein Erstklass‑Fall — siehe `technical/TRAINING_FRAMEWORK_SPEC.md` §4 |
+| **2** | **Planungs-/Rahmenmodus:** Übungen (beliebig oder aus Progression) auf **mehrere** Session-Slots / Trainingseinheiten **verteilen**, **mehrere Ziele**; speicherbare Rahmen-Vorlage (CURR‑002 (2) i. V. m. **CURR‑010–013**) | **nächster Implementierungsschwerpunkt** — Stufe 1 ist nicht Blocker (**CURR‑013**) |
 | **3** | **Konkrete Einheit:** aus Rahmen-/Verteilungsplan **Vorschläge** beim Ausarbeiten laden; Bezug zur Idee **„Warenkorb“** bei der Übungsplanung | folgt nach 2 |

 ### 2.b Übrige Konzept-Schritte (noch durchzuarbeiten)
@ -44,7 +44,7 @@
 | **F** | **Assessments** | 📌 Backlog (CURR-003) |
 | **G** | **Progressions-Automatik** (KI, komplexe Vorschläge) | 📌 Backlog (CURR-003) |

-**Aktueller Fokus:** Technische Ausarbeitung (Modus‑Flags Felder zweier Nutzungsbilder, Datenmodell **mehrere Ziele**, Slot‑Übung‑Zuordnung; Progressionsgraph Stufe 1 parallel). Schritt **E** (Lineage) als nächstes Konzeptpaket möglich.
+**Aktueller Fokus:** Umsetzung **Trainingsplanungs-/Rahmenmodul** (**CURR‑002 (2)**): Entitäten, Slots, mehrere Ziele — Progressionsgraph Stufe 1 ist **bereits** als unterstützende Bibliotheksfunktion vorhanden (**TRAINING_FRAMEWORK_SPEC.md**). Schritt **E** (Lineage) als nächstes Konzeptpaket möglich.

 ---

@ -204,8 +204,8 @@ Siehe **CURR-003:** Kurs-/Stufenprogramm (nach Rahmenkern), Assessments (Plantyp
 ## 8. Nächste Aktion (für dich / Team)

 1. ~~**Schritt C**~~ · siehe §2.d · **CURR‑009 bis CURR‑013**
-2. **Technical Spec:** `technical/TRAINING_FRAMEWORK_SPEC.md` — Datenmodell **Rahmen‑Entität** + **Zielliste** + Slot‑Zuordnung; Modus A/B; Graph Stufe 1 (**CURR‑002** (1))
-3. **Migrate** weiter **CURR‑007 / CURR‑008**
+2. ~~Progressionsgraph Stufe 1~~ ✅ siehe **`technical/TRAINING_FRAMEWORK_SPEC.md`** §3–§4 · **Jetzt:** **`TRAINING_FRAMEWORK_SPEC.md`** §2 (Checkliste) mit **DDL-/API-Abschnitt Rahmen** ergänzen (**CURR‑002 (2)**); Modus A/B siehe Funktionskonzept §6
+3. **Migrate** weiter **CURR‑007 / CURR‑008** (ideal parallel oder vor erster Rahmen‑Migration mit neuem Bibliothekstyp)
 4. Konzeptpaket optional **Schritt E** Lineage vor Implementierung Großrelease

 ---
@ -214,6 +214,7 @@ Siehe **CURR-003:** Kurs-/Stufenprogramm (nach Rahmenkern), Assessments (Plantyp

 | Datum | Änderung |
 |-------|-----------|
+| 2026-04-30 | §8 Punkt 2 angepasst (Graph ✅; nächster Fokus Rahmen‑Spec **CURR‑002 (2)**). |
 | 2026-04-28 | Technische Ausarbeitung gebündelt: neue Datei **`technical/TRAINING_FRAMEWORK_SPEC.md`** (Stub); Verweis §8. |
 | 2026-04-29 | **CURR‑009–013**, **CURR‑002** präzisiert; Glossar Modi A/B Slot; §2.d C geklärt; §6‑Backlog gekürzt. |
 | 2026-04-29 | CURR‑008 (Migration Standard‑Verein); **§2.d Schritt C** Checkpoints C1–C5; Glossar/§6 angepasst. |
--- a/.claude/docs/library/FEATURES_DELIVERED_2026-Q2.md
+++ b/.claude/docs/library/FEATURES_DELIVERED_2026-Q2.md
@ -1,9 +1,9 @@
 # Gelieferte Features & technische Basis (April 2026)

-**Stand:** 2026-04-27  
-**Referenz:** `backend/version.py` — **APP_VERSION 0.7.9**, **DB_SCHEMA_VERSION 20260427030**
+**Stand:** 2026-04-30  
+**Referenz:** `backend/version.py` — **APP_VERSION 0.8.7**, **DB_SCHEMA_VERSION 20260430034**

-Dieses Dokument bündelt die in der Entwicklungsphase erreichten **lieferbaren** Funktionen und die zugehörigen **technischen Artefakte**. Detail-Spezifikationen bleiben in den verlinkten Pfaden unter `.claude/docs/technical/` und `.claude/docs/functional/`.
+Dieses Dokument bündelt die in der Entwicklungsphase erreichten **lieferbaren** Funktionen und die zugehörigen **technischen Artefakte**. **Progressionsgraph zwischen Übungen** (Zwischenstand, Grenzen): **`technical/TRAINING_FRAMEWORK_SPEC.md`** §3–§4. Detail-Spezifikationen bleiben in den verlinkten Pfaden unter `.claude/docs/technical/` und `.claude/docs/functional/`.

 ---

@ -11,20 +11,29 @@ Dieses Dokument bündelt die in der Entwicklungsphase erreichten **lieferbaren**

 | Migration | Inhalt |
 |-----------|--------|
+| **032–034** | **Progressionsgraph Übung→Übung:** Container `exercise_progression_graphs`, Kanten `exercise_progression_edges`; **`notes`** (033); optionale Varianten-Endpunkte + Constraints (034) |
 | **028** | `exercise_media` erweitert (Embed/Metadaten), `exercise_skills` Level-Felder (VARCHAR); Medien-API |
 | **029** | Kanonische Fähigkeitsstufen (basis–optimierung), `model_levels`-Namen |
 | **030** | `training_unit_exercises.exercise_variant_id` → FK `exercise_variants(id)` ON DELETE SET NULL |

 ---

-## 2. Backend – Übungen (`routers/exercises.py`)
+## 2. Backend – Progressionsgraphen (`routers/exercise_progression_graphs.py`)

-### 2.1 Liste & Suche
+- REST unter **`/api/exercise-progression-graphs`** inkl. Kanten-CRUD, **`POST …/edges/sequence`** (Reihe auf einmal), **`POST …/edges/delete-batch`**.
+- AuthZ wie Trainingsvorlagen: Admin/Superadmin oder Graph‑Ersteller; Anlegen mit Trainings-/Planungsrolle (`_has_planning_role`).
+- Listenresponses mit Übungstiteln und Variantennamen (JOIN).
+
+---
+
+## 3. Backend – Übungen (`routers/exercises.py`)
+
+### 3.1 Liste & Suche

 - `GET /api/exercises` mit Filtern u. a.: Fokus, Stilrichtung, Trainingsstil, Zielgruppe, Fähigkeiten, **Skill-Stufe min/max**, `visibility_any`, `status_any`, `search`, **`ai_search`** (Platzhalter, derzeit gleiche Volltextlogik wie `search`).
 - Optional: **`include_variants=true`** — liefert pro Übung ein kompaktes **`variants`**-JSON (id, variant_name, sequence_order) für Planung/UI.

-### 2.2 Übungsvarianten (CRUD)
+### 3.2 Übungsvarianten (CRUD)

 Implementiert gemäß **`EXERCISES_API_SPEC.md`** (Varianten-Abschnitt):

@ -35,7 +44,7 @@ Implementiert gemäß **`EXERCISES_API_SPEC.md`** (Varianten-Abschnitt):

 Sortierung der Varianten im Detail: **`sequence_order`**, dann **`progression_level`**, dann **`id`**.

-### 2.3 Medien-Upload – Größenlimits
+### 3.3 Medien-Upload – Größenlimits

 - Standard: **50 MB** pro Datei (`EXERCISE_MEDIA_MAX_UPLOAD_MB`, Default 50).
 - **`admin`** / **`superadmin`**: **1024 MB** Default (`EXERCISE_MEDIA_ADMIN_MAX_UPLOAD_MB`), nie unter dem Nutzer-Limit (in MB verglichen).
@ -44,7 +53,7 @@ Logik: `_upload_limit_bytes(session)` vor `read()`-Prüfung.

 ---

-## 3. Backend – Trainingsplanung (`routers/training_planning.py`)
+## 4. Backend – Trainingsplanung (`routers/training_planning.py`)

 - `training_unit_exercises`: Schreiben/Lesen von **`exercise_variant_id`**.
 - Validierung: Variante muss zur gewählten **`exercise_id`** gehören.
@ -52,8 +61,9 @@ Logik: `_upload_limit_bytes(session)` vor `read()`-Prüfung.

 ---

-## 4. Frontend – Übungsliste (`ExercisesListPage.jsx`)
+## 5. Frontend – Übungsliste (`ExercisesListPage.jsx`)

+- Tabs **Liste** · **Progressionsgraphen** (`ExerciseProgressionGraphPanel`): Graphen anlegen/bearbeiten, Kanten inkl. Sequenz-Bulk und Tabellenansicht.
 - **Filter-Modal** (Fokus, Stilrichtung, Trainingsstil, Zielgruppe, Fähigkeit + Stufen von/bis, Sichtbarkeit, Status).
 - **Filter-Chips** unter der Suchleiste; Klick entfernt einen Filter; Badge am Filter-Button = Anzahl Chips.
 - **Kein Vollbild-Spinner** bei jeder Suche: nur noch **`listFetching`** — Suchfelder bleiben im DOM (**Fokus/Cursor** bleiben erhalten); Liste zeigt optional „Aktualisiere Treffer…“.
@ -62,29 +72,30 @@ Logik: `_upload_limit_bytes(session)` vor `read()`-Prüfung.

 ---

-## 5. Frontend – Übung bearbeiten (`ExerciseFormPage.jsx`)
+## 6. Frontend – Übung bearbeiten (`ExerciseFormPage.jsx`)

 - **Varianten-Editor**: eingeklappter Bereich (`<details>`), **eine Variante zur Zeit** über Dropdown oder „Neue Variante“; Felder über **`ExerciseVariantFields`**; Reihenfolge Nach oben/unten; Speichern/Löschen pro Variante.
 - **Medien** wie zuvor (Formularteil).
+- Block **Progressionsgraph** (Edit): Kanten mit Bezug zur aktuellen Übung.

 Hinweis: Es gibt **keine** separaten Routen `/exercises/:id/variants/...` — Bearbeitung erfolgt unter **`/exercises/:id/edit`** (Routing-Doku ggf. anpassen).

 ---

-## 6. Frontend – Übung Detail (`ExerciseDetailPage.jsx`)
+## 7. Frontend – Übung Detail (`ExerciseDetailPage.jsx`)

 - Varianten-Abschnitt mit **Meta** (Dauer, Schwierigkeit, Material, Progressionsstufe) wo vorhanden.

 ---

-## 7. Frontend – Trainingsplanung (`TrainingPlanningPage.jsx`)
+## 8. Frontend – Trainingsplanung (`TrainingPlanningPage.jsx`)

 - `listExercises({ include_variants: true })`.
 - Pro Zeile: Übung + **Variante** (optional), Dauer, Reihenfolge.

 ---

-## 8. Rich-Text (`RichTextEditor.jsx` + CSS)
+## 9. Rich-Text (`RichTextEditor.jsx` + CSS)

 - **Selection Save/Restore** vor Toolbar-Klicks (`insertUnorderedList` / `insertOrderedList` zuverlässiger bei Mehrzeilen-Markierung).
 - **`styleWithCSS` false** vor Formatbefehlen.
@ -92,24 +103,26 @@ Hinweis: Es gibt **keine** separaten Routen `/exercises/:id/variants/...` — Be

 ---

-## 9. Admin – Matrix / Reifegrad (Kontext)
+## 10. Admin – Matrix / Reifegrad (Kontext)

 - Bereits dokumentiert in **`CHANGELOG`** / Module **`maturity_models`**: Matrix-Stack-Bundle Export/Import, Kontext-Bindings — siehe `version.py` und Admin-UI-Pfade.

 ---

-## 10. Nächste sinnvolle Schritte (nicht Lieferstand)
+## 11. Nächste sinnvolle Schritte (nicht Lieferstand)

+- Trainingsplanungs-/Rahmenmodul (**CURR‑002 (2)**) — Progressionsgraph ist unterstützend, siehe **`TRAINING_FRAMEWORK_SPEC.md`** §4.
 - Progressions-Serien als **Blöcke** (angekündigt; Voraussetzung: `prerequisite_variant_id` / `progression_level` vorhanden).
 - Serverseitige **Suchvorschläge** (Autocomplete-Endpoint), falls datalist nicht reicht.
 - Optional: Streaming/chunked Upload für sehr große Videos (RAM-Thema).

 ---

-## 11. Verweise
+## 12. Verweise

 | Thema | Dokument |
 |--------|----------|
+| Rahmenprogramm / Progressionsgraph | `technical/TRAINING_FRAMEWORK_SPEC.md` |
 | API Übungen | `technical/EXERCISES_API_SPEC.md` |
 | Domänenmodell | `functional/DOMAIN_MODEL.md` |
 | Datenbank Überblick | `technical/DATABASE_SCHEMA.md` |
--- a/.claude/docs/technical/DATABASE_SCHEMA.md
+++ b/.claude/docs/technical/DATABASE_SCHEMA.md
@ -1,8 +1,8 @@
 # Shinkan Jinkendo - Datenbank-Schema (Technisch)

-**Version:** 0.4.0  
-**Stand:** 2026-04-27  
-**Aktuell deployed:** Migration 023 (Skills Complete Import)
+**Version:** 0.5.0  
+**Stand:** 2026-04-30  
+**Hinweis:** Produktiver Deploy sollte mindestens bis Migration **034** (Progressionsgraph Kanten/Varianten) geführt sein — Details siehe `backend/version.py` (`DB_SCHEMA_VERSION`).

 ---

@ -40,6 +40,10 @@ Dieses Dokument beschreibt die **technische Datenbankstruktur** von Shinkan Jink
 | 021 | 2026-04-27 | ~~Import Skills from Matrix~~ (DEPRECATED) | ⚠️ Faulty |
 | **022** | **2026-04-27** | **Skills Schema Complete (BREAKING)** | ✅ Deployed |
 | **023** | **2026-04-27** | **Skills Complete Import (69 Skills)** | ✅ Deployed |
+| 024–031 | *versch.* | Reifegradmodelle, Medien, Planvorlagen/Sektionen u. a. — siehe `backend/migrations/` | ✅ je Umgebung |
+| **032** | **2026-04-30** | **Progressionsgraph Übung→Übung:** `exercise_progression_graphs`, `exercise_progression_edges` | ✅ |
+| **033** | **2026-04-30** | **`exercise_progression_edges.notes`** | ✅ |
+| **034** | **2026-04-30** | **Kanten-Endpunkte optional `exercise_variants`; UNIQUE/CHECK** | ✅ |

 ---

@ -276,6 +280,26 @@ training_unit_exercises (
 exercise_blocks (id, name, description, created_by, club_id, ...)  -- Migration 017
 ```

+### Progressionsgraph Übung → Übung (Migrationen 032–034)
+
+Separater gerichteter Graph **zwischen** Übungen (nicht zu verwechseln mit Varianten-Reihen **innerhalb** einer Übung, Migration 014). Detail-DDL und REST siehe `technical/TRAINING_FRAMEWORK_SPEC.md` §3.
+
+```sql
+exercise_progression_graphs (
+  id, name, description, visibility, club_id, created_by,
+  created_at, updated_at
+)
+exercise_progression_edges (
+  id, graph_id,
+  from_exercise_id, to_exercise_id,
+  from_exercise_variant_id,  -- nullable (Migration 034)
+  to_exercise_variant_id,
+  edge_type,                 -- z. B. next_exercise, sibling
+  notes,                     -- Migration 033
+  created_at
+)
+```
+
 ### MediaWiki Import (Migration 018)

 ```sql
--- a/.claude/docs/technical/EXERCISES_API_SPEC.md
+++ b/.claude/docs/technical/EXERCISES_API_SPEC.md
@ -1,9 +1,10 @@
 # Exercises API Specification

-**Version:** 1.3  
-**Datum:** 2026-04-27  
-**Status:** Teilweise implementiert (Liste mit Filtern + Varianten + Medienlimits siehe Code)  
+**Version:** 1.4  
+**Datum:** 2026-04-30  
+**Status:** Teilweise implementiert (Liste mit Filtern + Varianten + Medienlimits + Progressionsgraphen siehe Code)  
 **Autor:** Claude Code  
+**Änderungen v1.4:** Endpoints **`/exercise-progression-graphs`** inkl. Kanten, **`POST …/edges/sequence`**, **`POST …/edges/delete-batch`** — Detailtabellen siehe **`TRAINING_FRAMEWORK_SPEC.md`** §3.3  
 **Änderungen v1.3:** `GET /exercises` erweiterte Query-Parameter (`include_variants`, Multi-Filter, `ai_search`-Platzhalter); Dokumentation angepasst  
 **Änderungen v1.2:** KI-Assistenz Endpoints, Skill-Level-System (benannte Stufen), intensity als low/medium/high
 **Änderungen v1.1:** Exercise Blocks Endpoints, Permissions dokumentiert, age_groups korrigiert
@ -60,6 +61,20 @@ Development: https://dev.shinkan.jinkendo.de/api
 | PUT | `/exercise-blocks/{id}/items/{item_id}` | Update item |
 | DELETE | `/exercise-blocks/{id}/items/{item_id}` | Remove item |
 | PUT | `/exercise-blocks/{id}/items/reorder` | Reorder items (DnD) |
+| **Progressionsgraphen** (Übung→Übung) |
+| GET | `/exercise-progression-graphs` | Liste Graphen |
+| GET | `/exercise-progression-graphs/{id}` | Detail; Query `include_edges` |
+| POST | `/exercise-progression-graphs` | Graph anlegen |
+| PUT | `/exercise-progression-graphs/{id}` | Metadaten |
+| DELETE | `/exercise-progression-graphs/{id}` | Graph + Kanten |
+| GET | `/exercise-progression-graphs/{id}/edges` | Kantenliste |
+| POST | `/exercise-progression-graphs/{id}/edges` | Einzelkante |
+| POST | `/exercise-progression-graphs/{id}/edges/sequence` | Reihe (`steps`) in einer Transaktion |
+| PUT | `/exercise-progression-graphs/{id}/edges/{edge_id}` | z. B. Notiz |
+| DELETE | `/exercise-progression-graphs/{id}/edges/{edge_id}` | Kante löschen |
+| POST | `/exercise-progression-graphs/{id}/edges/delete-batch` | `{ edge_ids }` |
+
+Vollständige Pfadtabelle, Auth und Feldgrenzen: **`TRAINING_FRAMEWORK_SPEC.md`** §3.

 ---

--- a/.claude/docs/technical/EXERCISES_ARCHITECTURE.md
+++ b/.claude/docs/technical/EXERCISES_ARCHITECTURE.md
@ -1,9 +1,10 @@
 # Exercise System Architecture

-**Version:** 1.0  
-**Datum:** 2026-04-24  
+**Version:** 1.1  
+**Datum:** 2026-04-30  
 **Status:** DRAFT - Awaiting Review  
-**Autor:** Claude Code
+**Autor:** Claude Code  
+**Änderungen v1.1:** Progressionsgraph **zwischen** Übungen (Migration 032–034); Verweis `TRAINING_FRAMEWORK_SPEC.md`

 ---

@ -54,6 +55,10 @@ Exercise Block ──── (N) Block Items ──── (1) Exercise
                                     └── is_placeholder (for templates)
 ```

+### 1.1b Progressionsgraph zwischen Übungen (nicht „Serie“)
+
+**Abgrenzung:** Separates Konzept von der **Varianten-Serie** (§1.1): hier geht es um **gerichtete Kanten zwischen verschiedenen Übungen** (optional mit Varianten als Knoten-Endpunkten), gruppiert in Bibliotheks-Containern (`exercise_progression_graphs`). Schema, REST, Produktgrenzen und Backlog (parallele Alternativ-Pakete): **`TRAINING_FRAMEWORK_SPEC.md`** §3–§4.
+
 ---

 ### 1.2 Medien-Strategie
--- a/.claude/docs/technical/EXERCISES_DATABASE_FINAL.md
+++ b/.claude/docs/technical/EXERCISES_DATABASE_FINAL.md
@ -19,6 +19,8 @@

 **Basis:** Migrationen 001-013 (bereits deployed)

+**Progressionsgraph zwischen Übungen:** Migrationen **032–034** — nicht Bestandteil dieses „Exercise Catalog“-Schemas-Dokuments; siehe **`TRAINING_FRAMEWORK_SPEC.md`** §3 und **`DATABASE_SCHEMA.md`** (Migrationshistorie).
+
 ---

 ## 2. Migration 014: Variant Progression + Search
--- a/.claude/docs/technical/EXERCISES_FRONTEND_ROUTING.md
+++ b/.claude/docs/technical/EXERCISES_FRONTEND_ROUTING.md
@ -1,9 +1,10 @@
 # Frontend Routing & Navigation Specification

-**Version:** 1.1  
-**Datum:** 2026-04-27  
+**Version:** 1.2  
+**Datum:** 2026-04-30  
 **Status:** DRAFT - Awaiting Review  
 **Autor:** Claude Code  
+**Änderungen v1.2:** Übersicht **Übungen**: Tabs Liste \| Progressionsgraphen auf `/exercises`; Progressions-Editor ohne neue Routen (Panel + Formularblock unter `/exercises/:id/edit`)  
 **Änderungen v1.1:** Übungsvarianten-Bearbeitung nur unter `/exercises/:id/edit` (keine VariantFormPage-Routen)

 ---
@ -13,10 +14,10 @@
 ### 1.1 Route-Übersicht

 ```
-/exercises                           → ExercisesListPage (Grid + Filter + Chips)
+/exercises                           → ExercisesListPage — Tabs: **Liste** \| **Progressionsgraphen** (`ExerciseProgressionGraphPanel`)
 /exercises/new                       → ExerciseFormPage (Create)
 /exercises/{id}                      → ExerciseDetailPage (Accordion-Layout)
-/exercises/{id}/edit                 → ExerciseFormPage (Edit inkl. Varianten-Editor inline)
+/exercises/{id}/edit                 → ExerciseFormPage (Edit inkl. Varianten-Editor inline + Block Progressionsgraph)

 /exercise-blocks                     → ExerciseBlocksListPage (Meine Blocks)
 /exercise-blocks/new                 → ExerciseBlockFormPage (Create)
@ -672,7 +673,7 @@ function App() {

 ---

-**Version:** 1.1
-**Letzte Änderung:** 2026-04-24
-**Status:** REVIEWED - Pending Implementation
-**Review-Änderungen:** Exercise Blocks Routes + Navigation hinzugefügt
+**Version:** 1.2  
+**Letzte Änderung:** 2026-04-30  
+**Status:** REVIEWED - Pending Implementation  
+**Review-Änderungen:** Progressionsgraphen-UI (Tabs, Formularblock); Exercise Blocks Routes + Navigation (früher)
--- a/.claude/docs/technical/TRAINING_FRAMEWORK_SPEC.md
+++ b/.claude/docs/technical/TRAINING_FRAMEWORK_SPEC.md
@ -1,20 +1,22 @@
-# Trainingsrahmenprogramm — Technische Spezifikation (Stub)
+# Trainingsrahmenprogramm — Technische Spezifikation

-**Status:** Entwurf · angelegt 2026-04-28  
+**Status:** Zwischenstand dokumentiert · **Stand:** 2026-04-30  
 **Bindendes Fachkonzept / Entscheide:** `.claude/docs/functional/TRAINING_CURRICULUM_AND_GOVERNANCE_CONCEPT.md` (CURR‑001 bis CURR‑013)

+**Relevant für nächsten Schritt:** CURR‑002 **(2)** Trainingsplanung / Rahmen über mehrere Einheiten — der hier dokumentierte **Progressionsgraph Stufe 1** ist bewusst **unterstützend**, keine Pflicht für Slot-Zuordnungen (**CURR‑013**).
+
 ---

 ## 1. Abgrenzung zu anderen Dokumenten

 | Dokument | Rolle · warum **nicht** hier hineinmischen |
 |----------|--------------------------------------------|
-| `EXERCISES_DATABASE_FINAL.md`, `EXERCISES_ARCHITECTURE.md`, `EXERCISES_API_SPEC.md` | **Übungskatalog** inkl. Varianten-Progression (Migration 014). Kein Ort für Multi-Session-Rahmen, Slots, Rahmen-Ziele oder `training_units`-Orchestrierung. |
-| `DATABASE_SCHEMA.md` | **Nachgeordnete** Übersicht: Migrationshistorie und kompakte Tabellenliste. Neue Migrationen hier **einzeilig** ergänzen, Detail-DDL gehört primär hierher (**§3**) oder in Migrations-SQL. |
-| `functional/DOMAIN_MODEL.md` | Fachliche Kernbegriffe; bei Release des Rahmenfeatures **ein kurzer Unterabschnitt** „Rahmen-Vorlage / Slots“ ergänzen, Verweis auf diese Datei. |
-| `TRAINING_CURRICULUM_AND_GOVERNANCE_CONCEPT.md` | **Was** und **warum** (Modus A/B, Governance, CURR‑Tabelle). Keine DDL-Pflicht. |
+| `EXERCISES_DATABASE_FINAL.md`, `EXERCISES_ARCHITECTURE.md`, `EXERCISES_API_SPEC.md` | **Übungskatalog** inkl. Varianten-Progression **innerhalb einer Übung** (Migration 014). Kanten **zwischen** Übungen siehe **§3**. |
+| `DATABASE_SCHEMA.md` | **Nachgeordnete** Übersicht: Migrationshistorie und Tabellenliste; Detail-DDL primär **hier §3** + SQL unter `backend/migrations/`. |
+| `functional/DOMAIN_MODEL.md` | Fachliche Begriffe; Kurzverweis auf Progressionsgraph ergänzt. |
+| `TRAINING_CURRICULUM_AND_GOVERNANCE_CONCEPT.md` | **Was** und **warum** (Modus A/B, Governance, CURR‑Tabelle). |

-**Konsequenz:** Diese Datei ist der **technische Arbeitspool** für Rahmenprogramm-Stufe 1–2 (Graph + Rahmenentität + Slots + Zielliste + API/Migrationen).
+**Konsequenz:** Diese Datei bleibt der **technische Arbeitspool** für Rahmenprogramm Stufe 1–2. Abschnitt **§4** beschreibt explizit den **aktuellen Produktfreigabe-Umfang** und **bekannte Lücken** (damit Trainingsplanung weiter gebaut werden kann ohne falscher Erwartung an „Alternative‑Pakete“ in der UI).

 ---

@ -24,63 +26,89 @@
 - [ ] **Modus A vs. B:** ein Typ mit nullable `group_id` / `plan_mode` vs. zwei Objekttypen — **offen** (Funktionskonzept §6).
 - [ ] **Zielliste:** ≥1 Zieleinträge pro Rahmen (**CURR‑011**); Felder und Optionalität.
 - [ ] **Slots:** Reihenfolge, Notizen, **direkte Übungszuordnungen** (M:N oder Join-Tabelle); optionales `training_plan_template_id` pro Slot (**CURR‑010**, MVP offen).
- [x] **Progressionsgraph zwischen Übungen:** Tabellen/Kanten, getrennt von Varianten-Progression in `exercise_variants` (**CURR‑002 (1)**, **CURR‑013**) — siehe **§3**.
+- [x] **Progressionsgraph zwischen Übungen:** persistiert, siehe **§3–§4** (**CURR‑002 (1)**, **CURR‑013**).
 - [ ] **Instanziierung (Modus B):** FK/Metadaten zu `training_units`, Bulk vs. Verknüpfen (**CURR‑012**).
- [ ] **Governance:** `visibility`, `club_id`, `created_by` für neue Bibliothekstypen (**CURR‑005**); Nachzug `training_plan_templates` (**CURR‑007**, **CURR‑008**).
- [ ] **REST/API:** Endpoints grob, AuthZ analog Trainingsplanung.
+- [ ] **Governance:** `training_plan_templates` ohne `visibility` (**CURR‑007**, **CURR‑008**); neue Bibliothekstypen nach **CURR‑005**.
+- [ ] **REST gesamt Rahmenprogramm:** Progressions-API ist umgesetzt; **Rahmen‑Slot‑REST** noch ausstehend.

 ---

-## 3. Progressionsgraph Übung → Übung (Stufe 1, Migration 032)
+## 3. Progressionsgraph Übung → Übung (implementierter Stand)

-**Abgrenzung:** Kanten verbinden **`exercises.id` → `exercises.id`**. Die Varianten-Kette innerhalb einer Übung bleibt in `exercise_variants` (Migration 014).
+### 3.1 Abgrenzung

-### Schema
+- **Zwischen Übungen:** gerichtete Kanten auf Ebene **`exercises`** mit optionalen Endpunkten auf konkreten **`exercise_variants`** (Knoten = „Übung“ oder „Übung · Variante“). Migrationen **032–034**.
+- **Innerhalb einer Übung:** Reihenfolge / Progressionsmetadaten der Varianten unverändert über **`exercise_variants`** (Migration **014**) — nicht duplizieren.

-| Tabelle | Zweck |
-|---------|--------|
-| `exercise_progression_graphs` | Kontainer für mehrere getrennte Graphen (Name, Beschreibung, **`visibility`** `private\|club\|official`, **`club_id`**, **`created_by`**). |
-| `exercise_progression_edges` | Gerichtete Kante: `graph_id`, `from_exercise_id`, `to_exercise_id`, **`edge_type`** (VARCHAR, Default `next_exercise`, erweiterbar ohne ENUM-Zwang). |
+AuthZ analog **`training_plan_templates`**: Graph nur für **Admin/Superadmin** oder **Ersteller** (`created_by`); Anlegen neuer Graphen mit **`_has_planning_role`**.

- **Eindeutigkeit:** `UNIQUE (graph_id, from_exercise_id, to_exercise_id, edge_type)`; `CHECK (from_exercise_id <> to_exercise_id)`.
- **Löschregeln (FK):**
-  - Kante → Graph: **`ON DELETE CASCADE`** (Graph löschen entfernt alle Kanten).
-  - Kante → Übung (von/nach): **`ON DELETE CASCADE`** (Übung löschen entfernt alle incident Kanten in allen Graphen — konsistent mit anderen Übungs-Abhängigkeiten wie `exercise_skills`).
- **Indizes:** `graph_id`, `from_exercise_id`, `to_exercise_id`.
+### 3.2 Migrationen & Schema (Kurz)

-### API (FastAPI, Prefix `/api`)
+| Mig. | Inhalt |
+|------|--------|
+| **032** | `exercise_progression_graphs` (Name, Beschreibung, **`visibility`**, **`club_id`**, **`created_by`**); `exercise_progression_edges` (`graph_id`, von/nach Übung, `edge_type` VARCHAR Default `next_exercise`). FK CASCADE zu Graph und Übungen. |
+| **033** | `exercise_progression_edges.notes` (freier Text / „Entwicklungsziel“ pro Kante). |
+| **034** | `from_exercise_variant_id`, `to_exercise_variant_id` (nullable, FK `exercise_variants`, CASCADE). CHECK: gleiche Übung nur mit **zwei verschiedenen Varianten**. UNIQUE-Index über Graph + Endpunkte inkl. `COALESCE(variant_id,0)` + `edge_type`. |

-| Methode | Pfad | Kurzbeschreibung |
-|---------|------|------------------|
-| GET | `/exercise-progression-graphs` | Liste (Admin/Superadmin: alle; sonst nur eigene `created_by`). |
-| GET | `/exercise-progression-graphs/{id}` | Detail; Query `include_edges=true` für eingebettete Kanten. |
-| POST | `/exercise-progression-graphs` | Anlegen (`_has_planning_role`, wie Trainingsvorlagen). |
-| PUT | `/exercise-progression-graphs/{id}` | Metadaten (`name`, `description`, `visibility`, `club_id`). |
-| DELETE | `/exercise-progression-graphs/{id}` | Graph + Kanten (CASCADE). |
-| GET | `/exercise-progression-graphs/{id}/edges` | Kantenliste; optional Filter `from_exercise_id`, `to_exercise_id`. |
-| POST | `/exercise-progression-graphs/{id}/edges` | Kante anlegen; Duplikat → **409**. |
-| DELETE | `/exercise-progression-graphs/{id}/edges/{edge_id}` | Kante löschen. |
+Kantentypen in Produktnutzung: **`next_exercise`** (Nachfolger), **`sibling`** (Schwester / gleiche „Entwicklungslage“, semantisch oft Paar — weiterhin eine gerichtete Kante in DB).

-**AuthZ:** Analog `training_plan_templates`: Zugriff auf einen Graphen nur **Admin/Superadmin** oder **Ersteller** (`created_by`).
+Listenqueries liefern Join‑Felder **`from_exercise_title`**, **`to_exercise_title`**, **`from_variant_name`**, **`to_variant_name`**.

-### Offen / später
+### 3.3 REST (`/api`, Router `exercise_progression_graphs.py`)

- Weitere **`edge_type`**-Semantik und Filter in der UI („Vorschläge“ beim Planen).
- **CURR‑013:** Graph bleibt unterstützend; keine Pflicht, jeden Trainingsplan über den Graph zu modellieren.
- Anbindung **`training_units`** / Rahmen-Slots (**Stufe 2**, CURR‑009–012).
+| Methode | Pfad | Zweck |
+|---------|------|--------|
+| GET | `/exercise-progression-graphs` | Liste (+ `edges_count`); Admin sieht alle, sonst nur eigene. |
+| GET | `/exercise-progression-graphs/{id}` | Detail; `?include_edges=true` |
+| POST | `/exercise-progression-graphs` | Graph anlegen |
+| PUT | `/exercise-progression-graphs/{id}` | Metadaten |
+| DELETE | `/exercise-progression-graphs/{id}` | Graph + Kanten |
+| GET | `/exercise-progression-graphs/{id}/edges` | Kanten; Query optional `from_exercise_id`, `to_exercise_id` |
+| POST | `/exercise-progression-graphs/{id}/edges` | Einzelkante; Duplikat/Constraint → **409** |
+| POST | `/exercise-progression-graphs/{id}/edges/sequence` | **Bulk:** `{ steps: [{ exercise_id, variant_id? }, …], segment_notes?: [...] }` — nur **`next_exercise`**, Transaktion alle oder keine Zeile |
+| PUT | `/exercise-progression-graphs/{id}/edges/{edge_id}` | z. B. **`notes`** |
+| DELETE | `/exercise-progression-graphs/{id}/edges/{edge_id}` | eine Kante |
+| POST | `/exercise-progression-graphs/{id}/edges/delete-batch` | `{ edge_ids: [...] }` — z. B. gesamte sichtbare „Reihe“ löschen |

-### Manuelle Prüfung
+### 3.4 Frontend (Stand Code)

-1. Nach Migration: `GET /api/exercise-progression-graphs` mit gültigem `X-Auth-Token`.
-2. `POST /exercise-progression-graphs` mit `{"name":"Testgraph"}` → `201`.
-3. `POST …/{id}/edges` mit gültigen `from_exercise_id` / `to_exercise_id`; zweites identisches Quadrupel → `409`.
-4. Übung löschen, die an einer Kante beteiligt ist: Kanten verschwinden (CASCADE).
+- **`ExercisesListPage`:** Tabs **Liste** · **Progressionsgraphen** → **`ExerciseProgressionGraphPanel`**.
+- **`ExerciseFormPage`** (nur Edit): eingeklappter Block **Progressionsgraph** mit Kontext „diese Übung“ + Filter „nur betroffene Kanten“.
+- Panel‑Funktionen: **Sequenz‑Editor** (mehrere Schritte → ein Bulk‑Speichern), zusammengefasste **Reihen‑Lesart** für `next_exercise`, eigene Liste für **Schwestern**, Einzelkantenbereich, Tab **Alle Kanten (Tabelle)**.
+- API‑Client: `frontend/src/utils/api.js` (`createExerciseProgressionSequence`, `deleteExerciseProgressionEdgesBatch`, …).

 ---

-## 4. Changelog
+## 4. Zwischenstand für Produkt / Trainingsplanung (bewusste Grenzen)
+
+**Freigabe:** Der beschriebene Stand gilt als **ausreichend**, um mit dem **Trainingsplanungsmodul** und später Rahmen/Slots (**CURR‑002 (2)**) weiterzuarbeiten — ohne dass Pflicht zur Pflege komplexer Graph‑Strukturen entsteht (**CURR‑013**).
+
+**Was gut nutzbar ist**
+
+- Lineare **Reihen** mehrerer Übungen (bzw. Varianten‑Knoten) über **Sequenz‑API** bzw. Sequenz‑UI.
+- **Nachfolger‑Lesart** als zusammenhängende Kette in der Übersicht.
+- **Schwester‑Kanten** als eigene Liste (Alternative gleicher „Stufe“ zwischen zwei Knoten).
+- **Einzelkanten** für Sonderfälle und Verzweigungen.
+
+**Was noch nicht „ein Knopf“ ist (bekannt)**  
+
+- **Parallele gleichwertige Alternativen** („Paket B bestehend aus mehreren Übungen als echte Alternative zu Paket A“) sind **nicht** als erste‑Klass‑UX modelliert: mehrere Nachfolger aus einem Knoten sind technisch möglich (mehrere `next_exercise`‑Kanten), aber **keine** dedizierte Gruppe „Alternativ‑Set“. Pflege kann mehrzeilig und koplastisch wirken.  
+- **Visualisierung echter Bäume** (Join‑Points, mehrere ausgehende Pfeile in einem Bild) ist nur eingeschränkt über Reihen‑Zusammenfassung + Tabelle abbildbar.
+
+**Nächste sinnvolle Ausbaustufen** (Backlog Graph‑UX, nicht Blocker Planung)
+
+- Semantik **`alternative_group_id`** oder **Hyperkanten** (ein UX‑Schritt legt mehrere Kanten mit gemeinsamer Gruppe an).
+- Komfort beim Pflegen **symmetrischer Schwestern** (ein Klick für zwei Richtungen / Dedupe).
+- Karten-/Baum‑Layout statt nur Zeilen.
+
+Details weiterhin Diskussionsgrundlage in `TRAINING_CURRICULUM_AND_GOVERNANCE_CONCEPT.md` §6 (Kantentypen).
+
+---
+
+## 5. Changelog (Dokument)

 | Datum | Änderung |
 |-------|----------|
-| 2026-04-30 | §3: Migration 032 + REST-Endpunkte Progressionsgraph (CURR‑002 (1)); Checkliste Graph erledigt. |
-| 2026-04-28 | Erstanlage: Abgrenzung + Checkliste (Artefakt der Doku-Entscheidung „eigene technische Spec“). |
+| 2026-04-30 | **Zwischen-Doku:** §3 auf Migrationen 032–034 + API **sequence/delete-batch** + Frontend erweitert; **§4** Produktfreigabe vs. Lücken (parallele Alternativen); Changelog §5. |
+| 2026-04-30 | §3: erste Fassung Migration 032 + REST‑Basis (CURR‑002 (1)). |
+| 2026-04-28 | Erstanlage Stub mit Checkliste. |
--- a/CLAUDE.md
+++ b/CLAUDE.md
@ -52,7 +52,7 @@ backend/
 ├── migrations/      # SQL-Migrationen (XXX_*.sql Pattern)
 └── routers/         # Router-Module
    auth · profiles · clubs · groups · skills · methods
-    exercises · training_units · training_programs
+    exercises · exercise_progression_graphs · training_units · training_programs
    planning · import_wiki · admin · membership

 frontend/src/