# 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."*