52 lines
3.7 KiB
Markdown
52 lines
3.7 KiB
Markdown
## 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
|