4.0 KiB
ADDED Requirements
Requirement: Authentic player identity creation
The system SHALL create and update SCUM player identity records only from authentic SCUM login/logout log observations and verified SCUM.db facts reported by the bound run/agent for the current server instance.
Scenario: Login log creates player record
- WHEN run ingests a plugin-declared SCUM
login_*.logline for a server-bound Steam/user identifier and character name - THEN platform stores or updates the matching local game player, player session, source log metadata, observed time, and confidence without inventing missing profile fields
Scenario: Logout log updates session
- WHEN run ingests a matching logout observation for a known player session
- THEN platform closes or marks the local session with the observed logout time while preserving historical login evidence
Requirement: Bound SCUM.db read observations
The system SHALL obtain player, squad, vehicle, flag, position, economy, and observation facts from SCUM.db through server-bound run/agent jobs that execute plugin-declared read templates against the current service machine.
Scenario: Current service database is queried
- WHEN a server instance has an active run binding with the declared SCUM SQLite read capability
- THEN platform queues declared read observation jobs for that server instance, run executes them against the local SCUM.db, and platform receives typed rows without exposing host paths, DSNs, sockets, or SQL text to the browser
Scenario: Database unavailable
- WHEN the bound run reports SCUM.db missing, locked, schema-incompatible, or unavailable
- THEN platform records the observation failure and marks affected projections stale without replacing existing values with generated or placeholder data
Requirement: Local projection surfaces
The system SHALL persist local projections for players, squads, squad members, vehicles, flags, current positions, and data observations before any product surface reads them.
Scenario: Typed result updates projections
- WHEN platform accepts a successful typed query result for a server/plugin/query binding
- THEN it validates schema, checksum, row bounds, observed time, and server binding before upserting the corresponding projection records
Scenario: Page reads projection only
- WHEN platform_web or a plugin page renders SCUM users, squads, vehicles, flags, or map positions
- THEN it reads platform-local projections and freshness metadata rather than directly querying run, SCUM.db, or sample data
Requirement: Freshness and conflict handling
The system SHALL keep observation sequence, checksum, observedAt, receivedAt, and fresh/stale state for every projected SCUM data category.
Scenario: Older observation arrives after newer one
- WHEN platform receives an observation whose sequence or observedAt is older than the current projection for the same source key
- THEN platform rejects it for projection while keeping an audit-safe observation record
Scenario: Query failure after successful projection
- WHEN a later read observation fails after a prior successful projection exists
- THEN platform keeps the last-known-good projection, records the failure, and exposes stale status to the UI
Requirement: Unknown fields stay unknown
The system SHALL represent missing or unverifiable SCUM fields as unknown, absent, or stale instead of deriving fake values from unrelated tables or timestamps.
Scenario: Steam ID missing from SCUM.db row
- WHEN a SCUM.db player row has a user_profile_id but no verified user_id/Steam identifier
- THEN platform stores the profile identifier separately and marks the external player identifier unknown rather than treating user_profile_id as Steam ID
Scenario: last_save_time is present
- WHEN a prisoner row includes
last_save_time - THEN platform may use it as data freshness evidence but SHALL NOT use it alone as online-state proof