4.3 KiB
Retrospektive — Epic 4: Frontend-Backend-Integration (Phase 3)
Datum: 2026-03-12 Epic: Epic 4 — Frontend-Backend-Integration (Phase 3) Status: Abgeschlossen — 3/3 Stories erledigt Facilitiert von: Bob (🏃 Scrum Master)
1. Epic-Zusammenfassung
Ziel: LangGraph liest JSON-Blueprint und baut Graph dynamisch. WebSocket-Events pulsieren Nodes im Canvas. Finaler Output erscheint im Frontend.
Stories abgeschlossen:
- ✅ 4.1: Dynamischer Graph-Builder aus Blueprint-JSON
- ✅ 4.2: WebSocket-Agent-Events integrieren
- ✅ 4.3: Konferenzzimmer — Live-Execution-UI
2. Was lief gut? (Keep)
Technische Entscheidungen:
dynamic_graph_builder.pyals eigenständiges Modul nebengraph_builder.pyerlaubt parallelen Betrieb — Phase 1 und Phase 3 koexistieren, bis Phase 1 depreciert wirdinterrupt_before-Mechanismus von LangGraph konnte nahtlos für God Mode (Phase 4) vorbereitet werden — keine Architektur-Änderung nötig- WebSocket
broadcast_event()mit automatischer Dead-Connection-Bereinigung ist robust gegen Verbindungsabbrüche useCouncilWebSocketHook kapselt alle WS-Logik — Konferenzzimmer-Komponente ist davon vollständig entkoppelt_resolve_tools()im dynamischen Graph-Builder mit Factory-Pattern ermöglicht saubere optionale Tool-Bindung
Prozess:
- Story 4.1 (Graph-Builder) wurde vor 4.2 (WebSocket) abgeschlossen — Backend-Grundlage vor Frontend-Integration war richtig
- Tests für
dynamic_graph_builder.pymit gemockten LLMs laufen schnell und zuverlässig in CI
3. Was lief nicht gut? (Drop / Improve)
Technisch:
_connections-Dict im WebSocket-Modul ist nicht persistent — bei Serverabsturz verlieren alle Clients ihre Verbindung ohne Wiederherstellungs-Mechanismusrun_in_executor(None, graph.invoke, state)überträgt Fehler aus dem Thread-Pool nicht sauber an den asyncio Event-Loop — Exception-Handling verbessern- Blueprint-Validierung beim
/api/councils/{id}/run-Endpunkt prüft nicht, ob das Blueprint einen gültigen Entry-Point hat
Prozess:
test_builds_cyclic_graphintest_dynamic_graph_builder.pyhätte auch Edge-Cases (leere Kondition, Selbst-Loops) abdecken können
4. Lernerkenntnisse
| Erkenntnis | Anwendung in kommenden Epics |
|---|---|
LangGraph-interrupt_before ist einfach zu aktivieren — einfach Node-Namen in Liste übergeben |
Für God Mode in Epic 5 Story 5.3 direkt genutzt |
WebSocket-Events sollten immer run_id mitschicken |
Clients können bei Multi-Tab-Szenarien Events filtern |
| Blueprint-Fehler erst beim Run zu melden ist zu spät | Pre-Run-Validierung in Konferenzzimmer vor POST /run hinzufügen |
_invoke_with_tools als gemeinsames Muster für Agent- und Critic-Nodes |
God-Mode-Nodes in Epic 5 nutzen denselben Wrapper |
5. Aktionspunkte für kommende Epics
| Priorität | Aktionspunkt | Verantwortlich | Status |
|---|---|---|---|
| Hoch | Pre-Run Blueprint-Validierung im Frontend (Entry-Point vorhanden?) | Dev | Backlog |
| Mittel | Exception-Handling für Thread-Pool-Fehler in run_council_async() |
Dev | Backlog |
| Niedrig | WebSocket-Reconnect-Logik im useCouncilWebSocket-Hook |
Dev | Backlog |
6. Nächstes Epic (Preview: Epic 5)
Epic 5 — Tools & God Mode erweitert die in Epic 4 gelegte Integrationsgrundlage:
- Tavily-Web-Suche und PDF-Reader als Agent-Tools (Stories 5.1, 5.2 ✅)
- God Mode mit
interrupt_beforefür Human-in-the-Loop (Story 5.3 ✅) - Run-Verlauf und History-API (Story 5.4 ✅)
Kritische Brücke: Die in Epic 4 etablierte WebSocket-Verbindung (run_paused-Event) ist die Grundlage für das God-Mode-Overlay in Epic 5.
Bob (Scrum Master): "Epic 4 war das technisch anspruchsvollste Epic — die Integration zweier komplexer Systeme (LangGraph + React Flow) über WebSockets. Dass alle NFRs (< 500 ms WS-Latenz, dynamischer Graph ab Phase 3) eingehalten wurden, ist ein großer Erfolg. Die Factory-Umstellung für Tools hat außerdem die Code-Qualität messbar verbessert!"