···11+## Context
22+33+The site currently uses one light visual theme across the home page, creator shell, dashboard, builder, response review, and public form runner. The requested change adds two related capabilities: automatic adaptation to OS theme preference and a creator-facing Settings page where the user can explicitly choose Light, Dark, or System.
44+55+This is a cross-cutting UI change because it affects shared tokens, top-level layout behavior, creator navigation, and both authenticated and public-facing pages. It also needs to avoid a visible flash of the wrong theme during initial page load.
66+77+## Goals / Non-Goals
88+99+**Goals:**
1010+- Support both light and dark themes site-wide.
1111+- Default to following the OS theme when no explicit preference is selected.
1212+- Add a Settings page in creator navigation with a three-way appearance control: Light, Dark, System.
1313+- Apply the selected preference consistently to creator pages, home page, and public forms.
1414+- Minimize theme flicker during initial render.
1515+1616+**Non-Goals:**
1717+- Syncing theme preference to the database or across all devices.
1818+- Per-form or per-page custom theme palettes.
1919+- Multiple settings sections beyond appearance.
2020+- Rebuilding every component with a unique dark-mode design language; the first pass should adapt the current design system coherently.
2121+2222+## Decisions
2323+2424+### Store the explicit preference client-side and derive the active theme at runtime
2525+Use a client-side persisted preference with values `light`, `dark`, or `system`, and compute the active theme from that setting plus `prefers-color-scheme`.
2626+2727+**Why this approach:**
2828+- Matches the requested Light / Dark / System behavior.
2929+- Avoids schema and account-model changes for an initial version.
3030+- Lets the theme apply to public pages in the same browser without authentication.
3131+3232+**Alternatives considered:**
3333+- Persist preference in the user record: stronger cross-device consistency, but adds backend and migration scope not required for the initial feature.
3434+- Support only automatic OS detection with no settings page: does not satisfy the requirement for explicit user control.
3535+3636+### Apply theme through shared CSS variables at the document level
3737+Use the existing tokenized color system in `app/globals.css` and switch token values through a top-level theme class or data attribute.
3838+3939+**Why this approach:**
4040+- Most of the UI already references shared variables like `--bg`, `--ink`, and `--accent`.
4141+- Allows broad theme coverage without rewriting each component individually.
4242+- Keeps the visual language aligned between creator and public surfaces.
4343+4444+**Alternatives considered:**
4545+- Add dark-mode utility classes component by component: harder to maintain and more error-prone for a site-wide theme.
4646+4747+### Set theme early during page boot to reduce flash
4848+Add a lightweight early theme initialization path so the chosen preference is applied before the main UI paints.
4949+5050+**Why this approach:**
5151+- Prevents a distracting flash from light to dark or dark to light.
5252+- Important because the theme affects the entire shell and public runner.
5353+5454+**Alternatives considered:**
5555+- Apply theme only after client hydration: simpler, but more likely to produce visible flicker.
5656+5757+### Add Settings as a creator page in the existing authenticated shell
5858+The Settings page should live alongside Dashboard in the creator navigation and initially expose only the appearance control.
5959+6060+**Why this approach:**
6161+- Matches the requested IA change.
6262+- Keeps settings discoverable in the same shell used for creator management.
6363+- Leaves room for future settings without changing navigation again.
6464+6565+**Alternatives considered:**
6666+- Put appearance controls in the dashboard header: faster, but less scalable and less aligned with the explicit request for a Settings page.
6767+6868+## Risks / Trade-offs
6969+7070+- **Client-side persistence does not sync across devices** → Mitigation: acceptable for the first version; document this as a non-goal and revisit later if needed.
7171+- **Some components may still use hard-coded light colors** → Mitigation: audit creator and public surfaces and move remaining values onto shared theme-aware tokens where needed.
7272+- **Theme flicker on first load** → Mitigation: initialize theme before main UI paint and keep the algorithm simple.
7373+- **System mode behavior can be confusing if OS theme changes while the page is open** → Mitigation: listen to `prefers-color-scheme` changes when the selected preference is `system`.
7474+7575+## Migration Plan
7676+7777+1. Introduce a shared theme preference model (`light`, `dark`, `system`) and early theme application logic.
7878+2. Extend global CSS variables to define both light and dark token sets.
7979+3. Add authenticated Settings navigation and build the Settings page with the appearance switch.
8080+4. Update creator and public surfaces to rely on theme-aware tokens instead of fixed light-only colors where necessary.
8181+5. Verify OS detection, explicit override behavior, and page-to-page consistency.
8282+8383+## Open Questions
8484+8585+- Should the theme preference also be reflected in the URL or remain fully local to the browser?
8686+- Do we want the settings control presented as segmented buttons, radio cards, or a select-style control?
8787+- Should future account-level persistence replace or complement browser-local persistence?
···11+## Why
22+33+The product currently uses a single light theme, which can feel out of place for users whose devices are already set to dark mode. Adding site-wide theme support and a simple appearance setting will make the experience feel more native and give creators explicit control over light, dark, or system behavior.
44+55+## What Changes
66+77+- Add site-wide dark mode support across creator and public form surfaces.
88+- Detect the user’s OS color scheme and use it automatically when no explicit preference is selected.
99+- Add a creator Settings page linked next to Dashboard in the authenticated navigation.
1010+- Add an appearance control with three options: Light, Dark, and System (default).
1111+- Apply the selected theme consistently across the full site, including the home page, creator pages, and public form runner.
1212+1313+## Capabilities
1414+1515+### New Capabilities
1616+- `site-theme-preferences`: site-wide theme support with system detection and a creator-accessible appearance setting for light, dark, or system mode.
1717+1818+### Modified Capabilities
1919+- None.
2020+2121+## Impact
2222+2323+- Affected specs: `site-theme-preferences`
2424+- Affected code: global layout, global styling variables, authenticated navigation, new settings page, theme preference persistence and hydration logic, public form and creator surfaces
2525+- Affected APIs: none required if theme preference is stored client-side for now
···11+## ADDED Requirements
22+33+### Requirement: Site supports light, dark, and system theme modes
44+The system SHALL support light and dark themes across site surfaces and SHALL use the system color scheme when the active appearance preference is `system`.
55+66+#### Scenario: Visitor has no explicit theme preference
77+- **WHEN** a visitor opens the site without a saved appearance preference
88+- **THEN** the system uses the device's current color scheme
99+1010+#### Scenario: User selects dark mode
1111+- **WHEN** a user selects the dark appearance mode
1212+- **THEN** the system applies the dark theme across the site
1313+1414+#### Scenario: User selects light mode
1515+- **WHEN** a user selects the light appearance mode
1616+- **THEN** the system applies the light theme across the site
1717+1818+#### Scenario: User selects system mode
1919+- **WHEN** a user selects the system appearance mode
2020+- **THEN** the system follows the device color scheme instead of forcing light or dark
2121+2222+### Requirement: Creator can manage appearance from a settings page
2323+The system SHALL provide an authenticated creator Settings page in creator navigation and SHALL allow the creator to choose Light, Dark, or System appearance mode from that page.
2424+2525+#### Scenario: Creator opens settings
2626+- **WHEN** an authenticated creator opens the Settings page
2727+- **THEN** the system shows an appearance control with Light, Dark, and System options
2828+2929+#### Scenario: Creator updates appearance preference
3030+- **WHEN** an authenticated creator changes the appearance setting in the Settings page
3131+- **THEN** the system applies the selected mode across the site
3232+3333+#### Scenario: Unauthenticated user opens creator settings
3434+- **WHEN** an unauthenticated user attempts to open the creator Settings page
3535+- **THEN** the system requires authentication before showing settings
3636+3737+### Requirement: Theme choice persists for the current browser
3838+The system SHALL remember the selected appearance preference for the current browser so it continues to apply across page reloads and navigation.
3939+4040+#### Scenario: User navigates after changing theme
4141+- **WHEN** a user changes the appearance preference and opens another page in the same browser
4242+- **THEN** the system keeps the selected appearance mode active
4343+4444+#### Scenario: User reloads after changing theme
4545+- **WHEN** a user reloads the site after selecting an appearance preference
4646+- **THEN** the system restores the same preference in that browser
···11+## 1. Theme foundation
22+33+- [x] 1.1 Add a shared theme preference model for `light`, `dark`, and `system`
44+- [x] 1.2 Add early theme initialization and browser persistence so the selected mode survives reloads and navigation
55+- [x] 1.3 Extend global theme tokens and shared surfaces to support both light and dark mode
66+77+## 2. Settings page and navigation
88+99+- [x] 2.1 Add Settings navigation next to Dashboard in the authenticated creator shell
1010+- [x] 2.2 Create the authenticated Settings page
1111+- [x] 2.3 Add an appearance control with Light, Dark, and System options and wire it to the shared theme preference
1212+1313+## 3. Site-wide adoption and verification
1414+1515+- [x] 3.1 Update creator and public pages that still rely on fixed light-only colors so they adapt correctly in dark mode
1616+- [x] 3.2 Verify system mode follows OS preference while explicit Light and Dark overrides remain stable across navigation and reloads
1717+- [x] 3.3 Run build and relevant checks to confirm site-wide theme switching works correctly
+46
openspec/specs/site-theme-preferences/spec.md
···11+## ADDED Requirements
22+33+### Requirement: Site supports light, dark, and system theme modes
44+The system SHALL support light and dark themes across site surfaces and SHALL use the system color scheme when the active appearance preference is `system`.
55+66+#### Scenario: Visitor has no explicit theme preference
77+- **WHEN** a visitor opens the site without a saved appearance preference
88+- **THEN** the system uses the device's current color scheme
99+1010+#### Scenario: User selects dark mode
1111+- **WHEN** a user selects the dark appearance mode
1212+- **THEN** the system applies the dark theme across the site
1313+1414+#### Scenario: User selects light mode
1515+- **WHEN** a user selects the light appearance mode
1616+- **THEN** the system applies the light theme across the site
1717+1818+#### Scenario: User selects system mode
1919+- **WHEN** a user selects the system appearance mode
2020+- **THEN** the system follows the device color scheme instead of forcing light or dark
2121+2222+### Requirement: Creator can manage appearance from a settings page
2323+The system SHALL provide an authenticated creator Settings page in creator navigation and SHALL allow the creator to choose Light, Dark, or System appearance mode from that page.
2424+2525+#### Scenario: Creator opens settings
2626+- **WHEN** an authenticated creator opens the Settings page
2727+- **THEN** the system shows an appearance control with Light, Dark, and System options
2828+2929+#### Scenario: Creator updates appearance preference
3030+- **WHEN** an authenticated creator changes the appearance setting in the Settings page
3131+- **THEN** the system applies the selected mode across the site
3232+3333+#### Scenario: Unauthenticated user opens creator settings
3434+- **WHEN** an unauthenticated user attempts to open the creator Settings page
3535+- **THEN** the system requires authentication before showing settings
3636+3737+### Requirement: Theme choice persists for the current browser
3838+The system SHALL remember the selected appearance preference for the current browser so it continues to apply across page reloads and navigation.
3939+4040+#### Scenario: User navigates after changing theme
4141+- **WHEN** a user changes the appearance preference and opens another page in the same browser
4242+- **THEN** the system keeps the selected appearance mode active
4343+4444+#### Scenario: User reloads after changing theme
4545+- **WHEN** a user reloads the site after selecting an appearance preference
4646+- **THEN** the system restores the same preference in that browser