69 lines
4.7 KiB
Markdown
69 lines
4.7 KiB
Markdown
## ADDED Requirements
|
|
|
|
### Requirement: Lean SCUM player record
|
|
The SCUM product SHALL maintain only server-scoped player identity, current display name, first/last seen times, online session/login history, and verified current-server player details required for management.
|
|
|
|
#### Scenario: Player changes display name
|
|
- **WHEN** a newer authentic login event reports a different display name for an existing server-scoped player
|
|
- **THEN** Platform updates the current display name and SHALL NOT create alias-intelligence, shared-IP, access-risk, or automatic-enforcement records
|
|
|
|
#### Scenario: SCUM player model is migrated
|
|
- **WHEN** the new player store becomes authoritative
|
|
- **THEN** SCUM page/API/manifest/log-ingestion flows no longer create, update, read, or expose player-intelligence, access-attempt, shared-fingerprint, security-signal, alias-history, projection, observation, or Workflow records; a shared non-SCUM domain may remain only for a proven non-SCUM consumer
|
|
|
|
### Requirement: Searchable and paginated player roster
|
|
The system SHALL provide a server-authorized local player-list API and full-width table with server-side pagination, bounded search, online-state and squad filters, and allowlisted sorting.
|
|
|
|
#### Scenario: Operator searches the roster
|
|
- **WHEN** an authorized operator searches by display name or external player ID and selects online or squad filters
|
|
- **THEN** Platform returns only matching players from the target server with total/page information and deterministic ordering
|
|
|
|
#### Scenario: Cross-server player identifier is supplied
|
|
- **WHEN** the same external player ID exists on another server or a filter references another server's squad
|
|
- **THEN** the response includes no cross-server row and reveals no other server association
|
|
|
|
#### Scenario: Unauthorized user requests players
|
|
- **WHEN** the session lacks effective read access to the target server
|
|
- **THEN** Platform denies the request without revealing whether any player exists
|
|
|
|
### Requirement: Trustworthy roster values
|
|
The player roster SHALL display current stored business fields without fabricating defaults and SHALL distinguish online-session evidence from database details.
|
|
|
|
#### Scenario: Verified player details exist
|
|
- **WHEN** local records contain verified fame, cash, gold, squad, and last activity facts
|
|
- **THEN** the roster shows player name, unique identifier, online state, those verified facts, and their last synchronized time
|
|
|
|
#### Scenario: Database details are not yet known
|
|
- **WHEN** a login-created player has no successful detail row yet
|
|
- **THEN** the roster shows the player identity/session with unknown detail fields and SHALL NOT substitute zero, `1`, sample data, or a guessed profile identifier
|
|
|
|
#### Scenario: No players have been recorded
|
|
- **WHEN** the local player table is confirmed empty
|
|
- **THEN** the page shows a normal player-data empty state without projection/Workflow terminology, sample players, or an action that starts data collection
|
|
|
|
### Requirement: Player detail and login history
|
|
The system SHALL provide a player detail surface containing server-scoped identity, current verified facts, current known coordinate, login history, and last synchronized/collected times.
|
|
|
|
#### Scenario: Operator opens player detail
|
|
- **WHEN** an authorized operator selects a roster row
|
|
- **THEN** a drawer, dialog, or detail route shows the player's known fields and bounded login history without exposing raw logs, IP addresses, database rows, SQL, XML, paths, or credentials
|
|
|
|
#### Scenario: Coordinate is unavailable
|
|
- **WHEN** no verified current coordinate exists for the player
|
|
- **THEN** the detail surface states that the coordinate is unavailable and SHALL NOT calculate or render a default map point
|
|
|
|
### Requirement: Explicit player edit form
|
|
The user-management surface SHALL edit player values through a named-field form that shows current and proposed values and delegates execution to the controlled-write capability.
|
|
|
|
#### Scenario: Operator edits an economy field
|
|
- **WHEN** an operator opens the Fame, cash, or gold edit control
|
|
- **THEN** the form requires an explicit target value and reason and SHALL NOT use hard-coded `+100`, `+1000`, or other fixed increment behavior
|
|
|
|
#### Scenario: Attribute current value is unknown
|
|
- **WHEN** an operator opens an attribute or `855` preset edit without verified current named values
|
|
- **THEN** the UI prevents submission and explains that current values must be known; it SHALL NOT default the before or after value to `0` or `1`
|
|
|
|
#### Scenario: User has read but not write access
|
|
- **WHEN** the current session may read players but lacks the effective permission for the selected field
|
|
- **THEN** the roster and detail remain available while the edit action is hidden or disabled with a readable permission explanation
|