From 528147aa6ebdc21309a479c07c743bb5a717e61e Mon Sep 17 00:00:00 2001 From: ValueOn AG Date: Wed, 19 Nov 2025 09:52:05 +0100 Subject: [PATCH] training data --- training/README.md | 135 +++++++ training/handover_agenda_sync.md | 221 ++++++++++++ training/handover_einarbeitungsplan.md | 416 +++++++++++++++++++++ training/handover_naming_convention.md | 478 +++++++++++++++++++++++++ 4 files changed, 1250 insertions(+) create mode 100644 training/README.md create mode 100644 training/handover_agenda_sync.md create mode 100644 training/handover_einarbeitungsplan.md create mode 100644 training/handover_naming_convention.md diff --git a/training/README.md b/training/README.md new file mode 100644 index 0000000..16f0bb7 --- /dev/null +++ b/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! 🚀** + diff --git a/training/handover_agenda_sync.md b/training/handover_agenda_sync.md new file mode 100644 index 0000000..4c5908e --- /dev/null +++ b/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` + diff --git a/training/handover_einarbeitungsplan.md b/training/handover_einarbeitungsplan.md new file mode 100644 index 0000000..aaf4800 --- /dev/null +++ b/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! 🚀** + diff --git a/training/handover_naming_convention.md b/training/handover_naming_convention.md new file mode 100644 index 0000000..7064533 --- /dev/null +++ b/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) +