# Review Prompt: Exercises System Specifications

**Zweck:** Vollständiger Review der erstellten Spezifikationen gegen ursprüngliche Anforderungen und User-Ergänzungen

**Reviewer:** Plan Agent (oder anderer spezialisierter Agent)

**Status:** ✅ Review abgeschlossen + Fixes implementiert

**Datum:** 2026-04-24
**Review-Datum:** 2026-04-24
**Ergebnis:** APPROVED WITH CHANGES – alle BLOCKER und MAJOR Issues behoben

---

## 1. Kontext & Auftrag

Du bist ein Plan Agent, der die erstellten Spezifikationen für das Exercise System in Shinkan Jinkendo reviewt. Deine Aufgabe ist es, die 7 Core-Specs gegen die ursprünglichen Anforderungen und User-Ergänzungen zu prüfen und sicherzustellen, dass **keine Anforderungen vergessen** wurden und **keine architektonischen Drifts** entstanden sind.

---

## 2. Zu reviewende Spezifikationen

### 2.1 Core Specs (Phase 0 Foundation)

**Lokation:** `c:/Dev/shinkan-jinkendo/.claude/docs/technical/`

1. **EXERCISES_ARCHITECTURE.md** (ca. 800 Zeilen)
   - Architektur-Entscheidungen
   - Exercise/Variant/Block/Series Definitionen
   - Media-Strategie
   - API-Konventionen
   - DB-Konventionen
   - Decision Log

2. **UI_COMPONENTS_SPEC.md** (ca. 600 Zeilen)
   - Base Components (Chip, MultiSelect, Accordion, DragDropList)
   - Exercise Components (Card, QuickInfo, VariantCard, MediaGallery, MediaUploader)
   - Layout Patterns
   - Responsive Breakpoints
   - Accessibility

3. **EXERCISES_API_SPEC.md** (ca. 574 Zeilen)
   - Alle Endpoints (Exercises, Variants, Media)
   - Request/Response Beispiele
   - Validierung Rules
   - Error Format
   - HTTP Status Codes

4. **EXERCISES_FRONTEND_ROUTING.md** (ca. 400 Zeilen)
   - Route-Struktur
   - Navigation Patterns
   - State Management (URL, Local, Context)
   - Deep Linking
   - Navigation Guards
   - Performance (Lazy Loading, Prefetching)

5. **MEDIA_UPLOAD_SPEC.md** (ca. 500 Zeilen)
   - Hybrid Upload-Strategie (Lokal + Embeds)
   - Upload-Flow (Client + Server)
   - Embed-Parsing (YouTube, Vimeo, Instagram, TikTok)
   - Media-Galerie
   - Drag & Drop Reordering
   - Security & Performance

6. **SEARCH_FILTER_SPEC.md** (ca. 450 Zeilen)
   - Multi-Layer Search (Keyword, Katalog, Meta)
   - Volltext-Suche (tsvector)
   - Frontend Filter-UI
   - Erweiterte Filter (Multi-Select, Range, Equipment)
   - Faceted Search
   - Saved Searches
   - Sortierung

7. **EXERCISES_DATABASE_FINAL.md** (ca. 600 Zeilen)
   - Migration 014 (Variant Progression + Search Vector)
   - Migration 015 (Semantic Matching - Optional)
   - Migration 016 (Saved Searches)
   - Vollständige Tabellenstruktur
   - Indizes
   - Constraints & Business Rules
   - Trigger-Funktionen

---

## 3. Ursprüngliche Anforderungen

### 3.1 User-Anforderungen (Initial Message)

**Quelle:** Erste User-Message in Session

**Kern-Anforderungen:**

1. **Formatierte Ausgabe:** Übungen mit Embedded Videos, Zeichnungen, optimiert für verschiedene Use Cases
2. **Varianten:** Mehrere Varianten mit progressiven Schwierigkeitsstufen
3. **Exercise Series:** Progression durch Varianten derselben Übung
4. **Exercise Blocks:** Sammlungen verschiedener Übungen
5. **Multi-dimensionale Kategorisierung:** Stil, Fokus, Zielgruppe, Fähigkeiten-Matrix mit Levels
6. **Trainingsplan-Integration:** Muss mit Trainingsplan-System integrieren
7. **MediaWiki-Import:** Direct API Integration (NICHT export-basiert)
8. **Robustheit:** Kein ständiger Drift, skalierbar, umfassend

**Spec-First Approach gewählt:** Alle Specs VOR Implementation

### 3.2 User-Ergänzungen (Follow-up)

**Quelle:** Zweite User-Message mit 5 Klarstellungen

**Präzisierungen:**

1. **Priorisierung OK:** Spec-First Ansatz bestätigt
2. **Web + Mobile Priorität (NICHT Print/PDF):**
   - Kurze vs. detaillierte Beschreibungen für Trainingspläne
3. **Media-Strategie:** Lokaler Upload + YouTube/Instagram Embeds
4. **Exercise Series vs. Blocks Klarstellung:**
   - **Series:** Progressive Varianten derselben Übung (via Variant-Metadata)
   - **Blocks:** Gruppierung VERSCHIEDENER Übungen (neue Entity)
   - **Template Blocks:** Blocks mit Platzhaltern (gefüllt beim Planen)
5. **MediaWiki Import:** Via Direct API (NICHT Export)

### 3.3 Referenz-Dokumente

**Quelle:** Zu lesende Dokumente vor Spec-Erstellung

1. **shinkan_anforderungsdokument_entwurf.md** (1425 Zeilen)
   - Fachliche Anforderungen
   - Reifegradmodelle
   - Übungen & Methoden
   - Trainingsplanung
   - MVP Scope: Trainer-fokussiert

2. **DOMAIN_MODEL.md** (Version 0.3.4)
   - Hierarchische Struktur: Fokusbereich → Stil → Zielgruppen (M:N)
   - Primary/Secondary Pattern für M:N
   - Migration 009 deployed (Zielgruppen M:N Refactoring)

3. **DATABASE_SCHEMA.md** (Version 0.3.4)
   - Existierende M:N Tabellen
   - Migrations 001-013 deployed

4. **backend/routers/exercises.py** (454 Zeilen)
   - Existierendes CRUD
   - Enrichment-Pattern für M:N Relations
   - Filter-Support

5. **backend/migrations/005_exercises.sql**
   - Base exercises table
   - exercise_skills, exercise_variants, exercise_media

6. **backend/migrations/008_mn_exercise_relations.sql**
   - M:N Migration (focus_areas, styles, target_groups, age_groups)

7. **frontend/src/pages/ExercisesPage.jsx** (609 Zeilen)
   - Existierende UI (Grid, Filters, Modal)
   - Limitation: Nutzt M:N Backend-Daten NICHT

---

## 4. Review-Kriterien

### 4.1 Vollständigkeit (Completeness)

**Prüfe gegen ursprüngliche Anforderungen:**

- [ ] **Formatierte Ausgabe:** Sind Embedded Videos, Zeichnungen, verschiedene Use Cases abgedeckt?
- [ ] **Varianten mit Progression:** Sind progressive Schwierigkeitsstufen spezifiziert?
- [ ] **Exercise Series:** Ist Progression durch Varianten klar definiert (OHNE separate Entity)?
- [ ] **Exercise Blocks:** Ist Gruppierung verschiedener Übungen spezifiziert?
- [ ] **Template Blocks:** Sind Platzhalter-Blocks für Planung definiert?
- [ ] **Multi-dimensionale Kategorisierung:** Sind Stil, Fokus, Zielgruppe, Skills mit Levels abgedeckt?
- [ ] **Trainingsplan-Integration:** Ist Integration mit Training Plan System spezifiziert?
- [ ] **MediaWiki-Import:** Ist Direct API Integration (NICHT Export) spezifiziert?
- [ ] **Kurz vs. Detail:** Sind verschiedene Beschreibungslängen für Trainingspläne definiert?

### 4.2 Konsistenz (Consistency)

**Prüfe gegen Referenz-Dokumente:**

- [ ] **DOMAIN_MODEL.md:** Folgen Specs der hierarchischen Struktur (Fokusbereich → Stil → Zielgruppen)?
- [ ] **M:N Pattern:** Wird `is_primary` Flag korrekt genutzt?
- [ ] **DATABASE_SCHEMA.md:** Bauen Migrationen 014-016 auf 001-013 auf?
- [ ] **Existierender Code:** Sind Specs kompatibel mit `backend/routers/exercises.py`?
- [ ] **Migration-Pattern:** Folgen neue Migrationen dem idempotenten DO $$ Pattern?

### 4.3 Architektonische Korrektheit (No Drift)

**Prüfe gegen User-Ergänzungen:**

- [ ] **Series vs. Blocks:** Ist die Unterscheidung klar und korrekt umgesetzt?
  - Series = Progression durch Varianten (Metadata in `exercise_variants`)
  - Blocks = Neue Entity für Gruppierung verschiedener Übungen
- [ ] **Media-Strategie:** Hybrid (Lokal + Embeds) korrekt spezifiziert?
- [ ] **Keine Cloud-Only Annahme:** Lokaler Upload vorhanden?
- [ ] **Direct API statt Export:** MediaWiki-Import via API spezifiziert?

### 4.4 Technische Machbarkeit (Feasibility)

- [ ] **Performance:** Sind Performance-Targets realistisch (<50ms List, <150ms Search)?
- [ ] **Skalierbarkeit:** DB-Schema skaliert auf 5.000+ Übungen?
- [ ] **Security:** File-Upload-Validierung mit python-magic (nicht nur Extension)?
- [ ] **UX:** Mobile-Optimierung (Filter-Drawer, Sticky Search, Bottom-Nav) vorhanden?

### 4.5 Gaps & Fehlende Features

**Prüfe auf vergessene Features:**

- [ ] **Trainingscharakter (M:N):** Ist `exercise_training_characters` spezifiziert?
- [ ] **Fähigkeiten-Levels:** Sind `required_level` und `target_level` in `exercise_skills` definiert?
- [ ] **Visibility-Workflow:** Ist `private → club → official` Status-Flow spezifiziert?
- [ ] **Permissions:** Sind Owner-Checks (nur Ersteller darf bearbeiten) definiert?
- [ ] **Pagination:** Ist Pagination in List-Endpoints spezifiziert?
- [ ] **Reordering:** Ist Drag & Drop Reordering für Variants + Media definiert?

---

## 5. Review-Prozess

### 5.1 Schritt-für-Schritt Anleitung

**Schritt 1: Dokumente lesen**
1. Lies alle 7 Core-Specs vollständig durch
2. Mache dir Notizen zu Auffälligkeiten
3. Markiere unklare oder widersprüchliche Stellen

**Schritt 2: Checkliste durchgehen**
1. Gehe durch Abschnitt 4.1 (Vollständigkeit) - jede Anforderung einzeln prüfen
2. Gehe durch Abschnitt 4.2 (Konsistenz) - gegen Referenz-Docs prüfen
3. Gehe durch Abschnitt 4.3 (Architektur) - gegen User-Ergänzungen prüfen
4. Gehe durch Abschnitt 4.4 (Machbarkeit) - technische Risiken bewerten
5. Gehe durch Abschnitt 4.5 (Gaps) - fehlende Features identifizieren

**Schritt 3: Cross-Check zwischen Specs**
1. ARCHITECTURE.md ↔ API_SPEC.md: Sind Decisions in API umgesetzt?
2. API_SPEC.md ↔ DATABASE_FINAL.md: Matchen Endpoints zur DB-Struktur?
3. UI_COMPONENTS_SPEC.md ↔ FRONTEND_ROUTING.md: Passen Komponenten zu Routes?
4. MEDIA_UPLOAD_SPEC.md ↔ DATABASE_FINAL.md: Passt `exercise_media` Tabelle?
5. SEARCH_FILTER_SPEC.md ↔ DATABASE_FINAL.md: Ist `search_vector` definiert?

**Schritt 4: Gap-Analyse**
1. Erstelle Liste aller **fehlenden** Anforderungen
2. Erstelle Liste aller **widersprüchlichen** Definitionen
3. Erstelle Liste aller **unklaren** Spezifikationen
4. Erstelle Liste aller **technischen Risiken**

**Schritt 5: Review-Report erstellen**
1. Folge Template in Abschnitt 6
2. Fülle alle Abschnitte vollständig aus
3. Sei konkret: Datei + Zeile + Problem + Lösungsvorschlag

---

## 6. Review-Report Template

**Nutze dieses Template für deinen Review-Report:**

```markdown
# Exercise System Specs - Review Report

**Reviewer:** [Dein Agent-Name]  
**Review-Datum:** [Datum]  
**Review-Dauer:** [ca. X Minuten]  
**Gesamtbewertung:** [APPROVED / APPROVED WITH CHANGES / REJECTED]

---

## 1. Executive Summary

[2-3 Sätze: Sind die Specs bereit für Implementation? Größte Probleme?]

---

## 2. Vollständigkeit (Completeness)

### 2.1 Erfüllte Anforderungen ✅

- [x] Formatierte Ausgabe: Abgedeckt in MEDIA_UPLOAD_SPEC.md (Abschnitt 4)
- [x] Varianten mit Progression: Abgedeckt in EXERCISES_DATABASE_FINAL.md (Migration 014)
- [... weitere ...]

### 2.2 Fehlende Anforderungen ❌

| Anforderung | Wo fehlt es? | Kritikalität | Lösungsvorschlag |
|-------------|--------------|--------------|------------------|
| Exercise Blocks Entity | EXERCISES_ARCHITECTURE.md erwähnt, aber nicht in DATABASE_FINAL.md | HIGH | Migration 017 für `exercise_blocks` Tabelle hinzufügen |
| Template Blocks Platzhalter | Nirgendwo spezifiziert | MEDIUM | Erweitere `exercise_blocks` um `is_template` + `placeholders` JSONB |
| ... | ... | ... | ... |

---

## 3. Konsistenz (Consistency)

### 3.1 Inkonsistenzen zwischen Specs

| Problem | Betroffene Dateien | Impact | Fix |
|---------|-------------------|--------|-----|
| API_SPEC.md definiert `age_groups_catalog` als JSONB, aber DOMAIN_MODEL.md sagt M:N | API_SPEC.md Zeile 104, DOMAIN_MODEL.md Abschnitt 3 | MEDIUM | Entscheide: JSONB ODER M:N (empfohlen: M:N für Konsistenz) |
| ... | ... | ... | ... |

### 3.2 Inkonsistenzen mit Referenz-Dokumenten

| Problem | Spec-Datei | Referenz-Dokument | Fix |
|---------|-----------|-------------------|-----|
| DOMAIN_MODEL.md sagt Zielgruppen sind global (M:N), aber API_SPEC.md zeigt `target_group_id` als FK | API_SPEC.md Zeile 267 | DOMAIN_MODEL.md Abschnitt 3.3 | Korrigiere API_SPEC zu M:N Array |
| ... | ... | ... | ... |

---

## 4. Architektur-Drift

### 4.1 Abweichungen von User-Ergänzungen

| User-Anforderung | Spec-Umsetzung | Konform? | Problem / Fix |
|-----------------|----------------|----------|---------------|
| "Series = Varianten-Progression OHNE separate Entity" | EXERCISES_ARCHITECTURE.md Abschnitt 2.2 definiert Series korrekt als Metadata | ✅ JA | - |
| "Blocks = neue Entity für verschiedene Übungen" | EXERCISES_ARCHITECTURE.md erwähnt, DATABASE_FINAL.md fehlt Migration | ❌ NEIN | Migration 017 fehlt |
| "Direct API statt Export" | Nirgendwo spezifiziert | ❌ NEIN | Neue Spec MEDIAWIKI_IMPORT_SPEC.md nötig |
| ... | ... | ... | ... |

---

## 5. Technische Risiken

| Risiko | Betroffene Spec | Wahrscheinlichkeit | Impact | Mitigation |
|--------|----------------|-------------------|--------|------------|
| tsvector auf großen Texten langsam | SEARCH_FILTER_SPEC.md | MEDIUM | HIGH | Teste Performance mit 10.000 Zeichen Execution-Text |
| 50MB File-Upload blockiert Server | MEDIA_UPLOAD_SPEC.md | HIGH | MEDIUM | Chunk-Upload oder separater Upload-Worker |
| pgvector Extension nicht verfügbar | DATABASE_FINAL.md Migration 015 | LOW | LOW | Migration 015 ist optional (Phase 2) |
| ... | ... | ... | ... | ... |

---

## 6. Gap-Analyse

### 6.1 Komplett fehlende Features

1. **Exercise Blocks Implementation**
   - Wo benötigt: DATABASE_FINAL.md, API_SPEC.md, UI_COMPONENTS_SPEC.md
   - Kritikalität: HIGH (User-Anforderung #4)
   - Aufwand: 1 Migration + 3 Endpoints + 2 Komponenten

2. **Template Blocks mit Platzhaltern**
   - Wo benötigt: DATABASE_FINAL.md, API_SPEC.md
   - Kritikalität: MEDIUM (User-Anforderung #4 Teil 2)
   - Aufwand: Erweitere Blocks-Tabelle + 1 Endpoint

3. **MediaWiki Direct API Import**
   - Wo benötigt: Neue Spec MEDIAWIKI_IMPORT_SPEC.md
   - Kritikalität: HIGH (User-Anforderung #7)
   - Aufwand: Neue Spec + Backend-Integration

4. [... weitere ...]

### 6.2 Unvollständig spezifizierte Features

1. **Trainingsplan-Integration**
   - Status: Erwähnt in ARCHITECTURE.md, aber keine konkreten Endpoints
   - Fehlende Details: Wie werden Übungen in Pläne eingefügt? API-Struktur?
   - Fix: Erweitere API_SPEC.md um `/training-plans/{id}/exercises` Endpoints

2. [... weitere ...]

---

## 7. Kritische Findings (Must-Fix vor Implementation)

### 🔴 BLOCKER (Implementation NICHT starten ohne Fix)

1. **Exercise Blocks fehlen komplett**
   - Impact: Kern-Anforderung #4 nicht erfüllt
   - Fix: Migration 017 + API-Endpoints + UI-Komponenten spezifizieren

2. **MediaWiki-Import nicht spezifiziert**
   - Impact: Kern-Anforderung #7 nicht erfüllt
   - Fix: Neue Spec MEDIAWIKI_IMPORT_SPEC.md erstellen

### 🟠 MAJOR (Fix vor Phase 1 Abschluss)

1. **age_groups: JSONB vs. M:N Inkonsistenz**
   - Impact: Daten-Modell unklar, spätere Migration schwierig
   - Fix: Entscheide für M:N (Konsistenz) oder JSONB (Einfachheit)

2. [... weitere ...]

### 🟡 MINOR (Fix in Phase 2 akzeptabel)

1. **Semantic Matching (Migration 015) optional**
   - Impact: Nice-to-have Feature, kein MVP-Blocker
   - Fix: Kein Fix nötig, als Phase 2 markieren

2. [... weitere ...]

---

## 8. Empfehlungen

### 8.1 Vor Implementation starten

1. **Fixe alle BLOCKER:** Exercise Blocks + MediaWiki-Import spezifizieren
2. **Kläre MAJOR Issues:** age_groups Inkonsistenz auflösen
3. **Ergänze Extended Specs:** VARIANTS_PROGRESSION_SPEC.md, EXERCISE_BLOCKS_SPEC.md, PERMISSIONS_VISIBILITY_SPEC.md
4. **User-Review:** Zeige Specs dem User, hole Feedback zu Blocks/Template-Blocks

### 8.2 Implementation-Reihenfolge (falls APPROVED)

**Phase 1A - Foundation:**
1. Migration 014 (Search Vector + Variant Progression)
2. Migration 016 (Saved Searches)
3. Backend: GET/POST/PUT/DELETE `/exercises` + `/exercises/{id}/variants`
4. Frontend: ExercisesListPage + ExerciseDetailPage (ohne Blocks)

**Phase 1B - Media:**
1. Backend: `/exercises/{id}/media` Endpoints
2. Frontend: MediaUploader + MediaGallery Komponenten

**Phase 1C - Search:**
1. Backend: Search + Filter in GET `/exercises`
2. Frontend: SearchFilterBar Komponente

**Phase 2 - Blocks (nach BLOCKER-Fix):**
1. Migration 017 (Exercise Blocks)
2. Backend: `/exercise-blocks` Endpoints
3. Frontend: BlockEditor Komponente

**Phase 3 - Import:**
1. MEDIAWIKI_IMPORT_SPEC.md erstellen
2. Backend: MediaWiki API Connector
3. Frontend: Import-UI

---

## 9. Positive Findings ✅

[Was ist gut gelaufen? Was ist besonders gut spezifiziert?]

1. **Sehr detaillierte API-Spec:** Alle Request/Response-Beispiele vorhanden
2. **Konsistentes M:N Pattern:** is_primary Flag durchgängig genutzt
3. **Performance-bewusst:** Indizes, Caching, Lazy Loading spezifiziert
4. **Accessibility:** ARIA, Keyboard-Nav, Skip-Links definiert
5. [... weitere ...]

---

## 10. Nächste Schritte

### Für Spec-Autor (Original Agent):
1. [ ] Fixe BLOCKER #1: Exercise Blocks spezifizieren
2. [ ] Fixe BLOCKER #2: MediaWiki-Import spezifizieren
3. [ ] Kläre MAJOR Issue: age_groups JSONB vs. M:N
4. [ ] Aktualisiere betroffene Specs (siehe Abschnitt 7)

### Für User:
1. [ ] Lese Executive Summary + Kritische Findings
2. [ ] Entscheide über Blocks/Template-Blocks Umsetzung
3. [ ] Priorisiere MediaWiki-Import (jetzt oder später?)
4. [ ] Gib Feedback zu age_groups Entscheidung

### Für Implementation:
- **WARTE** bis alle BLOCKER gefixt sind
- **DANACH:** Starte mit Phase 1A (Foundation)

---

**Review abgeschlossen:** [Datum/Uhrzeit]  
**Nächster Review:** [Nach BLOCKER-Fixes]
```

---

## 7. Wichtige Hinweise für Reviewer

### 7.1 Sei konkret

❌ **SCHLECHT:** "Die API-Spec ist inkonsistent"  
✅ **GUT:** "API_SPEC.md Zeile 267 zeigt `target_group_id` als FK, aber DOMAIN_MODEL.md Abschnitt 3.3 definiert Zielgruppen als M:N"

### 7.2 Priorisiere nach Impact

- **BLOCKER:** Verhindert Implementation-Start
- **MAJOR:** Muss vor Phase 1 Abschluss gefixt werden
- **MINOR:** Kann in Phase 2 gefixt werden

### 7.3 Schlage Lösungen vor

Nicht nur Probleme nennen, sondern auch:
- Konkrete Fix-Vorschläge
- Alternative Ansätze
- Trade-offs aufzeigen

### 7.4 Sei fair

- Lobe gute Spezifikationen
- Erkenne schwierige Trade-offs an
- Berücksichtige MVP-Scope (nicht alles muss perfekt sein)

---

## 8. Erfolgs-Kriterien für APPROVED

Specs sind **APPROVED**, wenn:

1. ✅ Alle User-Anforderungen (1-8) spezifiziert sind
2. ✅ Alle User-Ergänzungen (1-5) korrekt umgesetzt sind
3. ✅ Keine architektonischen Widersprüche existieren
4. ✅ Specs konsistent mit Referenz-Dokumenten sind
5. ✅ Keine BLOCKER-Issues offen sind
6. ✅ Technische Machbarkeit gegeben ist
7. ✅ Implementation-Reihenfolge klar definiert ist

Specs sind **APPROVED WITH CHANGES**, wenn:
- 1-2 MAJOR Issues existieren (aber klar, wie zu fixen)
- Mehrere MINOR Issues existieren
- Implementation kann starten, während Fixes parallel gemacht werden

Specs sind **REJECTED**, wenn:
- 3+ BLOCKER Issues existieren
- Fundamentale architektonische Probleme vorhanden
- Große Teile der Anforderungen fehlen

---

## 9. Beispiel-Review-Snippet

**So sollte ein gutes Review-Finding aussehen:**

```markdown
### 🔴 BLOCKER #1: Exercise Blocks fehlen in DB-Schema

**Problem:**
- EXERCISES_ARCHITECTURE.md Abschnitt 2.3 definiert Exercise Blocks als "Gruppierung verschiedener Übungen"
- EXERCISES_DATABASE_FINAL.md (Migration 014-016) enthält KEINE `exercise_blocks` Tabelle
- API_SPEC.md spezifiziert KEINE `/exercise-blocks` Endpoints

**Impact:**
- User-Anforderung #4 ("Exercise Blocks: Sammlungen verschiedener Übungen") NICHT erfüllt
- Trainingsplan-Integration (Anforderung #6) ohne Blocks schwierig

**Betroffene Dateien:**
- EXERCISES_DATABASE_FINAL.md (fehlt Migration 017)
- EXERCISES_API_SPEC.md (fehlt Abschnitt "Exercise Blocks")
- UI_COMPONENTS_SPEC.md (fehlt "BlockEditor" Komponente)

**Lösungsvorschlag:**

1. **Migration 017: Exercise Blocks**
```sql
CREATE TABLE exercise_blocks (
    id SERIAL PRIMARY KEY,
    name VARCHAR(200) NOT NULL,
    description TEXT,
    is_template BOOLEAN DEFAULT FALSE,
    placeholders JSONB, -- für Template-Blocks
    created_by INT REFERENCES profiles(id),
    created_at TIMESTAMP DEFAULT NOW()
);

CREATE TABLE exercise_block_items (
    id SERIAL PRIMARY KEY,
    block_id INT REFERENCES exercise_blocks(id) ON DELETE CASCADE,
    exercise_id INT REFERENCES exercises(id) ON DELETE CASCADE,
    sequence_order INT NOT NULL,
    notes TEXT,
    UNIQUE(block_id, sequence_order)
);
```

2. **API-Endpoints ergänzen:**
- `GET /exercise-blocks` - List blocks
- `POST /exercise-blocks` - Create block
- `PUT /exercise-blocks/{id}` - Update block
- `POST /exercise-blocks/{id}/items` - Add exercise to block
- `PUT /exercise-blocks/{id}/items/reorder` - Reorder exercises

3. **UI-Komponente spezifizieren:**
- BlockEditor mit Drag & Drop für Exercise-Reihenfolge
- Template-Modus mit Platzhalter-UI

**Aufwand:** ~4-6h (1 Migration + 5 Endpoints + 1 Komponente spezifizieren)

**Kritikalität:** BLOCKER - Implementation kann ohne Blocks NICHT User-Anforderungen erfüllen
```

---

## 10. Review starten

**Bereit? Dann:**

1. Lies alle 7 Spec-Dokumente gründlich
2. Gehe die Checkliste durch (Abschnitt 4)
3. Erstelle deinen Review-Report (Template Abschnitt 6)
4. Sei konkret, fair und konstruktiv
5. Priorisiere nach Impact (BLOCKER > MAJOR > MINOR)

**Viel Erfolg beim Review! 🚀**

---

**Letzte Aktualisierung:** 2026-04-24  
**Version:** 1.0  
**Autor:** Claude Code (Spec-Ersteller)