training data

training/README.md

@@ -0,0 +1,135 @@
+# Training & Handover Dokumentation
+
+Dieses Verzeichnis enthält alle Dokumente für den Handover und die Einarbeitung von Ida & Stephan.
+
+---
+
+## Dokumente
+
+### 1. Handover-Agenda für Sync-Meeting
+**Datei:** `handover_agenda_sync.md`
+
+Agenda für das erste Sync-Meeting mit Ida & Stephan. Enthält:
+- Projektkontext & Überblick
+- System-Architektur
+- Aktueller Stand & kritische Gaps
+- Wichtige Anforderungen
+- Rollenverteilung
+- Einarbeitungsplan-Übersicht
+- Naming Convention
+- Offene Fragen & Diskussion
+
+**Verwendung:** Als Agenda für das erste Handover-Meeting verwenden.
+
+---
+
+### 2. Einarbeitungsplan bis Weihnachten
+**Datei:** `handover_einarbeitungsplan.md`
+
+Detaillierter Einarbeitungsplan mit 4 Phasen:
+- **Phase 1**: Grundlagen (Woche 1-2)
+- **Phase 2**: Praktische Einarbeitung (Woche 3-4)
+- **Phase 3**: Selbstständige Entwicklung (Woche 5-6)
+- **Phase 4**: Konsolidierung (bis Weihnachten)
+
+Enthält:
+- Konkrete Aufgaben für Ida & Stephan
+- Checkpoints mit Erfolgskriterien
+- Metriken & Tracking
+- Risiken & Mitigation
+
+**Verwendung:** Als Roadmap für die Einarbeitung verwenden.
+
+---
+
+### 3. Naming Convention für Wiki-Dokumentation
+**Datei:** `handover_naming_convention.md`
+
+Vollständige Naming Convention für alle Dokumente im Wiki. Enthält:
+- Präfix-System (`doc_*`, `implementation_*`, `handover_*`, etc.)
+- Verzeichnisstruktur
+- Dateiformate
+- Best Practices
+- Migration bestehender Dokumente
+
+**Verwendung:** Als Referenz für alle neuen Dokumente verwenden.
+
+---
+
+## Verwendung
+
+### Für das erste Sync-Meeting
+1. `handover_agenda_sync.md` durchgehen
+2. Alle Punkte besprechen
+3. Offene Fragen klären
+4. Nächste Schritte vereinbaren
+
+### Für die Einarbeitung
+1. `handover_einarbeitungsplan.md` als Roadmap verwenden
+2. Wöchentliche Checkpoints durchführen
+3. Fortschritt dokumentieren
+4. Anpassungen vornehmen falls nötig
+
+### Für neue Dokumentation
+1. `handover_naming_convention.md` als Referenz verwenden
+2. Konsistente Namensgebung anwenden
+3. Richtiges Verzeichnis wählen
+4. Dokumentation pflegen
+
+---
+
+## Checkpoints
+
+### Checkpoint 1 (Ende Woche 2)
+- Architektur verstanden
+- Entwicklungsumgebung funktionsfähig
+- Erste Änderungen erfolgreich
+- Dokumentationsstruktur klar
+
+### Checkpoint 2 (Ende Woche 4)
+- Kritische Bug-Fixes implementiert
+- Feature-Integrations-Anleitung vorhanden
+- Dokumentation aktualisiert
+- Komponentenmodell vervollständigt
+
+### Checkpoint 3 (Ende Woche 6)
+- Kritische Gaps behoben
+- Neue Features integriert
+- Dokumentation konsolidiert
+- Sprint-Prozess etabliert
+
+### Final Checkpoint (Weihnachten)
+- Alle kritischen Gaps geschlossen
+- Dokumentation vollständig strukturiert
+- Feature-Integrations-Anleitung fertig
+- Komponentenmodell komplett
+- Selbstständige Entwicklung möglich
+
+---
+
+## Wichtige Links
+
+### Dokumentation
+- Architektur: `../appdoc/doc_gateway_architecture_overview.md`
+- Development Framework: `../appdoc/doc_gateway_development_framework.md`
+- Workflow System: `../appdoc/doc_dev_workflow.md`
+- Implementation Gaps: `../../gateway/WORKFLOW_IMPLEMENTATION_GAPS.md`
+
+### Code
+- Gateway: `../../gateway/`
+- Frontend: `../../frontend_agents/`
+- Tests: `../../gateway/tests/`
+
+---
+
+## Kontakt & Fragen
+
+Bei Fragen zur Einarbeitung oder Dokumentation:
+- **Ida**: Code-Entwicklung, Architektur
+- **Stephan**: Dokumentation, Strukturierung, Sprint-Planung
+- **[Name]**: Checkpoints, Validierung, Finale Entscheidungen
+
+---
+
+**Viel Erfolg bei der Einarbeitung! 🚀**
+

training/handover_agenda_sync.md

@@ -0,0 +1,221 @@
+# Handover-Agenda: Sync mit Ida & Stephan
+
+**Datum:** [Heute]  
+**Teilnehmer:** [Name], Ida (Coding Expertin, Architekt), Stephan (Sprintführung, Struktur, Dokumentation)  
+**Dauer:** 90-120 Minuten
+
+---
+
+## 1. Einführung & Überblick (15 Min)
+
+### 1.1 Projektkontext
+- **PowerOn Gateway**: Backend-System für intelligente Workflow-Automatisierung
+- **Frontend Agents**: React-basierte UI-Playground mit allen Implementierungen
+- **Architektur**: Multi-Layer-System (Connectors → Interfaces → Services → Workflows)
+- **Ziel**: Weiterentwicklung und Wartung des Systems übernehmen
+
+### 1.2 Zugriff & Ressourcen
+- ✅ GitHub Repository: Vollzugriff auf alle Daten
+- ✅ Dokumentation: `wiki/appdoc/`, `wiki/implementation/`, `wiki/deployment/`
+- ✅ Code: `gateway/` (Backend), `frontend_agents/` (UI-Playground)
+- ✅ Aktuelle Gaps: `gateway/WORKFLOW_IMPLEMENTATION_GAPS.md`
+
+---
+
+## 2. System-Architektur Überblick (20 Min)
+
+### 2.1 Layer-Struktur
+```
+Routes → Services → Interfaces → Connectors
+         ↓
+    Workflows (Orchestration)
+         ↓
+    Datamodels & AI Core
+```
+
+**Wichtige Verzeichnisse:**
+- `gateway/modules/routes/` - HTTP Endpoints
+- `gateway/modules/services/` - Business Logic
+- `gateway/modules/interfaces/` - Standardisierte APIs
+- `gateway/modules/connectors/` - Externe System-Integration
+- `gateway/modules/workflows/` - Workflow-Orchestrierung
+- `gateway/modules/datamodels/` - Datenmodelle
+
+### 2.2 Dokumentationsstruktur
+- **`wiki/appdoc/`**: Architektur-Dokumentation, System-Übersichten, User-Docs
+- **`wiki/implementation/`**: Implementierungsdetails, Refactoring-Dokumentation
+- **`wiki/deployment/`**: Deployment-Informationen, Instanzenübersicht
+- **`wiki/training/`**: Handover-Dokumente, Einarbeitungspläne
+
+### 2.3 Key Components
+- **Workflow System**: Multi-Mode-System (React Mode, Actionplan Mode)
+- **AI Core**: Zentrale AI-Orchestrierung mit verschiedenen Providern
+- **Service Center**: Registry für Service-Discovery und -Konfiguration
+- **Security Layer**: JWT, RBAC, Key Management, Verschlüsselung
+
+---
+
+## 3. Aktueller Stand & Wichtige Punkte (25 Min)
+
+### 3.1 Kritische Gaps (aus `WORKFLOW_IMPLEMENTATION_GAPS.md`)
+1. **Fast Path fehlt**: Keine Komplexitätserkennung für einfache Requests
+2. **Task-Nummerierung**: Zeigt immer "Task 0" statt korrekter Nummerierung
+3. **User-Language Messages**: Technische Texte statt benutzerfreundlicher Nachrichten
+4. **Workflow-Level Models**: RequestContext, UnderstandingResult fehlen
+
+### 3.2 Code-Qualität & Standards
+- **Naming**: camelStyle für Variablen/Funktionen, `_` Prefix für interne Funktionen
+- **Code-Stil**: Einfach, smart, lesbar - keine Overcomplications
+- **Fehlerbehandlung**: Root Cause identifizieren, keine Workarounds
+- **Logging**: Keine Emojis in Log-Einträgen
+
+### 3.3 Frontend als Referenz
+- `frontend_agents/` enthält alle UI-Implementierungen
+- Kann als Referenz für Backend-Integration verwendet werden
+- React-basiert, zeigt alle Features in Aktion
+
+---
+
+## 4. Wichtige Anforderungen (15 Min)
+
+### 4.1 Komplettes Komponentenmodell
+- **Ziel**: Vollständige Übersicht aller Komponenten und deren Beziehungen
+- **Status**: Teilweise vorhanden in `doc_diagram_components.md`
+- **Action**: Aktualisieren und vervollständigen
+
+### 4.2 Klare Dokumentation
+- **Ziel**: Strukturierte, gepflegte Dokumentation für alle Stakeholder
+- **Status**: Dokumentation vorhanden, aber nicht vollständig strukturiert
+- **Action**: Naming Convention etablieren, Dokumentation kategorisieren
+
+### 4.3 Feature-Integrations-Anleitung
+- **Ziel**: Schritt-für-Schritt-Anleitung, wie neue Features integriert werden
+- **Status**: Framework vorhanden (`doc_gateway_development_framework.md`), aber keine konkrete Anleitung
+- **Action**: Praktische Anleitung mit Beispielen erstellen
+
+---
+
+## 5. Rollenverteilung & Verantwortlichkeiten (10 Min)
+
+### 5.1 Ida (Coding Expertin, Architekt)
+- **Fokus**: Code-Entwicklung, Architektur-Entscheidungen, Python/React
+- **Verantwortung**:
+  - Feature-Implementierung
+  - Code-Review und Qualitätssicherung
+  - Architektur-Verbesserungen
+  - Bug-Fixes und Refactoring
+
+### 5.2 Stephan (Sprintführung, Struktur, Dokumentation)
+- **Fokus**: Projektmanagement, Dokumentation, Strukturierung
+- **Verantwortung**:
+  - Sprint-Planung und -Tracking
+  - Dokumentations-Pflege und -Strukturierung
+  - Prozess-Optimierung
+  - Stakeholder-Kommunikation
+
+### 5.3 Zusammenarbeit
+- Regelmäßige Syncs (wöchentlich)
+- Code-Reviews vor Merge
+- Dokumentation parallel zur Entwicklung
+- Checkpoints für [Name] zur Validierung
+
+---
+
+## 6. Einarbeitungsplan bis Weihnachten (15 Min)
+
+### 6.1 Phase 1: Grundlagen (Woche 1-2)
+- [ ] System-Architektur verstehen
+- [ ] Codebase explorieren
+- [ ] Lokale Entwicklungsumgebung aufsetzen
+- [ ] Erste kleine Änderungen testen
+
+**Checkpoint 1**: [Name] prüft Verständnis der Architektur
+
+### 6.2 Phase 2: Praktische Einarbeitung (Woche 3-4)
+- [ ] Erste Bug-Fixes implementieren
+- [ ] Dokumentation aktualisieren
+- [ ] Feature-Integrations-Anleitung erstellen
+- [ ] Komponentenmodell vervollständigen
+
+**Checkpoint 2**: [Name] prüft Qualität der ersten Änderungen
+
+### 6.3 Phase 3: Selbstständige Entwicklung (Woche 5-6)
+- [ ] Kritische Gaps beheben (siehe 3.1)
+- [ ] Neue Features entwickeln
+- [ ] Dokumentation strukturieren und pflegen
+- [ ] Best Practices etablieren
+
+**Checkpoint 3**: [Name] prüft Fortschritt und Qualität
+
+### 6.4 Phase 4: Konsolidierung (bis Weihnachten)
+- [ ] Alle kritischen Gaps geschlossen
+- [ ] Dokumentation vollständig strukturiert
+- [ ] Feature-Integrations-Anleitung fertig
+- [ ] Komponentenmodell komplett
+
+**Final Checkpoint**: [Name] prüft Gesamtergebnis
+
+**Detaillierter Plan**: Siehe `handover_einarbeitungsplan.md`
+
+---
+
+## 7. Naming Convention & Dokumentationsstruktur (10 Min)
+
+### 7.1 Dokument-Naming Convention
+Siehe `handover_naming_convention.md` für Details.
+
+**Kurzfassung:**
+- `doc_*` - Architektur- und System-Dokumentation
+- `implementation_*` - Implementierungsdetails
+- `handover_*` - Handover-Dokumente
+- `spec_*` - Spezifikationen
+- `user_*` - User-Dokumentation
+
+### 7.2 Dokumentationsstruktur
+- **`wiki/appdoc/`**: Architektur, System-Übersichten, User-Docs
+- **`wiki/implementation/`**: Implementierungsdetails
+- **`wiki/deployment/`**: Deployment-Informationen
+- **`wiki/training/`**: Handover, Einarbeitung
+- **`wiki/reviews/`**: Code-Reviews, Analysen
+- **`wiki/strategy/`**: Strategische Dokumente
+
+---
+
+## 8. Offene Fragen & Diskussion (10 Min)
+
+### 8.1 Fragen von Ida & Stephan
+- Technische Fragen zur Architektur
+- Prozess-Fragen zur Entwicklung
+- Dokumentations-Fragen
+
+### 8.2 Nächste Schritte
+- [ ] GitHub-Zugriff bestätigen
+- [ ] Lokale Entwicklungsumgebung aufsetzen
+- [ ] Erste Dokumentation lesen
+- [ ] Nächster Sync-Termin vereinbaren
+
+---
+
+## 9. Action Items
+
+### Für Ida & Stephan:
+- [ ] GitHub Repository klonen und explorieren
+- [ ] Lokale Entwicklungsumgebung aufsetzen
+- [ ] Dokumentation in `wiki/appdoc/` durcharbeiten
+- [ ] Erste Fragen sammeln für nächsten Sync
+
+### Für [Name]:
+- [ ] Zugriff auf alle Ressourcen bestätigen
+- [ ] Nächsten Sync-Termin festlegen
+- [ ] Checkpoint-Termine für Einarbeitungsplan vereinbaren
+
+---
+
+## Anhänge
+
+- **Einarbeitungsplan**: `handover_einarbeitungsplan.md`
+- **Naming Convention**: `handover_naming_convention.md`
+- **Architektur-Übersicht**: `../appdoc/doc_gateway_architecture_overview.md`
+- **Development Framework**: `../appdoc/doc_gateway_development_framework.md`
+- **Workflow Gaps**: `../../gateway/WORKFLOW_IMPLEMENTATION_GAPS.md`
+

training/handover_einarbeitungsplan.md

@@ -0,0 +1,416 @@
+# Einarbeitungsplan: Ida & Stephan bis Weihnachten
+
+**Zeitraum:** [Startdatum] bis Weihnachten  
+**Ziel:** Vollständige Übernahme der Code-Entwicklung und Dokumentation
+
+---
+
+## Übersicht: 4 Phasen
+
+```
+Phase 1: Grundlagen (Woche 1-2)
+    ↓
+Phase 2: Praktische Einarbeitung (Woche 3-4)
+    ↓
+Phase 3: Selbstständige Entwicklung (Woche 5-6)
+    ↓
+Phase 4: Konsolidierung (bis Weihnachten)
+```
+
+---
+
+## Phase 1: Grundlagen (Woche 1-2)
+
+### Ziel
+System-Architektur verstehen, Codebase explorieren, Entwicklungsumgebung aufsetzen
+
+### Aufgaben für Ida
+
+#### Woche 1: Architektur & Codebase
+- [ ] **Tag 1-2**: Architektur-Dokumentation lesen
+  - `doc_gateway_architecture_overview.md`
+  - `doc_gateway_development_framework.md`
+  - `doc_diagram_components.md`
+  - `doc_dev_workflow.md`
+- [ ] **Tag 3-4**: Codebase explorieren
+  - `gateway/modules/` Struktur verstehen
+  - Wichtige Dateien identifizieren:
+    - `app.py` (Entry Point)
+    - `workflowManager.py` (Workflow-Orchestrierung)
+    - `modules/services/__init__.py` (Service Center)
+    - `modules/workflows/` (Workflow-System)
+- [ ] **Tag 5**: Lokale Entwicklungsumgebung aufsetzen
+  - Python-Umgebung konfigurieren
+  - Dependencies installieren (`requirements.txt`)
+  - Environment-Variablen konfigurieren
+  - App lokal starten und testen
+
+#### Woche 2: Praktisches Verständnis
+- [ ] **Tag 1-2**: Workflow-System verstehen
+  - `workflowManager.py` durcharbeiten
+  - `workflowProcessor.py` analysieren
+  - React Mode vs. Actionplan Mode verstehen
+  - `modeDynamic.py` studieren
+- [ ] **Tag 3-4**: Service-Layer verstehen
+  - Service Center (`modules/services/__init__.py`)
+  - Beispiel-Services analysieren (`serviceAi`, `serviceExtraction`)
+  - Interface-Pattern verstehen
+  - Connector-Pattern verstehen
+- [ ] **Tag 5**: Erste kleine Änderung testen
+  - Kleiner Bug-Fix oder Code-Formatierung
+  - Pull Request erstellen
+  - Review-Prozess durchlaufen
+
+### Aufgaben für Stephan
+
+#### Woche 1: Dokumentationsstruktur
+- [ ] **Tag 1-2**: Dokumentationsstruktur analysieren
+  - Alle `wiki/` Unterordner durchgehen
+  - Dokumentations-Typen identifizieren
+  - Lücken in der Dokumentation finden
+- [ ] **Tag 3-4**: Naming Convention etablieren
+  - `handover_naming_convention.md` durcharbeiten
+  - Bestehende Dokumente kategorisieren
+  - Vorschläge für Verbesserungen sammeln
+- [ ] **Tag 5**: Dokumentations-Index erstellen
+  - Übersicht aller Dokumente
+  - Kategorisierung nach Typ
+  - Verlinkungen zwischen Dokumenten
+
+#### Woche 2: Prozess-Verständnis
+- [ ] **Tag 1-2**: Development-Workflow verstehen
+  - `doc_dev_workflow.md` durcharbeiten
+  - Git-Workflow verstehen
+  - Review-Prozess verstehen
+- [ ] **Tag 3-4**: Sprint-Struktur planen
+  - Sprint-Länge festlegen (z.B. 2 Wochen)
+  - Backlog-Struktur definieren
+  - Tracking-Tool einrichten (falls nötig)
+- [ ] **Tag 5**: Erste Dokumentation aktualisieren
+  - Ein Dokument aktualisieren/verbessern
+  - Naming Convention anwenden
+  - Feedback einholen
+
+### Checkpoint 1 (Ende Woche 2)
+
+**Prüfung durch [Name]:**
+- [ ] Ida kann die Architektur erklären
+- [ ] Ida hat lokale Entwicklungsumgebung funktionsfähig
+- [ ] Ida hat erste kleine Änderung erfolgreich gemacht
+- [ ] Stephan hat Dokumentationsstruktur verstanden
+- [ ] Stephan hat Naming Convention angewendet
+- [ ] Beide können Fragen zur Architektur beantworten
+
+**Erfolgskriterien:**
+- ✅ Lokale Entwicklungsumgebung läuft
+- ✅ Erste Code-Änderung erfolgreich
+- ✅ Dokumentationsstruktur klar
+- ✅ Naming Convention etabliert
+
+---
+
+## Phase 2: Praktische Einarbeitung (Woche 3-4)
+
+### Ziel
+Erste Bug-Fixes implementieren, Dokumentation aktualisieren, Feature-Integrations-Anleitung erstellen
+
+### Aufgaben für Ida
+
+#### Woche 3: Bug-Fixes & Code-Verbesserungen
+- [ ] **Tag 1-2**: Task-Nummerierung Fix (kritisch)
+  - Problem verstehen (siehe `WORKFLOW_IMPLEMENTATION_GAPS.md`)
+  - `workflowManager._executeTasks()` analysieren
+  - Fix implementieren
+  - Testen
+- [ ] **Tag 3-4**: Code-Qualität verbessern
+  - Unused Functions identifizieren (`tool_stats_showUnusedFunctions.py`)
+  - Code-Formatierung vereinheitlichen
+  - Linter-Fehler beheben
+- [ ] **Tag 5**: Code-Review für eigene Änderungen
+  - Pull Requests erstellen
+  - Review-Prozess durchlaufen
+  - Feedback einarbeiten
+
+#### Woche 4: Feature-Integrations-Anleitung
+- [ ] **Tag 1-2**: Bestehende Features analysieren
+  - Wie wurden Features bisher integriert?
+  - Patterns identifizieren
+  - Beispiele sammeln
+- [ ] **Tag 3-4**: Feature-Integrations-Anleitung erstellen
+  - Schritt-für-Schritt-Anleitung
+  - Beispiele für verschiedene Feature-Typen
+  - Checkliste für neue Features
+- [ ] **Tag 5**: Anleitung testen
+  - Kleines Feature als Beispiel integrieren
+  - Anleitung dabei verwenden
+  - Verbesserungen identifizieren
+
+### Aufgaben für Stephan
+
+#### Woche 3: Dokumentations-Pflege
+- [ ] **Tag 1-2**: Dokumentations-Lücken schließen
+  - Fehlende Dokumentation identifizieren
+  - Prioritäten setzen
+  - Erste Dokumente erstellen/aktualisieren
+- [ ] **Tag 3-4**: Dokumentations-Struktur verbessern
+  - Verlinkungen zwischen Dokumenten
+  - Index aktualisieren
+  - Kategorisierung vervollständigen
+- [ ] **Tag 5**: Review-Prozess für Dokumentation
+  - Review-Checkliste erstellen
+  - Qualitätskriterien definieren
+  - Erste Dokumente reviewen
+
+#### Woche 4: Komponentenmodell
+- [ ] **Tag 1-2**: Bestehendes Komponentenmodell analysieren
+  - `doc_diagram_components.md` durcharbeiten
+  - Lücken identifizieren
+  - Aktualitätsprüfung
+- [ ] **Tag 3-4**: Komponentenmodell vervollständigen
+  - Alle Komponenten dokumentieren
+  - Beziehungen zwischen Komponenten
+  - Diagramme aktualisieren/erstellen
+- [ ] **Tag 5**: Komponentenmodell validieren
+  - Mit Codebase abgleichen
+  - Feedback von Ida einholen
+  - Verbesserungen einarbeiten
+
+### Checkpoint 2 (Ende Woche 4)
+
+**Prüfung durch [Name]:**
+- [ ] Ida hat kritische Bug-Fixes implementiert
+- [ ] Code-Qualität hat sich verbessert
+- [ ] Feature-Integrations-Anleitung ist praktisch nutzbar
+- [ ] Dokumentation ist aktualisiert und strukturiert
+- [ ] Komponentenmodell ist vervollständigt
+
+**Erfolgskriterien:**
+- ✅ Task-Nummerierung funktioniert korrekt
+- ✅ Feature-Integrations-Anleitung vorhanden
+- ✅ Dokumentation strukturiert und gepflegt
+- ✅ Komponentenmodell vollständig
+
+---
+
+## Phase 3: Selbstständige Entwicklung (Woche 5-6)
+
+### Ziel
+Kritische Gaps beheben, neue Features entwickeln, Best Practices etablieren
+
+### Aufgaben für Ida
+
+#### Woche 5: Kritische Gaps beheben
+- [ ] **Tag 1-2**: Fast Path Implementation
+  - `detectComplexity()` Funktion implementieren
+  - `fastPathExecute()` Funktion implementieren
+  - Routing-Logik in `workflowManager.py` einbauen
+  - Tests schreiben
+- [ ] **Tag 3-4**: User-Language Messages
+  - AI-generierte benutzerfreundliche Nachrichten
+  - `messageCreator.py` anpassen
+  - Mehrsprachigkeit testen
+- [ ] **Tag 5**: Code-Review & Testing
+  - Alle Änderungen testen
+  - Integrationstests schreiben
+  - Code-Review durchführen
+
+#### Woche 6: Neue Features & Architektur-Verbesserungen
+- [ ] **Tag 1-2**: Workflow-Level Models (optional)
+  - `RequestContext` Model erstellen
+  - `UnderstandingResult` Model erstellen
+  - Migration planen (falls gewünscht)
+- [ ] **Tag 3-4**: Architektur-Verbesserungen
+  - Code-Duplikation reduzieren
+  - Performance-Optimierungen
+  - Refactoring wo nötig
+- [ ] **Tag 5**: Feature-Entwicklung
+  - Neues Feature nach Anleitung integrieren
+  - Dokumentation parallel erstellen
+  - Tests schreiben
+
+### Aufgaben für Stephan
+
+#### Woche 5: Dokumentations-Konsolidierung
+- [ ] **Tag 1-2**: Alle Dokumentationen durchgehen
+  - Aktualitätsprüfung
+  - Konsistenz prüfen
+  - Verbesserungen identifizieren
+- [ ] **Tag 3-4**: Dokumentations-Workflow etablieren
+  - Prozess für Dokumentations-Updates
+  - Review-Prozess für Dokumentation
+  - Qualitätskriterien durchsetzen
+- [ ] **Tag 5**: Dokumentations-Templates erstellen
+  - Template für neue Features
+  - Template für Architektur-Dokumente
+  - Template für Implementierungs-Dokumente
+
+#### Woche 6: Sprint-Planung & Strukturierung
+- [ ] **Tag 1-2**: Backlog strukturieren
+  - Features priorisieren
+  - Bugs kategorisieren
+  - Technische Schulden dokumentieren
+- [ ] **Tag 3-4**: Sprint-Planung für nächste Sprints
+  - Sprint-Ziele definieren
+  - Aufgaben verteilen
+  - Zeitplanung
+- [ ] **Tag 5**: Metriken & Reporting
+  - Fortschritts-Tracking einrichten
+  - Metriken definieren
+  - Reporting-Struktur etablieren
+
+### Checkpoint 3 (Ende Woche 6)
+
+**Prüfung durch [Name]:**
+- [ ] Kritische Gaps sind behoben
+- [ ] Neue Features wurden erfolgreich integriert
+- [ ] Dokumentation ist konsolidiert
+- [ ] Sprint-Planung funktioniert
+- [ ] Code-Qualität ist hoch
+
+**Erfolgskriterien:**
+- ✅ Fast Path funktioniert
+- ✅ User-Language Messages implementiert
+- ✅ Dokumentation vollständig strukturiert
+- ✅ Sprint-Prozess etabliert
+
+---
+
+## Phase 4: Konsolidierung (bis Weihnachten)
+
+### Ziel
+Alle kritischen Gaps geschlossen, Dokumentation vollständig strukturiert, Feature-Integrations-Anleitung fertig, Komponentenmodell komplett
+
+### Aufgaben für Ida
+
+#### Woche 7-8: Finalisierung kritischer Features
+- [ ] Alle kritischen Gaps aus `WORKFLOW_IMPLEMENTATION_GAPS.md` beheben
+- [ ] Code-Qualität auf hohem Niveau halten
+- [ ] Performance-Optimierungen
+- [ ] Umfassende Tests schreiben
+
+#### Woche 9-10: Feature-Entwicklung
+- [ ] Neue Features nach Anleitung entwickeln
+- [ ] Best Practices etablieren
+- [ ] Code-Reviews durchführen
+- [ ] Wissen dokumentieren
+
+### Aufgaben für Stephan
+
+#### Woche 7-8: Dokumentations-Finalisierung
+- [ ] Alle Dokumentationen aktualisieren
+- [ ] Komponentenmodell finalisieren
+- [ ] Feature-Integrations-Anleitung finalisieren
+- [ ] Dokumentations-Index vollständig
+
+#### Woche 9-10: Prozess-Optimierung
+- [ ] Sprint-Prozess optimieren
+- [ ] Metriken & Reporting etablieren
+- [ ] Wissenstransfer dokumentieren
+- [ ] Handover-Dokumentation vervollständigen
+
+### Final Checkpoint (Weihnachten)
+
+**Prüfung durch [Name]:**
+- [ ] Alle kritischen Gaps geschlossen
+- [ ] Dokumentation vollständig strukturiert und gepflegt
+- [ ] Feature-Integrations-Anleitung fertig und getestet
+- [ ] Komponentenmodell komplett
+- [ ] Ida & Stephan können selbstständig entwickeln
+- [ ] Qualität ist hoch und konsistent
+
+**Erfolgskriterien:**
+- ✅ System ist produktionsreif
+- ✅ Dokumentation ist vollständig
+- ✅ Prozesse sind etabliert
+- ✅ Wissenstransfer abgeschlossen
+
+---
+
+## Wöchentliche Checkpoints
+
+### Format
+- **Dauer**: 30-60 Minuten
+- **Teilnehmer**: [Name], Ida, Stephan
+- **Agenda**:
+  1. Fortschritt der letzten Woche
+  2. Herausforderungen & Blockaden
+  3. Nächste Schritte
+  4. Feedback & Anpassungen
+
+### Checkpoint-Termine
+- **Checkpoint 1**: Ende Woche 2
+- **Checkpoint 2**: Ende Woche 4
+- **Checkpoint 3**: Ende Woche 6
+- **Final Checkpoint**: Weihnachten
+
+---
+
+## Metriken & Tracking
+
+### Code-Metriken
+- Anzahl implementierter Features
+- Anzahl behobener Bugs
+- Code-Coverage (Tests)
+- Code-Qualität (Linter-Scores)
+
+### Dokumentations-Metriken
+- Anzahl aktualisierter Dokumente
+- Vollständigkeit des Komponentenmodells
+- Qualität der Dokumentation (Review-Scores)
+
+### Prozess-Metriken
+- Sprint-Velocity
+- Time-to-Market für Features
+- Review-Zyklus-Zeit
+
+---
+
+## Risiken & Mitigation
+
+### Risiko 1: Zu komplexe Architektur
+- **Mitigation**: Schrittweise Einarbeitung, Fragen stellen, Pair Programming
+
+### Risiko 2: Unvollständige Dokumentation
+- **Mitigation**: Dokumentation parallel zur Entwicklung, regelmäßige Reviews
+
+### Risiko 3: Zeitdruck
+- **Mitigation**: Realistische Planung, Priorisierung, Fokus auf kritische Punkte
+
+### Risiko 4: Wissenslücken
+- **Mitigation**: Regelmäßige Syncs, Code-Reviews, Dokumentation lesen
+
+---
+
+## Ressourcen & Links
+
+### Dokumentation
+- Architektur: `wiki/appdoc/doc_gateway_architecture_overview.md`
+- Development Framework: `wiki/appdoc/doc_gateway_development_framework.md`
+- Workflow System: `wiki/appdoc/doc_dev_workflow.md`
+- Implementation Gaps: `gateway/WORKFLOW_IMPLEMENTATION_GAPS.md`
+
+### Code
+- Gateway: `gateway/`
+- Frontend: `frontend_agents/`
+- Tests: `gateway/tests/`
+
+### Tools
+- GitHub: Repository
+- Development Environment: Lokal
+- Testing: pytest
+- Code Quality: Linter, Type Checking
+
+---
+
+## Erfolgsfaktoren
+
+1. **Regelmäßige Kommunikation**: Wöchentliche Syncs, offene Fragen
+2. **Schrittweise Einarbeitung**: Nicht alles auf einmal, sondern strukturiert
+3. **Praktische Übung**: Learning by doing, kleine Aufgaben zuerst
+4. **Dokumentation parallel**: Wissen sofort dokumentieren
+5. **Feedback-Loops**: Regelmäßige Checkpoints, Anpassungen
+
+---
+
+**Viel Erfolg bei der Einarbeitung! 🚀**
+

training/handover_naming_convention.md

@@ -0,0 +1,478 @@
+# Naming Convention für Wiki-Dokumentation
+
+**Zweck:** Klare Strukturierung und Auffindbarkeit aller Dokumente im Wiki
+
+---
+
+## Grundprinzipien
+
+1. **Konsistenz**: Einheitliche Namensgebung für ähnliche Dokumente
+2. **Selbsterklärend**: Dateiname sollte Inhalt und Typ erkennen lassen
+3. **Kategorisierung**: Präfixe für schnelle Identifikation
+4. **Versionierung**: Bei Bedarf Datum oder Version im Namen
+
+---
+
+## Präfix-System
+
+### `doc_*` - Architektur- und System-Dokumentation
+
+**Verwendung:** Architektur-Übersichten, System-Beschreibungen, High-Level-Dokumentation
+
+**Beispiele:**
+- `doc_gateway_architecture_overview.md` - Gateway-Architektur Übersicht
+- `doc_gateway_development_framework.md` - Development Framework
+- `doc_system_prompt_flow.md` - System: Prompt Flow
+- `doc_system_polling_logic.md` - System: Polling Logic
+- `doc_architecture_ai_service.html` - Architektur: AI Service
+- `doc_architecture_workflow.html` - Architektur: Workflow
+
+**Struktur:**
+```
+doc_[bereich]_[thema]_[detail].md
+```
+
+**Bereiche:**
+- `gateway` - Gateway-spezifische Dokumentation
+- `architecture` - Architektur-Dokumentation
+- `system` - System-spezifische Dokumentation
+- `security` - Sicherheits-Dokumentation
+- `user` - User-Dokumentation
+
+---
+
+### `implementation_*` - Implementierungsdetails
+
+**Verwendung:** Detaillierte Implementierungs-Beschreibungen, Refactoring-Dokumentation, Technische Details
+
+**Beispiele:**
+- `implementation_workflow_automation_architecture.md` - Workflow Automation Architektur
+- `implementation_chat_validation_workflow_task_action.md` - Chat Validation Workflow
+- `implementation_ui_table_pagination.md` - UI Table Pagination
+- `implementation_action_validation_generic.md` - Generic Action Validation
+- `implementation_content_handling_with_dynamic_ai_v2.md` - Content Handling mit Dynamic AI v2
+- `implementation_refactor_stats-unified.md` - Refactoring: Stats Unified
+- `implementation_refactor_db-consistency.md` - Refactoring: DB Consistency
+
+**Struktur:**
+```
+implementation_[komponente]_[aspekt]_[detail].md
+```
+
+**Komponenten:**
+- `workflow` - Workflow-Implementierungen
+- `chat` - Chat-Implementierungen
+- `ui` - UI-Implementierungen
+- `action` - Action-Implementierungen
+- `content` - Content-Handling
+- `refactor` - Refactoring-Dokumentation
+
+---
+
+### `handover_*` - Handover-Dokumente
+
+**Verwendung:** Handover-Dokumentation, Einarbeitungspläne, Wissenstransfer
+
+**Beispiele:**
+- `handover_agenda_sync.md` - Agenda für Sync-Meeting
+- `handover_einarbeitungsplan.md` - Einarbeitungsplan
+- `handover_naming_convention.md` - Naming Convention (dieses Dokument)
+- `handover_[thema]_[detail].md`
+
+**Struktur:**
+```
+handover_[thema]_[detail].md
+```
+
+---
+
+### `spec_*` - Spezifikationen
+
+**Verwendung:** Feature-Spezifikationen, Anforderungen, Design-Dokumente
+
+**Beispiele:**
+- `spec_workflow-implementation.md` - Workflow Implementation Spec
+- `spec_workflow-architecture.md` - Workflow Architecture Spec
+- `spec_ui.md` - UI Specification
+- `spec_progress_logging.md` - Progress Logging Specification
+
+**Struktur:**
+```
+spec_[bereich]_[thema].md
+```
+
+---
+
+### `user_*` - User-Dokumentation
+
+**Verwendung:** Benutzer-Anleitungen, How-To-Guides, User-Facing-Dokumentation
+
+**Beispiele:**
+- `user_applikation.md` - User: Applikation
+- `user_kunden.md` - User: Kunden
+- `user_partner.md` - User: Partner
+- `user_investoren.md` - User: Investoren
+- `user_product.md` - User: Product
+- `user_summary.md` - User: Summary
+
+**Struktur:**
+```
+user_[zielgruppe]_[thema].md
+```
+
+---
+
+### `security_*` - Sicherheits-Dokumentation
+
+**Verwendung:** Sicherheits-Richtlinien, Key Management, Zugriffskontrollen
+
+**Beispiele:**
+- `security_key_management.md` - Key Management
+- `security_role_based_access.md` - Role-Based Access Control
+- `security-migration-guide.md` - Security Migration Guide
+
+**Struktur:**
+```
+security_[thema]_[detail].md
+```
+
+---
+
+### `prompt_*` - Prompt-Dokumentation
+
+**Verwendung:** Prompt-Templates, Prompt-Engineering, AI-Prompt-Dokumentation
+
+**Beispiele:**
+- `prompt_produce_diagrams.md` - Prompt: Diagramme produzieren
+
+**Struktur:**
+```
+prompt_[zweck]_[detail].md
+```
+
+---
+
+## Dateiformate
+
+### Markdown (`.md`)
+**Standard-Format** für alle Text-Dokumentation
+- Einfach zu bearbeiten
+- Versionierbar
+- Gut lesbar in GitHub
+
+### HTML (`.html`)
+**Für komplexe Visualisierungen**
+- Interaktive Diagramme
+- Erweiterte Formatierung
+- Wenn Markdown nicht ausreicht
+
+### PDF (`.pdf`)
+**Für finale Dokumente**
+- Präsentationen
+- Externe Dokumentation
+- Druck-Versionen
+
+### Draw.io (`.drawio`)
+**Für Diagramme**
+- Architektur-Diagramme
+- Flowcharts
+- Komponenten-Diagramme
+
+### Mermaid (`.mermaid`)
+**Für Code-basierte Diagramme**
+- Versionierbare Diagramme
+- Einfach zu aktualisieren
+- In Markdown integrierbar
+
+---
+
+## Verzeichnisstruktur
+
+### `wiki/appdoc/` - Architektur-Dokumentation
+**Inhalt:**
+- `doc_*` - Architektur- und System-Dokumentation
+- `user_*` - User-Dokumentation
+- `spec_*` - Spezifikationen
+- `security_*` - Sicherheits-Dokumentation
+- `prompt_*` - Prompt-Dokumentation
+
+**Beispiele:**
+- `doc_gateway_architecture_overview.md`
+- `doc_system_prompt_flow.md`
+- `user_applikation.md`
+- `spec_ui.md`
+- `security_key_management.md`
+
+---
+
+### `wiki/implementation/` - Implementierungsdetails
+**Inhalt:**
+- `implementation_*` - Implementierungs-Dokumentation
+- `security-migration-guide.md` - Migration Guides
+
+**Beispiele:**
+- `implementation_workflow_automation_architecture.md`
+- `implementation_chat_validation_workflow_task_action.md`
+- `implementation_refactor_stats-unified.md`
+
+---
+
+### `wiki/deployment/` - Deployment-Informationen
+**Inhalt:**
+- Deployment-Diagramme
+- Instanzenübersicht
+- Deployment-Anleitungen
+- Secrets-Management
+
+**Beispiele:**
+- `Instanzenübersicht.drawio`
+- `Instanzenübersicht.svg`
+- `poweron_sec.kdbx`
+
+---
+
+### `wiki/training/` - Handover & Training
+**Inhalt:**
+- `handover_*` - Handover-Dokumente
+- Einarbeitungspläne
+- Training-Materialien
+
+**Beispiele:**
+- `handover_agenda_sync.md`
+- `handover_einarbeitungsplan.md`
+- `handover_naming_convention.md`
+
+---
+
+### `wiki/reviews/` - Code-Reviews & Analysen
+**Inhalt:**
+- Code-Review-Dokumente
+- Analysen
+- Reports
+
+**Beispiele:**
+- `context_checker_analysis.md`
+- `report_20251020_unused_functions_analysis.md`
+- `report_20251020_workflow_step_by_step_analysis.md`
+
+---
+
+### `wiki/strategy/` - Strategische Dokumente
+**Inhalt:**
+- Produktstrategie
+- Marketing-Materialien
+- Strategische Planung
+
+**Beispiele:**
+- `doc_produktestrategie.md`
+- `doc_playground_marketing_pitch.md`
+
+---
+
+### `wiki/archiv/` - Archivierte Dokumente
+**Inhalt:**
+- Alte Dokumente
+- Historische Versionen
+- Nicht mehr aktive Dokumente
+
+**Naming:** Keine spezielle Convention, aber Datum im Namen empfohlen
+- `2025-07_chat_process_visualization.md`
+- `poweron_summary_202404.md`
+
+---
+
+## Namenskonventionen im Detail
+
+### Allgemeine Regeln
+
+1. **Kleinbuchstaben**: Alle Dateinamen in Kleinbuchstaben
+2. **Unterstriche**: Wörter mit `_` trennen (nicht `-`)
+3. **Keine Leerzeichen**: Niemals Leerzeichen verwenden
+4. **Keine Sonderzeichen**: Keine Umlaute, Sonderzeichen außer `_`, `-`, `.`
+5. **Datum**: Wenn nötig, Format `YYYYMMDD` oder `YYYY-MM-DD`
+
+### Präfix + Thema + Detail
+
+**Format:**
+```
+[präfix]_[bereich]_[thema]_[detail].[extension]
+```
+
+**Beispiele:**
+- `doc_gateway_architecture_overview.md` ✅
+- `implementation_workflow_automation_architecture.md` ✅
+- `handover_agenda_sync.md` ✅
+- `spec_ui.md` ✅
+
+**Nicht:**
+- `Gateway Architecture Overview.md` ❌ (Leerzeichen, Großbuchstaben)
+- `doc-gateway-architecture-overview.md` ❌ (Bindestriche statt Unterstriche)
+- `DocGatewayArchitectureOverview.md` ❌ (CamelCase, kein Präfix)
+
+---
+
+## Versionierung
+
+### Option 1: Datum im Namen
+**Format:** `[präfix]_[thema]_[YYYYMMDD].md`
+
+**Beispiele:**
+- `doc_investor_20251014.md`
+- `report_20251020_unused_functions_analysis.md`
+
+### Option 2: Versionsnummer
+**Format:** `[präfix]_[thema]_v[version].md`
+
+**Beispiele:**
+- `implementation_content_handling_with_dynamic_ai_v2.md`
+- `spec_workflow_v1.md`
+
+### Option 3: Keine Versionierung
+Für aktuelle Dokumente, die kontinuierlich aktualisiert werden.
+
+---
+
+## Dateierweiterungen
+
+### `.md` - Markdown (Standard)
+**Verwendung:** Alle Text-Dokumentation
+
+### `.html` - HTML
+**Verwendung:** Komplexe Visualisierungen, interaktive Inhalte
+
+### `.pdf` - PDF
+**Verwendung:** Finale Dokumente, Präsentationen, externe Dokumentation
+
+### `.drawio` - Draw.io Diagramme
+**Verwendung:** Architektur-Diagramme, Flowcharts
+
+### `.mermaid` - Mermaid Diagramme
+**Verwendung:** Code-basierte Diagramme, versionierbare Diagramme
+
+### `.svg` - SVG Diagramme
+**Verwendung:** Exportierte Diagramme, Vektorgrafiken
+
+---
+
+## Beispiele für verschiedene Dokumenttypen
+
+### Architektur-Dokumentation
+```
+doc_gateway_architecture_overview.md
+doc_architecture_ai_service.html
+doc_architecture_workflow.html
+doc_system_prompt_flow.md
+doc_system_polling_logic.md
+```
+
+### Implementierungs-Dokumentation
+```
+implementation_workflow_automation_architecture.md
+implementation_chat_validation_workflow_task_action.md
+implementation_ui_table_pagination.md
+implementation_refactor_stats-unified.md
+```
+
+### User-Dokumentation
+```
+user_applikation.md
+user_kunden.md
+user_partner.md
+user_investoren.md
+user_product.md
+```
+
+### Spezifikationen
+```
+spec_workflow-implementation.md
+spec_workflow-architecture.md
+spec_ui.md
+spec_progress_logging.md
+```
+
+### Handover-Dokumentation
+```
+handover_agenda_sync.md
+handover_einarbeitungsplan.md
+handover_naming_convention.md
+```
+
+### Sicherheits-Dokumentation
+```
+security_key_management.md
+security_role_based_access.md
+security-migration-guide.md
+```
+
+---
+
+## Checkliste für neue Dokumente
+
+Vor dem Erstellen eines neuen Dokuments:
+
+- [ ] Richtigen Präfix gewählt? (`doc_`, `implementation_`, `handover_`, etc.)
+- [ ] Richtiges Verzeichnis gewählt? (`appdoc/`, `implementation/`, `training/`, etc.)
+- [ ] Konsistente Namensgebung? (Kleinbuchstaben, Unterstriche)
+- [ ] Selbsterklärender Name? (Inhalt erkennbar)
+- [ ] Richtige Dateierweiterung? (`.md` für Standard, `.html` für komplexe Inhalte)
+- [ ] Keine Duplikate? (Bestehende Dokumente prüfen)
+
+---
+
+## Migration bestehender Dokumente
+
+### Schritt 1: Kategorisierung
+- Alle Dokumente durchgehen
+- Präfix zuordnen
+- Verzeichnis zuordnen
+
+### Schritt 2: Umbenennung
+- Dateinamen anpassen
+- Konsistente Namensgebung
+- Verzeichnis verschieben falls nötig
+
+### Schritt 3: Verlinkungen aktualisieren
+- Interne Links aktualisieren
+- Referenzen aktualisieren
+- Index aktualisieren
+
+### Schritt 4: Dokumentation
+- Änderungen dokumentieren
+- Migration-Plan erstellen
+- Team informieren
+
+---
+
+## Best Practices
+
+1. **Konsistenz**: Immer die gleiche Namensgebung verwenden
+2. **Selbsterklärend**: Dateiname sollte Inhalt erkennen lassen
+3. **Kategorisierung**: Präfixe für schnelle Identifikation
+4. **Versionierung**: Bei Bedarf Datum oder Version im Namen
+5. **Verzeichnisstruktur**: Dokumente im richtigen Verzeichnis ablegen
+6. **Dokumentation**: Änderungen dokumentieren
+
+---
+
+## FAQ
+
+### Q: Was wenn ein Dokument in mehrere Kategorien passt?
+**A:** Hauptkategorie wählen, andere im Dokument erwähnen. Bei Bedarf Verlinkungen erstellen.
+
+### Q: Was wenn ein Dokument keinen passenden Präfix hat?
+**A:** Neuen Präfix vorschlagen und dokumentieren. Konsistenz ist wichtig.
+
+### Q: Soll ich bestehende Dokumente umbenennen?
+**A:** Schrittweise, wenn sinnvoll. Nicht alles auf einmal, sondern bei Gelegenheit.
+
+### Q: Was mit sehr langen Dateinamen?
+**A:** Prägnant bleiben, aber selbsterklärend. Abkürzungen vermeiden, wenn möglich.
+
+### Q: Soll ich Datum oder Versionsnummer verwenden?
+**A:** Datum für Reports/Analysen, Versionsnummer für Features/Specs, keine Versionierung für aktuelle Dokumente.
+
+---
+
+**Letzte Aktualisierung:** [Datum]  
+**Verantwortlich:** Stephan (Dokumentation & Struktur)
+