initial commit

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

.ralph/review-findings/overseer.md

@@ -0,0 +1,25 @@
+# Overseer Notes
+
+<!-- This file is written by the human's primary Claude session (the "overseer"). -->
+<!-- Ralph reads this file each iteration and must address any items marked as ACTION REQUIRED. -->
+<!-- Items marked as OBSERVATION are informational — Ralph may use them but is not required to act. -->
+
+## Action Required
+
+- **Add setup-task dependencies to all user stories that require project infrastructure.** Currently no user story references T-1 or T-2 as a dependency. This is misleading for a greenfield project where no code exists yet. Every story that requires backend infrastructure (Spring Boot project, DB connection) must depend on T-1 and T-2. Every story that requires only frontend infrastructure must depend on at least T-1. Stories that are purely client-side with no build requirement (e.g. US-7 reading localStorage, US-17 CSS toggle) may remain at `Dependencies: None` but should get a note explaining they require the frontend scaffold from T-1 to be practically implementable. Review each story individually and add the appropriate setup-task dependencies.
+
+- **Create T-4: Development infrastructure setup.** T-1 scaffolds empty projects, T-2 creates the Dockerfile and DB connection config. But there is no task for the development foundation needed before the first user story can be implemented with TDD (as required by CLAUDE.md). T-4 should cover: (1) DB migration framework setup (Flyway or Liquibase) with a first empty migration, (2) SPA router configuration for Svelte, (3) API client layer in the frontend (fetch wrapper or similar), (4) Test infrastructure for both backend (JUnit + integration test setup, e.g. Testcontainers) and frontend (Vitest). T-4 depends on T-1 and T-2. All user stories that previously depended on T-1/T-2 should now depend on T-4 instead (since T-4 transitively includes T-1 and T-2).
+
+- **Mark forward-references in acceptance criteria as deferred.** Several stories contain ACs that reference features from stories that will be implemented later. These must be explicitly marked so implementors know they are not part of the initial story scope. The specific forward-references to mark: US-2 AC 5 (cancelled state → deferred until US-18), US-2 AC 6 (deleted after expiry → deferred until US-12, and "or US-19" deferred until US-19), US-3 AC 10 (cancelled event block → deferred until US-18), US-8 AC 9 (STATUS:CANCELLED → deferred until US-18), US-12 AC 2 (stored header images → deferred until US-16). Use the format `[deferred until US-X is implemented]` inline in the AC text. Do NOT remove the ACs — they remain as documentation of the complete behavior, just clearly marked as not part of the initial implementation scope.
+
+- **Split US-10 (Update Messages) into two stories.** US-10 contains two separable concerns with 11 ACs total: (a) posting, displaying, and deleting update messages (organizer posts, public display, deletion — the server-side feature), and (b) the "new update" badge/indicator based on localStorage tracking (the client-side read-state feature). Split into US-10a (Update Messages: post, display, delete) and US-10b (Update Messages: new-update indicator). US-10b depends on US-10a. Update the status counter, personas, and any cross-references in other stories accordingly.
+
+- **Add practical-dependency notes to US-7 and US-14.** Both stories say `Dependencies: None` which is technically correct (US-7 renders from localStorage, US-14 is PWA infrastructure). But for a greenfield project this is misleading. US-7 is only meaningfully testable after US-1, US-3, or US-6 populate localStorage with data. US-14's service worker needs actual assets and pages to cache. Add a note to each story explaining when it becomes practically useful, without changing the Dependencies field. Example: "Note: This story has no structural dependencies but is only meaningfully testable after [US-X, US-Y] provide data/content."
+
+- **Create an implementation phase plan document.** Based on the dependency graph across all stories and setup tasks, create a new file `implementation-phases.md` that documents a recommended implementation order grouped into phases. The phases should respect all declared dependencies, group parallelizable work, and reflect the practical reality that some stories (e.g. US-18, US-19) are only meaningfully testable after their transitive dependencies exist. Include a note that Phase 0 (setup tasks) must complete before any user story work begins.
+
+## Observations
+
+- US-1 is implicitly the "durchstich" (vertical slice) story that bootstraps the entire stack: DB table, backend endpoint, frontend form, localStorage, routing. This is expected for the first story in a greenfield project. No split necessary, but implementors should be aware it will take significantly longer than subsequent stories. If it turns out to be too large during implementation, it can be split into backend-only and frontend-only at that point.
+- Q-5 (CI/CD platform) remains open and blocks T-3. This should be resolved before the first story is complete, so code has a pipeline from the start.
+- US-15 (event color themes) and US-17 (dark/light mode) have a noted interaction: event themes must remain readable in both dark and light mode. Both stories already mention this in their notes, but no AC defines concrete behavior. This is a design decision that should be made before implementing either story.