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>
5.0 KiB
5.0 KiB
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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.