nitrix
6aeb4b8bca
- Move cross-cutting docs (personas, design system, implementation phases, Ideen.md) to .specify/memory/ - Move cross-cutting research and plans to .specify/memory/research/ and .specify/memory/plans/ - Extract 5 setup tasks from spec/setup-tasks.md into individual specs/001-005/spec.md files with spec-kit template format - Extract 20 user stories from spec/userstories.md into individual specs/006-026/spec.md files with spec-kit template format - Relocate feature-specific research and plan docs into specs/[feature]/ - Add spec-kit constitution, templates, scripts, and slash commands - Slim down CLAUDE.md to Claude-Code-specific config, delegate principles to .specify/memory/constitution.md - Update ralph.sh with stream-json output and per-iteration logging - Delete old spec/ and docs/agents/ directories - Gitignore Ralph iteration JSONL logs Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
6.8 KiB
Feature Specification: View Event Landing Page
Feature: 007-view-event
Created: 2026-03-06
Status: Draft
Source: Migrated from spec/userstories.md
User Scenarios & Testing
User Story 1 - View event details as guest (Priority: P1)
A guest receives a shared event link, opens it, and sees all relevant event information: title, description (if provided), date and time, location (if provided), and the list of confirmed attendees with a count.
Why this priority: Core value of the feature — without this, no other part of the event page is meaningful.
Independent Test: Can be fully tested by navigating to a valid event URL and verifying all event fields are displayed correctly, including attendee list and count.
Acceptance Scenarios:
- Given a valid event link, When a guest opens the URL, Then the page displays the event title, date and time, and attendee count.
- Given a valid event link for an event with optional fields set, When a guest opens the URL, Then the description and location are also displayed.
- Given a valid event link for an event with optional fields absent, When a guest opens the URL, Then only the required fields are shown — no placeholder text for missing optional fields.
- Given a valid event with RSVPs, When a guest opens the event page, Then the names of all confirmed attendees ("attending") are listed and a total count is shown.
- Given an event page, When it is rendered, Then no external resources (CDNs, fonts, tracking scripts) are loaded — all assets are served from the app's own domain.
- Given a guest with no account, When they open the event URL, Then the page loads without any login, account, or access code required.
User Story 2 - View expired event (Priority: P2)
A guest opens a shared event link after the event's expiry date has passed. The event details are still accessible but the page clearly communicates that the event has ended and RSVP actions are not available.
Why this priority: The expired state is a required UI behavior that derives directly from the mandatory expiry date in US-1. Displaying expired events incorrectly would mislead guests.
Independent Test: Can be tested by creating an event with a past expiry date (or advancing the system clock) and verifying the "event has ended" state renders without RSVP controls.
Acceptance Scenarios:
- Given an event whose expiry date has passed, When a guest opens the event URL, Then the page displays a clear "this event has ended" state and no RSVP actions are shown.
User Story 3 - View cancelled event (Priority: P2)
A guest opens a shared event link for an event that has been cancelled (US-18). The page clearly communicates the cancellation and optionally displays the organizer's cancellation message. No RSVP actions are shown. [Deferred until US-18 is implemented]
Why this priority: Cancellation is a distinct state from expiry; guests must not be misled into thinking they can still RSVP.
Independent Test: Can be tested once US-18 is implemented by cancelling an event and verifying the cancelled state renders correctly.
Acceptance Scenarios:
- Given a cancelled event (US-18), When a guest opens the event URL, Then the page displays a clear "cancelled" state with the cancellation message if provided, and no RSVP actions are shown. [Deferred until US-18 is implemented]
User Story 4 - Event not found (Priority: P2)
A guest navigates to an event URL that no longer resolves — the event was deleted by the organizer (US-19) or automatically removed after expiry (US-12). The page displays a clear "event not found" message with no partial data or error traces.
Why this priority: Correct handling of deleted events is a privacy requirement — no partial data may be served.
Independent Test: Can be tested by navigating to a URL with an unknown event token and verifying the "event not found" message renders.
Acceptance Scenarios:
- Given an event token that does not match any event on the server, When a guest opens the URL, Then the page displays a clear "event not found" message — no partial data, no error traces, no stack dumps.
Edge Cases
- What happens when the event has no attendees yet? — Attendee list is empty; count shows 0.
- What happens when the event has been cancelled after US-18 is implemented? — Renders cancelled state with optional message; RSVP hidden. [Deferred]
- What happens when the server is temporarily unavailable? — [NEEDS EXPANSION]
- How does the page behave when JavaScript is disabled? — Per Q-3 resolution: the app is a SPA; JavaScript-dependent rendering is acceptable.
Requirements
Functional Requirements
- FR-001: The event page MUST display: title, date and time, and attendee count for any valid event.
- FR-002: The event page MUST display description and location when those optional fields are set on the event.
- FR-003: The event page MUST list the names of all confirmed attendees (those who RSVPed "attending").
- FR-004: If the event's expiry date has passed, the page MUST render a clear "this event has ended" state and MUST NOT show any RSVP actions.
- FR-005: If the event has been cancelled (US-18), the page MUST display a "cancelled" state with the cancellation message (if provided) and MUST NOT show any RSVP actions. [Deferred until US-18 is implemented]
- FR-006: If the event token does not match any event on the server, the page MUST display a clear "event not found" message — no partial data or error traces.
- FR-007: The event page MUST be accessible without any login, account, or access code — only the event token in the URL is required.
- FR-008: The event page MUST NOT load any external resources (no CDNs, no Google Fonts, no tracking scripts).
Key Entities
- Event: Has a public event token (UUID in URL), title, optional description, date/time, optional location, expiry date, and optionally a cancelled state with message.
- RSVP: Has a guest name and attending status; confirmed attendees (status = attending) are listed on the public event page.
Success Criteria
Measurable Outcomes
- SC-001: A guest who opens a valid event URL can see all set event fields (title, date/time, and any optional fields) without logging in.
- SC-002: The attendee list and count reflect all current server-side RSVPs with attending status.
- SC-003: An expired event URL renders the "ended" state — RSVP controls are absent from the DOM, not merely hidden via CSS.
- SC-004: An unknown event token URL renders a "not found" message — no event data, no server error details.
- SC-005: No network requests to external domains are made when loading the event page.