fete/review-findings.md

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