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

.ralph/story-refinement/answers.md

@@ -0,0 +1,4 @@
+# Answers
+
+<!-- Human answers to open questions. Ralph processes these one per iteration. -->
+<!-- This run is archived — no pending answers. -->

.ralph/story-refinement/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/story-refinement/meta.md

@@ -0,0 +1,7 @@
+# Run: story-refinement
+
+- **Created**: 2026-03-02
+- **Description**: Initial user story refinement — reviewing and improving all user stories and setup tasks for implementation readiness.
+- **Model**: opus
+- **Max iterations**: 20
+- **Status**: Completed (29 iterations)

.ralph/story-refinement/overseer.md

@@ -0,0 +1,11 @@
+# Overseer Notes
+
+<!-- This file is written by the overseer session. Ralph reads it but never modifies it. -->
+
+## Action Required
+
+(No action items — this run is archived.)
+
+## Observations
+
+(No observations.)

.ralph/story-refinement/progress.txt

@@ -0,0 +1,160 @@
+# Ralph Loop Progress Log
+# Each iteration appends its findings and decisions here.
+
+# Previous phase (story writing) completed with 17 user stories and 3 setup tasks.
+# Full history archived. Starting fresh for refinement phase.
+
+## Iteration 1 — US-1 reviewed
+- Added missing honeypot field acceptance criterion to the event creation form, consistent with Ideen.md's "Honeypot-Felder in Formularen" and US-3's existing honeypot criterion. Event creation is an open, unauthenticated form and needs the same bot protection.
+- Clarified that the server returns BOTH the event token and the organizer token in the creation response (was ambiguous — criterion said organizer token is "stored in localStorage" without explicitly stating the server returns it).
+
+## Iteration 2 — US-2 reviewed
+- Reviewed US-2 (View event landing page), no changes needed. Token terminology is correct, all criteria are concrete and testable, edge cases (expired event, event not found, zero attendees) are covered, no external resources requirement is present, and scope is appropriate as the base event page with other stories adding their own elements independently.
+
+## Iteration 3 — US-3 reviewed
+- Fixed a cross-story consistency issue in the localStorage data AC: US-1 and US-6 both explicitly store "event token, title, and date" in localStorage, but US-3 only mentioned "event title and date" alongside the RSVP data, omitting the event token. Added the event token to the AC for consistency. The event token is needed so US-7 can link back to the event page. All other aspects of US-3 are solid: token terminology correct, Ideen.md alignment verified (RSVP flow, honeypot, duplicate protection, acceptable spam risk), scope appropriate, all ACs testable, edge cases covered (pre-fill, update existing entry, expiry block).
+
+## Iteration 4 — US-4 reviewed
+- Reviewed US-4 (Manage guest list as organizer), no changes needed. Token terminology correct (organizer token, localStorage). All 7 ACs are concrete and testable. Edge cases covered: access control (token present/absent), deletion with immediate update, no guessable URL. Anonymous "not attending" entries (US-3 allows optional name) are implicitly covered by "all RSVPs." Expiry behavior is consistent — US-4 doesn't restrict by expiry, organizer view works as long as data exists, US-12 handles cleanup. Cross-references to US-1 and Q-4 are accurate. Scope appropriate (separate from US-5 editing). Aligned with Ideen.md ("Einsicht angemeldete Gäste, kann bei Bedarf Einträge entfernen") and persona capabilities.
+
+## Iteration 5 — US-5 reviewed
+- Added `**Dependencies:** US-1` field. US-5 requires an existing event and the organizer token in localStorage, both established by US-1. References to US-12 (expiry cleanup) and US-9 (change highlighting) are informational cross-references, not runtime dependencies.
+- All other aspects verified and solid: token terminology correct, editable fields match US-1 creation fields exactly, no honeypot needed (form is already behind organizer token auth), expiry manipulation edge case covered with confirmation warning, all 9 ACs are concrete and testable, scope appropriate (separate from US-4 guest management, US-9 change highlighting, US-10 update messages), aligned with Ideen.md and Q-4 resolution.
+- Noted for later: when the organizer edits title/date, the locally cached values in localStorage (used by US-7's overview) should be refreshed. This is already acknowledged in US-7's notes as "refreshed when the user next visits the event page." The specific refresh mechanism will be addressed during US-7 review.
+
+## Iteration 6 — US-6 reviewed
+- Added `**Dependencies:** US-2` field. US-6 places a bookmark action on the event page (US-2), which provides both the UI surface and the event data (token, title, date) that gets stored in localStorage. No direct dependency on US-1 (that's transitive through US-2).
+- All other aspects verified and solid: token terminology correct, localStorage data format consistent with US-1 and US-3 ("event token, event title, and event date"), edge cases covered (expired events, toggle on/off, RSVP independence, no server contact), all 7 ACs concrete and testable, scope appropriate, aligned with Ideen.md ("rein lokal, kein Serverkontakt, kein Name nötig") and privacy statutes.
+- Note: US-1 through US-4 were reviewed before the Dependencies convention was established in iteration 5. Missing Dependencies fields for those stories should be addressed during cross-cutting review.
+
+## Iteration 7 — Overseer action item: Event cancellation as explicit feature
+- Addressed the overseer's action item: "Event cancellation must be an explicit feature, not a side effect of editing the expiry date."
+- Created US-18 (Cancel an event as organizer) with 12 acceptance criteria covering: dedicated cancel action, optional cancellation message, optional expiry adjustment, confirmation step, cancelled state display, RSVP blocking, one-way state transition (no un-cancel), organizer token auth.
+- Updated US-5: Removed cancellation-via-expiry framing. The confirmation warning for setting expiry to today/past now explains data deletion consequences without implying cancellation. Notes updated to reference US-18 as the dedicated cancellation mechanism.
+- Updated US-2: Added new AC for cancelled state display (shows "cancelled" with cancellation message, no RSVP actions). Updated notes to explain cancelled-state requirement.
+- Updated US-3: Added new AC blocking RSVP submission on cancelled events (references US-18).
+- Updated personas.md: Event Organizer capabilities now list US-5 (edit) and US-18 (cancel) separately instead of the old "canceling by shortening expiry (US-5)". Added US-18 to Appears in.
+- Updated status counter: 17 → 18 total stories, 17 → 18 remaining.
+
+## Iteration 8 — US-7 reviewed
+- Added `**Dependencies:** None` field. US-7 lives at the root page `/` and renders entirely from localStorage. It reads data written by US-1 (organizer tokens), US-3 (RSVP records), and US-6 (bookmarks), but handles the absence of all data gracefully with an explicit empty state (AC 8). No other story's runtime output is required for US-7 to function.
+- All other aspects verified and solid: token terminology correct, localStorage data format consistent with US-1/US-3/US-6 (all store event token, title, date), cross-references accurate, all 11 ACs concrete and testable, edge cases well covered (empty state, expired events, deleted events, entry removal for all three sources, confirmation for organizer token loss). Cancelled events are server-side state — US-7 is purely client-side and correctly doesn't attempt to display cancellation status (US-2 handles that when the user clicks through). Scope appropriate for one implementation effort. Aligned with Ideen.md and Q-2 resolution.
+
+## Iteration 9 — US-8 reviewed
+- Added `**Dependencies:** US-2` field. US-8 places .ics download and webcal:// subscription links on the event page (US-2), which provides the UI surface and the event data to generate calendar entries.
+- Added a new AC for cancelled events: when an event is cancelled (US-18), the .ics file and webcal:// feed must include `STATUS:CANCELLED` so subscribed calendar applications reflect the cancellation on their next sync. This is especially important for webcal:// subscribers — the entire point of the subscription is live updates, and cancellation is the most critical update a calendar subscriber needs to see.
+- All other aspects verified and solid: token terminology correct (event token used for UID derivation and URL), all 9 ACs (now 10) concrete and testable, scope appropriate, no overlap with other stories, aligned with Ideen.md ("Kalender-Integration: .ics-Download + optional webcal:// für Live-Updates bei Änderungen") and privacy statutes (server-side generation, no external services, no PII logging).
+
+## Iteration 10 — Overseer action item: Explicit event deletion feature
+- Addressed the overseer's second action item: "Explicit event deletion feature."
+- Created US-19 (Delete an event as organizer) with 9 acceptance criteria covering: dedicated delete action (separate from edit and cancel), confirmation warning about irreversibility, permanent deletion of all associated data (RSVPs, update messages, field-change metadata, header images, cancellation state), organizer token auth, works regardless of event state (active/cancelled/expired).
+- Updated US-5: Removed the two ACs that allowed setting expiry to today/past with a confirmation warning. Replaced with a single AC enforcing that the expiry date can only be set to a future date, with a validation message directing to US-19 for immediate deletion. Updated notes to explain the rationale.
+- Updated personas.md: Event Organizer capabilities now list US-19. Added US-19 to "Appears in."
+- Updated status counter: 18 → 19 total stories, 18 → 19 remaining.
+
+## Iteration 11 — US-9 reviewed
+- Added `**Dependencies:** US-2, US-5` field. US-9 requires the event page (US-2) as its display surface where highlights are rendered, and US-5 (edit event details) as the trigger that causes the server to record which fields changed and when. Without US-5, there are no edits to highlight.
+- All other aspects verified and solid: token terminology correct, localStorage key `last_seen_at` is distinct from US-10's `updates_last_seen_at`, all 8 ACs concrete and testable, edge cases covered (first visit, multiple successive edits, no edits since creation), scope appropriate, no overlap with US-10 (free-form messages vs. field change highlighting), aligned with Ideen.md and privacy statutes (no visit data transmitted to server).
+
+## Iteration 12 — US-10 reviewed
+- Added `**Dependencies:** US-1, US-2` field. US-10 requires US-1 for event creation and the organizer token in localStorage (needed to access the organizer view and post messages), and US-2 for the public event page where update messages are displayed to guests.
+- Added explicit note about cancelled event behavior: posting update messages is not blocked by cancellation, only by expiry (AC 4). This is intentional — US-18 explicitly blocks RSVPs and allows editing the cancellation message, while update messages serve a different purpose (stream of announcements vs. static cancellation reason). The organizer may need to communicate post-cancellation (e.g. rescheduling info).
+- All other aspects verified and solid: token terminology correct, localStorage key `updates_last_seen_at` distinct from US-9's `last_seen_at`, cross-references accurate, all 11 ACs concrete and testable, scope appropriate, no overlap with US-9 (free-form messages vs. field change highlighting), aligned with Ideen.md and privacy statutes.
+
+## Iteration 13 — US-11 reviewed
+- Added `**Dependencies:** US-2` field. US-11 places the QR code on the event page (US-2), which provides both the display surface and the public event URL that the QR code encodes.
+- All other aspects verified and solid: token terminology correct ("public event URL", "event link"), all 7 ACs concrete and testable, server-side generation explicitly required (no external services — consistent with privacy statutes), cancelled event behavior doesn't need special QR handling (QR encodes the URL, US-2 handles cancelled display when scanned), expired event QR availability explicitly covered (AC 7), scope appropriate, no overlap with other stories, aligned with Ideen.md ("QR Code generieren") and persona capabilities (both organizer and guest have QR code access in personas.md).
+
+## Iteration 14 — US-12 reviewed
+- Added `**Dependencies:** US-1` field. US-12 is a background cleanup process that deletes expired events. It requires events to exist (created by US-1). The AC references data from US-3 (RSVPs), US-9 (field-change metadata), US-10 (update messages), and US-16 (header images), but US-12 doesn't structurally depend on those stories — it cascades whatever associated data exists. If those features aren't implemented yet, there's simply nothing extra to cascade.
+- All other aspects verified and solid: token terminology correct, all 7 ACs concrete and testable, edge cases covered (extending expiry before it passes via US-5, post-deletion URL behavior, no PII logging during deletion, timing guarantee). Cancelled events (US-18) still have an expiry date and are cleaned up normally — the cancellation state is part of the event record and is implicitly deleted. No overlap with US-19 (manual deletion vs. automatic cleanup). Aligned with Ideen.md ("Ablaufdatum als Pflichtfeld, nach dem alle gespeicherten Daten gelöscht werden") and privacy statutes.
+
+## Iteration 15 — US-13 reviewed
+- Added `**Dependencies:** US-1` field. US-13 enforces a server-side limit on event creation — it modifies the event creation flow (US-1) by rejecting new events when the cap is reached. Without the event creation endpoint, there is nothing to apply the limit against.
+- All other aspects verified and solid: no token terminology involved (server config feature), ACs are concrete and testable, edge cases covered (expired events excluded from count, unlimited default when env var unset, server-side enforcement). Cancelled events (US-18) correctly count toward the limit since they still consume server resources and remain accessible until expiry — this is self-evident from the "non-expired" criterion. Deleted events (US-19) obviously don't count since the record is removed. No overlap with other stories. Aligned with Ideen.md ("Max aktive Events als serverseitige Konfiguration (env variable)") and CLAUDE.md deployment model.
+
+## Iteration 16 — US-14 reviewed
+- Added `**Dependencies:** None` field. US-14 is PWA infrastructure (manifest, service worker, icons) that can be set up independently. The start_url reference to `/` (US-7's content) is informational — the PWA shell doesn't structurally depend on the content at the root page.
+- All other aspects verified and solid: no token terminology involved, all 7 ACs concrete and testable, service worker caching framed as "fast loading" without over-promising offline functionality (appropriate for SPA + REST API), no external resources requirement consistent with privacy statutes, start URL and SPA references match Q-2 and Q-3 resolutions, scope appropriate for single implementation effort, no overlap with other stories. Aligned with Ideen.md ("Soll als PWA im Browser laufen").
+
+## Iteration 17 — US-15 reviewed
+- Added `**Dependencies:** US-1, US-2` field. US-15 adds a theme picker to the event creation form (US-1) and renders the selected theme on the event page (US-2). Both are structurally required at runtime. US-5 (editing) is referenced as a secondary entry point for changing the theme but is not a strict runtime dependency — US-15 works for newly created events without US-5.
+- Added a note about the dark/light mode interaction: predefined themes must remain readable and visually coherent regardless of whether the user has dark or light mode active. This addresses the overseer's observation about potential visual conflicts between US-15 and US-17, and cross-references the matching note in US-17.
+- All other aspects verified and solid: token terminology not applicable, all 7 ACs concrete and testable, default theme fallback covered (AC 2), scope appropriate, no overlap with US-16 (header images) or US-17 (dark/light mode), aligned with Ideen.md and Q-1 resolution.
+
+## Iteration 19 — US-17 reviewed
+- Added `**Dependencies:** None` field. US-17 is purely client-side UI infrastructure (CSS theming + localStorage toggle for dark/light mode preference). It doesn't structurally depend on any other story's runtime output.
+- All other aspects verified and solid: no token terminology involved, all 8 ACs concrete and testable, scope boundary with US-15 is explicitly delineated (AC 5-6: app-level dark/light mode vs. event-level color themes), no overlap with other stories, cross-reference to US-15 in Notes is accurate and reciprocal (US-15 notes reference US-17 interaction, added in iteration 17). WCAG AA contrast requirement aligns with CLAUDE.md accessibility statute. Scope appropriate for single implementation effort.
+- Alignment note: US-17 doesn't trace to an explicit Ideen.md feature (no mention of dark/light mode), but is consistent with the PWA "feels like a native app" goal and CLAUDE.md's "accessibility is a baseline requirement" statute. No action needed — the story was established during the writing phase and aligns with project principles.
+
+## Iteration 20 — US-18 reviewed
+- Added "must be in the future" constraint to AC 3 (optional expiry date adjustment during cancellation). The overseer's directive explicitly included this constraint, but the AC as written only described the purpose ("to control how long the cancellation notice remains visible") without stating the rule. Now consistent with US-5's future-only expiry enforcement and US-19's role as the immediate-removal mechanism.
+- All other aspects verified and solid: Dependencies field present (US-1), token terminology correct, all 12 ACs concrete and testable, cross-references verified against US-2/US-3/US-5/US-8/US-19/personas.md, scope appropriate (single cohesive capability), no overlap with US-19, edge cases covered (one-way state transition, organizer auth, editable cancellation message post-cancellation).
+
+## Iteration 18 — US-16 reviewed
+- Added `**Dependencies:** US-1, US-2` field. US-16 integrates into the event creation form (US-1) as the primary entry point for selecting a header image, and displays the selected image on the event page (US-2). Both are structurally required at runtime. US-5 is referenced as a secondary entry point for changing the image during editing but is not a strict runtime dependency — US-16 works for newly created events without US-5 (same pattern as US-15).
+- All other aspects verified and solid: token terminology correct (event token referenced indirectly through US-12 cleanup), all 11 ACs concrete and testable, edge cases well covered (no API key graceful degradation, API key removed after images stored, cleanup on expiry, persistent volume requirement). Cancelled events don't need special handling — the header image continues to display since the event page still renders per US-18/US-2. No overlap with US-15 (color themes vs. header images). Aligned with Ideen.md (Q-1 resolution), CLAUDE.md privacy statutes (server-proxied Unsplash), and personas (organizer capability). Consistent with US-12 and US-19 which both reference "stored header images (US-16)" for deletion cascading.
+
+## Iteration 21 — US-19 reviewed
+- Added a new AC for post-deletion UI behavior: after the server confirms deletion, the app must remove the event's organizer token and metadata from localStorage and redirect the organizer to the root page (`/`). Without this, the organizer would be stranded on a broken page with stale localStorage data. This follows the same pattern as the confirmation/cleanup behavior in US-7 (AC 9-10) but is proactive rather than reactive — the organizer triggered the deletion, so the app should handle cleanup immediately rather than waiting for the next visit.
+- All other aspects verified and solid: Dependencies field already present (US-1) — correct, the organizer token established by US-1 is the structural requirement. Token terminology correct. All 10 ACs (now 10, was 9) concrete and testable. Edge cases covered: works regardless of event state (active/cancelled/expired), confirmation warning, no PII logging. Cross-references to US-5, US-18, US-2, US-12, US-9, US-10, US-16 are accurate. Scope appropriate (single capability, distinct from US-18 cancel). No overlap with other stories. Aligned with privacy statutes and overseer directive.
+- Noted for cross-cutting review: US-7 AC 7 parenthetical "(deleted per US-12)" should also reference US-19, since manual organizer deletion is an equally valid reason an event might return "not found" from the server.
+
+## Iteration 22 — T-1 reviewed
+
+- Added `**Dependencies:** None` field.
+- Added GPL LICENSE file to AC 4 (shared top-level files). CLAUDE.md explicitly states the project is GPL-licensed — a repository scaffold should include the license file. The previous list (README, Dockerfile, CLAUDE.md, .gitignore) omitted it.
+- All other aspects verified and solid: tech stack matches Ideen.md exactly (Java latest LTS, Spring Boot, Maven, hexagonal/onion architecture, Svelte with Vite), the Dockerfile placeholder in T-1 is reasonable alongside T-2 which gives it real multi-stage build content, .gitignore coverage is appropriately scoped for both Java/Maven and Node/Svelte ecosystems, "both projects build successfully with no source code" is a clear, testable criterion for the empty scaffold.
+
+## Iteration 23 — T-2 reviewed
+- Added `**Dependencies:** T-1` field. T-2's multi-stage Dockerfile builds from the `backend/` and `frontend/` directories scaffolded by T-1, and the README it documents in is also created by T-1.
+- All other aspects verified and solid: ACs are concrete and testable, PostgreSQL via env var consistent with Ideen.md ("PostgreSQL, wird separat gehostet... verbindet sich per Konfiguration (env variable) mit der externen Postgres-Instanz"), runtime env vars align with US-13 (MAX_ACTIVE_EVENTS) and US-16 (Unsplash API key), docker-compose example aligns with CLAUDE.md deployment statute ("docker-compose example in the README is sufficient"), health-check endpoint is standard Docker practice. The "migrations run on startup or are documented" phrasing correctly leaves the implementation strategy open. No overlap with T-1 (T-1 creates a placeholder Dockerfile, T-2 gives it real multi-stage build content — already noted in iteration 22). US-16's persistent volume requirement will be added to the docker-compose example when US-16 is implemented — not T-2's scope.
+
+## Iteration 24 — T-3 reviewed
+- Added `**Dependencies:** T-1, T-2` field. T-3 needs T-1 for the repository structure (both projects to test/build) and T-2 for the Dockerfile (used by the pipeline to build and publish the container image).
+- Identified an undocumented assumption: T-3 originally assumed Gitea as the CI/CD platform (Gitea Actions, `.gitea/workflows/`, Gitea container registry). This choice is not documented in Ideen.md or CLAUDE.md. Generalized the task title and ACs to be platform-independent (removed "Gitea" from title and AC references), flagged with ⚠️ ASSUMPTION in Notes, and raised Q-5 for the human to decide on the CI/CD platform.
+- Core ACs (test, build, publish on success, fail visibly on errors) are solid, concrete, and testable regardless of platform choice. The platform-specific details (workflow format, registry config) will be filled in once Q-5 is resolved.
+
+## Iteration 25 — Cross-cutting review: deferred consistency fixes
+- Added `**Dependencies:** None` to US-1 (foundational story, no dependencies).
+- Added `**Dependencies:** US-1` to US-2 (requires an event to exist for display).
+- Added `**Dependencies:** US-2` to US-3 (RSVP form is placed on the event page).
+- Added `**Dependencies:** US-1` to US-4 (requires organizer token and event existence; consistent with US-5's dependency pattern).
+- These four stories were reviewed before the Dependencies convention was established in iteration 5 (noted in iteration 6 for cross-cutting resolution).
+- Fixed US-7 AC 7: changed "(deleted per US-12)" to "(deleted per US-12 or US-19)" — manual organizer deletion (US-19) is an equally valid reason an event might return "not found" (noted in iteration 21 for cross-cutting resolution).
+- All 19 stories and 3 tasks now have Dependencies fields. All deferred items from individual reviews are resolved.
+
+## Iteration 26 — Cross-cutting review #1: Ideen.md feature coverage
+- Systematically mapped every feature, requirement, and design decision from Ideen.md to user stories and setup tasks.
+- **Grundsätze**: PWA (US-14), self-hostable (T-2, US-13), privacy (embedded across all stories), no registration/login (US-1, US-3), localStorage for local data (US-1, US-3, US-6, US-7, US-9, US-10, US-17). ✓
+- **Core idea/Zielbild**: Event creation (US-1), sharing via link (US-1/US-2), RSVP (US-3). ✓
+- **Gedankensammlung features**: Landing page (US-2), one link per event (US-1/US-2), designable (US-15/US-16), RSVP with name + server+localStorage (US-3), duplicate protection (US-3), bookmark/follow (US-6), organizer update (US-5), organizer guest management (US-4), calendar .ics+webcal (US-8), change highlighting (US-9), update messages (US-10), QR code (US-11), mandatory expiry + data deletion (US-1/US-12), localStorage overview (US-7). ✓
+- **Sicherheit/Missbrauchsschutz**: Non-guessable UUIDs (US-1), open creation (US-1), max events config (US-13), honeypot fields (US-1/US-3). ✓
+- **Abgrenzungskriterien**: No chat, no discovery (US-1 AC), no event planning — all correctly absent. ✓
+- **Getroffene Designentscheidungen**: Single link per event, RSVP name, localStorage binding, spam=acceptable risk, no rate limiting/captcha/admin password (correctly absent), pragmatic measures (covered), SPA+REST (T-1/Q-3), PostgreSQL external (T-2), two UUIDs (US-1/token model), single Docker container (T-2), Java LTS+Spring Boot+Maven+hexagonal (T-1), Svelte+Vite (T-1). ✓
+- **Overseer-added features**: Event cancellation (US-18), event deletion (US-19). ✓
+- **Note**: US-17 (dark/light mode) has no direct Ideen.md entry but aligns with PWA "native app feel" and CLAUDE.md accessibility statute (already noted in iteration 19).
+- **Result**: All features from Ideen.md are fully covered. No gaps found.
+
+## Iteration 27 — Cross-cutting review #2: Persona consistency
+- Verified all three personas (Event Organizer, Guest, Self-Hoster) against the actual stories.
+- **Finding**: US-7 (local event overview) and US-17 (dark/light mode) are both written "As a user" (both roles apply), but the Event Organizer persona was missing these from both capabilities and "Appears in." The Guest persona already had them.
+- **Fix**: Added US-7 and US-17 to Event Organizer's capabilities (with "(shared with Guest — story uses 'user' role)" annotation) and to the "Appears in" list.
+- US-14 (PWA install) is "As a guest" — the organizer also benefits from PWA but the story is written from the guest perspective and the organizer doesn't have unique PWA interactions. Left as-is.
+- Guest persona: all capabilities, limitations, and "Appears in" entries verified correct. ✓
+- Self-Hoster persona: capabilities (US-13, US-16 config, T-2 deployment) and limitations all verified correct. ✓
+- Remaining cross-cutting checks: status counter accuracy, cross-story inconsistencies.
+
+## Iteration 28 — Cross-cutting review #3: Status counter accuracy
+- Verified the status counter at the top of `userstories.md`: Total 19, Complete 0, Remaining 19.
+- Counted all stories in the file: US-1 through US-19 = 19 stories. No stories have been implemented yet.
+- Status counter is accurate. No changes needed.
+- Remaining cross-cutting check: cross-story inconsistencies.
+
+## Iteration 29 — Cross-cutting review #4: Cross-story inconsistencies
+- Systematically checked localStorage keys, token terminology, expiry behavior, cancellation behavior, deletion cascading, cross-references, and dependency chains across all 19 stories and 3 tasks.
+- **Fix 1 — US-12 AC 2**: Added "(US-10)" cross-reference after "update messages" and added "cancellation state (US-18 if applicable)" to the deletion cascade list. Now matches the explicit enumeration in US-19 AC 3, which describes the same cascading deletion behavior. Previously missing because US-12 was reviewed (iteration 14) before US-18 and US-19 existed (created in iterations 7 and 10).
+- **Fix 2 — US-12 AC 3**: Removed "or 'event has ended'" from the post-deletion response. After the cleanup process deletes event data, the server cannot distinguish "this event was cleaned up" from "this event never existed" — the only honest response is "event not found," consistent with US-2 AC 6 and US-19 AC 4. The "event has ended" display (US-2 AC 4) applies only during the window when an event is expired but not yet cleaned up — that happens before US-12 acts, not after.
+- **Fix 3 — US-7 AC 6**: Changed "Events that have expired" to "Events whose date has passed." The expiry date is not stored in localStorage (US-1, US-3, US-6 all store event token, title, and event date — not the expiry date), and US-7 AC 5 requires the list to render entirely from localStorage. The event date — which IS stored locally — is what matters to users: whether the event has already taken place, not the server's data retention deadline.
+- **No other cross-story inconsistencies found.** All localStorage key names consistent, token terminology consistent, expiry/cancellation behavior consistent, cross-references accurate, dependency chains valid with no cycles.
+- All four cross-cutting checks now complete: (1) Ideen.md feature coverage ✓, (2) Persona consistency ✓, (3) Status counter accuracy ✓, (4) Cross-story inconsistencies ✓.

.ralph/story-refinement/questions.md

@@ -0,0 +1,12 @@
+# Questions
+
+<!-- Questions raised during the story-refinement run. -->
+<!-- This run is archived — see progress.txt for details. -->
+
+## Open
+
+(No open questions.)
+
+## Resolved
+
+(Questions from this run were carried forward into review-findings.)

.ralph/story-refinement/run.log

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

.ralph/verify-impl-order/answers.md

@@ -0,0 +1,3 @@
+# Answers
+
+<!-- Human answers to open questions. Ralph processes these one per iteration. -->

.ralph/verify-impl-order/instructions.md

@@ -0,0 +1,97 @@
+# Ralph Loop — Verify Implementation Order
+
+You are an autonomous agent running inside a Ralph Loop. Your job is to verify that the implementation order documented in `spec/implementation-phases.md` is consistent with the declared dependencies in all user stories and setup tasks. You report findings — you do not modify any spec files.
+
+## 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. `{{RUN_DIR}}/questions.md` — open and resolved questions.
+5. `CLAUDE.md` — project statutes and principles.
+6. `spec/implementation-phases.md` — the implementation order you are verifying.
+7. `spec/userstories.md` — user stories with their declared dependencies.
+8. `spec/setup-tasks.md` — setup tasks with their declared dependencies.
+9. `Ideen.md` — project vision and binding design decisions.
+
+## 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 that hasn't been addressed yet (check `{{RUN_DIR}}/progress.txt`). Do NOT modify `{{RUN_DIR}}/overseer.md`.
+
+### Priority 2: Process answers
+If `{{RUN_DIR}}/answers.md` contains an answer, process it. Remove the processed entry from `{{RUN_DIR}}/answers.md`.
+
+### Priority 3: Verify one phase
+Work through the phases in `spec/implementation-phases.md` in order (Phase 0, Phase 1, Phase 2, ...). For each phase, check:
+
+- **Dependency satisfaction:** Every story/task in this phase must have all its declared dependencies satisfied by stories/tasks in earlier phases (or the same phase, if they are independent of each other within the phase). Flag any story that is scheduled before one of its dependencies.
+- **Completeness:** Are there stories/tasks whose dependencies are all satisfied by earlier phases but that are not yet scheduled in any phase? They could be moved earlier.
+- **Parallelizability:** Are stories within the same phase truly independent of each other, or do some have inter-dependencies that force a specific order within the phase?
+
+Report findings in `{{RUN_DIR}}/progress.txt`. If you find a problem, also raise it as a question in `{{RUN_DIR}}/questions.md` with a suggested fix.
+
+Track which phases you have verified in `{{RUN_DIR}}/progress.txt` so you don't re-verify them.
+
+### Priority 4: Cross-cutting consistency check
+After all individual phases have been verified, do ONE cross-cutting check:
+
+- Are all user stories and setup tasks from `spec/userstories.md` and `spec/setup-tasks.md` accounted for in some phase?
+- Are there circular dependencies that make the order impossible?
+- Does the phase grouping align with the practical notes in `Ideen.md` (e.g. vertical slice considerations, MVP scope)?
+- Is the overall order sensible from a development workflow perspective (e.g. infrastructure before features, backend before frontend where needed)?
+
+Report findings in `{{RUN_DIR}}/progress.txt`.
+
+### Priority 5: Complete
+If all phases are verified, the cross-cutting check is done, all answers processed, and all overseer action items addressed:
+Output `<promise>COMPLETE</promise>` and stop.
+
+## File Ownership
+
+Respect these boundaries strictly:
+
+| File | Owner | You may... |
+|------|-------|------------|
+| `{{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. |
+| `CLAUDE.md` | Human | **Read only.** Never modify. |
+| `spec/implementation-phases.md` | Human | **Read only.** Never modify. |
+| `spec/userstories.md` | Human | **Read only.** Never modify. |
+| `spec/setup-tasks.md` | Human | **Read only.** Never modify. |
+| `Ideen.md` | Human | **Read only.** Never modify. |
+
+## Handling Uncertainty
+
+If you encounter an ambiguity in the dependency declarations (e.g. a dependency that could be interpreted multiple ways, or a missing dependency that seems implied but isn't declared), raise a question in `{{RUN_DIR}}/questions.md`:
+
+```
+### Q-{number}: {short title}
+
+**Context:** {why this question came up}
+**Affects:** {which stories/tasks/phases are affected}
+**Suggested fix:** {what you think should change in implementation-phases.md}
+```
+
+## Rules
+
+- ONE task per iteration. No exceptions.
+- You are a verifier, not an editor. Never modify spec files.
+- Base your analysis on declared dependencies (`**Dependencies:**` fields), not on your own judgment of what should depend on what.
+- When you find issues, be specific: name the story/task, the phase it's in, the dependency that is violated, and where the dependency should be satisfied.

.ralph/verify-impl-order/meta.md

@@ -0,0 +1,6 @@
+# Run: verify-impl-order
+
+- **Created**: 2026-03-03
+- **Description**: (add description here)
+- **Model**: sonnet
+- **Max iterations**: 10

.ralph/verify-impl-order/overseer.md

@@ -0,0 +1,11 @@
+# Overseer Notes
+
+<!-- This file is written by the overseer session. Ralph reads it but never modifies it. -->
+
+## Action Required
+
+(No action items.)
+
+## Observations
+
+(No observations.)

.ralph/verify-impl-order/progress.txt

@@ -0,0 +1,189 @@
+# Ralph Loop Progress Log
+# Each iteration appends its findings and decisions here.
+
+---
+## Iteration 1 — 2026-03-03
+
+**Task:** Verify Phase 0 (Project Infrastructure)
+
+**Verified phases:** Phase 0
+
+**Method:** Checked each task's position in Phase 0 against its declared `Dependencies:` field in spec/setup-tasks.md.
+
+### Findings
+
+**Dependency satisfaction:** PASS
+
+| Task | Declared Dependencies | Scheduled at | All deps in earlier slots? |
+|------|-----------------------|--------------|---------------------------|
+| T-1  | None                  | Order 1      | ✓ (no deps) |
+| T-2  | T-1                   | Order 2      | ✓ T-1 is Order 1 |
+| T-4  | T-1, T-2              | Order 3      | ✓ T-1 (Order 1), T-2 (Order 2) |
+| T-3  | T-1, T-2              | Order 3*     | ✓ T-1 (Order 1), T-2 (Order 2) |
+
+**Completeness:** PASS — all four setup tasks (T-1, T-2, T-3, T-4) are accounted for in Phase 0.
+
+**Parallelizability:** PASS — T-3 and T-4 have identical declared dependencies (T-1, T-2) and are marked as parallelizable with each other. This is correct.
+
+**Minor prose inconsistency (not an ordering problem):** Phase 0's introductory sentence states "All setup tasks must complete before any user story work begins," but the same paragraph notes "T-3 can run in parallel with Phase 1." These two sentences contradict each other in plain language. The dependency-based analysis is correct: no user story has a declared dependency on T-3, so Phase 1 can proceed without T-3 being complete. The parenthetical note is accurate; the introductory sentence is overly broad. Not raising a question since this is a prose issue only and the implementation order is unambiguous.
+
+**Verdict:** Phase 0 is correctly ordered. No dependency violations found.
+
+---
+## Iteration 3 — 2026-03-03
+
+**Task:** Verify Phase 2 (Organizer Management & Event Lifecycle)
+
+**Verified phases:** Phase 0, Phase 1, Phase 2
+
+**Method:** Checked each story's position in Phase 2 against its declared `Dependencies:` field in spec/userstories.md. Phases 0 and 1 are treated as already verified.
+
+### Findings
+
+**Dependency satisfaction:** PASS
+
+| Story | Declared Dependencies | All deps in earlier phases? |
+|-------|-----------------------|-----------------------------|
+| US-4  | US-1, T-4             | ✓ US-1 is Phase 1; T-4 is Phase 0 |
+| US-5  | US-1, T-4             | ✓ US-1 is Phase 1; T-4 is Phase 0 |
+| US-18 | US-1, T-4             | ✓ US-1 is Phase 1; T-4 is Phase 0 |
+| US-19 | US-1, T-4             | ✓ US-1 is Phase 1; T-4 is Phase 0 |
+| US-12 | US-1, T-4             | ✓ US-1 is Phase 1; T-4 is Phase 0 |
+| US-13 | US-1, T-4             | ✓ US-1 is Phase 1; T-4 is Phase 0 |
+
+**Completeness:** PASS — All six stories with dependencies satisfied by Phase 1 or earlier (and belonging to the organizer/lifecycle domain) are accounted for in Phase 2. No eligible story is missing.
+
+Note: Several later-phase stories (US-6, US-8, US-10a, US-11, US-15, US-16, US-7, US-14, US-17) also have their declared dependencies satisfied by Phase 1 or earlier, but they are correctly grouped into later phases by functional domain (enhanced guest features, visual customization, PWA shell). This is a deliberate, documented grouping choice — not a scheduling error.
+
+**Parallelizability:** PASS — All six Phase 2 stories declare only US-1 and T-4 as dependencies. None of them declare a dependency on any other Phase 2 story. They are structurally independent and can be worked on in parallel. The recommended within-phase order (US-5 first, since US-9 in Phase 3 depends on it) is an efficiency hint, not a structural constraint.
+
+**Undeclared dependency observation (no violation):** US-4's ACs state the organizer view is "accessible from the event page" — this implies UX integration with US-2 at the view level. However, the organizer view can be implemented as a standalone route/endpoint independently of US-2's visual implementation, so the omission of US-2 from US-4's declared dependencies is defensible and consistent with Phase 2 placement. No ordering violation.
+
+**Mermaid diagram consistency:** The diagram shows US-1 branching to all Phase 2 stories (US-4, US-5, US-12, US-13, US-18, US-19). T-4 is not shown as a direct arrow to these stories, but it is a transitive dependency via T-4 → US-1. The diagram caption notes "(and T-4 transitively)" — consistent with declared dependencies.
+
+**Verdict:** Phase 2 is correctly ordered. No dependency violations found.
+
+---
+## Iteration 4 — 2026-03-03
+
+**Task:** Verify Phase 3 (Enhanced Event Page Features)
+
+**Verified phases:** Phase 0, Phase 1, Phase 2, Phase 3
+
+**Method:** Checked each story's position in Phase 3 against its declared `Dependencies:` field in spec/userstories.md. Phases 0–2 are treated as already verified.
+
+### Findings
+
+**Dependency satisfaction:** PASS
+
+| Story | Declared Dependencies | All deps in earlier phases? |
+|-------|-----------------------|-----------------------------|
+| US-6  | US-2, T-4             | ✓ US-2 is Phase 1; T-4 is Phase 0 |
+| US-8  | US-2, T-4             | ✓ US-2 is Phase 1; T-4 is Phase 0 |
+| US-9  | US-2, US-5, T-4       | ✓ US-2 is Phase 1; US-5 is Phase 2; T-4 is Phase 0 |
+| US-10a | US-1, US-2, T-4      | ✓ US-1 and US-2 are Phase 1; T-4 is Phase 0 |
+| US-10b | US-10a               | US-10a is Phase 3 (same phase) — see parallelizability below |
+| US-11  | US-2, T-4            | ✓ US-2 is Phase 1; T-4 is Phase 0 |
+
+**Completeness:** PASS — All six stories with dependencies satisfied by Phase 2 or earlier and belonging to the enhanced event-page domain are included in Phase 3. No eligible story appears to be missing.
+
+**Parallelizability:** PASS (with one documented intra-phase sequential pair)
+
+- US-6, US-8, US-11: mutually independent; no intra-phase dependencies. ✓
+- US-10a: independent of US-6, US-8, US-11 within the phase. ✓
+- US-10b → US-10a: **intra-phase dependency**. US-10b must follow US-10a. This forces sequential implementation of the pair within Phase 3. This is explicitly acknowledged in the spec: "US-10b: Must follow US-10a" and "US-10a → US-10b (sequential pair)" in the recommended order note. Not a violation — the constraint is documented and correct.
+- US-9: independent of US-6, US-8, US-10a, US-10b, US-11 within Phase 3 (its cross-phase deps US-2 and US-5 are already satisfied). ✓
+
+**Diagram consistency (minor observation, no ordering problem):** The Mermaid diagram shows only `US-2 → US-10a` for US-10a's dependencies. US-10a's declared dependencies include `US-1` in addition to US-2, but US-1 is a transitive prerequisite of US-2, so US-1 is reachable in the diagram via `US-1 → US-2 → US-10a`. This is a diagram simplification, not a missing dependency — the implementation order is unambiguous.
+
+**Verdict:** Phase 3 is correctly ordered. No dependency violations found. The US-10a → US-10b sequential constraint is known and documented.
+
+---
+## Iteration 5 — 2026-03-03
+
+**Task:** Verify Phase 4 (Visual Customization)
+
+**Verified phases:** Phase 0, Phase 1, Phase 2, Phase 3, Phase 4
+
+**Method:** Checked each story's position in Phase 4 against its declared `Dependencies:` field in spec/userstories.md. Phases 0–3 are treated as already verified.
+
+### Findings
+
+**Dependency satisfaction:** PASS
+
+| Story | Declared Dependencies | All deps in earlier phases? |
+|-------|-----------------------|-----------------------------|
+| US-15 | US-1, US-2, T-4       | ✓ US-1 is Phase 1; US-2 is Phase 1; T-4 is Phase 0 |
+| US-16 | US-1, US-2, T-4       | ✓ US-1 is Phase 1; US-2 is Phase 1; T-4 is Phase 0 |
+
+**Completeness:** PASS — both visual customization stories (US-15, US-16) are accounted for in Phase 4. No other story in the spec belongs to this domain without being included here.
+
+**Parallelizability:** PASS — US-15 and US-16 share no declared dependency on each other. They are structurally independent and can be worked on in parallel. The recommended order (US-15 before US-16) is an efficiency hint (simpler story, no external API dependency, and the interaction with dark/light mode is easier to resolve first), not a structural constraint.
+
+**Undeclared dependency observation (no violation):** US-15 and US-16 both state in their ACs "During event creation or editing (US-5)" — implying functional integration with the edit form from US-5. US-5 is not listed as a declared dependency for either story. This omission is defensible because:
+1. The core functionality (selecting a theme or image during event creation) is implementable using the creation form from US-1 alone.
+2. Phase 4 comes after Phase 2 where US-5 is implemented, so US-5 will be available in practice when US-15 and US-16 are worked on.
+No ordering violation.
+
+**Grouping note (no violation):** US-15 and US-16 have declared dependencies satisfied after Phase 1 (same as several Phase 3 stories). Their placement in Phase 4 rather than Phase 3 is a deliberate functional grouping decision — visual customization is a separate concern from enhanced event page features. This is consistent with the documented grouping rationale in the spec. No scheduling error.
+
+**Verdict:** Phase 4 is correctly ordered. No dependency violations found.
+
+---
+## Iteration 6 — 2026-03-03
+
+**Task:** Verify Phase 5 (App Shell & PWA)
+
+**Verified phases:** Phase 0, Phase 1, Phase 2, Phase 3, Phase 4, Phase 5
+
+**Method:** Checked each story's position in Phase 5 against its declared `Dependencies:` field in spec/userstories.md. Phases 0–4 are treated as already verified.
+
+### Findings
+
+**Dependency satisfaction:** PASS
+
+| Story | Declared Dependencies | All deps in earlier phases? |
+|-------|-----------------------|-----------------------------|
+| US-7  | None                  | ✓ (no deps) |
+| US-14 | T-4                   | ✓ T-4 is Phase 0 |
+| US-17 | None                  | ✓ (no deps) |
+
+**Completeness:** PASS — all three App Shell & PWA stories (US-7, US-14, US-17) are accounted for in Phase 5. No other story in the spec belongs to this domain without being included here.
+
+**Parallelizability:** PASS — US-7, US-14, and US-17 share no declared dependencies on each other. They are structurally independent and can be worked on in parallel. The recommended within-phase order (US-17 → US-7 → US-14) is a practical sequencing hint, not a structural constraint.
+
+**Undeclared dependency observations (no violations):**
+
+- US-7's ACs reference US-1, US-3, and US-6 as sources of localStorage data (organizer tokens, RSVP records, bookmarks). None of these are declared dependencies. This is intentional and correct: US-7 can be implemented and passes acceptance in its empty state without those stories. The references are "practically useful after" notes, not structural prerequisites.
+- US-7 AC 7 references US-12 and US-19 ("event no longer exists" handling) — not declared dependencies. US-7 can implement the error path even before US-12/US-19 are available; the condition simply won't be triggerable in testing until those stories are done. No violation.
+- US-14 AC 7 references US-7 (manifest start URL points to `/`, which serves the local event overview). US-7 is not declared as a dependency of US-14. Defensible: the start URL can be set to `/` regardless of whether US-7 is implemented. No violation.
+- US-17's notes state it "requires the frontend scaffold from T-4 (which includes T-1) to be practically implementable" but correctly omits T-4 from the declared dependencies (since US-17 has no structural gating on T-4 — it is a styling/CSS concern and the declared deps list only hard structural prerequisites). Consistent with how US-7's notes treat T-4 similarly.
+
+**Phase 5 timing note (no violation):** The spec notes that US-17 "can be started early once the frontend scaffold exists — consider implementing alongside Phase 2 or 3." This is sound advice given that US-15 (Phase 4) must consider the interaction between event color themes and dark/light mode. However, the placement of US-17 in Phase 5 is not a scheduling error — it is a logical grouping. The practical recommendation to implement it earlier is correctly surfaced as a note, not enforced via a dependency constraint. No violation.
+
+**Verdict:** Phase 5 is correctly ordered. No dependency violations found.
+
+---
+## Iteration 2 — 2026-03-03
+
+**Task:** Verify Phase 1 (Core Event Flow — Vertical Slice)
+
+**Verified phases:** Phase 0, Phase 1
+
+**Method:** Checked each story's position in Phase 1 against its declared `Dependencies:` field in spec/userstories.md. Phase 0 is treated as already verified.
+
+### Findings
+
+**Dependency satisfaction:** PASS
+
+| Story | Declared Dependencies | Scheduled at | All deps in earlier slots? |
+|-------|-----------------------|--------------|---------------------------|
+| US-1  | T-4                   | Phase 1 Order 1 | ✓ T-4 is Phase 0 Order 3 |
+| US-2  | US-1, T-4             | Phase 1 Order 2 | ✓ US-1 is Phase 1 Order 1; T-4 is Phase 0 |
+| US-3  | US-2, T-4             | Phase 1 Order 3 | ✓ US-2 is Phase 1 Order 2; T-4 is Phase 0 |
+
+**Completeness:** PASS — US-1, US-2, US-3 are the only stories with all dependencies in Phase 0 or earlier. No eligible story is missing from Phase 1.
+
+**Parallelizability:** PASS — The chain US-1 → US-2 → US-3 is strictly sequential; US-2 depends on US-1 and US-3 depends on US-2, so no parallelization is possible. The phase note "These three stories are strictly sequential" is accurate.
+
+**Verdict:** Phase 1 is correctly ordered. No dependency violations found.

.ralph/verify-impl-order/questions.md

@@ -0,0 +1,9 @@
+# Questions
+
+## Open
+
+(No open questions.)
+
+## Resolved
+
+(No resolved questions.)

.ralph/verify-impl-order/run.log

@@ -0,0 +1,8 @@
+
+=== Run started: 2026-03-03T12:41:18 | model=sonnet | max=10 ===
+[12:42:21] Iteration 1 done
+[12:43:23] Iteration 2 done
+[12:45:10] Iteration 3 done
+[12:46:24] Iteration 4 done
+[12:47:44] Iteration 5 done
+[12:49:13] COMPLETE after 6 iteration(s)