Add missing Epic 1 and Epic 2 retrospective files

Co-authored-by: Kenearos <86194771+Kenearos@users.noreply.github.com>

_bmad-output/implementation-artifacts/epic-1-retro-2026-03-12.md

@@ -0,0 +1,89 @@
+# Retrospektive — Epic 1: Projekt-Setup & Infrastruktur
+
+<!-- 🏃 Facilitiert von BMAD SM Skill — Agent: Bob (Scrum Master) -->
+<!-- Skill Command: /bmad-agent-bmm-sm → [ER] Epic Retrospective -->
+<!-- Workflow: _bmad/bmm/workflows/4-implementation/retrospective/workflow.yaml -->
+
+**Datum:** 2026-03-12
+**Epic:** Epic 1 — Projekt-Setup & Infrastruktur
+**Status:** Abgeschlossen — 3/3 Stories erledigt
+**Facilitiert von:** Bob (🏃 Scrum Master)
+
+---
+
+## 1. Epic-Zusammenfassung
+
+**Ziel:** Vollständig konfiguriertes, lauffähiges Entwicklungsumfeld mit Docker Compose, PostgreSQL, FastAPI-Skeleton und Next.js-Skeleton.
+
+**Stories abgeschlossen:**
+- ✅ 1.1: Docker-Compose-Umgebung aufsetzen
+- ✅ 1.2: Backend-Python-Umgebung & Requirements
+- ✅ 1.3: Datenbank-Migrationen mit Alembic
+
+---
+
+## 2. Was lief gut? (Keep)
+
+**Technische Entscheidungen:**
+- **Docker Compose** mit drei Services (db, api, frontend) und Health-Checks gewährleistet fehlerfreies Hochfahren — kein Race-Condition zwischen PostgreSQL und FastAPI
+- **Async-First-Design** durchgehend: `asyncpg` als DB-Treiber, `aiosqlite` für Tests, `pytest-asyncio` mit `asyncio_mode = auto` — das zahlt sich in allen folgenden Epics aus
+- **Dual-Database-Support**: SQLite für lokale Entwicklung, PostgreSQL für Docker/Produktion — senkt die Einstiegshürde für Entwickler
+- **Alembic-Migrationen** von Anfang an konfiguriert — Schema-Evolution ist nie ein Nachgedanke
+- **Named Volumes** (`postgres_data`, `chroma_data`) verhindern Datenverlust bei Container-Neustarts
+
+**Prozess:**
+- Story-Reihenfolge war optimal: Docker → Requirements → Migrationen (jede Story baut auf der vorherigen auf)
+- `.env.example` und `.gitignore` von Anfang an korrekt — keine versehentlichen Secret-Commits
+- `pytest.ini` mit `asyncio_mode = auto` spart in allen folgenden Stories Boilerplate bei async Tests
+
+---
+
+## 3. Was lief nicht gut? (Drop / Improve)
+
+**Technisch:**
+- `requirements.txt` verwendet `>=`-Versionen statt gepinnte Versionen — Reproduzierbarkeit bei längerer Projektlaufzeit gefährdet. Ein `pip freeze > requirements.lock` wäre sinnvoll
+- `check_same_thread=False` bei SQLite deaktiviert Thread-Sicherheit — akzeptabel für Tests, aber muss dokumentiert bleiben
+- Uvicorn `--reload` ist im Dockerfile hard-coded — für Produktions-Builds sollte ein separates Dockerfile oder Multi-Stage-Build verwendet werden
+- Keine explizite Connection-Pool-Konfiguration für SQLAlchemy — Defaults könnten bei Last nicht ausreichen
+
+**Prozess:**
+- Keine automatische CI-Pipeline eingerichtet (GitHub Actions) — Tests müssen manuell ausgeführt werden
+- `alembic.ini` hat die `sqlalchemy.url` hard-coded — sollte aus Umgebungsvariablen gelesen werden (bereits in `env.py` gefixt)
+
+---
+
+## 4. Lernerkenntnisse
+
+| Erkenntnis | Anwendung in kommenden Epics |
+|------------|------------------------------|
+| Async-First-Design vermeidet teure Refactoring-Runden später | Alle Agent-Nodes in Epic 2 als async-kompatibel designen |
+| SQLite als Test-DB ermöglicht In-Memory-Tests ohne Docker | Alle Backend-Tests in Epics 2–5 nutzen `aiosqlite` |
+| Docker Health-Checks sind essentiell bei Multi-Service-Setups | Für Produktion noch Readiness-Probes ergänzen |
+| `pytest-asyncio` `auto`-Mode spart pro Test 2 Zeilen Boilerplate | Konsistent in allen 125+ Backend-Tests verwendet |
+
+---
+
+## 5. Aktionspunkte für kommende Epics
+
+| Priorität | Aktionspunkt | Verantwortlich | Status |
+|-----------|-------------|----------------|--------|
+| Hoch | Agent-Nodes als reine Funktionen implementieren (State rein → Dict raus) | Dev | Umgesetzt in Epic 2 |
+| Mittel | `requirements.lock` mit gepinnten Versionen erstellen | Dev | Backlog |
+| Mittel | Produktions-Dockerfile ohne `--reload` erstellen | Dev | Backlog |
+| Niedrig | CI-Pipeline mit GitHub Actions aufsetzen | Dev | Backlog |
+
+---
+
+## 6. Nächstes Epic (Preview: Epic 2)
+
+**Epic 2 — LangGraph Engine Backend** baut direkt auf der Infrastruktur aus Epic 1 auf:
+- CouncilState TypedDict mit `operator.add`-Reducern (Story 2.1 ✅)
+- Master-, Critic- und Writer-Agent als reine Node-Funktionen (Stories 2.2–2.4 ✅)
+- Hartcodierter LangGraph-Graph mit zyklischer Routing-Logik (Story 2.5 ✅)
+- FastAPI-Endpunkte für Council-Runs (Story 2.6 ✅)
+
+**Wichtige Brücke:** Die async-Architektur aus Epic 1 (asyncpg, pytest-asyncio) ist das Fundament für alle Backend-Services in Epic 2.
+
+---
+
+*Bob (Scrum Master): "Epic 1 war das stille Fundament-Epic — keine sichtbaren Features, aber absolut kritisch für alles Folgende. Die Entscheidung für Async-First und Dual-Database hat sich in allen 5 Epics ausgezahlt. Saubere Infrastruktur von Anfang an ist kein Luxus, sondern Notwendigkeit."*