initial commit

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

.ralph/review-findings/answers.md

@@ -0,0 +1,5 @@
+# Answers
+
+<!-- This file is YOUR file. Write your answers to open questions from questions.md here. -->
+<!-- Ralph will pick them up in the next iteration. -->
+

.ralph/review-findings/instructions.md

@@ -0,0 +1,111 @@
+# Ralph Loop — User Story Refinement
+
+You are an autonomous agent running inside a Ralph Loop. Your job is to refine existing user stories and setup tasks until they are implementation-ready.
+
+## CRITICAL RULE: One Task Per Iteration
+
+You MUST perform exactly ONE task per iteration. Not two, not "a few small ones", not "all remaining items". ONE.
+
+After completing your single task:
+1. Append a short summary of what you did to `{{RUN_DIR}}/progress.txt`.
+2. Stop. Do not look for more work. Do not "while I'm at it" anything.
+
+The only exception: if the single task you perform reveals that the work is complete, you may additionally output `<promise>COMPLETE</promise>`.
+
+## Startup: Read Project State
+
+At the start of every iteration, read these files in order:
+
+1. `{{RUN_DIR}}/progress.txt` — what previous iterations did (your memory across iterations).
+2. `{{RUN_DIR}}/overseer.md` — notes from the overseer. Items under `## Action Required` have highest priority.
+3. `{{RUN_DIR}}/answers.md` — check if the human answered any open questions.
+4. `CLAUDE.md` — project statutes and principles.
+5. `Ideen.md` — project vision, features, and binding design decisions.
+6. `spec/userstories.md` — the user stories you are refining.
+7. `spec/setup-tasks.md` — technical setup tasks.
+8. `spec/personas.md` — persona definitions.
+9. `{{RUN_DIR}}/questions.md` — open and resolved questions.
+
+## Task Selection (Priority Order)
+
+Pick the FIRST applicable task from this list. Do that ONE task, then stop.
+
+### Priority 1: Overseer action items
+If `{{RUN_DIR}}/overseer.md` has items under `## Action Required`, address the FIRST one. Note in `{{RUN_DIR}}/progress.txt` which item you addressed and how. Do NOT modify `{{RUN_DIR}}/overseer.md`.
+
+### Priority 2: Process answers
+If `{{RUN_DIR}}/answers.md` contains an answer: move the corresponding question from `## Open` to `## Resolved` in `{{RUN_DIR}}/questions.md` (include the answer), update the affected story or task accordingly, and remove the processed answer from `{{RUN_DIR}}/answers.md`. Process ONE answer, then stop.
+
+### Priority 3: Raise a question
+If you discover an ambiguity, inconsistency, or assumption that requires a human decision — and no existing question in `{{RUN_DIR}}/questions.md` already covers it — add ONE question to `{{RUN_DIR}}/questions.md` under `## Open`. Then stop. Do NOT attempt to resolve it yourself.
+
+### Priority 4: Refine one story or task
+Pick the next story or task that could be improved. Refinement means:
+
+- **Dependencies:** Add a `**Dependencies:**` field after Notes listing story/task IDs that must be implemented first (e.g. `US-1, T-1`). Use `None` if the story is independent. Do NOT simply extract cross-references already mentioned in the Notes or Acceptance Criteria — those are hints, not the full picture. You must independently reason about each story: what data, API endpoints, UI components, or infrastructure does this story require at runtime that another story or task provides? Think about it from scratch for every story, even if the existing text mentions no other stories at all. Dependencies are stories whose output this story structurally requires — not merely stories that mention related concepts.
+- **Consistency:** Does the story use the correct token terminology? Are cross-references to other stories accurate? Are localStorage key names consistent across stories?
+- **Completeness:** Are there missing edge cases? Missing acceptance criteria? Unclear behavior?
+- **Scope:** Is the story too large for a single implementation effort? If so, propose a split.
+- **Testability:** Is every acceptance criterion concrete and verifiable?
+- **Alignment:** Does the story align with `Ideen.md` decisions, `CLAUDE.md` statutes, and `spec/personas.md` capabilities/limitations?
+- **Overlap:** Does the story duplicate behavior already covered by another story?
+- **Setup tasks:** Are the setup tasks complete and aligned with the decided tech stack and architecture?
+
+Work through stories in order (US-1, US-2, ... US-17, then T-1, T-2, T-3). Track which stories you have already reviewed in `{{RUN_DIR}}/progress.txt` so you don't re-review them. If a story needs no changes, note it as "reviewed, no changes needed" in `{{RUN_DIR}}/progress.txt` and stop — that counts as your one task for this iteration.
+
+### Priority 5: Cross-cutting review
+After all individual stories and tasks have been reviewed, do ONE cross-cutting check:
+- Are all features from `Ideen.md` covered?
+- Are persona capabilities/limitations consistent with what the stories allow?
+- Is the status counter at the top of `spec/userstories.md` accurate?
+- Are there any cross-story inconsistencies that individual reviews missed?
+
+### Priority 6: Complete
+If all stories and tasks are refined, all cross-cutting checks pass, all answers are processed, and all overseer action items are addressed:
+Output `<promise>COMPLETE</promise>` and stop.
+
+## File Ownership
+
+Respect these boundaries strictly:
+
+| File | Owner | You may... |
+|------|-------|------------|
+| `spec/userstories.md` | Ralph | Read and write |
+| `spec/setup-tasks.md` | Ralph | Read and write |
+| `spec/personas.md` | Ralph | Read and write |
+| `{{RUN_DIR}}/progress.txt` | Ralph | Read and append |
+| `{{RUN_DIR}}/questions.md` | Ralph | Read and write |
+| `{{RUN_DIR}}/answers.md` | Human | **Read only.** Only remove entries you have already processed. |
+| `{{RUN_DIR}}/overseer.md` | Overseer | **Read only.** Never modify. |
+| `Ideen.md` | Human | **Read only.** Never modify. |
+| `CLAUDE.md` | Human | **Read only.** Never modify. |
+
+## Handling Uncertainty
+
+You MUST NOT make architectural or design decisions on your own. Check the "Architekturentscheidungen die NOCH NICHT getroffen wurden" section in `Ideen.md`.
+
+- **If a question affects the core of a story** (answer could require a rewrite): Do NOT change the story. Add a question to `{{RUN_DIR}}/questions.md` instead.
+- **If a question only affects a detail** (only individual criteria would change): Mark it with `⚠️ ASSUMPTION:` in the Notes section and add a question to `{{RUN_DIR}}/questions.md`.
+
+### Question Format
+
+```
+### Q-{number}: {short title}
+
+**Context:** {why this question came up}
+**Affects:** {which stories/tasks are affected}
+**Options:** {possible answers, if applicable}
+```
+
+## Rules
+
+- ONE task per iteration. No exceptions.
+- Derive all content strictly from `Ideen.md`. Do not invent features.
+- Respect binding decisions in `Ideen.md` ("Getroffene Designentscheidungen").
+- Respect project statutes in `CLAUDE.md`.
+- Keep stories small and focused. One story = one user-facing capability.
+- Acceptance criteria must be concrete and testable.
+- Write everything in English (per statutes: code and documentation in English).
+- Use the correct persona roles: "event organizer" vs "guest" vs "self-hoster" vs "user" (when both roles apply).
+- After modifying any story, update the status counters at the top of `spec/userstories.md`.
+- Always append a summary of your single task to `{{RUN_DIR}}/progress.txt` before stopping.

.ralph/review-findings/meta.md

@@ -0,0 +1,7 @@
+# Run: review-findings
+
+- **Created**: 2026-03-03
+- **Description**: Addressing review findings — overseer action items from the story-refinement review (setup-task dependencies, forward-references, story splits, implementation phases).
+- **Model**: opus
+- **Max iterations**: 20
+- **Status**: Completed

.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.

.ralph/review-findings/progress.txt

@@ -0,0 +1,151 @@
+# Ralph Loop Progress Log
+# Each iteration appends its findings and decisions here.
+
+# Previous refinement phase (29 iterations) archived to progress-refinement-phase-1.txt.
+# Starting phase 2: addressing review findings from review-findings.md.
+
+## Iteration 1 (Phase 2)
+**Task:** Overseer action item #1 — Add setup-task dependencies to all user stories that require project infrastructure.
+**Changes made to userstories.md:**
+- US-1: Dependencies: None → T-1, T-2 (backend API + DB)
+- US-2: US-1 → US-1, T-1, T-2 (backend API)
+- US-3: US-2 → US-2, T-1, T-2 (backend API + DB)
+- US-4: US-1 → US-1, T-1, T-2 (backend API)
+- US-5: US-1 → US-1, T-1, T-2 (backend API)
+- US-6: US-2 → US-2, T-1 (frontend only, localStorage-based)
+- US-7: None → None, added note that T-1 frontend scaffold is needed to be practically implementable (purely client-side)
+- US-8: US-2 → US-2, T-1, T-2 (server-side .ics generation)
+- US-9: US-2, US-5 → US-2, US-5, T-1, T-2 (server-side field tracking)
+- US-10: US-1, US-2 → US-1, US-2, T-1, T-2 (backend API)
+- US-11: US-2 → US-2, T-1, T-2 (server-side QR generation)
+- US-12: US-1 → US-1, T-1, T-2 (server-side scheduled job)
+- US-13: US-1 → US-1, T-1, T-2 (server-side config)
+- US-14: None → T-1 (frontend infrastructure: manifest + service worker)
+- US-15: US-1, US-2 → US-1, US-2, T-1, T-2 (server-side theme persistence)
+- US-16: US-1, US-2 → US-1, US-2, T-1, T-2 (server-side proxy + image storage)
+- US-17: None → None, added note that T-1 frontend scaffold is needed to be practically implementable (purely client-side CSS toggle)
+- US-18: US-1 → US-1, T-1, T-2 (server-side cancellation state)
+- US-19: US-1 → US-1, T-1, T-2 (server-side deletion)
+
+## Iteration 2 (Phase 2)
+**Task:** Overseer action item #2 — Create T-4: Development infrastructure setup.
+**Changes made:**
+- Created T-4 in `setup-tasks.md` with 6 ACs covering: DB migration framework (Flyway/Liquibase), SPA router for Svelte, API client layer, backend test infrastructure (JUnit 5 + Testcontainers), frontend test infrastructure (Vitest), and runnable test commands. T-4 depends on T-1 and T-2.
+- Updated all user story dependencies from T-1/T-2 to T-4 (since T-4 transitively includes both):
+  - US-1: T-1, T-2 → T-4
+  - US-2: US-1, T-1, T-2 → US-1, T-4
+  - US-3: US-2, T-1, T-2 → US-2, T-4
+  - US-4: US-1, T-1, T-2 → US-1, T-4
+  - US-5: US-1, T-1, T-2 → US-1, T-4
+  - US-6: US-2, T-1 → US-2, T-4
+  - US-8: US-2, T-1, T-2 → US-2, T-4
+  - US-9: US-2, US-5, T-1, T-2 → US-2, US-5, T-4
+  - US-10: US-1, US-2, T-1, T-2 → US-1, US-2, T-4
+  - US-11: US-2, T-1, T-2 → US-2, T-4
+  - US-12: US-1, T-1, T-2 → US-1, T-4
+  - US-13: US-1, T-1, T-2 → US-1, T-4
+  - US-14: T-1 → T-4
+  - US-15: US-1, US-2, T-1, T-2 → US-1, US-2, T-4
+  - US-16: US-1, US-2, T-1, T-2 → US-1, US-2, T-4
+  - US-18: US-1, T-1, T-2 → US-1, T-4
+  - US-19: US-1, T-1, T-2 → US-1, T-4
+- US-7 and US-17 remain at Dependencies: None; updated their notes to reference T-4 instead of T-1.
+- T-3 left unchanged (setup task, not a user story; its T-1/T-2 dependencies are direct, not via T-4).
+
+## Iteration 3 (Phase 2)
+**Task:** Overseer action item #3 — Mark forward-references in acceptance criteria as deferred.
+**Changes made to userstories.md:**
+- US-2 AC 5: Added `[deferred until US-18 is implemented]` to the cancelled-state criterion
+- US-2 AC 6: Added `[deferred until US-12 is implemented]` and `[deferred until US-19 is implemented]` to the event-not-found criterion (also added the US-19 deletion scenario which was missing from the parenthetical examples)
+- US-3 AC 11: Added `[deferred until US-18 is implemented]` to the cancelled-event RSVP block criterion
+- US-8 AC 9: Added `[deferred until US-18 is implemented]` to the STATUS:CANCELLED calendar criterion
+- US-12 AC 2: Added `[deferred until US-16 is implemented]` to the stored header images reference in the cleanup criterion
+All ACs remain in place as documentation of complete behavior — only marked so implementors know they are not part of the initial story scope.
+
+## Iteration 4 (Phase 2)
+**Task:** Overseer action item #4 — Split US-10 (Update Messages) into two stories.
+**Changes made:**
+- Split US-10 into US-10a and US-10b in `userstories.md`:
+  - US-10a (Post update messages as organizer): server-side feature — posting, displaying, and deleting update messages. 6 ACs. Dependencies: US-1, US-2, T-4.
+  - US-10b (New-update indicator for guests): client-side read-state tracking — badge/indicator for unread updates via localStorage. 5 ACs. Dependencies: US-10a.
+- Updated cross-references in US-12 AC 2 and US-19 AC 3: "(US-10)" → "(US-10a)"
+- Updated `personas.md`:
+  - Event Organizer: US-10 → US-10a in capabilities and Appears in
+  - Guest: Split "See organizer update messages (US-10)" into US-10a (as reader) and US-10b; updated Appears in
+- Updated status counter: 19 → 20 total stories (and remaining)
+
+## Iteration 5 (Phase 2)
+**Task:** Overseer action item #5 — Add practical-dependency notes to US-7 and US-14.
+**Changes made to userstories.md:**
+- US-7: Extended the existing practical-implementability note to also explain that the story is only meaningfully testable after US-1, US-3, or US-6 populate localStorage with event data (without those, only the empty state can be tested).
+- US-14: Added a note clarifying that while the story depends only on T-4 structurally, the service worker and manifest are only meaningfully testable after other stories (e.g. US-2, US-7) provide actual pages and assets to cache.
+
+## Iteration 6 (Phase 2)
+**Task:** Overseer action item #6 — Create implementation phase plan document.
+**Changes made:**
+- Created `implementation-phases.md` with 6 phases (Phase 0–5) grouping all setup tasks and user stories by dependency order:
+  - Phase 0: Project Infrastructure (T-1 → T-2 → T-4, T-3 parallel)
+  - Phase 1: Core Event Flow vertical slice (US-1 → US-2 → US-3, strictly sequential)
+  - Phase 2: Organizer Management & Event Lifecycle (US-4, US-5, US-12, US-13, US-18, US-19 — parallelizable, all depend on US-1)
+  - Phase 3: Enhanced Event Page Features (US-6, US-8, US-9, US-10a, US-10b, US-11 — mostly parallelizable, depend on US-2)
+  - Phase 4: Visual Customization (US-15, US-16 — depend on US-1 + US-2)
+  - Phase 5: App Shell & PWA (US-7, US-14, US-17 — minimal structural deps, practically need earlier phases)
+- Included: recommended order within each phase, parallelizability notes, deferred AC tracking table, and ASCII dependency graph
+- Noted that US-17 can be pulled earlier (Phase 2/3 timeframe) to facilitate US-15's dark/light mode interaction
+- Noted T-3 is blocked on Q-5 resolution
+- All 6 overseer action items are now addressed.
+
+## Iteration 7 (Phase 2)
+**Task:** Process answer to Q-5 (CI/CD platform choice).
+**Answer received:** (a) Gitea — project optimized for Gitea, only Gitea infrastructure used.
+**Changes made:**
+- Moved Q-5 from Open to Resolved in `questions.md` with the answer included.
+- Updated T-3 in `setup-tasks.md`: removed ⚠️ ASSUMPTION warning, specified Gitea Actions (`.gitea/workflows/`), Gitea container registry, and updated ACs and notes to reflect the concrete platform choice.
+- Removed processed answer from `answers.md`.
+
+## Iteration 8 (Phase 2)
+**Task:** Review US-10a (Post update messages as organizer) — created in Phase 2 iteration 4 but never individually reviewed.
+**Changes made to userstories.md:**
+- Added two missing acceptance criteria for organizer token authentication and server-side enforcement:
+  - "If the organizer token is absent or invalid, the compose and delete UI is not shown and the server rejects any attempt to post or delete update messages"
+  - "No account or additional authentication step is required beyond the organizer token"
+- This aligns US-10a with the auth pattern established by all other organizer stories (US-4 ACs 2/6/7, US-5 ACs 3/7/8, US-18 ACs 9/10/12, US-19 ACs 6/7/9). Without these ACs, an implementor might not enforce server-side auth on the update message endpoints.
+- All other aspects verified: Dependencies correct (US-1 for organizer token + event, US-2 for public display, T-4 for infrastructure). Token terminology consistent. All ACs (now 8) concrete and testable. Cancelled-event behavior documented in Notes (posting not blocked, only expiry blocks). No overlap with US-10b (client-side read tracking), US-9 (field change highlighting). Aligned with Ideen.md and personas. Scope appropriate (single cohesive capability).
+- Remaining unreviewed Phase 2 creations: US-10b, T-4.
+
+## Iteration 9 (Phase 2)
+**Task:** Review US-10b (New-update indicator for guests) — created in Phase 2 iteration 4 but never individually reviewed.
+**Result:** Reviewed, no changes needed.
+- Dependencies correct: US-10a is the sole dependency. US-10a transitively provides US-1, US-2, and T-4. Unlike US-7/US-17 (which have zero story deps and need practical-dependency notes), US-10b has a direct story dependency covering all transitive needs.
+- Consistency verified: Token terminology correct ("event token" for localStorage keying). `updates_last_seen_at` key explicitly distinct from US-9's `last_seen_at`. Cross-references to US-10a and US-9 accurate.
+- Completeness verified: Edge cases (organizer deletes newest update, expired event, no updates, first visit) all handled correctly by existing ACs or produce correct behavior without additional criteria.
+- Scope appropriate: Small, focused, single cohesive capability (client-side read-state tracking).
+- All 5 ACs concrete and testable.
+- Aligned with Ideen.md ("pro Device wird via LocalStorage gemerkt"), CLAUDE.md statutes, and personas.md.
+- No overlap with US-9 (field change highlighting vs. free-form announcement awareness).
+- Remaining unreviewed Phase 2 creations: T-4.
+
+## Iteration 10 (Phase 2)
+**Task:** Review T-4 (Development infrastructure setup) — created in Phase 2 iteration 2 but never individually reviewed.
+**Result:** Reviewed, no changes needed.
+- Dependencies correct: T-1 (project scaffolds) and T-2 (DB connection config/Dockerfile) are both needed. T-1 provides the empty projects to build upon; T-2 establishes the PostgreSQL datasource configuration that the migration framework wires into.
+- Consistency verified: Cross-references accurate — notes correctly state all user stories depend on T-4 transitively. Tech stack references (Flyway/Liquibase, JUnit 5, Testcontainers, Vitest) match Ideen.md decisions.
+- Completeness verified: All 6 ACs match the overseer's original action item #2 specification exactly (migration framework, SPA router, API client, backend test infra, frontend test infra, runnable commands). No missing concerns for the "empty scaffold → TDD-ready" gap.
+- Scope appropriate: Single cohesive setup task — all items are development foundation work that logically belongs together.
+- All 6 ACs concrete and testable (specific tools, commands, and observable outcomes).
+- Aligned with CLAUDE.md's TDD mandate and Ideen.md's decided tech stack.
+- No overlap with T-1 (scaffolds), T-2 (deployment), or T-3 (CI/CD).
+- All Phase 2 creations (US-10a, US-10b, T-4) are now reviewed.
+
+## Iteration 11 (Phase 2)
+**Task:** Cross-cutting review — verify consistency after Phase 2 changes.
+**Checks performed:**
+1. Status counter: 20 total, 0 complete, 20 remaining — matches actual story count. ✓
+2. Persona consistency: US-10a/US-10b split correctly reflected in Event Organizer and Guest personas (capabilities and Appears in). ✓
+3. Deferred AC references: All 6 deferred markers use consistent format `[deferred until US-X is implemented]`, AC numbers match current story text, referenced stories are correct. ✓
+4. Dependency graph in implementation-phases.md: All 20 stories + 4 tasks verified against ASCII graph — all edges and transitive relationships accurate. ✓
+5. localStorage key consistency: All keys (event data, organizer token, RSVP data, bookmarks, `last_seen_at`, `updates_last_seen_at`, dark/light preference) are distinct and consistently referenced across stories. ✓
+6. Token terminology: "event token" and "organizer token" used consistently across all 20 stories. ✓
+**Finding:** implementation-phases.md had stale Q-5 references — Phase 0 intro said "T-3 may run in parallel with Phase 1 once Q-5 is resolved" and table said "Blocked on Q-5." Q-5 was resolved in iteration 7 (Gitea). Updated both references to reflect resolved state.
+**No other cross-story inconsistencies found.** All Phase 2 changes (dependency additions, T-4 creation, US-10 split, deferred AC markers, practical-dependency notes) are internally consistent.
+- Cross-cutting checks completed for Phase 2: consistency verified ✓. Remaining cross-cutting checks from Phase 1 (Ideen.md coverage, persona consistency, status counter) were re-verified as part of this check — all still valid after Phase 2 changes.

.ralph/review-findings/questions.md

@@ -0,0 +1,66 @@
+# Open Questions
+
+<!-- Questions that need human decision before certain user stories can be written or finalized. -->
+<!-- Format: Each question gets a unique ID, status (open/resolved), and affected stories if known. -->
+
+## Open
+
+(No open questions.)
+
+## Resolved
+
+### Q-5: CI/CD platform choice
+
+**Context:** T-3 originally assumed Gitea as the CI/CD platform (Gitea Actions with `.gitea/workflows/`, publishing to Gitea's container registry). However, this choice is not documented in Ideen.md or CLAUDE.md. The CI/CD platform determines the workflow file format, container registry configuration, and available pipeline features. The platform-independent requirements (run tests, build, publish on success) are clear, but the implementation depends on where the repository is hosted.
+**Affects:** T-3
+**Options:**
+- (a) Gitea Actions (`.gitea/workflows/`, Gitea container registry) — if the project is hosted on a Gitea instance
+- (b) GitHub Actions (`.github/workflows/`, GitHub Container Registry or Docker Hub) — if the project is hosted on GitHub
+- (c) GitLab CI (`.gitlab-ci.yml`, GitLab Container Registry) — if the project is hosted on GitLab
+- (d) Other platform or defer CI/CD to the self-hoster's responsibility
+
+**Answer:** (a) Gitea. The project shall be optimized for Gitea. Only Gitea infrastructure will be used — Gitea Actions for CI/CD pipelines, Gitea container registry for Docker image publishing.
+
+### Q-1: Event page customization scope ("Designbar")
+
+**Context:** Ideen.md mentions under the event landing page description: "Irgendwie auch Designbar, sofern man das will" (somehow also designable, if you want to). This clearly implies some form of visual customization for event pages, but the scope is entirely undefined. The answer fundamentally changes what the user story would look like — from a trivial theme picker to a complex layout system.
+**Affects:** US-15 (written based on this answer).
+**Options:**
+- (a) The organizer can choose from a small set of predefined themes or color schemes when creating/editing an event
+- (b) The organizer can set a custom accent color and/or upload a header image for the event page
+- (c) More elaborate customization (custom CSS, layout options, etc.)
+- (d) "Designbar" was aspirational / nice-to-have and is deferred or out of scope for the initial version
+
+**Answer:** (a) predefined themes, plus as a separate feature the organizer can search/select a header image from Unsplash (server-proxied to maintain privacy). US-15 written accordingly.
+
+### Q-2: PWA start URL target
+
+**Context:** US-14 (PWA installability) requires a `start_url` in the web app manifest — the page shown when a user launches the installed app from their home screen. The natural candidates are the local event overview (US-7) or a generic landing/home page.
+**Affects:** US-7 (route changed to `/`), US-14 (start URL updated).
+**Options:**
+- (a) Start URL points to the local event overview (`/my-events`) — returning users immediately see their tracked events
+- (b) Start URL points to a home/landing page that offers both event creation and a link to the local overview
+
+**Answer:** The local event overview lives at the root page `/`. That is also the start URL. The page should show a project header/branding and the list of events the user attends or watches underneath. US-7 and US-14 updated accordingly.
+
+### Q-3: Progressive enhancement requirement (no-JavaScript content rendering)
+
+**Context:** Several user stories originally included acceptance criteria requiring content to be renderable without JavaScript (e.g. US-2: "core content must be in server-rendered HTML", US-10: "reading updates does not require JavaScript"). This presupposes a progressive enhancement / server-side rendering strategy — but the rendering strategy is explicitly listed as undecided in Ideen.md. The app is also specified as a PWA, which typically implies heavy JavaScript usage. These two forces are in tension: progressive enhancement favors server-rendered HTML enhanced by JS, while a PWA/SPA approach favors client-side rendering. The answer determines whether stories need "works without JS" acceptance criteria or not.
+**Affects:** US-2, US-10, US-11, and all page-rendering stories. Assumption notes removed from affected stories.
+**Options:**
+- (a) Progressive enhancement is a hard requirement: all core content (event details, attendee list, update messages) must be in server-rendered HTML; JavaScript enhances the experience but is not required to view content
+- (b) JavaScript-dependent rendering is acceptable: the app can be a SPA with client-side rendering, as long as it meets accessibility standards (screen reader compatibility, semantic HTML in the DOM, etc.)
+- (c) Hybrid: critical public pages (event landing page) must work without JavaScript for maximum reach; internal pages (local overview, organizer views) may require JavaScript
+
+**Answer:** SPA with PWA, no server-side rendering. Classic frontend + RESTful API. JavaScript-dependent rendering is acceptable. Accessibility must be ensured through proper semantic HTML and ARIA attributes in the client-rendered DOM. Assumption notes cleaned up in US-2, US-10, and US-11.
+
+### Q-4: Organizer authentication mechanism (token format and transmission)
+
+**Context:** Multiple user stories (US-1, US-4, US-5) assume that organizer authentication works via a secret token stored in localStorage on the device where the event was created. This is a reasonable default in the no-account design, but Ideen.md explicitly lists "Wie genau die Organizer-Authentifizierung technisch funktioniert (Token-Format, Übertragungsweg)" as an undecided architectural decision. Alternative approaches — such as a special organizer URL with the secret embedded — would have different UX and security trade-offs. A URL-based approach would enable cross-device organizer access (the organizer can share or bookmark the management link) while a localStorage-based approach is device-bound but keeps the secret out of URLs, browser history, and referrer headers.
+**Affects:** US-1, US-4, US-5, and indirectly US-10. Assumption notes removed from affected stories.
+**Options:**
+- (a) localStorage-based: the server returns a secret organizer token after event creation; the client stores it in localStorage; organizer access is device-bound
+- (b) URL-based: the server returns a special organizer URL containing the secret (e.g. `/events/{id}/manage/{secret}`); the organizer bookmarks or shares this URL; no localStorage needed for auth
+- (c) Hybrid: the organizer receives a secret URL after creation, and the app also stores the token in localStorage for convenience; either mechanism grants access
+
+**Answer:** Confirmed localStorage-based approach. The user suggested the event's unique ID could double as the organizer access token but left the door open for separation. Recommendation applied: the organizer secret token is kept separate from the public event ID, because the event link is designed to be shared in group chats — using a single token for both guest access and organizer management would allow any link recipient to edit or delete event data. Existing story acceptance criteria (which already assumed separate tokens) are confirmed correct. Assumption notes removed from US-1, US-4, US-5.

.ralph/review-findings/run.log

@@ -0,0 +1 @@
+=== Run completed (archived) | model=opus | max=20 ===