2.1 KiB
2.1 KiB
ADDED Requirements
Requirement: Authenticated users have a personal settings page
The platform web application SHALL provide a normal page-level personal settings workspace for every authenticated user.
Scenario: User opens personal settings
- WHEN an authenticated user activates the account settings entry point
- THEN the application MUST navigate to a full personal settings page instead of opening a cramped profile popover
Scenario: User sees current account data
- WHEN the personal settings page renders
- THEN it MUST show the current user's display name, email, role labels, status, profile fields, theme palette, background preset, and custom background state
Requirement: Personal profile saves through platform APIs
The personal settings page SHALL save editable profile fields through platform-mediated current-user APIs.
Scenario: User saves profile
- WHEN a user submits display name, avatar URL, phone, QQ, or contact note changes
- THEN the page MUST call the current-user profile API and render the updated current user from the response
Scenario: Profile API is unavailable
- WHEN the current-user profile API cannot be reached in local development fallback mode
- THEN the page MUST mark the resulting profile state as local fallback rather than pretending database persistence succeeded
Requirement: Theme preferences save through platform APIs
The personal settings page SHALL save theme palette, background preset, and custom background preferences through platform-mediated current-user APIs where available.
Scenario: User changes theme preference
- WHEN a user selects a palette, selects a background preset, uploads a background, or removes a background
- THEN the page MUST update the visible theme and persist the preference through the current-user theme API
Scenario: Theme API is unavailable
- WHEN the current-user theme API cannot be reached in local development fallback mode
- THEN the page MUST preserve local theme preference behavior and clearly show that the preference is local