3.7 KiB
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