Files

nitrix 6aeb4b8bca Migrate project artifacts to spec-kit format

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

2026-03-06 20:19:41 +01:00

5.0 KiB

Raw Blame History

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:

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

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

5.0 KiB Raw Blame History