4.6 KiB
ADDED Requirements
Requirement: SCUM user management surface
The system SHALL provide a SCUM user management surface backed by local projections from login logs and SCUM.db observations.
Scenario: Player list renders real records
- WHEN an operator opens SCUM user management
- THEN the page lists real player records with source, identity, character name, profile ID, Steam/user ID when known, squad, balances, fame, coordinates, online/session status evidence, and last observation freshness
Scenario: Player edit opens typed workflow
- WHEN an operator edits fame, currency, gift eligibility, or declared player state fields
- THEN the page creates a typed operation workflow for review/approval instead of editing projected values directly
Requirement: Squad and flag management surface
The system SHALL provide squad and flag management backed by real squad, squad_member, user_profile, base_element, and related SCUM observations where available.
Scenario: Squad page shows roster and territory
- WHEN an operator opens squad management
- THEN the page shows squads, members, ranks, leader, linked flags, member/player projection freshness, and unknown fields without fabricated owners or coordinates
Scenario: Flag page shows stale ownership
- WHEN a flag observation is stale or owner data cannot be verified
- THEN the page marks the flag stale or unknown and offers a refresh workflow rather than inventing owner data
Requirement: Realtime map surface
The system SHALL provide a realtime SCUM map surface where players, vehicles, flags, squads, and selected risk overlays use platform-local projections and freshness state.
Scenario: Map renders current projections
- WHEN map data is fresh enough for display
- THEN the page overlays players, vehicles, flags, squad territory, last-observed timestamps, and source confidence from local projections
Scenario: Map data is stale
- WHEN the map has stale or missing projections
- THEN the page shows stale status and refresh workflow controls without using sample points, fake routes, or placeholder coordinates
Requirement: Gift management surface
The system SHALL provide gift catalog, schedule, eligibility, approval, delivery, notification, confirmation, and claim-state management using typed workflows.
Scenario: Scheduled gift becomes eligible
- WHEN a daily, weekly, monthly, yearly, one-time, or multi-per-day gift rule becomes eligible for a player type or achievement condition
- THEN platform creates a gift delivery workflow and marks the grant delivered only after typed run/companion result and confirmation succeed
Scenario: Delivery result unknown
- WHEN delivery dispatch succeeds but confirmation is missing or ambiguous
- THEN platform marks the grant unknown or pending-confirmation and prevents duplicate delivery until reconciliation completes
Requirement: AI assistant remains for typed configuration and workflows
The system SHALL keep the AI assistant as a first-party helper for plugin setup, config diffing, and operation drafts while routing all proposed effects through reviewable typed diffs or workflows.
Scenario: AI configures plugin settings
- WHEN an operator asks AI to configure the SCUM plugin
- THEN AI can propose changes only for plugin-declared config fields, platform validates the diff, and approved changes use the existing config approval/dispatch path
Scenario: AI suggests operation workflow
- WHEN AI suggests a player correction, gift rule, map refresh, squad audit, or vehicle audit
- THEN platform creates a draft workflow request that requires human review before execution
Requirement: Raw product surfaces removed
The system SHALL remove product-facing raw log, management terminal/RCON input, arbitrary config workbench, and generic operation history pages and dedicated APIs from the server detail experience.
Scenario: Server detail route list is built
- WHEN platform_web builds server detail navigation and plugin workspace contracts
- THEN it excludes raw logs, management terminal, arbitrary config editor, and generic operation-history views while preserving AI assistant, typed workflows, lifecycle status, internal log ingest, audit, and run channels
Scenario: Raw endpoint is requested
- WHEN a browser calls a removed product-layer raw logs, terminal, arbitrary config, or operation-history API
- THEN platform returns not found or the new typed workflow/status API without exposing raw terminal, raw SQL, raw host paths, or raw config editing capability