89 lines
4.6 KiB
Markdown
89 lines
4.6 KiB
Markdown
# 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."*
|