## 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