.specify/memory/ideen.md

@@ -84,31 +84,12 @@ Die folgenden Punkte wurden in Diskussionen bereits geklärt und sind verbindlic
 	* (derzeit keine offenen Architekturentscheidungen)
 
 ## Nicht umgesetzte Feature-Ideen (ehemals Specs 009–026)
-
-### 009 – Gästeliste
-Organisator sieht alle RSVPs (Name, Status) und kann einzelne Einträge löschen.
-* Nur mit gültigem Organizer-Token sichtbar
-* Gäste ohne Token sehen keine Gästeliste
-* Löschung serverseitig validiert
-
 ### 010 – Event bearbeiten
 Organisator kann Titel, Beschreibung, Datum, Ort und Ablaufdatum ändern.
 * Formular vorausgefüllt mit aktuellen Werten
 * Ablaufdatum muss in der Zukunft liegen
 * Ohne Organizer-Token kein Edit-UI sichtbar
 
-### 011 – Event merken/bookmarken
-Gäste können Events lokal merken, ohne RSVP abzugeben — rein clientseitig via localStorage.
-* Kein Serverkontakt nötig
-* Unabhängig vom RSVP-Status
-* Auch bei abgelaufenen Events möglich
-
-### 012 – Lokale Event-Übersicht
-Startseite (`/`) zeigt alle getrackten Events (erstellt, zugesagt, gemerkt) aus localStorage.
-* Zeigt Titel, Datum, Beziehungstyp (Organisator/Gast/Gemerkt)
-* Vergangene Events als "beendet" markiert
-* Einträge können entfernt werden
-
 ### 013 – Kalender-Export
 .ics-Download (RFC 5545) mit Event-Details, optional webcal:// für Live-Updates.
 * Stabile UID aus Event-Token (Re-Import aktualisiert statt dupliziert)
@@ -137,19 +118,6 @@ Badge/Indikator bei ungelesenen Organisator-Updates, rein clientseitig via local
 Event-Seite zeigt QR-Code mit der öffentlichen Event-URL.
 * Serverseitig generiert (kein externer QR-Service)
 * Download als SVG oder hochauflösendes PNG
-* Auch bei abgelaufenen Events verfügbar
-
-### 018 – Datenlöschung
-Automatische Löschung aller Event-Daten nach Ablaufdatum (Privacy-Garantie).
-* Scheduled Job oder Lazy Cleanup bei Zugriff
-* Löscht Event, RSVPs, Updates, Bilder, Metadaten
-* Idempotent, kein PII im Log
-
-### 019 – Instanz-Limit
-`MAX_ACTIVE_EVENTS` als Env-Variable begrenzt aktive Events für Self-Hoster.
-* Nur nicht-abgelaufene Events zählen
-* Unset/leer = unbegrenzt
-* Serverseitige Durchsetzung bei Event-Erstellung
 
 ### 020 – PWA
 Web App Manifest + Service Worker für Installierbarkeit und Offline-Caching.
@@ -169,27 +137,11 @@ Organisator sucht Headerbild über integrierte Unsplash-Suche.
 * Bild lokal gespeichert + Unsplash-Attribution
 * Feature deaktiviert wenn kein API-Key konfiguriert
 
-### 023 – Dark Mode
-App erkennt `prefers-color-scheme` und bietet manuellen Toggle.
-* Manuelle Auswahl in localStorage gespeichert
-* Gilt für globales App-Chrome, nicht Event-Farbthemen
-* Beide Modi WCAG AA konform
-
-### 024 – Event absagen
-Organisator kann Event absagen (mit optionaler Nachricht, Einweg-Transition).
-* RSVPs werden nach Absage abgelehnt
-* Absage-Nachricht nachträglich editierbar
-* Kann nicht rückgängig gemacht werden
-* Wenn Organisator Event auf der Eventlistenseite löscht, muss dabei das Event abgesagt werden (nicht nur lokal entfernen)
-
-### 025 – Event löschen
-Organisator löscht Event permanent und unwiderruflich.
-* Entfernt alle zugehörigen Daten sofort
-* localStorage-Eintrag wird entfernt, Redirect zu `/`
-* Funktioniert in jedem Event-Status
-
 ### 026 – 404-Seite
 Catch-all Route für ungültige Pfade mit "Seite nicht gefunden" und Link zur Startseite.
 * Folgt dem Design System (Electric Dusk + Sora)
 * WCAG AA konform
 * Verhindert leere Seiten bei Fehlnavigation
+
+### 027 - Update der EventListe
+* Irgendwie ein update der event liste, wenn man sie betritt oder wenn man mit touch die seite nach unten zieht (hier müssen wir noch überlegen, wie wir mit den verschiedenen update fällen umgehen und wie wir das update überhaupt requesten. Ich meine sowas wie: was ist, wenn das event nicht mehr gefunden wurde?)

specs/019-ical-download/checklists/requirements.md

@@ -0,0 +1,36 @@
+# Specification Quality Checklist: iCal Download
+
+**Purpose**: Validate specification completeness and quality before proceeding to planning
+**Created**: 2026-03-13
+**Feature**: [spec.md](../spec.md)
+
+## Content Quality
+
+- [x] No implementation details (languages, frameworks, APIs)
+- [x] Focused on user value and business needs
+- [x] Written for non-technical stakeholders
+- [x] All mandatory sections completed
+
+## Requirement Completeness
+
+- [x] No [NEEDS CLARIFICATION] markers remain
+- [x] Requirements are testable and unambiguous
+- [x] Success criteria are measurable
+- [x] Success criteria are technology-agnostic (no implementation details)
+- [x] All acceptance scenarios are defined
+- [x] Edge cases are identified
+- [x] Scope is clearly bounded
+- [x] Dependencies and assumptions identified
+
+## Feature Readiness
+
+- [x] All functional requirements have clear acceptance criteria
+- [x] User scenarios cover primary flows
+- [x] Feature meets measurable outcomes defined in Success Criteria
+- [x] No implementation details leak into specification
+
+## Notes
+
+- All items pass. Spec mentions "RFC 5545" and "Blob" which are standard/format references, not implementation details.
+- FR-004 (SEQUENCE number) depends on whether the backend exposes an update counter or timestamp — documented as assumption.
+- Spec is ready for `/speckit.clarify` or `/speckit.plan`.

specs/019-ical-download/plan.md

@@ -0,0 +1,95 @@
+# Implementation Plan: iCal Download
+
+**Branch**: `019-ical-download` | **Date**: 2026-03-13 | **Spec**: [spec.md](spec.md)
+**Input**: Feature specification from `/specs/019-ical-download/spec.md`
+
+## Summary
+
+Add a calendar download button to the event detail page that generates RFC 5545-compliant `.ics` files client-side. The button appears in the RsvpBar for all non-organizer users (not shown for cancelled events). No backend changes are required — all event data is already available in the frontend after fetching event details.
+
+## Technical Context
+
+**Language/Version**: TypeScript 5.x, Vue 3 (Composition API)
+**Primary Dependencies**: None new — uses existing Vue 3, openapi-fetch stack. iCal generation is hand-rolled (RFC 5545 is simple enough; no library needed).
+**Storage**: N/A (no persistence; generates file on demand)
+**Testing**: Vitest (unit tests for iCal generation + slug utility), Playwright + MSW (E2E for button behavior)
+**Target Platform**: PWA, mobile-first (320px–768px), all modern browsers
+**Project Type**: Web application (frontend-only change)
+**Performance Goals**: Instant download (< 50ms generation time, all client-side)
+**Constraints**: No external dependencies, no backend changes, UTF-8 encoded output
+**Scale/Scope**: 1 new composable, 1 utility, modifications to 2 existing components
+
+## Constitution Check
+
+*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
+
+| Principle | Status | Notes |
+|-----------|--------|-------|
+| I. Privacy by Design | ✅ PASS | Client-side only, no data sent to external services, no tracking |
+| II. Test-Driven Methodology | ✅ PLAN | Unit tests for iCal generation + slug utility, E2E for button UX |
+| III. API-First Development | ✅ N/A | No new API endpoints — uses existing `GetEventResponse` data |
+| IV. Simplicity & Quality | ✅ PLAN | Hand-rolled iCal (no library for ~40 lines of format code), minimal changes to existing components |
+| V. Dependency Discipline | ✅ PASS | Zero new dependencies |
+| VI. Accessibility | ✅ PLAN | Aria labels on calendar button, keyboard navigable, WCAG AA contrast |
+
+**Gate result**: PASS — no violations.
+
+## Project Structure
+
+### Documentation (this feature)
+
+```text
+specs/019-ical-download/
+├── plan.md              # This file
+├── research.md          # Phase 0 output
+├── data-model.md        # Phase 1 output
+├── quickstart.md        # Phase 1 output
+└── tasks.md             # Phase 2 output (via /speckit.tasks)
+```
+
+### Source Code (repository root)
+
+```text
+frontend/src/
+├── composables/
+│   └── useIcalDownload.ts       # NEW: iCal generation + download trigger
+├── utils/
+│   └── slugify.ts               # NEW: ASCII slug for filename
+├── components/
+│   └── RsvpBar.vue              # MODIFIED: add calendar button (2 visual states)
+└── views/
+    └── EventDetailView.vue      # MODIFIED: pass event data, handle calendar emit
+```
+
+**Structure Decision**: Frontend-only changes. New composable for iCal logic (consistent with project pattern: `useEventStorage`, `useRelativeTime`). Slug utility in `utils/` since it's a pure function with no Vue reactivity.
+
+## Key Design Decisions
+
+### D1: No iCal library
+
+**Decision**: Hand-roll iCal generation (~40 lines).
+
+**Rationale**: RFC 5545 VEVENT with 8–10 properties is trivial. Adding a library (e.g., `ical-generator`, `ics`) would violate Principle V (dependency discipline) — we'd use < 5% of its features.
+
+### D2: Calendar button visual states
+
+Per FR-006, the calendar button has 2 visual contexts:
+
+| State | Layout | Button Style |
+|-------|--------|-------------|
+| Before RSVP | Row: [bookmark] [CTA] [calendar] | glow-border + glass-inner (matches bookmark) |
+| After RSVP | Row: [status-bar (flex)] [calendar (fixed)] | glassmorphic bar style (matches status bar) |
+
+The button is not shown for cancelled events (RsvpBar remains hidden when `event.cancelled`).
+
+### D3: UID format
+
+**Decision**: `{eventToken}@fete` — stable across re-downloads, enables calendar deduplication per FR-003.
+
+### D4: SEQUENCE strategy
+
+**Decision**: Always `0`. Per FR-004, a proper version counter requires backend changes (future scope).
+
+## Complexity Tracking
+
+No constitution violations to justify.

specs/019-ical-download/spec.md

@@ -0,0 +1,80 @@
+# Feature Specification: iCal Download
+
+**Feature Branch**: `019-ical-download`
+**Created**: 2026-03-13
+**Status**: Draft
+**Input**: User description: "Add iCal (.ics) calendar download button to event detail page"
+
+## User Scenarios & Testing *(mandatory)*
+
+### User Story 1 - Download event as calendar file (Priority: P1)
+
+As a user viewing an event, I want to add it to my personal calendar so I don't forget the date and time.
+
+The user taps a calendar icon button in the bottom action bar. The browser downloads a `.ics` file containing the current event details. The user opens the file in their preferred calendar app (Apple Calendar, Google Calendar, Outlook, Thunderbird, etc.) and the event appears in their calendar.
+
+**Why this priority**: Core value of the feature — getting the event into the user's calendar.
+
+**Independent Test**: Can be fully tested by viewing an event, tapping the calendar button, and verifying the downloaded .ics file opens correctly in a calendar app.
+
+**Acceptance Scenarios**:
+
+1. **Given** a user views an active event (as attendee, pre-RSVP visitor, or organizer), **When** they tap the calendar icon in the action bar, **Then** a valid `.ics` file is downloaded containing the event's title, date/time, location, and description.
+2. **Given** the event is cancelled, **When** the user views the event detail page, **Then** the calendar button is NOT shown.
+3. **Given** the downloaded `.ics` file, **When** opened in any major calendar app, **Then** the event is created without errors.
+4. **Given** the user downloads the `.ics` file multiple times, **Then** the generated file is identical each time (deterministic output from the same event data).
+
+---
+
+### Edge Cases
+
+- What happens when the event has no location set? The `.ics` file omits the location field.
+- What happens when the event has no description? The `.ics` file omits the description field.
+- What happens when event title or description contains special characters (umlauts, emoji, newlines)? The `.ics` file uses proper UTF-8 encoding and RFC 5545 text escaping.
+- What happens on a browser that blocks Blob downloads? The download should work via standard browser download mechanisms; no special fallback is needed since all modern browsers support Blob downloads.
+
+## Clarifications
+
+### Session 2026-03-13
+
+- Q: Event hat kein Endzeit-Feld — wie soll DTEND in der .ics gehandhabt werden? → A: Kein DTEND/DURATION — nur DTSTART (punktuelles Ereignis gemäß RFC 5545).
+- Q: Dateiname-Sanitierung bei Sonderzeichen, Umlauten, langen Titeln? → A: Slugify — ASCII-Transliteration (ä→ae etc.), Leerzeichen→Bindestrich, max 60 Zeichen.
+- Q: Gibt es ein Konzept von "aktualisierten" .ics-Dateien? → A: Nein. Jeder Download erzeugt die gleiche Datei aus den aktuellen Event-Daten. Kein Update-Mechanismus.
+- Q: Button bei abgesagten Events? → A: Nein, kein Button wenn Event cancelled.
+- Q: Nur für Attendees oder auch für Organisatoren? → A: Alle Rollen — Attendee, Besucher ohne RSVP, Organisator. Button an gleicher Position.
+
+## Requirements *(mandatory)*
+
+### Functional Requirements
+
+- **FR-001**: System MUST generate a valid `.ics` file (RFC 5545 VEVENT) client-side without requiring backend changes.
+- **FR-002**: The `.ics` file MUST contain: UID, DTSTAMP, DTSTART, SUMMARY. DTEND and DURATION MUST NOT be included (the event has no end time; RFC 5545 treats a VEVENT with only DTSTART as a point-in-time event). It MUST include LOCATION and DESCRIPTION when those fields are present on the event.
+- **FR-003**: The UID MUST be derived from the event token (e.g. `{eventToken}@fete`) to produce a stable identifier for the calendar entry.
+- **FR-004**: The `.ics` file MUST include a SEQUENCE number of `0`.
+- **FR-006**: The calendar icon button MUST appear in the bottom action bar for all users (attendees, pre-RSVP visitors, and organizers), adapting its visual style to match the surrounding elements:
+  - **Before RSVP (attendee)**: Button order (left to right): bookmark, "I'm attending!" CTA, calendar. The calendar button MUST use the same glow-border + glass-inner style as the bookmark button.
+  - **After RSVP (attendee)**: The calendar button MUST appear to the right of the "You're attending!" status bar. It MUST use the same glassmorphic bar style (gradient background, glass border, backdrop blur) as the status bar — not the glow-border style. Layout: "You're attending!" status (flex), calendar icon button (fixed width).
+  - **Organizer**: The calendar button MUST appear in the same fixed bottom position. Styling TBD (consistent with existing organizer UI).
+- **FR-007**: The calendar button MUST NOT be shown when the event is cancelled.
+- **FR-008**: The downloaded file MUST use UTF-8 encoding and the `text/calendar` MIME type.
+- **FR-009**: The filename MUST be human-readable, derived from the event title using ASCII slugification (e.g. `Sommerfest am See` → `sommerfest-am-see.ics`). Rules: lowercase, umlauts transliterated (ä→ae, ü→ue, ö→oe, ß→ss), non-ASCII characters removed, spaces/special chars replaced with hyphens, consecutive hyphens collapsed, max 60 characters before `.ics` extension.
+
+### Key Entities
+
+- **iCal Event (VEVENT)**: A calendar entry generated from fete event data. Key attributes: UID (from event token), SUMMARY (title), DTSTART (date/time, no DTEND — point-in-time event), LOCATION, DESCRIPTION, SEQUENCE, DTSTAMP.
+
+## Success Criteria *(mandatory)*
+
+### Measurable Outcomes
+
+- **SC-001**: Any user (attendee, visitor, organizer) can download a calendar file with 1 tap.
+- **SC-002**: Downloaded `.ics` files import successfully into Apple Calendar, Google Calendar, and Outlook without errors.
+- **SC-003**: The calendar button does not disrupt the existing bottom bar layout or interaction patterns on devices from 320px to 768px width.
+
+## Assumptions
+
+- The `.ics` file generation is entirely client-side (no new backend endpoints needed), since all required event data is already available in the frontend after fetching event details.
+- The generated `.ics` file is deterministic: same event data always produces the same output. There is no concept of "updated" files — each download is a fresh snapshot of the current event data.
+- SEQUENCE is always `0`.
+- The calendar button is visible for all user roles (attendee, visitor, organizer) on active events. Not shown for cancelled events.
+- All date/time values in the `.ics` file use UTC format (Z suffix) since the event times are already stored in UTC.

specs/019-ical-download/tasks.md

@@ -0,0 +1,109 @@
+# Tasks: iCal Download
+
+**Input**: Design documents from `/specs/019-ical-download/`
+**Prerequisites**: plan.md, spec.md
+
+**Tests**: TDD is mandated by the project constitution. Tests are written first and must fail before implementation.
+
+**Organization**: Single user story (US1). Foundational phase covers the two pure utility modules; US1 phase covers component integration.
+
+## Format: `[ID] [P?] [Story] Description`
+
+- **[P]**: Can run in parallel (different files, no dependencies)
+- **[Story]**: Which user story this task belongs to (e.g., US1)
+- Include exact file paths in descriptions
+
+---
+
+## Phase 1: Foundational (Pure Utilities)
+
+**Purpose**: iCal generation and slug utility — pure functions with no UI dependencies
+
+### Tests (RED)
+
+- [x] T001 [P] Write unit tests for slugify (umlaut transliteration, special chars, max length, empty input) in `frontend/src/utils/__tests__/slugify.spec.ts`
+- [x] T002 [P] Write unit tests for iCal generation (required fields, optional LOCATION/DESCRIPTION omission, UTF-8 text escaping, UID format, deterministic output, DTSTAMP) in `frontend/src/composables/__tests__/useIcalDownload.spec.ts`
+
+### Implementation (GREEN)
+
+- [x] T003 Implement slugify utility in `frontend/src/utils/slugify.ts` — ASCII transliteration (ä→ae, ü→ue, ö→oe, ß→ss), lowercase, non-ASCII removal, hyphens for spaces/special chars, collapse consecutive hyphens, max 60 chars
+- [x] T004 Implement `generateIcs()` function and `useIcalDownload()` composable in `frontend/src/composables/useIcalDownload.ts` — RFC 5545 VEVENT with UID (`{eventToken}@fete`), DTSTAMP, DTSTART (UTC), SUMMARY, SEQUENCE:0, optional LOCATION/DESCRIPTION, Blob download with `text/calendar` MIME type, slugified filename
+
+**Checkpoint**: `npm run test:unit` passes — both utilities work in isolation
+
+---
+
+## Phase 2: User Story 1 — Download event as calendar file (Priority: P1) 🎯 MVP
+
+**Goal**: Calendar icon button in the bottom action bar for all user roles (attendee pre-RSVP, attendee post-RSVP, organizer). Tap triggers `.ics` download. Not shown for cancelled events.
+
+**Independent Test**: View any active event → tap calendar button → `.ics` file downloads → opens in calendar app.
+
+### Tests (RED)
+
+- [x] T005 Write E2E test for calendar download button in `frontend/e2e/ical-download.spec.ts` — verify button visible for pre-RSVP visitor, post-RSVP attendee, and organizer; verify button NOT visible for cancelled event; verify download triggers with correct filename
+
+### Implementation (GREEN)
+
+- [x] T006 [US1] Add calendar button and `calendar` emit to RsvpBar in `frontend/src/components/RsvpBar.vue` — pre-RSVP state: glow-border + glass-inner icon button after CTA; post-RSVP state: glassmorphic icon button right of status bar
+- [x] T007 [US1] Add calendar button for organizer view in `frontend/src/views/EventDetailView.vue` — fixed bottom position next to existing "Cancel event" button, consistent glassmorphic styling
+- [x] T008 [US1] Wire calendar download handler in `frontend/src/views/EventDetailView.vue` — import `useIcalDownload`, call on `@calendar` emit from RsvpBar and on organizer button click, pass event data
+
+**Checkpoint**: All acceptance scenarios pass — any user on an active event can download a valid `.ics` file with 1 tap
+
+---
+
+## Phase 3: Polish & Cross-Cutting Concerns
+
+- [ ] T009 Verify calendar button layout does not disrupt existing RsvpBar on 320px–768px viewports (visual check via `browser-interactive-testing` skill)
+
+---
+
+## Dependencies & Execution Order
+
+### Phase Dependencies
+
+- **Foundational (Phase 1)**: No dependencies — can start immediately
+- **US1 (Phase 2)**: Depends on Phase 1 completion (T003, T004 must be done)
+- **Polish (Phase 3)**: Depends on Phase 2 completion
+
+### Within Phases
+
+- T001 and T002 are parallel (different files)
+- T003 before T004 (`useIcalDownload` imports `slugify`)
+- T005 can be written before T006–T008 (TDD: test fails first)
+- T006 and T007 are parallel (different files)
+- T008 depends on T006 and T007 (wires them together)
+
+### Parallel Opportunities
+
+```text
+# Phase 1 tests (parallel):
+T001: slugify unit tests
+T002: iCal generation unit tests
+
+# Phase 2 implementation (parallel after T005):
+T006: RsvpBar calendar button
+T007: Organizer calendar button
+```
+
+---
+
+## Implementation Strategy
+
+### MVP (Single Pass)
+
+1. Complete Phase 1: Write tests → implement slugify → implement iCal generation
+2. Complete Phase 2: Write E2E → add buttons to RsvpBar + organizer view → wire handler
+3. Complete Phase 3: Visual verification
+4. **DONE**: Single user story, single deliverable
+
+---
+
+## Notes
+
+- No backend changes required — all client-side
+- Zero new dependencies — hand-rolled iCal generation
+- `generateIcs()` must be a pure function (deterministic, no side effects) for easy testing
+- `useIcalDownload()` wraps `generateIcs()` + Blob download trigger
+- Calendar SVG icon: use a calendar outline matching the existing date/time meta icon style