browser/openspec/changes/replace-scum-projections-with-real-data-management/specs/scum-player-management/spec.md

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