Remove unimplemented specs (009-026) and consolidate ideas into ideen.md
Move feature summaries for 18 unimplemented specs into .specify/memory/ideen.md before deleting the full spec files. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -82,3 +82,113 @@ Die folgenden Punkte wurden in Diskussionen bereits geklärt und sind verbindlic
|
||||
* Frontend: Vue 3 (mit Vite als Bundler, TypeScript, Vue Router)
|
||||
* Architekturentscheidungen die NOCH NICHT getroffen wurden (hier darf nichts eigenmächtig entschieden werden!):
|
||||
* (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)
|
||||
* Bei Absage: STATUS:CANCELLED im .ics
|
||||
* Kein externer Kalenderservice kontaktiert
|
||||
|
||||
### 014 – Änderungen hervorheben
|
||||
Geänderte Felder werden visuell hervorgehoben, wenn der Gast seit der letzten Änderung nicht mehr auf der Seite war.
|
||||
* Server trackt `last_edited_at` + geänderte Feldnamen
|
||||
* Client speichert `last_seen_at` in localStorage
|
||||
* Privacy-freundlich: kein serverseitiges Read-Tracking
|
||||
|
||||
### 015 – Organisator-Updates
|
||||
Organisator kann Textnachrichten im Event posten (Pinnwand-Stil).
|
||||
* Chronologisch sortiert, löschbar durch Organisator
|
||||
* Nach Ablauf kein Posting mehr möglich
|
||||
* Ohne Organizer-Token kein Compose-UI
|
||||
|
||||
### 016 – Gast-Benachrichtigungen
|
||||
Badge/Indikator bei ungelesenen Organisator-Updates, rein clientseitig via localStorage.
|
||||
* Eigener Timestamp `updates_last_seen_at` (getrennt von Feld-Änderungen)
|
||||
* Kein Indikator beim ersten Besuch
|
||||
* Kein serverseitiges Tracking (Privacy)
|
||||
|
||||
### 017 – QR-Code
|
||||
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.
|
||||
* Standalone-Modus ohne Browser-Chrome
|
||||
* Icon + Name auf Home-Screen
|
||||
* Alle Assets selbstgehostet
|
||||
|
||||
### 021 – Farbthemen
|
||||
Organisator wählt bei Erstellung ein vordefiniertes Farbthema für die Event-Seite.
|
||||
* Nur auf der Gast-Seite angewendet (nicht global)
|
||||
* Änderbar beim Bearbeiten
|
||||
* Unabhängig von Dark/Light Mode
|
||||
|
||||
### 022 – Headerbild
|
||||
Organisator sucht Headerbild über integrierte Unsplash-Suche.
|
||||
* Serverseitig geproxied (Client kontaktiert nie Unsplash)
|
||||
* 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
|
||||
|
||||
### 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
|
||||
|
||||
@@ -1,63 +0,0 @@
|
||||
# Feature Specification: Manage Guest List as Organizer
|
||||
|
||||
**Feature**: `009-guest-list`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - View and manage RSVPs (Priority: P1)
|
||||
|
||||
As an event organizer, I want to view all RSVPs for my event and remove individual entries if needed, so that I have an accurate overview of attendance and can moderate erroneous or spam entries.
|
||||
|
||||
The organizer view is accessible from the event page when a valid organizer token for that event is present in localStorage. When no organizer token is present, no organizer-specific UI is shown. The organizer can see each RSVP entry with name and attending status, and can permanently delete any entry.
|
||||
|
||||
**Why this priority**: Core organizer capability — without it, the organizer has no way to manage erroneous or spam RSVP entries. The public attendee list is only trustworthy if the organizer can moderate it.
|
||||
|
||||
**Independent Test**: Can be tested by creating an event (obtaining an organizer token), submitting several RSVPs via the RSVP form, then opening the organizer view to verify the list is displayed and deletion works.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an organizer token for an event is present in localStorage, **When** the organizer opens the event page, **Then** an organizer view link or section is visible that is not shown to guests without the token.
|
||||
2. **Given** the organizer view is open, **When** the page loads, **Then** all RSVPs for the event are listed, each showing the entry's name and attending status.
|
||||
3. **Given** the organizer view is open with at least one RSVP entry, **When** the organizer deletes an entry, **Then** the entry is permanently removed from the server and immediately disappears from the attendee list on the public event page.
|
||||
4. **Given** a visitor without an organizer token in localStorage opens the event page, **When** the page renders, **Then** no organizer-specific UI (link, button, or organizer view) is visible.
|
||||
5. **Given** the organizer view is open, **When** the organizer attempts to access it via a guessable URL without the organizer token in localStorage, **Then** organizer access is denied — it requires the organizer token established during event creation.
|
||||
6. **Given** the organizer has a valid organizer token in localStorage, **When** the organizer accesses the organizer view, **Then** no additional authentication step beyond the localStorage token is required.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens when the organizer token is present in localStorage but the event no longer exists on the server?
|
||||
- How does the system handle a deletion request when the organizer token is invalid or has been cleared from localStorage mid-session?
|
||||
- What if all RSVPs are deleted — does the organizer view show an empty state?
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: System MUST display the organizer view (guest list management) only when a valid organizer token for that event is present in localStorage.
|
||||
- **FR-002**: System MUST hide all organizer-specific UI (links, buttons, organizer view) from visitors who do not have the organizer token in localStorage.
|
||||
- **FR-003**: Organizer view MUST list all RSVPs for the event, showing each entry's name and attending status.
|
||||
- **FR-004**: Organizer MUST be able to permanently delete any individual RSVP entry from the organizer view.
|
||||
- **FR-005**: System MUST reflect RSVP deletions immediately on the public event page — the attendee list must update without delay.
|
||||
- **FR-006**: Organizer view MUST NOT be accessible via a guessable URL — access requires the organizer token stored in localStorage during event creation (US-1).
|
||||
- **FR-007**: System MUST NOT require any additional authentication step beyond the presence of the organizer token in localStorage.
|
||||
- **FR-008**: Server MUST reject RSVP deletion requests that do not include a valid organizer token.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **RSVP**: An entry submitted by a guest (US-3). Attributes: event association, guest name, attending status. The organizer can delete individual entries.
|
||||
- **Organizer token**: A secret UUID stored in localStorage on the device where the event was created (US-1). Grants organizer access to the guest list management view.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: An organizer can view the complete guest list for their event from the event page without navigating away to a separate URL.
|
||||
- **SC-002**: An organizer can delete any RSVP entry and the deletion is reflected on the public event page within the same page interaction (no reload required).
|
||||
- **SC-003**: A visitor without the organizer token in localStorage sees no organizer UI at all — zero organizer-specific elements rendered.
|
||||
- **SC-004**: The organizer view is not reachable by guessing or constructing a URL — it requires the in-memory/localStorage token to render.
|
||||
- **SC-005**: No additional login, account, or authentication beyond the organizer token is required to manage the guest list.
|
||||
@@ -1,89 +0,0 @@
|
||||
# Feature Specification: Edit Event Details as Organizer
|
||||
|
||||
**Feature**: `010-edit-event`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Edit event details (Priority: P1)
|
||||
|
||||
The event organizer wants to update the details of an event they created — title, description, date/time, location, or expiry date — so that guests always see accurate and up-to-date information if something changes.
|
||||
|
||||
**Why this priority**: Core organizer capability. Edits are expected for any real-world event (date changes, venue updates). Without this, the organizer has no recourse when details change after creation.
|
||||
|
||||
**Independent Test**: Can be fully tested by creating an event (US-1), navigating to the edit form, submitting changed values, and verifying the event page reflects the updates.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an organizer on the event page with a valid organizer token in localStorage, **When** they navigate to the edit form, **Then** the form is pre-filled with the current event values (title, description, date/time, location, expiry date).
|
||||
2. **Given** the edit form is pre-filled, **When** the organizer modifies one or more fields and submits, **Then** the changes are persisted server-side and the organizer is returned to the event page which reflects the updated details.
|
||||
3. **Given** the organizer is on the event page without an organizer token in localStorage, **When** they attempt to access the edit UI, **Then** no edit option is shown and the server rejects any update request.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Expiry date future-date validation (Priority: P2)
|
||||
|
||||
When editing, the organizer must set the expiry date to a future date. Setting it to today or a past date is rejected, and the organizer is directed to the delete feature (US-19) if they want to remove the event immediately.
|
||||
|
||||
**Why this priority**: Enforces the invariant that an event's expiry date is always in the future. Prevents the expiry date field from being misused as an implicit deletion mechanism, keeping the model clean.
|
||||
|
||||
**Independent Test**: Can be tested by submitting the edit form with a past or current date in the expiry date field and verifying the rejection response and validation message.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the edit form is open, **When** the organizer sets the expiry date to today or a past date and submits, **Then** the submission is rejected with a clear validation message directing the organizer to use the delete feature (US-19) instead.
|
||||
2. **Given** the edit form is open, **When** the organizer sets the expiry date to a date in the future and submits, **Then** the change is accepted and persisted.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Organizer token authentication (Priority: P2)
|
||||
|
||||
If the organizer token is absent or invalid, neither the edit UI is shown nor the edit request is accepted server-side.
|
||||
|
||||
**Why this priority**: Security constraint — the organizer token is the sole authentication mechanism. Both client and server must enforce it independently.
|
||||
|
||||
**Independent Test**: Can be tested by attempting an edit request with a missing or wrong organizer token and verifying a 403/401 response and no UI exposure.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a visitor without an organizer token in localStorage for the event, **When** they view the event page, **Then** no edit option or link is shown.
|
||||
2. **Given** an edit request is submitted with an absent or invalid organizer token, **When** the server processes the request, **Then** it rejects the request and the event data is unchanged.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens when the organizer submits the edit form with no changes? The server accepts the submission (idempotent update) and the organizer is returned to the event page.
|
||||
- What happens if the title field is left empty? Submission is rejected with a validation message — title is required.
|
||||
- What happens if the event has expired before the organizer submits the edit form? The server rejects the edit — editing an expired event is not permitted.
|
||||
- How does the system handle concurrent edits (e.g. organizer edits from two devices simultaneously)? [NEEDS EXPANSION — last-write-wins is the simplest strategy]
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: System MUST allow the organizer to edit: title (required), description (optional), date and time (required), location (optional), expiry date (required).
|
||||
- **FR-002**: System MUST pre-fill the edit form with the current stored values for all editable fields.
|
||||
- **FR-003**: System MUST reject an edit submission where the expiry date is today or in the past, and MUST return a validation message directing the organizer to use the delete feature (US-19).
|
||||
- **FR-004**: System MUST persist all submitted changes server-side upon successful validation.
|
||||
- **FR-005**: System MUST redirect the organizer to the event page after a successful edit, with the updated details visible.
|
||||
- **FR-006**: System MUST NOT expose the edit UI to any visitor who does not have a valid organizer token for the event in localStorage.
|
||||
- **FR-007**: System MUST reject any edit request where the organizer token is absent or does not match the event's stored organizer token.
|
||||
- **FR-008**: No account or additional authentication step beyond the organizer token is required to edit an event.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **Event**: Mutable entity with fields: title, description, date/time, location, expiry date. Identified externally by its event token. Updated via the organizer token.
|
||||
- **Organizer token**: Secret UUID stored in localStorage on the device where the event was created. Required to authenticate all organizer operations including editing.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: An organizer can update any editable field and see the change reflected on the public event page without a page reload after redirect.
|
||||
- **SC-002**: Any attempt to set the expiry date to a non-future date is rejected with a user-visible validation message before the server persists the change.
|
||||
- **SC-003**: No edit operation is possible — client or server — without a valid organizer token.
|
||||
- **SC-004**: The edit form is never shown to a visitor who does not hold the organizer token for the event.
|
||||
- **SC-005**: Visual highlighting of changed fields for guests is deferred to US-9 (Highlight changed event details); this story covers only the server-side persistence and organizer UX of editing.
|
||||
@@ -1,90 +0,0 @@
|
||||
# Feature Specification: Bookmark an Event
|
||||
|
||||
**Feature**: `011-bookmark-event`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
> **Note on directory naming**: The migration task list labeled this directory `us-06-calendar-export`, but US-6 in userstories.md is "Bookmark an event". Calendar export is US-8. The directory was created with the correct name reflecting the actual story content.
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Bookmark an event without RSVP (Priority: P1)
|
||||
|
||||
A guest who has opened an event page wants to save it for later without committing to attendance. They activate a "Remember" / "Follow" action on the event page. The event token, title, and date are stored in localStorage — no server request is made. The bookmark persists across browser sessions on the same device. The guest can unfollow by activating the action again.
|
||||
|
||||
**Why this priority**: Core bookmarking capability — without this, the entire feature has no value.
|
||||
|
||||
**Independent Test**: Can be fully tested by visiting an event page, activating the bookmark action, closing the browser, and reopening to verify persistence. Delivers value by enabling the local event overview (US-7) to display bookmarked events.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a guest has opened an event page, **When** they activate the "Remember" / "Follow" action, **Then** the event token, title, and date are stored in localStorage and no server request is made.
|
||||
2. **Given** a guest has bookmarked an event, **When** they close and reopen the browser, **Then** the bookmark is still present in localStorage.
|
||||
3. **Given** a guest has bookmarked an event, **When** they activate the bookmark action again, **Then** the bookmark is removed from localStorage ("unfollow") without any server contact.
|
||||
4. **Given** a guest has bookmarked an event, **When** the event page is loaded again, **Then** the bookmark action reflects the current bookmarked state.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Bookmark is independent of RSVP state (Priority: P2)
|
||||
|
||||
A guest who has already RSVPed to an event on their device can still explicitly bookmark or un-bookmark the event. The bookmark state is tracked separately from RSVP state.
|
||||
|
||||
**Why this priority**: Important for correctness but not the primary use case. The primary scenario is the undecided guest who wants to remember without committing.
|
||||
|
||||
**Independent Test**: Can be tested by RSVPing to an event and then toggling the bookmark action — both states persist independently in localStorage.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a guest has RSVPed "attending" on this device, **When** they activate the bookmark action, **Then** the bookmark is stored independently and the RSVP state is unaffected.
|
||||
2. **Given** a guest has bookmarked an event and RSVPed, **When** they remove the bookmark, **Then** the RSVP state is unaffected.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Bookmark available on expired events (Priority: P2)
|
||||
|
||||
A guest who is viewing an event that has passed its expiry date can still bookmark it, so it remains visible in their local event overview (US-7).
|
||||
|
||||
**Why this priority**: Edge case that ensures continuity of the local overview even for past events.
|
||||
|
||||
**Independent Test**: Can be tested by visiting an expired event page and verifying the bookmark action is present and functional.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an event has passed its expiry date, **When** a guest views the event page, **Then** the bookmark action is still shown and functional.
|
||||
2. **Given** a guest bookmarks an expired event, **When** they view their local event overview (US-7), **Then** the event appears in the list marked as ended.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens when the event title or date changes after bookmarking? Locally cached title and date may become stale if the organizer edits the event — this is an accepted trade-off. Cached values are refreshed when the guest next visits the event page.
|
||||
- How does the app handle localStorage being unavailable (e.g. private browsing in some browsers)? [NEEDS EXPANSION]
|
||||
- What happens if the guest bookmarks the same event from multiple devices? Each device maintains its own independent bookmark — no server-side sync.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: The event page MUST display a "Remember" / "Follow" action accessible to any visitor holding the event link.
|
||||
- **FR-002**: Activating the bookmark action MUST store the event token, event title, and event date in localStorage with no server request.
|
||||
- **FR-003**: The bookmark MUST persist across browser sessions on the same device.
|
||||
- **FR-004**: A second activation of the bookmark action MUST remove the bookmark ("unfollow") with no server contact.
|
||||
- **FR-005**: The bookmark state MUST be independent of the RSVP state — both can coexist for the same event on the same device.
|
||||
- **FR-006**: The bookmark action MUST remain available on event pages where the event has expired.
|
||||
- **FR-007**: No personal data, IP address, or identifier MUST be transmitted to the server when bookmarking or un-bookmarking.
|
||||
- **FR-008**: The bookmark action MUST reflect the current state (bookmarked / not bookmarked) when the event page loads.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **Bookmark record** (localStorage): Stored per event token. Contains: event token, event title, event date. Indicates the guest has explicitly bookmarked this event without RSVPing. Independent of the RSVP record.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: A guest can bookmark an event and find it in their local overview (US-7) without any server contact at any point in the bookmark flow.
|
||||
- **SC-002**: Bookmarking and un-bookmarking produce no network requests (verifiable via browser DevTools).
|
||||
- **SC-003**: A bookmark persists after browser restart on the same device.
|
||||
- **SC-004**: The bookmark state is correctly reflected on the event page across multiple sessions.
|
||||
- **SC-005**: Guests with existing RSVPs on this device can independently toggle the bookmark without affecting their RSVP state.
|
||||
@@ -1,111 +0,0 @@
|
||||
# Feature Specification: Local Event Overview List
|
||||
|
||||
**Feature**: `012-local-event-overview`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - View tracked events on the root page (Priority: P1)
|
||||
|
||||
A user who has created, bookmarked, or RSVPed to events on this device opens the root page (`/`) and sees a list of all those events, each with the event title, date, and their relationship to the event (organizer / attending / not attending / bookmarked only). Each entry is a link to the event page. The list is rendered entirely from localStorage — no server request is required. If no events are tracked locally, an empty state is shown.
|
||||
|
||||
**Why this priority**: This is the core feature — the reason the overview exists. Without this story, no other scenario is meaningful.
|
||||
|
||||
**Independent Test**: Can be fully tested by seeding localStorage with event entries (simulating US-1/US-3/US-6 data) and loading the root page. Delivers value by allowing users to navigate back to any tracked event without the original link.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the user has created an event from this device (organizer token in localStorage), **When** they navigate to `/`, **Then** the event appears in the list with title, date, and relationship "organizer"
|
||||
2. **Given** the user has RSVPed "attending" to an event from this device, **When** they navigate to `/`, **Then** the event appears in the list with title, date, and relationship "attending"
|
||||
3. **Given** the user has RSVPed "not attending" to an event from this device, **When** they navigate to `/`, **Then** the event appears in the list with title, date, and relationship "not attending"
|
||||
4. **Given** the user has bookmarked an event from this device (US-6), **When** they navigate to `/`, **Then** the event appears in the list with title, date, and relationship "bookmarked only"
|
||||
5. **Given** no events are tracked in localStorage, **When** the user navigates to `/`, **Then** an empty state message is shown — not an error
|
||||
6. **Given** the list is rendered, **When** the user clicks an entry, **Then** they are navigated directly to the event page for that entry
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Visually distinguish past events (Priority: P2)
|
||||
|
||||
Events whose date has passed are still shown in the list but rendered with a visual distinction (e.g. marked as "ended"), so the user can differentiate between upcoming and past events at a glance.
|
||||
|
||||
**Why this priority**: Useful for UX clarity but the overview is still functional without this distinction. Past events in the list are still navigable.
|
||||
|
||||
**Independent Test**: Can be tested by placing a past-dated event entry in localStorage and loading the root page. The entry should appear visually distinct from current events.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an event in localStorage has a date in the past, **When** the user views the overview, **Then** the entry is visually distinguished (e.g. marked "ended") compared to upcoming events
|
||||
2. **Given** an event in localStorage has a date in the future, **When** the user views the overview, **Then** the entry is rendered without any "ended" indicator
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Remove an entry from the local list (Priority: P2)
|
||||
|
||||
The user can remove individual entries from the local overview. The behavior depends on the entry type: for bookmarked-only events the bookmark is removed; for RSVPed events the local record is removed (server-side RSVP unaffected); for organizer-created events the organizer token and event data are removed from localStorage, with a confirmation warning that organizer access on this device will be lost.
|
||||
|
||||
**Why this priority**: Important for list hygiene but not required for the core navigation use case.
|
||||
|
||||
**Independent Test**: Can be tested by placing entries of each type in localStorage and verifying removal behavior from the overview UI.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a bookmarked-only event is in the local list, **When** the user removes that entry, **Then** the bookmark is removed from localStorage and the entry disappears from the list
|
||||
2. **Given** an RSVPed event is in the local list, **When** the user removes that entry, **Then** the local RSVP record is removed from localStorage; the server-side RSVP is unaffected
|
||||
3. **Given** an organizer-created event is in the local list, **When** the user initiates removal, **Then** a confirmation warning is shown explaining that organizer access on this device will be revoked
|
||||
4. **Given** the organizer confirms removal, **Then** the organizer token and event metadata are removed from localStorage and the entry disappears from the list
|
||||
|
||||
---
|
||||
|
||||
### User Story 4 - Handle a deleted event when navigating from the overview (Priority: P2)
|
||||
|
||||
If the user clicks an entry in the local overview and the server responds that the event no longer exists (deleted per US-12 automatic cleanup or US-19 organizer deletion), the app displays an "event no longer exists" message and offers to remove the entry from the local list.
|
||||
|
||||
**Why this priority**: Edge case that improves consistency and prevents stale entries from accumulating, but not core to the overview's primary purpose.
|
||||
|
||||
**Independent Test**: Can be tested by navigating to an event whose token does not exist on the server. The app should display a "no longer exists" message and offer removal.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an entry exists in the local overview, **When** the user navigates to that event and the server returns "event not found", **Then** the app displays an "event no longer exists" message and offers to remove the entry from the local list
|
||||
2. **Given** the user confirms removal of the stale entry, **Then** the entry is removed from localStorage and the user is returned to the overview
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens if localStorage is unavailable or disabled in the browser? The overview cannot render — [NEEDS EXPANSION: define fallback message or behavior]
|
||||
- What happens if the same event appears under multiple localStorage keys (e.g. both RSVPed and organizer)? [NEEDS EXPANSION: define de-duplication or priority rule for relationship label]
|
||||
- What happens if an event's locally cached title or date is stale (organizer edited via US-5)? Stale values are displayed until the user next visits the event page — this is an accepted trade-off per the story notes.
|
||||
- What happens when the user has a very large number of tracked events? [NEEDS EXPANSION: pagination or truncation strategy]
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: The root page (`/`) MUST display the local event overview list below a project header/branding section
|
||||
- **FR-002**: The list MUST include any event for which an organizer token, RSVP record, or bookmark exists in localStorage for this device
|
||||
- **FR-003**: Each list entry MUST show at minimum: event title, event date, and the user's relationship to the event (organizer / attending / not attending / bookmarked only)
|
||||
- **FR-004**: Each list entry MUST be a link that navigates directly to the corresponding event page
|
||||
- **FR-005**: The list MUST be populated entirely from localStorage — no server request is made to render the overview
|
||||
- **FR-006**: Events whose date has passed MUST be visually distinguished (e.g. marked "ended") from upcoming events
|
||||
- **FR-007**: An individual entry MUST be removable from the list; removal behavior depends on entry type (bookmark removal, local RSVP record removal, or organizer token removal)
|
||||
- **FR-008**: Removing an organizer-created event entry MUST require a confirmation warning explaining that organizer access on this device will be revoked
|
||||
- **FR-009**: No personal data or event data MUST be transmitted to the server when viewing or interacting with the overview
|
||||
- **FR-010**: If no events are tracked locally, an empty state MUST be shown — not an error or blank screen
|
||||
- **FR-011**: When navigating from the overview to an event that the server reports as deleted, the app MUST display an "event no longer exists" message and offer to remove the stale entry from the local list
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **LocalEventEntry**: A localStorage-stored record representing one tracked event. Contains at minimum: event token, event title, event date, and relationship type (organizer / attending / not attending / bookmarked). May also contain: organizer token (for organizer entries), RSVP choice and name (for RSVP entries).
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: A user with events tracked in localStorage can navigate to `/` and see all tracked events without any server request being made
|
||||
- **SC-002**: Each event entry links correctly to its event page
|
||||
- **SC-003**: Past events are visually distinguishable from upcoming events in the list
|
||||
- **SC-004**: An entry can be removed from the list, and the corresponding localStorage key is cleaned up correctly for each entry type
|
||||
- **SC-005**: The empty state is shown when no events are tracked in localStorage — no blank page or error state
|
||||
@@ -1,92 +0,0 @@
|
||||
# Feature Specification: Add Event to Calendar
|
||||
|
||||
**Feature**: `013-calendar-export`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Download .ics file (Priority: P1)
|
||||
|
||||
A guest who wants to remember the event opens the event page and downloads an iCalendar file to import into their personal calendar application. The file contains all relevant event details: title, description, start date/time, location, and the public event URL. The UID in the file is derived from the event token so that re-downloading the file and re-importing it updates the existing calendar entry rather than creating a duplicate.
|
||||
|
||||
**Why this priority**: Core calendar integration — the most common and universally supported way to add an event to a calendar across all platforms.
|
||||
|
||||
**Independent Test**: Can be fully tested by visiting a valid event page, clicking the `.ics` download link, and verifying the downloaded file is a valid iCalendar (RFC 5545) document with the correct event fields and a stable UID.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a valid event page, **When** the guest clicks the `.ics` download link, **Then** a standards-compliant iCalendar file is downloaded containing the event title, description (if present), start date and time, location (if present), the public event URL, and a unique UID derived from the event token.
|
||||
2. **Given** the guest downloads the `.ics` file twice for the same event, **When** they import both files into a calendar application, **Then** the calendar application updates the existing entry rather than creating a duplicate (due to the stable UID).
|
||||
3. **Given** a guest holding only the event link (no RSVP, no login), **When** they access the `.ics` download link, **Then** the file is served without requiring any authentication or personal data.
|
||||
4. **Given** an event whose expiry date has passed, **When** the guest accesses the `.ics` download link, **Then** the file is still served (the guest can still obtain the calendar record of a past event).
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Subscribe via webcal:// link (Priority: P2)
|
||||
|
||||
A guest subscribes to the event via a `webcal://` link so that their calendar application automatically picks up any changes — such as a rescheduled date or updated location — when the organizer edits the event via US-5.
|
||||
|
||||
**Why this priority**: Adds live-update value on top of the static `.ics` download. Requires the `.ics` download (P1) to already work. Most useful in conjunction with US-5 (Edit event details).
|
||||
|
||||
**Independent Test**: Can be tested by opening the `webcal://` URL in a calendar application and verifying it subscribes to the feed and shows the correct event details.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a valid event page, **When** the guest clicks the `webcal://` subscription link, **Then** their calendar application subscribes to the feed and displays the event.
|
||||
2. **Given** a subscribed `webcal://` feed and an organizer who edits the event date via US-5, **When** the calendar application syncs the feed, **Then** the calendar entry is updated to reflect the new date.
|
||||
3. **Given** a `webcal://` endpoint, **When** it is accessed, **Then** it serves identical iCalendar content as the `.ics` download, using the same event token in the URL.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Cancelled event reflected in calendar (Priority: P3)
|
||||
|
||||
When an event is cancelled (US-18), the `.ics` file and `webcal://` feed include `STATUS:CANCELLED` so that subscribed calendar applications reflect the cancellation automatically on their next sync.
|
||||
|
||||
**Why this priority**: Quality-of-life enhancement dependent on US-18 (cancel event). Deferred until US-18 is implemented.
|
||||
|
||||
**Independent Test**: Can be tested by cancelling an event and verifying the calendar feed includes `STATUS:CANCELLED`.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an event that has been cancelled (US-18), **When** a calendar application syncs the `webcal://` feed, **Then** the calendar entry is updated to show the cancelled status.
|
||||
2. **Given** an event that has been cancelled (US-18), **When** the guest downloads the `.ics` file, **Then** it includes `STATUS:CANCELLED`.
|
||||
|
||||
> **Note**: Deferred until US-18 is implemented.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens when the event has no description or location? The `.ics` file must omit those optional fields rather than including blank values.
|
||||
- What happens if the server has no public URL configured? The event URL included in the `.ics` file must always be the correct public event URL.
|
||||
- What happens if the event's date or timezone changes after a guest already imported the `.ics` file? The static import will be stale; the `webcal://` subscription will auto-update on next sync.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: System MUST expose a server-side endpoint that generates and serves a standards-compliant iCalendar (RFC 5545) `.ics` file for any event identified by its event token.
|
||||
- **FR-002**: The `.ics` file MUST include: event title, description (if present), start date and time, location (if present), the public event URL, and a unique UID derived from the event token.
|
||||
- **FR-003**: The UID in the `.ics` file MUST be stable across regenerations (same event token always produces the same UID) so that calendar applications update existing entries on re-import rather than creating duplicates.
|
||||
- **FR-004**: The `.ics` file MUST be generated server-side; no external calendar or QR code service is called.
|
||||
- **FR-005**: System MUST expose a `webcal://` subscription endpoint that serves identical iCalendar content as the `.ics` download, using the same event token in the URL.
|
||||
- **FR-006**: Both the `.ics` download link and the `webcal://` subscription link MUST be accessible to any visitor holding the event link — no RSVP, login, or personal data required.
|
||||
- **FR-007**: No personal data, name, or IP address MUST be logged when either link is accessed.
|
||||
- **FR-008**: Both links MUST remain available and functional after the event's expiry date has passed.
|
||||
- **FR-009**: When an event is cancelled (US-18), the `.ics` file and `webcal://` feed MUST include `STATUS:CANCELLED`. [Deferred until US-18 is implemented]
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **CalendarFeed**: A virtual resource derived from the Event entity. Identified by the event token. Serialized to iCalendar (RFC 5545) format on demand. Has no independent storage — always generated from current event state.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: Downloading the `.ics` file and importing it into a standard calendar application (Google Calendar, Apple Calendar, Outlook) results in the event appearing with correct title, date/time, and location.
|
||||
- **SC-002**: Re-importing the `.ics` file after an event edit updates the existing calendar entry rather than creating a duplicate.
|
||||
- **SC-003**: Subscribing via `webcal://` and triggering a calendar sync after an event edit (US-5) reflects the updated details in the calendar application.
|
||||
- **SC-004**: Both endpoints are accessible without authentication and without transmitting any personal data.
|
||||
- **SC-005**: No external service is contacted during `.ics` generation or `webcal://` feed serving.
|
||||
@@ -1,107 +0,0 @@
|
||||
# Feature Specification: Highlight Changed Event Details
|
||||
|
||||
**Feature**: `014-highlight-changes`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
> **NOTE on directory name**: The migration task list specified `us-09-reminders` for this directory, but US-9 in userstories.md is "Highlight changed event details". The directory has been created as `014-highlight-changes` to match the actual story content. This is consistent with corrections made in iterations 16 (us-06-bookmark-event) and 18 (us-08-calendar-export).
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Guest sees highlight for recently changed fields (Priority: P1)
|
||||
|
||||
A guest opens an event page that the organizer has edited since the guest's last visit. Changed fields (e.g. new date, new location) are visually highlighted so the guest immediately notices what is different. After the page loads, the highlight is cleared for the next visit.
|
||||
|
||||
**Why this priority**: Core value of the feature — guests must notice important updates like a rescheduled date or changed location without having to read the entire page again.
|
||||
|
||||
**Independent Test**: Can be fully tested by creating an event, visiting it (establishing `last_seen_at`), editing it as organizer, then revisiting as guest — changed fields appear highlighted; unmodified fields do not.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a guest has previously visited an event page (establishing `last_seen_at` in localStorage), **When** the organizer saves an edit that changes one or more fields, **Then** on the guest's next visit those changed fields are visually highlighted with a "recently changed" indicator.
|
||||
2. **Given** an event with an edit, **When** a guest opens the event page and the `last_edited_at` timestamp is newer than the stored `last_seen_at`, **Then** only the fields changed in the most recent edit are highlighted; unmodified fields are not highlighted.
|
||||
3. **Given** a guest who has seen the latest edit, **When** they visit the event page again without any new edits having occurred, **Then** no highlights are shown.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - No highlight on first visit (Priority: P2)
|
||||
|
||||
A guest opens an event page for the first time (no `last_seen_at` in localStorage). Even if the organizer has made edits since creation, no "recently changed" highlights are shown — the event is new to the guest, so labelling fields as changed would be misleading.
|
||||
|
||||
**Why this priority**: Correctness requirement. Showing highlights on first visit would be confusing because the guest has no reference point for what "changed" means.
|
||||
|
||||
**Independent Test**: Can be tested by clearing localStorage and opening an edited event page — no highlight indicators should appear.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** no `last_seen_at` value in localStorage for a given event token, **When** a guest opens the event page, **Then** no field highlights are shown regardless of whether the organizer has made edits.
|
||||
2. **Given** a first visit with no `last_seen_at`, **When** the event page is rendered, **Then** `last_seen_at` is written to localStorage with the current `last_edited_at` value, so the next visit will correctly compare against it.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Highlight clears after viewing (Priority: P2)
|
||||
|
||||
After the guest views the highlighted changes, the highlight is cleared on the next visit. Subsequent visits to the same event page (without new edits) show no highlights.
|
||||
|
||||
**Why this priority**: Without this, the highlight would become permanent noise rather than a meaningful "new change" signal.
|
||||
|
||||
**Independent Test**: Can be tested by visiting an event page with a change (seeing highlights), then visiting again — highlights should be gone.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a guest views an event page with highlighted fields, **When** the page is rendered, **Then** `last_seen_at` in localStorage is updated to match the current `last_edited_at`.
|
||||
2. **Given** `last_seen_at` was updated on the previous visit, **When** the guest visits the event page again (with no new edits), **Then** no highlights are shown.
|
||||
|
||||
---
|
||||
|
||||
### User Story 4 - Only most recent edit is tracked (Priority: P3)
|
||||
|
||||
If the organizer makes multiple successive edits, only the fields changed in the most recent edit are highlighted. Intermediate changes between visits are not accumulated.
|
||||
|
||||
**Why this priority**: Simplicity constraint — tracking the full change history is overengineered for this scope. Guests see what changed last, not everything that ever changed.
|
||||
|
||||
**Independent Test**: Can be tested by making two successive edits to different fields, then visiting as a guest — only fields from the second edit are highlighted.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an organizer edits the event twice (first changing title, then changing location), **When** a guest visits the page after both edits, **Then** only the location is highlighted (changed in the most recent edit); title is not highlighted (changed in an earlier edit).
|
||||
2. **Given** an event with no edits since creation, **When** any guest visits the event page, **Then** no highlights are shown.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What if the organizer edits the event while the guest has the page open? The highlight logic runs on page load; open-page state is stale and will be corrected on the next visit.
|
||||
- What if localStorage is unavailable (e.g. private browsing)? No `last_seen_at` can be stored, so the guest is treated as a first-time visitor and no highlights are shown. This is safe and graceful.
|
||||
- What if `last_edited_at` is null (event has never been edited)? No highlights are shown. The field-change metadata is only populated on the first actual edit.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: System MUST record which fields changed (title, description, date/time, location) and store a `last_edited_at` timestamp server-side whenever the organizer saves an edit (US-5).
|
||||
- **FR-002**: System MUST include `last_edited_at` and the set of changed field names in the event page API response.
|
||||
- **FR-003**: Client MUST store a `last_seen_at` value per event token in localStorage, set to the event's `last_edited_at` on each page render.
|
||||
- **FR-004**: Client MUST compare the event's `last_edited_at` against the stored `last_seen_at` on page load to determine whether highlights should be shown.
|
||||
- **FR-005**: Client MUST display a "recently changed" visual indicator next to each field that appears in the server's changed-fields set, only when `last_edited_at` is newer than `last_seen_at`.
|
||||
- **FR-006**: Client MUST NOT show any highlights when no `last_seen_at` is present in localStorage for the event (first visit).
|
||||
- **FR-007**: Client MUST NOT show any highlights when `last_edited_at` is null or equal to `last_seen_at`.
|
||||
- **FR-008**: Client MUST update `last_seen_at` in localStorage after rendering the event page, regardless of whether highlights were shown.
|
||||
- **FR-009**: System MUST NOT transmit any visit data or `last_seen_at` value to the server — the read-state tracking is entirely client-side.
|
||||
- **FR-010**: System MUST track only the most recent edit's changed fields; intermediate changes between visits are not accumulated.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **EditMetadata** (server-side): Records `last_edited_at` timestamp and the set of changed field names for an event. Associated with the event record. Populated on first edit; overwritten on each subsequent edit.
|
||||
- **last_seen_at** (client-side, localStorage): Per-event-token timestamp. Records when the guest last viewed the event page. Used to determine whether highlights should be shown. Never transmitted to the server.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: A guest who has visited an event page before an edit correctly sees highlight indicators on the changed fields when revisiting after the edit.
|
||||
- **SC-002**: A guest who visits an event page for the first time sees no highlight indicators, even if edits have been made.
|
||||
- **SC-003**: Highlights disappear on the guest's next visit after they have viewed the highlighted changes.
|
||||
- **SC-004**: No server request beyond the normal event page load is required to determine whether highlights should be shown.
|
||||
- **SC-005**: No visit data or read-state information is transmitted to the server — privacy is fully preserved.
|
||||
@@ -1,74 +0,0 @@
|
||||
# Feature Specification: Post Update Messages as Organizer
|
||||
|
||||
**Feature**: `015-organizer-updates`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Post and manage update messages (Priority: P1)
|
||||
|
||||
As an event organizer, I want to post short update messages on the event page and manage them, so that guests are informed of announcements or notes without requiring a separate communication channel.
|
||||
|
||||
**Why this priority**: The ability to post and display update messages is the core capability of this feature. Without it, nothing else in this story is testable.
|
||||
|
||||
**Independent Test**: Can be tested by creating an event, posting an update message via the organizer view, and verifying the message appears on the public event page.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a valid organizer token is present in localStorage, **When** the organizer submits a plain-text update message, **Then** the message is stored server-side with a timestamp and appears on the public event page in reverse chronological order.
|
||||
2. **Given** multiple update messages have been posted, **When** a guest opens the event page, **Then** all messages are displayed newest-first, each with a human-readable timestamp.
|
||||
3. **Given** a valid organizer token is present in localStorage, **When** the organizer deletes a previously posted update message, **Then** the message is permanently removed and no longer appears on the public event page.
|
||||
4. **Given** no organizer token is present in localStorage, **When** a visitor views the event page, **Then** no compose or delete UI is shown and the server rejects any attempt to post or delete update messages.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Block posting after event expiry (Priority: P2)
|
||||
|
||||
As an event organizer, I want to be prevented from posting update messages after the event's expiry date has passed, so that the system remains consistent with the event lifecycle.
|
||||
|
||||
**Why this priority**: Expiry enforcement is a consistency constraint on top of the core posting capability.
|
||||
|
||||
**Independent Test**: Can be tested by attempting to post an update message via the API after an event's expiry date and verifying a rejection response is returned.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an event has passed its expiry date, **When** the organizer attempts to submit an update message, **Then** the server rejects the request and the message is not stored.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens if the organizer submits an empty or whitespace-only update message?
|
||||
- What is the maximum length of an update message? [NEEDS EXPANSION]
|
||||
- How many update messages can an event accumulate? [NEEDS EXPANSION]
|
||||
- Cancelled events (US-18): posting update messages is not blocked by cancellation, only by expiry — the organizer may want to post post-cancellation communication (e.g. a rescheduling notice or explanation).
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: System MUST allow the organizer to compose and submit a plain-text update message from the organizer view when a valid organizer token is present in localStorage.
|
||||
- **FR-002**: System MUST store each submitted update message server-side, associated with the event, with a server-assigned timestamp at the time of posting.
|
||||
- **FR-003**: System MUST display all update messages for an event on the public event page in reverse chronological order (newest first), each with a human-readable timestamp.
|
||||
- **FR-004**: System MUST reject any attempt to post an update message after the event's expiry date has passed.
|
||||
- **FR-005**: System MUST allow the organizer to permanently delete any previously posted update message from the organizer view.
|
||||
- **FR-006**: System MUST immediately remove a deleted update message from the public event page upon deletion.
|
||||
- **FR-007**: System MUST reject any attempt to post or delete update messages when the organizer token is absent or invalid.
|
||||
- **FR-008**: System MUST NOT show the compose or delete UI to visitors who do not have a valid organizer token in localStorage.
|
||||
- **FR-009**: System MUST NOT log personal data or IP addresses when update messages are fetched or posted.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **UpdateMessage**: A plain-text message associated with an event. Key attributes: event reference, message body (plain text), created_at timestamp. Owned by the event; deleted when the event is deleted (US-12, US-19) or manually removed by the organizer.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: A posted update message appears on the public event page without requiring a page reload beyond the normal navigation.
|
||||
- **SC-002**: Deleting an update message removes it from the public event page immediately upon deletion confirmation.
|
||||
- **SC-003**: An attempt to post an update message without a valid organizer token returns a 4xx error response from the server.
|
||||
- **SC-004**: An attempt to post an update message after the event's expiry date returns a 4xx error response from the server.
|
||||
- **SC-005**: No IP addresses or personal data appear in server logs when update messages are fetched or posted.
|
||||
@@ -1,84 +0,0 @@
|
||||
# Feature Specification: New-Update Indicator for Guests
|
||||
|
||||
**Feature**: `016-guest-notifications`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Unread update indicator (Priority: P1)
|
||||
|
||||
A guest opens the event page and sees a visual indicator (badge or highlighted section) drawing attention to update messages that were posted since their last visit. The read state is tracked entirely in localStorage — no server involvement.
|
||||
|
||||
**Why this priority**: Core purpose of this feature. Without this, guests miss new organizer announcements unless they manually read through all messages.
|
||||
|
||||
**Independent Test**: Can be tested by opening an event page after new update messages have been posted, verifying that a badge or visual highlight appears on the update messages section.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a guest has previously visited the event page and `updates_last_seen_at` is stored in localStorage, **When** they return and the event has updates newer than `updates_last_seen_at`, **Then** a visual indicator is shown drawing attention to the unread messages.
|
||||
2. **Given** the event page is rendered with unread updates shown, **When** the page finishes loading, **Then** `updates_last_seen_at` in localStorage is updated to the timestamp of the most recent update, so the indicator does not appear on the next visit.
|
||||
3. **Given** a guest opens the event page and all updates are older than the stored `updates_last_seen_at`, **When** the page loads, **Then** no "new update" indicator is shown.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - First visit: no indicator (Priority: P2)
|
||||
|
||||
A guest who has never visited the event page before (no `updates_last_seen_at` in localStorage) sees the update messages without any "new" badge or indicator.
|
||||
|
||||
**Why this priority**: A first-time visitor has not established a baseline; labeling existing updates as "new" would be misleading since they have never seen the event before.
|
||||
|
||||
**Independent Test**: Can be tested by opening an event page on a device with no prior localStorage state for that event token, verifying that no unread indicator is shown even if update messages are present.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a guest opens an event page for the first time (no `updates_last_seen_at` in localStorage for this event token), **When** the page loads and update messages are present, **Then** no "new update" indicator is shown and `updates_last_seen_at` is initialized to the most recent update timestamp.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - No server read-tracking (Priority: P1)
|
||||
|
||||
No server request is made to record that a guest viewed the updates. The read state is purely client-side.
|
||||
|
||||
**Why this priority**: Fundamental privacy requirement — tracking which guests have read which updates would be a form of user surveillance, violating the project's privacy statutes.
|
||||
|
||||
**Independent Test**: Can be tested by inspecting network traffic when a guest opens the event page, verifying that no "mark as read" or analytics request is sent.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a guest opens the event page with unread updates, **When** the page loads and `updates_last_seen_at` is updated in localStorage, **Then** no additional server request is made to record the read event.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens when all update messages are deleted (US-10a) and a guest reopens the page? The stored `updates_last_seen_at` should remain in localStorage; no indicator is shown since there are no updates to compare against.
|
||||
- What happens if localStorage is unavailable (private browsing, storage quota exceeded)? The indicator is not shown (degrades gracefully); no error is displayed to the user.
|
||||
- The `updates_last_seen_at` key is separate from the `last_seen_at` key used in US-9 (field-change highlights). The two mechanisms operate independently.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: System MUST display a visual indicator (badge or highlighted section) on the event page when the guest has unread update messages, determined by comparing the newest update's timestamp against `updates_last_seen_at` stored in localStorage.
|
||||
- **FR-002**: System MUST store the `updates_last_seen_at` timestamp in localStorage per event token after each page render, so the indicator clears on subsequent visits.
|
||||
- **FR-003**: System MUST NOT show a "new update" indicator on a guest's first visit to an event page (when no `updates_last_seen_at` exists in localStorage for that event token).
|
||||
- **FR-004**: System MUST initialize `updates_last_seen_at` in localStorage on first visit, set to the timestamp of the most recent update (or a sentinel value if no updates exist), to prevent spurious indicators on subsequent visits.
|
||||
- **FR-005**: System MUST NOT transmit any data to the server when a guest views or is marked as having read update messages — read tracking is purely client-side.
|
||||
- **FR-006**: System MUST use a localStorage key distinct from the `last_seen_at` key used in US-9 to avoid conflicts between the two read-state mechanisms.
|
||||
- **FR-007**: System MUST degrade gracefully if localStorage is unavailable: no indicator is shown, and no error is surfaced to the user.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **UpdateReadState** (client-side only): Stored in localStorage, keyed by event token. Contains `updates_last_seen_at` (timestamp of the most recent update at last visit). Never transmitted to the server.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: A guest who has not visited an event page since a new update was posted sees a visual indicator on their next visit, without any server request being made to track readership.
|
||||
- **SC-002**: After the event page is rendered, the same guest sees no indicator on their next visit (indicator clears after viewing).
|
||||
- **SC-003**: A first-time visitor to an event page with existing updates sees no "new" indicator.
|
||||
- **SC-004**: No network request is sent to the server when the read state transitions from unread to read.
|
||||
- **SC-005**: The read-state mechanism is independent of US-9's field-change highlight mechanism — toggling one does not affect the other.
|
||||
@@ -1,60 +0,0 @@
|
||||
# Feature Specification: Generate a QR Code for an Event
|
||||
|
||||
**Feature**: `017-qr-code`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Display and Download QR Code (Priority: P1)
|
||||
|
||||
Any visitor who holds the event link can view a QR code on the event page that encodes the public event URL. The QR code is generated server-side — no external service is contacted — and can be downloaded as a print-ready file (SVG or high-resolution PNG). This makes it easy to print the code on posters or flyers.
|
||||
|
||||
**Why this priority**: This is the core deliverable of US-11. Without a downloadable, server-generated QR code, the feature has no value. All other criteria are conditions of this baseline.
|
||||
|
||||
**Independent Test**: Can be fully tested by loading any event page and verifying that a QR code is displayed, that a download link produces a valid SVG or PNG file whose content encodes the correct event URL, and that no external network request was made to generate it.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a valid event exists, **When** a visitor opens the event page, **Then** a QR code encoding the public event URL is displayed on the page.
|
||||
2. **Given** a QR code is displayed, **When** the visitor clicks the download link, **Then** a file (SVG or high-resolution PNG) is downloaded directly from the app's backend without client-side generation.
|
||||
3. **Given** the downloaded file, **When** it is scanned with a QR reader, **Then** it resolves to the correct public event URL.
|
||||
4. **Given** the QR code endpoint is accessed, **When** the server generates the code, **Then** no request is made to any external QR code service.
|
||||
5. **Given** a visitor who has not RSVPed or logged in, **When** they access the event page, **Then** the QR code and download link are still available — no organizer token or RSVP required.
|
||||
6. **Given** the event has expired, **When** a visitor opens the event page, **Then** the QR code and download link remain available and functional.
|
||||
7. **Given** the QR code download is requested, **When** the server handles the request, **Then** no personal data, IP address, or identifier is transmitted to any third party.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens when the event does not exist? The server returns "event not found" — the QR code endpoint must behave consistently and not leak data.
|
||||
- How does the download link behave when the event URL is long? The QR code must be generated at sufficient error-correction level to remain scannable even for longer URLs.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: The event page MUST display a QR code that encodes the public event URL.
|
||||
- **FR-002**: The QR code MUST be generated entirely server-side — no external QR code service or third-party API may be contacted.
|
||||
- **FR-003**: The QR code MUST be downloadable as a file suitable for printing (SVG or high-resolution PNG).
|
||||
- **FR-004**: The QR code download MUST be served from a direct backend endpoint — the actual file download MUST NOT require client-side generation.
|
||||
- **FR-005**: The QR code MUST be accessible to any visitor holding the event link; no organizer token or RSVP is required.
|
||||
- **FR-006**: No personal data, IP address, or identifier MUST be transmitted to any third party when the QR code is generated or downloaded.
|
||||
- **FR-007**: The QR code MUST remain available and downloadable after the event has expired.
|
||||
- **FR-008**: The QR code endpoint MUST return a consistent "event not found" response if the event does not exist — no partial data or error traces may be exposed.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **QRCode**: Virtual — no independent storage. Generated on demand from the event token and the public event URL. Not persisted.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: A visitor can view a QR code on any event page without performing any additional action (no login, no RSVP).
|
||||
- **SC-002**: The downloaded file scans correctly to the event URL in at least two independent QR reader applications.
|
||||
- **SC-003**: No outbound network request to an external service is made during QR code generation (verifiable via network inspection).
|
||||
- **SC-004**: The QR code endpoint returns a valid file for both active and expired events.
|
||||
- **SC-005**: The download link works without JavaScript (direct server endpoint).
|
||||
@@ -1,90 +0,0 @@
|
||||
# Feature Specification: Automatic Data Deletion After Expiry Date
|
||||
|
||||
**Feature**: `018-data-deletion`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Automatic cleanup of expired event data (Priority: P1)
|
||||
|
||||
As a guest, I want all event data — including my RSVP and any other stored personal information — to be automatically and permanently deleted after the event's expiry date, so that I can trust that data I submitted is not retained on the server longer than necessary.
|
||||
|
||||
**Why this priority**: This is a privacy guarantee, not merely a housekeeping task. The mandatory expiry date in US-1 is only meaningful if the server actually enforces deletion. Without this story, the expiry date is a lie.
|
||||
|
||||
**Independent Test**: Can be tested by creating an event with a near-future expiry date, submitting an RSVP, waiting for expiry, and verifying that the event's public URL returns "event not found" and no data remains accessible.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an event whose expiry date has passed, **When** the cleanup process runs, **Then** the event record and all associated data (RSVPs, update messages, field-change metadata, header images, cancellation state) are permanently deleted from the server.
|
||||
2. **Given** an event that has been deleted by the cleanup process, **When** a guest navigates to the event's public URL, **Then** the server returns a clear "event not found" response with no partial data or error traces.
|
||||
3. **Given** a deletion event, **When** the cleanup process deletes data, **Then** no log entry records the names, RSVPs, or any personal data of the deleted event's guests — the deletion is silent from a logging perspective.
|
||||
4. **Given** the cleanup process, **When** it runs, **Then** it runs automatically without manual operator intervention (e.g. via a scheduled job or on-request lazy cleanup triggered by access attempts).
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Expiry date extension delays deletion (Priority: P2)
|
||||
|
||||
As an event organizer, I want to be able to extend the expiry date of my event (via US-5) and have the deletion be deferred accordingly, so that I can keep my event data available for longer when needed.
|
||||
|
||||
**Why this priority**: Ensures US-5 (edit expiry date) and US-12 (deletion) work together correctly — the cleanup must always use the current stored expiry date, not the original one.
|
||||
|
||||
**Independent Test**: Can be tested by creating an event, extending its expiry date before expiry passes, and verifying that the event data is not deleted until the new expiry date.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an event whose expiry date was extended via US-5 before the original expiry passed, **When** the cleanup process runs after the original date but before the new date, **Then** the event data is not deleted.
|
||||
2. **Given** an event whose expiry date was extended, **When** the new expiry date passes and the cleanup process runs, **Then** the event and all associated data are deleted.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Cleanup does not trigger early (Priority: P2)
|
||||
|
||||
As a guest, I want my event data to be retained until the expiry date has fully passed, so that I can access the event page right up until expiry without unexpected data loss.
|
||||
|
||||
**Why this priority**: Ensures correctness — data must not be deleted prematurely.
|
||||
|
||||
**Independent Test**: Can be tested by verifying that an event with an expiry date set to tomorrow remains fully accessible today.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an event whose expiry date is today but has not yet passed, **When** a guest accesses the event page, **Then** the event data is still served normally.
|
||||
2. **Given** an event whose expiry date passed yesterday, **When** the cleanup process runs, **Then** the event and all associated data are deleted.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens if the cleanup process fails mid-run (e.g. server crash)? The next run must safely re-attempt deletion without corrupting partial state.
|
||||
- What happens if multiple cleanup runs overlap? The process must be idempotent — deleting an already-deleted event must not cause errors.
|
||||
- LocalStorage entries on guests' devices are unaffected by server-side deletion — this is intentional. The app handles the "event not found" response gracefully (US-2, US-7).
|
||||
- If a stored header image file is missing on disk at deletion time (e.g. corrupted storage), the cleanup must still complete and delete the database record.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: The server MUST run a periodic cleanup process that automatically deletes all data associated with events whose expiry date has passed.
|
||||
- **FR-002**: The cleanup MUST delete the event record along with all associated data: RSVPs, update messages (US-10a), field-change metadata (US-9), stored header images (US-16) [deferred until US-16 is implemented], and cancellation state (US-18 if applicable).
|
||||
- **FR-003**: After deletion, the event's public URL MUST return a clear "event not found" response — no partial data is ever served.
|
||||
- **FR-004**: The cleanup process MUST run automatically without manual operator intervention (e.g. a scheduled job, Spring `@Scheduled`, or on-request lazy cleanup triggered by access attempts).
|
||||
- **FR-005**: The cleanup MUST NOT log the names, RSVPs, or any personal data of deleted events — deletion is silent from a logging perspective.
|
||||
- **FR-006**: The cleanup MUST always use the current stored expiry date when determining whether an event is eligible for deletion — extending the expiry date via US-5 before expiry passes delays deletion accordingly.
|
||||
- **FR-007**: The cleanup MUST NOT be triggered early — data is retained until the expiry date has passed, not before.
|
||||
- **FR-008**: The cleanup process MUST be idempotent — re-running it against already-deleted events must not cause errors.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **Event (expiry_date)**: The `expiry_date` field on the Event entity determines when the event becomes eligible for deletion. It is updated by US-5 (edit event details).
|
||||
- **Cleanup Job**: A background process (not a user-facing entity) responsible for identifying and deleting expired events and all their associated data.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: An event with a passed expiry date returns "event not found" from the server within one cleanup cycle of the expiry.
|
||||
- **SC-002**: All associated data (RSVPs, update messages, metadata, images) is deleted atomically with the event record — no orphaned records remain after a successful cleanup run.
|
||||
- **SC-003**: No PII (names, RSVP choices) appears in server logs during or after the deletion process.
|
||||
- **SC-004**: Extending an event's expiry date via US-5 correctly defers deletion — verified by querying the database after the original expiry would have triggered cleanup.
|
||||
- **SC-005**: The cleanup process completes successfully even if a stored header image file is missing on disk (resilient to partial storage failures).
|
||||
@@ -1,88 +0,0 @@
|
||||
# Feature Specification: Limit Active Events Per Instance
|
||||
|
||||
**Feature**: `019-instance-limit`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md (US-13)
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Enforce Configured Event Cap on Creation (Priority: P1)
|
||||
|
||||
As a self-hoster, I want to configure a maximum number of simultaneously active events via a server environment variable, so that I can prevent storage exhaustion and limit potential abuse on my instance without modifying code.
|
||||
|
||||
**Why this priority**: The event cap is the primary deliverable of this story — without it, there is no feature. All other scenarios are edge cases of this core enforcement behavior.
|
||||
|
||||
**Independent Test**: Can be fully tested by configuring `MAX_ACTIVE_EVENTS=1`, creating one event, then attempting to create a second — the second creation should be rejected with a clear error.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the server is configured with `MAX_ACTIVE_EVENTS=3` and 3 non-expired events exist, **When** a user submits the event creation form, **Then** the server rejects the request with a clear error indicating the instance is at capacity, and the frontend surfaces this error on the creation form — not as a silent failure.
|
||||
2. **Given** the server is configured with `MAX_ACTIVE_EVENTS=3` and 2 non-expired events exist, **When** a user submits the event creation form, **Then** the request succeeds and the new event is created normally.
|
||||
3. **Given** the server is configured with `MAX_ACTIVE_EVENTS=3` and 3 non-expired events exist, but 1 is past its expiry date (awaiting cleanup), **When** a user submits the event creation form, **Then** the request succeeds — expired events do not count toward the limit.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - No Limit When Variable Is Unset (Priority: P2)
|
||||
|
||||
As a self-hoster running a personal or trusted-group instance, I want no event limit applied by default, so that I do not need to configure anything to run the app normally.
|
||||
|
||||
**Why this priority**: The default behavior (unlimited) must be safe and require no configuration. Self-hosters who do not need a cap should not have to think about this setting.
|
||||
|
||||
**Independent Test**: Can be fully tested by starting the server without `MAX_ACTIVE_EVENTS` set and verifying that multiple events can be created without rejection.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the server has no `MAX_ACTIVE_EVENTS` environment variable set, **When** any number of events are created, **Then** no capacity error is returned — event creation is unlimited.
|
||||
2. **Given** the server has `MAX_ACTIVE_EVENTS` set to an empty string, **When** events are created, **Then** no capacity error is returned — an empty value is treated the same as unset.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Cap Is Enforced Server-Side Only (Priority: P2)
|
||||
|
||||
As a self-hoster, I want the event cap to be enforced exclusively on the server, so that it cannot be bypassed by a modified or malicious client.
|
||||
|
||||
**Why this priority**: Client-side enforcement alone would be trivially bypassable. The server is the authoritative enforcement point.
|
||||
|
||||
**Independent Test**: Can be fully tested by sending a direct HTTP POST to the event creation endpoint (bypassing the frontend entirely) when the cap is reached — the server must reject it.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the configured cap is reached, **When** a direct HTTP POST is made to the event creation endpoint (bypassing the frontend), **Then** the server returns an error response indicating the instance is at capacity.
|
||||
2. **Given** the configured cap is reached, **When** no personal data is included in the rejection response or logs, **Then** the server returns only the rejection status — no PII is logged.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens when `MAX_ACTIVE_EVENTS=0`? [NEEDS EXPANSION — treat as "no limit" or "reject all"? Clarify during implementation.]
|
||||
- What happens when `MAX_ACTIVE_EVENTS` is set to a non-integer value? The server should fail fast at startup with a clear configuration error.
|
||||
- Race condition: two concurrent creation requests when the cap is at N-1. The server must handle this atomically — one request succeeds, the other is rejected.
|
||||
- Expired events that have not yet been cleaned up must not count toward the limit. The check must query only non-expired events.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: The server MUST read a `MAX_ACTIVE_EVENTS` environment variable at startup to determine the event creation cap.
|
||||
- **FR-002**: If `MAX_ACTIVE_EVENTS` is set to a positive integer and the number of non-expired events equals or exceeds that value, the server MUST reject new event creation requests with a clear error response.
|
||||
- **FR-003**: The frontend MUST surface the capacity error on the event creation form — not as a silent failure or generic error.
|
||||
- **FR-004**: If `MAX_ACTIVE_EVENTS` is unset or empty, the server MUST apply no limit — event creation is unlimited.
|
||||
- **FR-005**: Only non-expired events MUST count toward the limit; expired events awaiting cleanup are excluded from the count.
|
||||
- **FR-006**: The limit MUST be enforced server-side; client-side state or input cannot bypass it.
|
||||
- **FR-007**: No personal data or PII MUST be logged when a creation request is rejected due to the cap.
|
||||
- **FR-008**: The `MAX_ACTIVE_EVENTS` environment variable MUST be documented in the README's self-hosting section (configuration table).
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **Event (active count)**: The count of events whose `expiry_date` is in the future. This is the value checked against `MAX_ACTIVE_EVENTS` at event creation time.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: When the cap is reached, a POST to the event creation endpoint returns an appropriate HTTP error status with a machine-readable error body.
|
||||
- **SC-002**: The capacity error is displayed to the user on the creation form with a message that does not expose internal state or configuration values.
|
||||
- **SC-003**: Creating events up to but not exceeding the cap succeeds without any change in behavior compared to uncapped instances.
|
||||
- **SC-004**: The `MAX_ACTIVE_EVENTS` variable appears in the README configuration table with its type, default, and description documented.
|
||||
- **SC-005**: Expired events (past `expiry_date`) are never counted toward the cap, verifiable by inspecting the query or checking behavior after expiry.
|
||||
@@ -1,73 +0,0 @@
|
||||
# Feature Specification: Install as Progressive Web App
|
||||
|
||||
**Feature**: `020-pwa`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Install the app on a mobile or desktop device (Priority: P1)
|
||||
|
||||
**As a** guest,
|
||||
**I want to** install the app on my device from the browser,
|
||||
**so that** it feels like a native app and I can launch it directly from my home screen.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the app is open in a supported mobile browser, **When** the user opens the browser menu, **Then** an "Add to Home Screen" or install prompt is available because the app serves a valid manifest and a registered service worker.
|
||||
|
||||
2. **Given** the user has installed the app, **When** they launch it from the home screen, **Then** the app opens in standalone mode — without browser address bar or navigation chrome.
|
||||
|
||||
3. **Given** the app is installed, **When** the user views their device's home screen or app switcher, **Then** the configured icon and app name are displayed.
|
||||
|
||||
4. **Given** the user has visited the app previously, **When** they open the app again (including on a slow or offline connection), **Then** previously loaded pages and assets load quickly due to service worker caching.
|
||||
|
||||
5. **Given** the app is installed and launched from the home screen, **When** the app starts, **Then** the start URL is the root page (`/`), which serves the local event overview (US-7), so returning users see their tracked events immediately.
|
||||
|
||||
### User Story 2 - Serve a valid web app manifest (Priority: P1)
|
||||
|
||||
**As a** browser,
|
||||
**I want** the app to serve a well-formed web app manifest,
|
||||
**so that** I can offer the user an install prompt and render the installed app correctly.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a browser fetches the app's manifest, **Then** it includes at minimum: app name, icons in multiple sizes, standalone display mode, theme color, and a start URL.
|
||||
|
||||
2. **Given** the manifest and service worker are present, **Then** the app meets browser installability requirements (manifest + registered service worker) so that the install prompt is available on supported browsers.
|
||||
|
||||
3. **Given** the manifest or service worker loads assets, **Then** no external resources are fetched — all assets referenced are self-hosted.
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- Browsers that do not support service workers or PWA installation should still render the app normally — PWA features are an enhancement, not a requirement.
|
||||
- If the service worker fails to install (e.g. due to a browser policy), the app must still function as a standard web page.
|
||||
- Service worker caching strategy (cache-first, network-first, stale-while-revalidate) is an implementation decision to be determined during implementation.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-01**: The app serves a valid web app manifest (JSON) accessible at a standard path (e.g. `/manifest.webmanifest` or `/manifest.json`).
|
||||
- **FR-02**: The manifest includes at minimum: app name, short name, icons in multiple sizes (e.g. 192x192 and 512x512), `display: "standalone"`, `theme_color`, `background_color`, and `start_url: "/"`.
|
||||
- **FR-03**: The app registers a service worker that meets browser installability requirements alongside the manifest.
|
||||
- **FR-04**: When launched from the home screen, the app opens in standalone mode without browser navigation chrome.
|
||||
- **FR-05**: The app icon and name are shown on the device home screen and in the OS app switcher after installation.
|
||||
- **FR-06**: The service worker caches app assets so that repeat visits load quickly.
|
||||
- **FR-07**: The manifest's start URL is `/`, serving the local event overview (US-7).
|
||||
- **FR-08**: No external resources (CDNs, external fonts, remote icons) are fetched by the manifest or service worker — all assets are self-hosted.
|
||||
- **FR-09**: PWA installability does not depend on any backend state — it is a purely frontend concern served by the static assets.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **Web App Manifest**: A static JSON file describing the app's identity, icons, display mode, and start URL. No database storage required.
|
||||
- **Service Worker**: A client-side script registered by the app to handle caching and (optionally) offline behavior. No server-side representation.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
1. A supported mobile browser shows an "Add to Home Screen" prompt or install banner for the app.
|
||||
2. After installation, the app launches in standalone mode with the correct icon and name.
|
||||
3. The installed app's start URL leads directly to the local event overview (`/`).
|
||||
4. Repeat visits are noticeably faster due to service worker asset caching.
|
||||
5. No external resources are loaded by the manifest or service worker — all assets are served from the app's own origin.
|
||||
@@ -1,74 +0,0 @@
|
||||
# Feature Specification: Choose Event Color Theme
|
||||
|
||||
**Feature**: `021-color-themes`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Select color theme during event creation (Priority: P1)
|
||||
|
||||
An organizer creating a new event can select a visual color theme from a predefined set. If no theme is selected, a default theme is applied automatically. The choice is persisted server-side and the guest-facing event page renders with the selected theme.
|
||||
|
||||
**Why this priority**: Core feature value — without theme selection during creation, the feature has no entry point.
|
||||
|
||||
**Independent Test**: Can be fully tested by creating an event, selecting a non-default theme, and verifying the event page renders with the correct theme applied.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the event creation form is open, **When** the organizer selects a predefined color theme and submits the form, **Then** the theme is persisted server-side alongside the event data.
|
||||
2. **Given** an event has been created with a specific theme, **When** a guest opens the event page, **Then** the page renders with the selected color theme applied.
|
||||
3. **Given** the event creation form is open, **When** the organizer submits the form without selecting a theme, **Then** a default theme is applied and persisted server-side.
|
||||
4. **Given** a theme has been applied to an event, **When** the event page renders, **Then** only the event page is themed — the app's global UI (navigation, local overview, forms) is unaffected.
|
||||
5. **Given** a predefined theme is applied, **When** the event page renders, **Then** no external resources are required — all styles are self-contained.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Update color theme via event editing (Priority: P2)
|
||||
|
||||
An organizer editing an existing event can change the event's color theme. The updated theme is persisted server-side and reflected immediately on the guest-facing event page.
|
||||
|
||||
**Why this priority**: Extends the P1 creation flow to editing. Less critical than initial theme selection but necessary for full feature completeness.
|
||||
|
||||
**Independent Test**: Can be fully tested by editing an existing event, changing its theme, and verifying the event page updates accordingly.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an event with an existing theme, **When** the organizer opens the edit form (US-5), **Then** the current theme selection is shown in the customization UI.
|
||||
2. **Given** the organizer changes the theme in the edit form and saves, **When** a guest opens the event page, **Then** the updated theme is applied.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens when the theme value stored server-side no longer matches any predefined theme (e.g. after an app upgrade removes a theme)? The system must fall back to the default theme gracefully — no broken styles.
|
||||
- How does the event-level color theme interact with the app-level dark/light mode (US-17)? Predefined themes must remain readable and visually coherent regardless of whether dark or light mode is active in the surrounding app chrome.
|
||||
- What if no theme is stored at all (legacy events created before this feature)? The default theme must be applied as a safe fallback.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: The system MUST offer a set of predefined color themes for event pages.
|
||||
- **FR-002**: The event creation form MUST include a theme selection UI (e.g. color swatches or named options).
|
||||
- **FR-003**: The event editing form (US-5) MUST include the same theme selection UI, pre-populated with the current theme.
|
||||
- **FR-004**: The selected theme MUST be persisted server-side as part of the event record.
|
||||
- **FR-005**: A default theme MUST be applied if the organizer makes no explicit selection.
|
||||
- **FR-006**: The guest-facing event page MUST render with the event's stored color theme.
|
||||
- **FR-007**: Event-level color themes MUST affect only the event page — not the app's global UI (navigation, local overview, forms, or any other chrome).
|
||||
- **FR-008**: All theme styles MUST be self-contained — no external resources (CDNs, external stylesheets) may be required for any predefined theme.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **ColorTheme**: A predefined named color scheme. Stored as a reference (e.g. a string identifier) on the Event entity. Not an independent database entity — it is a value type on the Event.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: An organizer can select a color theme during event creation and the selection is reflected on the event page without additional steps.
|
||||
- **SC-002**: All predefined themes render correctly without external network requests.
|
||||
- **SC-003**: Changing the theme via the edit form (US-5) is reflected immediately on the next event page load.
|
||||
- **SC-004**: The default theme is applied automatically to all events without an explicit theme selection, including legacy events created before this feature.
|
||||
- **SC-005**: Event-level theming does not interfere with the app-level dark/light mode (US-17) — both can coexist without breaking contrast or readability (WCAG AA).
|
||||
@@ -1,106 +0,0 @@
|
||||
# Feature Specification: Select Event Header Image from Unsplash
|
||||
|
||||
**Feature**: `022-header-image`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Select header image during creation or editing (Priority: P1)
|
||||
|
||||
The event organizer can search for a header image via an integrated Unsplash search during event creation or editing. The search is server-proxied — the client never contacts Unsplash directly. When an image is selected, the server downloads and stores it locally. Proper Unsplash attribution is displayed on the event page.
|
||||
|
||||
**Why this priority**: Core functionality of this feature. All other stories depend on an image being selectable and stored.
|
||||
|
||||
**Independent Test**: Can be fully tested by creating an event with a header image selected, verifying the event page renders the image served from the app's own domain with attribution.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the organizer is on the event creation or editing form and the server has an Unsplash API key configured, **When** the organizer enters a search query, **Then** the client sends the query to the app's backend which proxies it to Unsplash and returns results — the client never contacts Unsplash directly.
|
||||
2. **Given** the organizer selects an image from search results, **When** the selection is confirmed, **Then** the server downloads and stores the image locally on disk and serves it from the app's own domain.
|
||||
3. **Given** an event has a stored header image, **When** a guest views the event page, **Then** the header image is rendered and Unsplash attribution (photographer name and link to Unsplash) is displayed alongside it.
|
||||
4. **Given** an event has a header image, **When** the organizer removes it, **Then** the image is no longer displayed on the event page.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Event page renders header image (Priority: P1)
|
||||
|
||||
The guest-facing event page renders the selected header image if one is set. The image is served from the app's own domain, not from Unsplash's CDN, so no guest data or IP address is transmitted to Unsplash.
|
||||
|
||||
**Why this priority**: Directly impacts the visual presentation that motivated the feature.
|
||||
|
||||
**Independent Test**: Can be tested by loading an event page with a stored header image and verifying the image URL is on the app's domain and no network request is made to Unsplash domains.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an event has a stored header image, **When** a guest opens the event page, **Then** the image is loaded from the app's own domain and no request is made to Unsplash or any third-party CDN.
|
||||
2. **Given** an event has no header image set, **When** a guest opens the event page, **Then** the page renders without a header image and no error is shown.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Feature unavailable when API key not configured (Priority: P2)
|
||||
|
||||
If the server has no Unsplash API key configured, the image search feature is simply not shown in the UI. No error is displayed. Existing stored images continue to serve normally if the key is removed after images were already stored.
|
||||
|
||||
**Why this priority**: Required for graceful degradation — the feature must not break the app when the API key is absent.
|
||||
|
||||
**Independent Test**: Can be tested by starting the server without `UNSPLASH_API_KEY` set and verifying the image search UI is absent from the creation and editing forms, and that any previously stored images still render.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the server has no `UNSPLASH_API_KEY` environment variable set, **When** the organizer opens the event creation or editing form, **Then** the image search option is not shown — no error, no broken UI element.
|
||||
2. **Given** the API key is removed from the config after images were already stored, **When** a guest opens an event page with a previously stored image, **Then** the image still renders from disk and only the search/select UI becomes unavailable.
|
||||
|
||||
---
|
||||
|
||||
### User Story 4 - Image deleted with event on expiry (Priority: P2)
|
||||
|
||||
When an event expires and is deleted by the cleanup process (US-12), the stored header image file is deleted along with all other event data.
|
||||
|
||||
**Why this priority**: Privacy requirement — stored files must not outlive the event data.
|
||||
|
||||
**Independent Test**: Can be tested by creating an event with a header image, expiring it, running the cleanup process, and verifying the image file no longer exists on disk.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an event with a stored header image has passed its expiry date, **When** the cleanup process runs (US-12), **Then** the image file is deleted from disk along with the event record and all associated data.
|
||||
2. **Given** an event with a header image is explicitly deleted by the organizer (US-19), **When** the deletion is confirmed, **Then** the image file is deleted from disk immediately.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens when the Unsplash API returns an error or rate-limit response? — Server returns a clear error to the client; the organizer can retry.
|
||||
- What happens when disk is full and the server cannot store the downloaded image? — Server returns an error; the event can still be created/saved without an image.
|
||||
- What happens if an image download from Unsplash fails mid-transfer? — Server returns an error; no partial file is stored.
|
||||
- What happens if the `UNSPLASH_API_KEY` is set but invalid? — Server proxies the call and returns the Unsplash API error to the client (e.g. "unauthorized").
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: The server MUST expose an Unsplash image search proxy endpoint that accepts a query string, calls the Unsplash API server-side, and returns results to the client — the client MUST NOT contact Unsplash directly.
|
||||
- **FR-002**: When an image is selected, the server MUST download and store the image file locally on disk; the image MUST be served from the app's own domain.
|
||||
- **FR-003**: The server MUST store Unsplash attribution metadata (photographer name and Unsplash URL) alongside the image reference and display it on the event page.
|
||||
- **FR-004**: The organizer MUST be able to remove a previously selected header image.
|
||||
- **FR-005**: The guest-facing event page MUST render the header image if one is set, served from the app's own domain.
|
||||
- **FR-006**: If `UNSPLASH_API_KEY` is not configured, the image search UI MUST NOT be shown; no error is displayed.
|
||||
- **FR-007**: If the API key is removed after images were stored, existing images MUST continue to render from disk; only the search/select UI becomes unavailable.
|
||||
- **FR-008**: The server MUST NOT log any guest IP address or identifier when serving the stored image.
|
||||
- **FR-009**: When an event is deleted (US-12 or US-19), the server MUST delete the stored image file along with all other event data.
|
||||
- **FR-010**: The `UNSPLASH_API_KEY` environment variable and the persistent volume requirement for image storage MUST be documented in the README's self-hosting section.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **HeaderImage**: Stored image file on disk, associated with an event. Attributes: local file path, Unsplash image ID, photographer name, photographer URL, Unsplash attribution URL. Not independently stored — deleted with the event.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: A guest opening an event page with a header image makes no network requests to Unsplash or any third-party domain.
|
||||
- **SC-002**: Removing the `UNSPLASH_API_KEY` does not break the app, the event creation form, or the rendering of previously stored images.
|
||||
- **SC-003**: After event expiry and cleanup, no image file remains on disk for that event.
|
||||
- **SC-004**: Unsplash attribution (photographer name and link) is visible on every event page that has a header image.
|
||||
- **SC-005**: The image search, download, and storage flow works end-to-end when a valid API key is configured.
|
||||
@@ -1,120 +0,0 @@
|
||||
# Feature Specification: Dark/Light Mode
|
||||
|
||||
**Feature**: `023-dark-mode`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - System preference respected on first visit (Priority: P1)
|
||||
|
||||
A user opens the app for the first time. The app automatically adopts their operating system or browser dark/light preference without any manual configuration required. No preference data is transmitted to the server.
|
||||
|
||||
**Why this priority**: This is the baseline behavior — it works without any user interaction and provides the correct experience immediately.
|
||||
|
||||
**Independent Test**: Can be tested by opening the app in a browser with `prefers-color-scheme: dark` set at the OS level and verifying the dark theme is applied, then repeating with light preference.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a user opens the app for the first time with no manual preference stored, **When** the OS/browser preference is `prefers-color-scheme: dark`, **Then** the app renders in dark mode.
|
||||
2. **Given** a user opens the app for the first time with no manual preference stored, **When** the OS/browser preference is `prefers-color-scheme: light`, **Then** the app renders in light mode.
|
||||
3. **Given** the app is rendering in either mode, **When** the page is loaded, **Then** no server request is made and no preference data is transmitted.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Manual toggle overrides system preference (Priority: P1)
|
||||
|
||||
A user can switch between dark and light mode using a visible toggle available on any page. Their choice is persisted in localStorage and takes precedence over the OS preference on all subsequent visits.
|
||||
|
||||
**Why this priority**: The explicit user preference must be honoured and must persist — without this, the toggle would reset on every visit, making it unusable.
|
||||
|
||||
**Independent Test**: Can be tested by toggling the mode, closing and reopening the browser, and verifying the manually selected mode is still active even if it differs from the OS preference.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the app is in light mode (system preference), **When** the user activates the dark mode toggle, **Then** the UI immediately switches to dark mode and the preference is stored in localStorage.
|
||||
2. **Given** the user has a dark mode preference stored in localStorage, **When** the user revisits the app, **Then** dark mode is applied regardless of the current OS/browser preference.
|
||||
3. **Given** the user has a light mode preference stored in localStorage and the OS preference is dark, **When** the user revisits the app, **Then** light mode is applied (localStorage takes precedence).
|
||||
4. **Given** the app is running, **When** the user toggles the mode, **Then** no server request is made and no preference data is transmitted.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Toggle accessible from any page (Priority: P2)
|
||||
|
||||
The dark/light mode toggle is reachable from every page of the app — event pages, local event overview, creation form, etc. — so the user never has to navigate away to change their preference.
|
||||
|
||||
**Why this priority**: This is a usability enhancement. The feature works without it (if the toggle were only on one page), but accessibility from any page is important for a good experience.
|
||||
|
||||
**Independent Test**: Can be tested by navigating to the event page, the local event overview, and the creation form and verifying the toggle is visible and functional on each.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the user is on the local event overview page (`/`), **When** they look for the mode toggle, **Then** it is visible and functional.
|
||||
2. **Given** the user is on an event page, **When** they look for the mode toggle, **Then** it is visible and functional.
|
||||
3. **Given** the user is on the event creation form, **When** they look for the mode toggle, **Then** it is visible and functional.
|
||||
|
||||
---
|
||||
|
||||
### User Story 4 - Dark/light mode does not affect event-level color themes (Priority: P2)
|
||||
|
||||
Dark/light mode affects only the app's global UI chrome (navigation, local event overview, forms, etc.). Individual event pages use their own color theme (US-15), which is independent of the app-level dark/light setting.
|
||||
|
||||
**Why this priority**: Necessary to define the boundary between app-level theming and event-level theming clearly, but secondary to the core toggle behaviour.
|
||||
|
||||
**Independent Test**: Can be tested by creating an event with a custom color theme, then toggling dark/light mode and verifying the event page theme is unaffected while the surrounding chrome does change.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an event page is rendered with a custom color theme (US-15), **When** the user switches the app to dark mode, **Then** the event page color theme remains unchanged (only surrounding chrome changes).
|
||||
2. **Given** the app is in dark mode, **When** the user navigates to the local event overview, **Then** the overview uses the dark color scheme.
|
||||
|
||||
---
|
||||
|
||||
### User Story 5 - Both modes meet WCAG AA contrast (Priority: P1)
|
||||
|
||||
Both dark and light modes must meet accessibility contrast requirements at the WCAG AA minimum level, ensuring the app is usable for users with visual impairments in both modes.
|
||||
|
||||
**Why this priority**: Accessibility is a baseline requirement per the project statutes, not an afterthought.
|
||||
|
||||
**Independent Test**: Can be tested using automated contrast checking tools against both mode variants.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the app is in dark mode, **When** text and interactive elements are checked for contrast ratio, **Then** all text/background pairings meet WCAG AA minimum (4.5:1 for normal text, 3:1 for large text).
|
||||
2. **Given** the app is in light mode, **When** text and interactive elements are checked for contrast ratio, **Then** all text/background pairings meet WCAG AA minimum.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens when the OS `prefers-color-scheme` value changes while the app is open (e.g. user switches OS theme at runtime)? If no manual preference is stored in localStorage, should the app react? [NEEDS EXPANSION during implementation]
|
||||
- What happens when localStorage is unavailable (private browsing with strict settings)? The system preference fallback must still work without crashing.
|
||||
- How does app-level dark/light mode interact with the event-level color themes (US-15) when an event page is embedded in the app chrome? Themes should remain readable in both modes.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: The app MUST detect and apply `prefers-color-scheme` as the default on first visit when no manual preference is stored in localStorage.
|
||||
- **FR-002**: The app MUST provide a visible toggle UI element to switch between dark and light mode, accessible from any page.
|
||||
- **FR-003**: The app MUST persist the user's manual mode preference in localStorage and apply it on subsequent visits, overriding the system preference.
|
||||
- **FR-004**: Dark/light mode MUST affect all global app chrome: navigation, local event overview, event creation/editing forms, and all non-event-page UI elements.
|
||||
- **FR-005**: Dark/light mode MUST NOT affect individual event page color themes (US-15); event pages are styled independently.
|
||||
- **FR-006**: The mode switch MUST be entirely client-side; no server request is made and no preference data is transmitted.
|
||||
- **FR-007**: Both dark and light modes MUST meet WCAG AA contrast requirements for all text and interactive elements.
|
||||
- **FR-008**: The toggle MUST be accessible (keyboard-navigable, labelled for screen readers).
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **DarkLightPreference**: A client-side-only value (`"dark"` | `"light"` | absent) stored in localStorage. No server-side equivalent. Determines which CSS theme is applied to the global app chrome.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: On first visit with `prefers-color-scheme: dark`, the dark theme is applied without any user interaction.
|
||||
- **SC-002**: A user's manual toggle selection persists across browser sessions and overrides the OS preference.
|
||||
- **SC-003**: The mode toggle is visible and functional on all primary app pages (local event overview, event page, creation form).
|
||||
- **SC-004**: Automated contrast checks pass WCAG AA thresholds for all text elements in both dark and light modes.
|
||||
- **SC-005**: No network request is made when toggling the mode or when the stored preference is applied on page load.
|
||||
@@ -1,96 +0,0 @@
|
||||
# Feature Specification: Cancel an Event as Organizer
|
||||
|
||||
**Feature**: `024-cancel-event`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Cancel event with optional message (Priority: P1)
|
||||
|
||||
The event organizer, from the organizer view, triggers a dedicated "Cancel event" action. A confirmation step is required before finalising. The organizer may optionally enter a cancellation message (reason or explanation). After confirmation, the server sets the event to cancelled state with the provided message. The event page immediately displays a "cancelled" state visible to all visitors. No RSVP submissions are accepted by the server from this point.
|
||||
|
||||
**Why this priority**: Cancellation is a fundamental lifecycle action — guests need to be clearly informed when an event is cancelled rather than discovering it silently. This is the core of US-18.
|
||||
|
||||
**Independent Test**: Can be fully tested by creating an event, triggering cancel (with and without a message), and verifying the event page shows a "cancelled" indicator and the RSVP form is absent.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an organizer with a valid organizer token in localStorage, **When** they click "Cancel event", **Then** a confirmation step is shown before any change is made.
|
||||
2. **Given** the organizer confirms cancellation without entering a message, **When** the server processes the request, **Then** the event is marked cancelled and the event page shows a "cancelled" state with no message.
|
||||
3. **Given** the organizer confirms cancellation with a message, **When** the server processes the request, **Then** the event page displays the "cancelled" state along with the cancellation message.
|
||||
4. **Given** a cancelled event, **When** a guest attempts to submit an RSVP, **Then** the server rejects the submission and the RSVP form is not shown on the event page.
|
||||
5. **Given** a cancelled event that has not yet expired, **When** any visitor opens the event URL, **Then** the full event page renders with a clear "cancelled" indicator — no partial data is hidden.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Adjust expiry date during cancellation (Priority: P2)
|
||||
|
||||
When cancelling, the organizer can optionally adjust the event's expiry date to control how long the cancellation notice remains visible before automatic data deletion (US-12). The adjusted date must be in the future, consistent with US-5's expiry date constraint.
|
||||
|
||||
**Why this priority**: The expiry date adjustment is a convenience — organizers may want to keep the cancellation notice visible for a specific period (e.g. one more week) or trigger earlier cleanup. The core cancellation (P1) works without it.
|
||||
|
||||
**Independent Test**: Can be tested by cancelling an event while setting a new expiry date in the future, then verifying the event's expiry date was updated and data persists until that date.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the organizer confirms cancellation with a new expiry date set in the future, **When** the server processes the request, **Then** the event is cancelled and its expiry date is updated to the provided value.
|
||||
2. **Given** the organizer provides an expiry date in the past or set to today during cancellation, **When** the server processes the request, **Then** the request is rejected with a clear validation error.
|
||||
3. **Given** the organizer confirms cancellation without adjusting the expiry date, **When** the server processes the request, **Then** the existing expiry date is unchanged.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Edit cancellation message after cancellation (Priority: P3)
|
||||
|
||||
After an event is cancelled, the organizer can update the cancellation message (e.g. to correct a typo or add further explanation). The cancelled state itself cannot be changed.
|
||||
|
||||
**Why this priority**: Editing the message is a refinement capability. The core behaviour (cancellation + message at time of cancellation) is sufficient for P1 and P2.
|
||||
|
||||
**Independent Test**: Can be tested by cancelling an event, then submitting an updated cancellation message via the organizer view, and verifying the new message is displayed on the event page.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a cancelled event with a valid organizer token, **When** the organizer submits an updated cancellation message, **Then** the event page displays the new message.
|
||||
2. **Given** a cancelled event with a valid organizer token, **When** the organizer attempts to un-cancel (set the event back to active), **Then** the server rejects the request — cancellation is a one-way state transition.
|
||||
3. **Given** a cancelled event with an absent or invalid organizer token, **When** a request is made to edit the cancellation message, **Then** the server rejects the request.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- Organizer token absent or invalid: the "Cancel event" action is not shown in the UI and the server rejects any cancel or message-edit request with an appropriate error response.
|
||||
- RSVP on a cancelled event: the server rejects RSVP submissions with a clear error; the RSVP form is hidden on the client.
|
||||
- Cancellation message is optional: omitting it is valid — the event still transitions to cancelled state with no message displayed.
|
||||
- Cancellation + expiry: after the expiry date passes, the event is deleted by the cleanup process (US-12) regardless of cancelled state; the cancellation data is removed as part of the full event deletion.
|
||||
- Already-expired event at time of cancellation: [NEEDS EXPANSION] — it is unclear whether cancellation should be allowed if the event has already expired but not yet been cleaned up. This edge case should be addressed during implementation.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: The Event entity MUST persist a `is_cancelled` boolean (default false) and an optional `cancellation_message` string, both server-side.
|
||||
- **FR-002**: The cancel endpoint MUST require a valid organizer token; requests without a valid token are rejected.
|
||||
- **FR-003**: The cancel endpoint MUST accept an optional plain-text cancellation message.
|
||||
- **FR-004**: The cancel endpoint MUST accept an optional updated expiry date, which MUST be in the future; if provided and not in the future, the request is rejected with a clear validation error.
|
||||
- **FR-005**: Cancellation MUST be a one-way state transition: once cancelled, the event cannot be set back to active via any API endpoint.
|
||||
- **FR-006**: The event page MUST display a "cancelled" state indicator and the cancellation message (if present) for any visitor once the event is cancelled.
|
||||
- **FR-007**: The RSVP endpoint MUST reject submissions for cancelled events; the RSVP form MUST be hidden on the client for cancelled events.
|
||||
- **FR-008**: The organizer MUST be able to update the cancellation message after cancellation via a dedicated update action; this action MUST require a valid organizer token.
|
||||
- **FR-009**: The UI MUST present a confirmation step before submitting the cancellation request; the cancel action MUST NOT be triggerable in a single click without confirmation.
|
||||
- **FR-010**: The "Cancel event" action and organizer-specific cancel UI MUST NOT be rendered when no valid organizer token is present in localStorage.
|
||||
- **FR-011**: No personal data, IP addresses, or identifiers MUST be logged during cancellation or cancellation message updates.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **CancellationState**: Value type on Event. Fields: `is_cancelled` (boolean, persistent), `cancellation_message` (optional string, persistent). Not a separate entity — stored on the Event record.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: An organizer with a valid token can cancel an event (with or without a message) in a single confirmed action, and the cancelled state is immediately reflected on the event page.
|
||||
- **SC-002**: After cancellation, no guest can successfully submit an RSVP via the API, regardless of client-side state.
|
||||
- **SC-003**: The event page correctly renders a "cancelled" indicator (and message if provided) for any visitor after cancellation — no RSVP form, no false "active" state.
|
||||
- **SC-004**: Cancellation data (state and message) is removed automatically when the event expires and is deleted by the cleanup process (US-12).
|
||||
- **SC-005**: No client or API call can revert a cancelled event to an active state.
|
||||
@@ -1,90 +0,0 @@
|
||||
# Feature Specification: Delete an Event as Organizer
|
||||
|
||||
**Feature**: `025-delete-event`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - Immediately delete an active event (Priority: P1)
|
||||
|
||||
The organizer wants to permanently remove an event they created — because it was a mistake, contains wrong information, or is no longer needed at all. From the organizer view, they trigger a dedicated "Delete event" action. After confirming a clear warning, the server immediately and permanently deletes all event data. The organizer is redirected to the root page and the event's local entry is removed.
|
||||
|
||||
**Why this priority**: This is the core action of the story. Without it, organizers have no manual removal mechanism — they can only wait for automatic expiry (US-12). It is the "nuclear option" that complements editing (US-5) and cancellation (US-18).
|
||||
|
||||
**Independent Test**: Can be tested by creating an event, navigating to the organizer view, triggering deletion, confirming the warning, and verifying the event URL returns "not found" and the root page no longer lists the event.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a valid organizer token is present in localStorage for an event, **When** the organizer triggers "Delete event" and confirms the warning, **Then** the server permanently deletes the event record and all associated data (RSVPs, update messages, field-change metadata, stored header images, cancellation state), and the event's public URL returns an "event not found" response.
|
||||
2. **Given** deletion succeeds, **When** the server responds with success, **Then** the app removes the event's organizer token and metadata from localStorage and redirects the organizer to the root page (`/`).
|
||||
3. **Given** the organizer view is open, **When** the organizer triggers "Delete event", **Then** a confirmation warning is shown that clearly states the action is immediate, permanent, and irreversible — all event data including RSVPs, update messages, and images will be lost.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Delete a cancelled or expired event (Priority: P2)
|
||||
|
||||
The organizer wants to delete an event regardless of its current state — whether it is still active, already cancelled (US-18), or past its expiry date. Deletion must not be gated on event state.
|
||||
|
||||
**Why this priority**: Extending P1 to cover all event states. A cancelled event may have data the organizer wants removed immediately, without waiting for the expiry date.
|
||||
|
||||
**Independent Test**: Can be tested by cancelling an event (US-18), then triggering deletion from the organizer view and verifying that the deletion succeeds.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** an event that has been cancelled (US-18), **When** the organizer confirms deletion, **Then** the server deletes the event and all its data, including the cancellation state, exactly as for an active event.
|
||||
2. **Given** an event that has passed its expiry date but not yet been cleaned up by US-12, **When** the organizer confirms deletion, **Then** the deletion succeeds and the event is immediately removed.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Reject deletion without a valid organizer token (Priority: P2)
|
||||
|
||||
A visitor without a valid organizer token must not be able to delete an event — the delete action is not shown to them and the server rejects any deletion request.
|
||||
|
||||
**Why this priority**: Security boundary. Without this, any visitor who knows the event token could delete the event.
|
||||
|
||||
**Independent Test**: Can be tested by attempting a DELETE request to the event endpoint without a valid organizer token and verifying the server rejects it with an appropriate error.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** no organizer token is present in localStorage for a given event, **When** a visitor opens the event page, **Then** the delete action is not shown anywhere in the UI.
|
||||
2. **Given** an organizer token is absent or invalid, **When** a DELETE request is sent to the server for that event, **Then** the server rejects the request and does not delete any data.
|
||||
|
||||
---
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens if the organizer dismisses the confirmation warning? The deletion is aborted; no data is changed; the organizer remains on the event page.
|
||||
- What happens if the network fails after confirmation but before the server responds? The event may or may not be deleted depending on whether the request reached the server. The app should display an error and not redirect; the organizer can retry.
|
||||
- What happens if the organizer token in localStorage is valid but the event was already deleted (e.g. by US-12 cleanup between page load and deletion attempt)? The server returns "event not found"; the app should handle this gracefully and redirect to the root page, removing the stale localStorage entry.
|
||||
- What if a stored header image file deletion fails during event deletion? The server must still delete the database record and must not leave the event in a partially-deleted state — image file cleanup failure should be logged server-side but must not abort deletion.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: The server MUST expose a DELETE endpoint for events, authenticated via the organizer token.
|
||||
- **FR-002**: The server MUST permanently delete all associated data on deletion: RSVPs, update messages (US-10a), field-change metadata (US-9), stored header images (US-16), and cancellation state (US-18), in addition to the event record itself.
|
||||
- **FR-003**: After deletion, the event's public URL MUST return an "event not found" response — no partial data may be served.
|
||||
- **FR-004**: The frontend MUST show a confirmation warning before deletion, clearly stating that the action is immediate, permanent, and irreversible.
|
||||
- **FR-005**: On successful deletion, the frontend MUST remove the event's organizer token and associated metadata from localStorage.
|
||||
- **FR-006**: On successful deletion, the frontend MUST redirect the organizer to the root page (`/`).
|
||||
- **FR-007**: The delete action MUST be accessible regardless of event state (active, cancelled, or expired).
|
||||
- **FR-008**: If no valid organizer token is present, the delete action MUST NOT be shown in the UI and the server MUST reject the request.
|
||||
- **FR-009**: No personal data or event data MUST be logged during deletion — deletion is silent from a logging perspective.
|
||||
|
||||
### Key Entities
|
||||
|
||||
- **Event**: The primary entity being deleted. Deletion removes it and all child data (RSVPs, update messages, field-change metadata, images, cancellation state).
|
||||
- **OrganizerToken**: The authentication credential (UUID) stored in localStorage and validated server-side. Required to authorize deletion.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: After deletion, a GET request to the event's public URL returns "event not found" — verifiable in an automated test immediately after deletion.
|
||||
- **SC-002**: After deletion, no record of the event, its RSVPs, or its messages exists in the database — verifiable via database assertion in integration tests.
|
||||
- **SC-003**: After deletion, the localStorage entry for the event (organizer token + metadata) is removed — verifiable in an E2E test.
|
||||
- **SC-004**: A DELETE request without a valid organizer token is rejected by the server — verifiable in an automated API test.
|
||||
- **SC-005**: The confirmation warning is always shown before deletion is triggered — verifiable in an E2E test by asserting the dialog appears before any data is sent to the server.
|
||||
@@ -1,48 +0,0 @@
|
||||
# Feature Specification: 404 Page
|
||||
|
||||
**Feature**: `026-404-page`
|
||||
**Created**: 2026-03-06
|
||||
**Status**: Draft
|
||||
**Source**: Migrated from spec/userstories.md
|
||||
|
||||
## User Scenarios & Testing
|
||||
|
||||
### User Story 1 - See a helpful error page for unknown URLs (Priority: P1)
|
||||
|
||||
As a user who navigates to a non-existent URL, I want to see a helpful error page so that I can find my way back instead of seeing a blank screen.
|
||||
|
||||
**Why this priority**: Without this, users see a blank page on invalid routes. Basic UX hygiene.
|
||||
|
||||
**Independent Test**: Navigate to any non-existent path (e.g. `/does-not-exist`) and verify the error page renders with a way back.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a user navigates to a URL that does not match any defined route, **When** the page loads, **Then** a "Page not found" message is displayed.
|
||||
2. **Given** the 404 page is displayed, **When** the user looks for navigation, **Then** a link back to the home page is visible and functional.
|
||||
3. **Given** the 404 page is displayed, **When** its appearance is evaluated, **Then** it follows the project design system (Electric Dusk + Sora).
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- What happens when the URL contains special characters or very long paths? The catch-all route should still match and display the 404 page.
|
||||
- What happens when JavaScript is disabled? [NEEDS EXPANSION — SPA limitation]
|
||||
|
||||
## Requirements
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: The Vue Router MUST include a catch-all route that matches any undefined path.
|
||||
- **FR-002**: The catch-all route MUST render a dedicated 404 component with a "Page not found" message.
|
||||
- **FR-003**: The 404 page MUST include a link back to the home page.
|
||||
- **FR-004**: The 404 page MUST follow the design system defined in `.specify/memory/design-system.md`.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Measurable Outcomes
|
||||
|
||||
- **SC-001**: Navigating to any undefined route displays the 404 page instead of a blank screen.
|
||||
- **SC-002**: The home page link on the 404 page navigates back to `/` successfully.
|
||||
- **SC-003**: The 404 page passes WCAG AA contrast requirements.
|
||||
|
||||
**Dependencies:** None (requires frontend scaffold from T-1/T-4 to be practically implementable)
|
||||
|
||||
**Notes:** Identified during US-1 post-review. Navigating to an unknown path currently shows a blank page because the Vue Router has no catch-all route.
|
||||
Reference in New Issue
Block a user