## ADDED Requirements

### Requirement: Server-local game-player identity
The system SHALL maintain a game-player identity independently of platform users, uniquely scoped by `serverInstanceId` and immutable game-player ID, with bounded display-name alias history.

#### Scenario: A known game player logs in under a new name
- **WHEN** a successful declared SCUM login contains an existing player ID and a different valid display name
- **THEN** the system SHALL update the player's current display name and retain the previous and new names as server-local aliases

### Requirement: Idempotent semantic login/logout projection
The system SHALL project accepted `scum.login` and `scum.logout` semantic events using a durable event identity and SHALL tolerate duplicate and out-of-order delivery without creating duplicate access evidence or regressing player state.

#### Scenario: A duplicate login event is received
- **WHEN** the same accepted log stream sequence is ingested again
- **THEN** the system SHALL return the normal duplicate acknowledgement and SHALL not create an additional session or alias record

#### Scenario: A stale logout arrives after a later login
- **WHEN** a logout event is older than the player's latest successful login
- **THEN** the system SHALL only close an eligible earlier open session and SHALL not overwrite the newer player last-seen state

### Requirement: Privacy-preserving access evidence
The system SHALL persist no raw IP address, raw network fingerprint, host path, credential, or raw sensitive log content in game-player access records or browser-visible responses. Network correlation SHALL be derived as an irreversible value scoped to one server instance.

#### Scenario: An access event carries a source address
- **WHEN** a SCUM event contains a source address or network identifier
- **THEN** the system SHALL use it only to derive a server-isolated correlation value and SHALL omit the source value from stored models and API responses

### Requirement: Review-only risk signals
The system SHALL create bounded security signals for thresholded failed access and possible shared-fingerprint identities, and SHALL expose them as manual-review evidence only.

#### Scenario: Repeated failed access crosses the threshold
- **WHEN** five failed attempts with one server-local correlation value occur within fifteen minutes
- **THEN** the system SHALL create or refresh an excessive-failed-access signal with an explicit textual review status and evidence count

#### Scenario: An operator reviews a signal
- **WHEN** an authorized operator reads a player security signal
- **THEN** the response SHALL contain no automated enforcement command, raw network identifier, or raw log line

### Requirement: Authorized player intelligence console
The system SHALL provide server-authorized player profile, aliases, sessions, access-attempt, and security-signal responses through named contracts, and the SCUM console SHALL render labels and status text rather than relying only on color.

#### Scenario: An unauthorized user requests server player data
- **WHEN** a platform session lacks read access to the requested server instance
- **THEN** the player intelligence API SHALL deny access without revealing whether a game-player record exists

### Requirement: Bounded evidence retention
The system SHALL retain access attempts and active security evidence for a bounded period, prune expired evidence during normal service operations, and keep independent player identity history intact.

#### Scenario: Evidence is older than the retention limit
- **WHEN** a query or projection runs after an access attempt exceeds the retention period
- **THEN** the system SHALL remove the expired attempt and any expired non-active signal evidence without deleting the game-player identity