shinkan-jinkendo/.claude/docs/REVIEW_PROMPT_EXERCISES_SPECS.md

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:

# 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:

### 🔴 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)