# Review Findings — Technische Vorbereitung

Reviewer-Perspektive: Greenfield-Projekt, keine einzige Zeile Code vorhanden. Prüfung auf Umsetzbarkeit, Vorbereitung, Blockaden, Größe und Aufbaureihenfolge.

## Gesamtbewertung

Die Vorarbeit ist bemerkenswert gründlich. 19 User Stories, 3 Setup Tasks, definierte Personas, ein konsistentes Token-Modell, durchgängige Privacy-Berücksichtigung, und ein sauberer iterativer Refinement-Prozess über 29 Iterationen. Die Story-Qualität ist hoch — klare ACs, testbar, konsistente Terminologie, Edge Cases abgedeckt.

Trotzdem gibt es konkrete Probleme, die vor der Umsetzung gelöst werden sollten.

---

## Finding 1: Fehlende Dependencies auf Setup-Tasks (kritisch)

**Keine einzige User Story hat eine Dependency auf T-1 oder T-2.** Das ist für ein Greenfield-Projekt ein echtes Problem.

US-1 sagt `Dependencies: None` — aber man kann keinen Event-Endpoint schreiben, wenn es kein Spring Boot Projekt, keine Datenbank-Verbindung und kein Frontend-Routing gibt. Faktisch hängen **alle** Backend-Stories von T-1 und T-2 ab, und **alle** Frontend-Stories mindestens von T-1.

**Empfehlung:** Entweder explizite Dependencies auf T-1/T-2 in die Stories aufnehmen, oder einen deutlichen Hinweis in der Doku, dass T-1 und T-2 die implizite Voraussetzung für alles sind. Sonst ist die Dependency-Darstellung irreführend.

---

## Finding 2: Fehlende Setup-Tasks für ein Greenfield-Projekt

T-1 scaffoldet die Verzeichnisstruktur, T-2 macht Dockerfile + Config. Aber es fehlt:

- **DB-Migration-Setup** (Flyway oder Liquibase) — wo/wann werden Tabellen angelegt? T-2 sagt nur nebulös „migrations run on startup or are documented". Für Hexagonal Architecture mit Spring Boot ist das ein echter Architektur-Schritt.
- **SPA-Routing-Grundgerüst** — Svelte braucht ein Router-Setup (z.B. svelte-routing oder SvelteKit Routing). Ohne das kann keine einzige Page-Story umgesetzt werden.
- **API-Client-Layer im Frontend** — Wie ruft das Frontend die REST API? Fetch-Wrapper? Generierter Client? Das ist bei Hexagonal Architecture eine bewusste Entscheidung.
- **Test-Infrastruktur** — CLAUDE.md verlangt TDD. Aber weder T-1 noch eine andere Task definiert, dass z.B. Testcontainers für Integrationstests, Vitest für Frontend-Tests, oder eine Test-DB-Strategie aufgesetzt wird. T-1 sagt nur „both projects build successfully" — das reicht nicht als Test-Fundament.

**Empfehlung:** Mindestens ein T-4 (oder T-1 erweitern) das explizit abdeckt:

- DB-Migration-Framework aufsetzen + erste leere Migration
- SPA-Router konfigurieren
- Test-Infrastruktur (Unit + Integration) aufsetzen und mit einer Smoke-Test-Suite verifizieren

---

## Finding 3: US-1 ist für ein Greenfield-Projekt die „Monster-Story"

US-1 hat 8 ACs, aber implizit beinhaltet sie den gesamten Erstaufbau des Stacks:

| Schicht | Was US-1 implizit verlangt |
|---------|---------------------------|
| DB | Event-Tabelle, Migration, Flyway-Setup |
| Backend | Entity, Repository, Service, REST Controller, UUID-Generation, JSON-Serialisierung |
| Frontend | Formular, Validierung, API-Call, localStorage-Management, Routing zur Erstellungsseite, Redirect zur Event-Page |
| Integration | Frontend↔Backend Verbindung, CORS-Konfiguration |

Jedes nachfolgende Ticket (US-2, US-3, ...) profitiert davon, dass US-1 diesen ganzen Unterbau bereits etabliert hat. Aber US-1 selbst trägt die gesamte Last.

**Empfehlung:** Entweder:

- (a) Das bewusst akzeptieren und US-1 als „Durchstich-Story" betrachten, die naturgemäß größer ist — aber das explizit dokumentieren.
- (b) US-1 splitten in US-1a (Backend: Event erstellen + API Endpoint + DB) und US-1b (Frontend: Formular + localStorage + Redirect). Das ermöglicht unabhängiges Arbeiten und kleinere Reviews.

---

## Finding 4: Forward-References in ACs — unklar, was wann implementiert wird

Mehrere Stories referenzieren Features, die erst durch spätere Stories existieren:

| Story | AC referenziert | Problem |
|-------|----------------|---------|
| US-2 AC 5 | „If the event has been cancelled (US-18)..." | US-18 kommt erst viel später |
| US-2 AC 6 | „deleted after expiry per US-12" / US-19 | US-12/US-19 kommen später |
| US-3 AC 10 | „not possible if cancelled (US-18)" | US-18 kommt später |
| US-8 AC 9 | „STATUS:CANCELLED" (US-18) | US-18 kommt später |
| US-12 AC 2 | „stored header images (US-16)" | US-16 kommt später |

Technisch ist das kein Dependency-Problem — man kann diese ACs weglassen und nachrüsten. Aber es ist nirgends dokumentiert, ob:

- diese ACs bei der Erstimplementierung schon umgesetzt werden sollen (dann SIND es Dependencies), oder
- sie erst nachgerüstet werden, wenn die referenzierte Story fertig ist (dann sollten sie als solche markiert sein).

**Empfehlung:** Jede Forward-Reference als `[deferred until US-X]` markieren oder die ACs in die referenzierte Story verschieben. Zum Beispiel: Der cancelled-state-Display gehört logisch in US-18, nicht in US-2 — US-18 sollte dann ein AC haben: „US-2 zeigt cancelled state an."

---

## Finding 5: Split-Kandidaten

### US-10 (Update Messages) — 11 ACs, zwei verschiedene Concerns

US-10 enthält zwei klar trennbare Funktionen:

1. **Nachrichten posten, anzeigen, löschen** (AC 1-5, 10-11) — Backend + Frontend
2. **„New update" Badge/Indicator** (AC 5-9) — rein localStorage-basiert

**Empfehlung:** Splitten in:

- US-10a: Organizer kann Update-Nachrichten posten und löschen; Gäste sehen sie chronologisch
- US-10b: „Neue Updates"-Badge basierend auf localStorage-Tracking

### US-16 (Unsplash Header Image) — 11 ACs, externe Dependency

US-16 ist komplex (Server-Proxy, Unsplash API, lokale Bildspeicherung, Attribution, Graceful Degradation, Volume Mount). Aber es ist ein kohärentes Feature und lässt sich schwer sinnvoll vertikal splitten. Kein Split nötig, aber als eine der aufwändigeren Stories markieren.

### US-7 (Local Event Overview) — 11 ACs, drei Datenquellen + Entry-Removal

Grenzwertig. Die Entry-Removal-Logik (AC 9-10: drei verschiedene Verhaltensweisen für Organizer/Guest/Bookmark-only Einträge) ist ein eigener Mini-Workflow. Optional splitten, aber nicht zwingend.

---

## Finding 6: Q-5 (CI/CD Platform) ist noch offen

T-3 kann nicht umgesetzt werden. Das blockiert zwar nichts am Anfang, sollte aber geklärt werden, bevor die erste Story fertig ist — sonst hat man Code ohne Pipeline.

---

## Finding 7: Fehlende Implementierungsreihenfolge / Phasenplan

Dependencies existieren, aber ein expliziter Phasenplan fehlt. Für ein Greenfield-Projekt ist eine klare Reihenfolge essenziell, weil jede Phase auf der vorherigen aufbaut. Basierend auf dem Dependency-Graph:

```
Phase 0 — Infrastruktur
  T-1 → T-2 (→ T-3 nach Q-5)

Phase 1 — Minimal Viable Flow (End-to-End Durchstich)
  US-1 (Event erstellen)
  US-2 (Event anzeigen)
  US-3 (RSVP)

Phase 2 — Organizer-Fähigkeiten
  US-4 (Gästeliste verwalten)
  US-5 (Event bearbeiten)

Phase 3 — Client-seitige Features (parallelisierbar)
  US-6 (Bookmark)
  US-7 (Lokale Übersicht)
  US-17 (Dark/Light Mode)

Phase 4 — Zusatzfeatures (parallelisierbar)
  US-8 (Kalender .ics/webcal)
  US-9 (Change Highlighting) — braucht US-5
  US-10 (Update Messages)
  US-11 (QR Code)

Phase 5 — Server-Infrastruktur
  US-12 (Auto-Deletion)
  US-13 (Max Events Limit)

Phase 6 — Design & Customization
  US-14 (PWA)
  US-15 (Color Themes)
  US-16 (Unsplash Header Image)

Phase 7 — Event-Lifecycle (braucht soliden Grundflow)
  US-18 (Event Cancellation)
  US-19 (Event Deletion)
```

**Anmerkung zu Phase 7:** US-18 und US-19 haben zwar nur `Dependencies: US-1`, sind aber in der Praxis erst sinnvoll testbar, wenn US-2, US-3, US-4, US-5 existieren. Die reine Dependency-Analyse unterschätzt das.

---

## Finding 8: Kleinere Inkonsistenzen

### US-14 (PWA) sagt `Dependencies: None`

Ein Service Worker braucht Assets zum Cachen. US-14 ist technisch unabhängig, aber praktisch erst sinnvoll, wenn es Pages gibt (US-1, US-2, US-7). Sollte mindestens als Hinweis in den Notes stehen.

### US-7 sagt `Dependencies: None`

Rendert aus localStorage-Daten, die von US-1, US-3, US-6 geschrieben werden. Ohne diese Quellen hat US-7 nur den Empty State. Technisch korrekt als „None", aber irreführend — ein Hinweis wie „praktisch erst nach US-1/US-3/US-6 sinnvoll testbar" wäre hilfreich.

### US-15 und US-17 Wechselwirkung

Beide Notes erwähnen das Problem (Event-Themes vs. Dark/Light Mode), aber kein AC definiert konkretes Verhalten. Was passiert, wenn ein helles Event-Theme in Dark Mode angezeigt wird? Das ist kein Story-Problem, aber eine offene Design-Frage, die VOR der Implementierung geklärt sein sollte.

---

## Zusammenfassung der Handlungsempfehlungen

| Prio | Thema | Handlung |
|------|-------|----------|
| **Hoch** | Dependencies auf T-1/T-2 | Explizit machen oder dokumentieren |
| **Hoch** | Fehlende Setup-Tasks | T-4 für DB-Migrations, Router, Test-Infra |
| **Hoch** | Forward-References | Als `[deferred until US-X]` markieren |
| **Hoch** | Phasenplan | Explizite Reihenfolge dokumentieren |
| **Mittel** | US-1 Größe | Als Durchstich akzeptieren ODER splitten |
| **Mittel** | US-10 splitten | Post/Display vs. Badge trennen |
| **Mittel** | Q-5 klären | CI/CD Platform entscheiden |
| **Niedrig** | US-7/US-14 „None" Dependencies | Notes ergänzen |
| **Niedrig** | US-15/US-17 Wechselwirkung | Design-Entscheidung treffen |
