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