功能修改
This commit is contained in:
npc0-hue
+127
@@ -0,0 +1,127 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: SCUM plugin owns SCUM operation semantics
|
||||
|
||||
The `game.scum` plugin SHALL declare SCUM-specific commands, snapshot schemas, log event schemas, database query templates, permissions, approval levels, page contracts, and policy labels.
|
||||
|
||||
#### Scenario: Platform loads SCUM bridge declarations
|
||||
|
||||
- **WHEN** the Platform registers the SCUM plugin manifest
|
||||
- **THEN** it validates the declared SCUM operation catalog and stores safe declarations without adding SCUM business logic to independent Run
|
||||
|
||||
#### Scenario: Unknown SCUM command is rejected
|
||||
|
||||
- **WHEN** a plugin page or operator attempts to queue a SCUM command that is not declared by the active SCUM plugin catalog
|
||||
- **THEN** the Platform rejects the command before it reaches a companion client
|
||||
|
||||
### Requirement: SCUM companion client uses Platform identity and bridge APIs
|
||||
|
||||
The SCUM companion client SHALL register and heartbeat through the Platform Client Manager component-session flow and SHALL use Game Client Bridge command and snapshot APIs for game-window interaction.
|
||||
|
||||
#### Scenario: Generated client package starts with platform config
|
||||
|
||||
- **WHEN** a SCUM Client Manager package is generated and deployed
|
||||
- **THEN** its runtime configuration aligns with the actual companion client bootstrap and includes only the material required to register with Platform through the current component-key generation
|
||||
|
||||
#### Scenario: Legacy shared-token endpoint is not used
|
||||
|
||||
- **WHEN** a SCUM companion client exchanges commands or snapshots with Platform
|
||||
- **THEN** it does not use legacy shared-token `/api/v1/scum-clients/hello`, `/heartbeat`, `/commands`, `/results`, or `/snapshots` endpoints
|
||||
|
||||
#### Scenario: Insecure TLS skip is not allowed
|
||||
|
||||
- **WHEN** the SCUM companion client connects to Platform
|
||||
- **THEN** it must not disable certificate verification through an unconditional insecure TLS setting
|
||||
|
||||
### Requirement: SCUM snapshots cover core operational state
|
||||
|
||||
The SCUM plugin SHALL define typed snapshot schemas for at least online sessions, players, squads, vehicles, flags or territories, and companion health diagnostics.
|
||||
|
||||
#### Scenario: Player snapshot is ingested
|
||||
|
||||
- **WHEN** the SCUM companion client uploads a declared player or online-session snapshot
|
||||
- **THEN** Platform stores a versioned safe projection that plugin pages can query by server instance and observed time
|
||||
|
||||
#### Scenario: Vehicle and flag snapshots are ingested
|
||||
|
||||
- **WHEN** the SCUM companion client uploads declared vehicle, squad, flag, or territory snapshots
|
||||
- **THEN** Platform validates the schema version and sequence before updating the current projection
|
||||
|
||||
### Requirement: SCUM command catalog is bounded and permissioned
|
||||
|
||||
The SCUM plugin SHALL expose only declared, typed, permission-scoped game commands such as announcements, player lookup, reward delivery, event actions, maintenance preparation, and safe companion diagnostics.
|
||||
|
||||
#### Scenario: Operator queues announcement
|
||||
|
||||
- **WHEN** an authorized operator queues a declared SCUM announcement command
|
||||
- **THEN** Platform records the requester, approval state, command payload, idempotency key, and audit event before the companion client can claim it
|
||||
|
||||
#### Scenario: Risky command requires approval
|
||||
|
||||
- **WHEN** a SCUM command is marked as risky, destructive, economy-affecting, or punitive
|
||||
- **THEN** Platform requires the declared approval level before making the command claimable
|
||||
|
||||
### Requirement: SCUM moderation begins as evidence and review
|
||||
|
||||
The SCUM plugin SHALL model suspicious duplicate IP, unlock, mine, trade, kill, admin, and economy signals as evidence, alerts, and operator-reviewed recommendations by default.
|
||||
|
||||
#### Scenario: Suspicious event is parsed
|
||||
|
||||
- **WHEN** SCUM semantic log parsing detects a suspicious event pattern
|
||||
- **THEN** Platform records a typed evidence event or alert without automatically banning, punishing, or modifying the player
|
||||
|
||||
#### Scenario: Operator approves punitive action
|
||||
|
||||
- **WHEN** an operator chooses a punitive SCUM action from a recommendation
|
||||
- **THEN** Platform applies the command catalog permission and approval rules before dispatching any companion command
|
||||
|
||||
### Requirement: SCUM logs are parsed into typed events
|
||||
|
||||
The SCUM plugin SHALL define typed semantic log events for chat, login, logout, kill, trade, mine, unlock, admin, and performance records.
|
||||
|
||||
#### Scenario: Chat log event is parsed
|
||||
|
||||
- **WHEN** SCUM chat log lines are ingested
|
||||
- **THEN** Platform stores typed chat events that plugin pages can filter by player, time range, and server instance
|
||||
|
||||
#### Scenario: Performance log event updates metrics
|
||||
|
||||
- **WHEN** SCUM performance log lines are ingested
|
||||
- **THEN** Platform maps FPS and entity counts into bounded metric projections and alert inputs
|
||||
|
||||
### Requirement: SCUM database access uses read-only templates
|
||||
|
||||
The SCUM plugin SHALL declare read-only SCUM.db query templates with typed parameters, bounded result schemas, and permission scopes instead of exposing arbitrary SQL.
|
||||
|
||||
#### Scenario: Operator runs player lookup template
|
||||
|
||||
- **WHEN** an authorized operator runs a declared player lookup query template
|
||||
- **THEN** Platform dispatches a bounded read-only request and returns only the declared result columns
|
||||
|
||||
#### Scenario: Arbitrary SQL is requested
|
||||
|
||||
- **WHEN** a plugin page submits SQL text that is not backed by a declared query template
|
||||
- **THEN** Platform rejects the request and does not dispatch it to Run or the companion client
|
||||
|
||||
### Requirement: SCUM backup and restart policy remains plugin-declared
|
||||
|
||||
The SCUM plugin SHALL declare backup scopes, retention policy, restart schedules, warning announcements, and update-check policy as SCUM operational policy while Platform and Run execute only generic jobs.
|
||||
|
||||
#### Scenario: Scheduled restart is prepared
|
||||
|
||||
- **WHEN** a SCUM restart schedule reaches its warning window
|
||||
- **THEN** Platform queues declared SCUM announcement commands and generic lifecycle actions according to plugin policy and operator approvals
|
||||
|
||||
#### Scenario: Backup is requested
|
||||
|
||||
- **WHEN** an authorized operator requests a SCUM backup
|
||||
- **THEN** Platform records the logical SCUM backup scope and dispatches generic archive/artifact operations without exposing raw host paths or storage credentials to the plugin page
|
||||
|
||||
### Requirement: SCUM operation pages use safe Platform projections
|
||||
|
||||
The SCUM plugin pages SHALL render bridge state, snapshots, commands, logs, backup/restart policy, and review flows using Platform-mediated DTOs only.
|
||||
|
||||
#### Scenario: SCUM operations page loads
|
||||
|
||||
- **WHEN** a user opens the SCUM operations page for a server instance
|
||||
- **THEN** the page can display safe bridge status, companion health, current snapshots, command availability, and recent results without receiving raw secrets, host paths, DSNs, direct Run sockets, or component session material
|
||||
Reference in New Issue
Block a user