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.4 KiB
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:
- 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).
- 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.
- 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:
- 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.
- 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:
- 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.
- 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.