first commit
This commit is contained in:
@@ -0,0 +1,34 @@
|
||||
## 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
|
||||
@@ -0,0 +1,23 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Platform startup loads local environment files
|
||||
The platform SHALL load local `.env` configuration before constructing runtime configuration for storage initialization.
|
||||
|
||||
#### Scenario: Platform env file selects MySQL storage
|
||||
- **WHEN** `platform/.env` contains `PLATFORM_STORAGE_BACKEND=mysql` and `PLATFORM_MYSQL_DSN`
|
||||
- **THEN** platform configuration MUST use the MySQL storage backend and DSN from the env file
|
||||
|
||||
#### Scenario: Process environment overrides env file
|
||||
- **WHEN** a process environment variable and a local `.env` file both define the same platform setting
|
||||
- **THEN** platform configuration MUST use the process environment value
|
||||
|
||||
### Requirement: Metadata backend selection remains database-backed
|
||||
The platform SHALL initialize the configured metadata repository through the existing store boundary rather than falling back to hardcoded local sample data.
|
||||
|
||||
#### Scenario: MySQL storage is configured
|
||||
- **WHEN** `PLATFORM_STORAGE_BACKEND=mysql` and a non-empty `PLATFORM_MYSQL_DSN` are loaded
|
||||
- **THEN** platform startup MUST initialize the MySQL metadata store
|
||||
|
||||
#### Scenario: MySQL storage is missing DSN
|
||||
- **WHEN** `PLATFORM_STORAGE_BACKEND=mysql` is loaded without `PLATFORM_MYSQL_DSN`
|
||||
- **THEN** platform startup MUST fail with a direct configuration error instead of silently using file or memory storage
|
||||
Reference in New Issue
Block a user