109 lines
6.8 KiB
Markdown
109 lines
6.8 KiB
Markdown
## ADDED Requirements
|
|
|
|
### Requirement: Authentication entry flows
|
|
The platform web application SHALL provide clear registration and login flows before users enter authenticated workspaces.
|
|
|
|
#### Scenario: User registers an account
|
|
- **WHEN** a visitor submits the registration form with valid identity fields
|
|
- **THEN** the platform creates or requests creation of a user account without granting platform administrator privileges by default
|
|
|
|
#### Scenario: User logs in
|
|
- **WHEN** a user submits valid login credentials
|
|
- **THEN** the application establishes the current session and routes the user to the role-appropriate default workspace
|
|
|
|
#### Scenario: Authentication failure is visible
|
|
- **WHEN** registration or login fails
|
|
- **THEN** the form shows a scoped error with a retry path and does not leave the user on a blank page
|
|
|
|
### Requirement: Platform administrator user management
|
|
The platform web application SHALL allow platform administrators to create and manage users from the user management area.
|
|
|
|
#### Scenario: Platform administrator creates a user
|
|
- **WHEN** a platform administrator submits valid user details and role assignments
|
|
- **THEN** the platform creates the user and shows a visible success result with the created user's status
|
|
|
|
#### Scenario: Platform administrator manages users
|
|
- **WHEN** a platform administrator opens user management
|
|
- **THEN** the page shows users, status, roles, contact/profile summary, and available management actions
|
|
|
|
#### Scenario: Server-only user cannot manage users
|
|
- **WHEN** a server owner or server administrator without user management capability opens navigation
|
|
- **THEN** user management is not shown and direct access redirects to that user's authorized default workspace
|
|
|
|
### Requirement: Current user profile settings
|
|
The platform web application SHALL expose current-user profile settings from the user's avatar or account menu.
|
|
|
|
#### Scenario: User opens profile from avatar
|
|
- **WHEN** an authenticated user selects their avatar or account menu
|
|
- **THEN** the application provides access to profile settings without requiring user management permissions
|
|
|
|
#### Scenario: User edits contact details
|
|
- **WHEN** an authenticated user updates allowed personal fields
|
|
- **THEN** the profile settings support display name, avatar, phone, QQ, and other bounded contact fields when available
|
|
|
|
#### Scenario: Profile save has visible result
|
|
- **WHEN** a profile update is submitted
|
|
- **THEN** the UI shows pending, success, or failure feedback and preserves the user's entered values on recoverable failure
|
|
|
|
### Requirement: Per-user theme preferences
|
|
The platform web application SHALL let authenticated users configure their own interface theme and background preferences.
|
|
|
|
#### Scenario: User chooses from multiple magical palettes
|
|
- **WHEN** a user opens theme settings
|
|
- **THEN** the application offers multiple named color palettes based on strawberry pink, lavender purple, mint green, milk yellow, icy blue, white highlights, and bright gold accents
|
|
|
|
#### Scenario: Palette choice is applied immediately
|
|
- **WHEN** a user selects a theme palette
|
|
- **THEN** the workspace updates its surfaces, buttons, highlights, status accents, and decorative effects without requiring a page reload
|
|
|
|
#### Scenario: User uploads a background
|
|
- **WHEN** a user uploads a background image from profile or theme settings
|
|
- **THEN** the application applies the background to the workspace with contrast surfaces that keep text, controls, logs, and forms readable
|
|
|
|
#### Scenario: User chooses a built-in magical desktop
|
|
- **WHEN** a user opens theme settings without uploading a custom background
|
|
- **THEN** the application offers original built-in desktop presets with moon, sparkle, ribbon, magic-circle, crystal, candy, or aurora motifs that render behind translucent workspace surfaces
|
|
|
|
#### Scenario: Uploaded background takes precedence
|
|
- **WHEN** a user has both a built-in magical desktop preset and an uploaded background image
|
|
- **THEN** the uploaded background is shown as the workspace desktop while preserving the selected preset for fallback after the upload is removed
|
|
|
|
#### Scenario: Theme is scoped to current user
|
|
- **WHEN** a user changes theme settings while authenticated
|
|
- **THEN** the preference is associated with that user and does not change another user's workspace theme
|
|
|
|
#### Scenario: Theme remains usable without profile API
|
|
- **WHEN** backend profile preference APIs are unavailable
|
|
- **THEN** the frontend may persist theme settings locally and labels the state clearly enough that users are not misled about cross-device persistence
|
|
|
|
### Requirement: Cute game visual style remains operational
|
|
The platform web application SHALL use an original cute anime/game visual style without sacrificing operator clarity.
|
|
|
|
#### Scenario: Magical-girl materials are visible
|
|
- **WHEN** the workspace renders default UI surfaces
|
|
- **THEN** buttons, panels, dialogs, and account/theme controls use pastel gradients, crystal-moonlight transparent surfaces, glossy jelly controls, white and icy-blue rim highlights, diamond-like borders, candy-color glow, built-in magical desktop imagery, and lightweight shadows rather than dead black, flat white cards, or heavy dark saturated themes
|
|
|
|
#### Scenario: Background remains visibly part of the interface
|
|
- **WHEN** a default or user-uploaded background is present
|
|
- **THEN** major dashboard cards, side navigation, profile controls, and dialogs remain translucent enough for the background to be visible while preserving readable text contrast
|
|
|
|
#### Scenario: Magical motifs support the interface
|
|
- **WHEN** decorative UI elements are shown
|
|
- **THEN** they use original hearts, stars, moons, sparkles, ribbons, frosted crystal borders, or magic-circle inspired patterns without replacing operational labels or hiding status text
|
|
|
|
#### Scenario: Magical ultimate effects are globally coordinated
|
|
- **WHEN** the authenticated workspace renders ambient magical decoration
|
|
- **THEN** magical ultimate effects are provided by a shared theme-aware global layer rather than page-local fixed decorative DOM elements
|
|
|
|
#### Scenario: Common chrome uses cute icons
|
|
- **WHEN** users view navigation, account settings, theme controls, refresh actions, and non-dangerous page commands
|
|
- **THEN** the UI uses cute magical icons such as hearts, moons, stars, candy, dessert, or magic wands while preserving familiar warning icons for destructive or failed operations
|
|
|
|
#### Scenario: Visual style uses original motifs
|
|
- **WHEN** the platform ships default visual elements
|
|
- **THEN** they use original colors, shapes, icons, and UI motifs rather than bundled recognizable third-party character art
|
|
|
|
#### Scenario: Colorful panels remain readable
|
|
- **WHEN** saturated blocks, gradients, or user backgrounds are visible
|
|
- **THEN** operational text, metrics, form controls, errors, and operation results meet readable contrast and do not overlap
|