功能修改
This commit is contained in:
npc0-hue
+119
@@ -0,0 +1,119 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Component sessions authenticate bridge access
|
||||
|
||||
The Platform SHALL require every Game Client Bridge request from a companion client to use a valid component session issued through the Client Manager registration flow.
|
||||
|
||||
#### Scenario: Valid component session uses bridge capability
|
||||
|
||||
- **WHEN** a deployed companion client registers with the current component key generation, deployment generation, and `game-client.bridge` capability
|
||||
- **THEN** the Platform accepts bridge requests for the bound server instance, plugin, profile key, artifact, and session expiry window
|
||||
|
||||
#### Scenario: Stale component session is rejected
|
||||
|
||||
- **WHEN** a companion client uses a session from a revoked key generation, expired session, old deployment generation, or undeclared bridge capability
|
||||
- **THEN** the Platform rejects the bridge request without returning raw key material or internal secret locations
|
||||
|
||||
### Requirement: Commands are durable and fenced
|
||||
|
||||
The Platform SHALL persist Game Client Bridge commands with lifecycle state, idempotency key, expiry, priority, declared command type, payload reference or inline bounded payload, target server instance, plugin, requester, approval state, claim lease, fencing token, and audit metadata.
|
||||
|
||||
#### Scenario: Operator queues declared bridge command
|
||||
|
||||
- **WHEN** an authorized operator queues a command declared by the active plugin bridge catalog
|
||||
- **THEN** the Platform stores the command as pending, records an audit event, and exposes only safe command status to plugin pages
|
||||
|
||||
#### Scenario: Duplicate idempotency key is reused
|
||||
|
||||
- **WHEN** the same requester submits the same command type with the same idempotency key for the same server instance
|
||||
- **THEN** the Platform returns the existing command instead of creating a duplicate command
|
||||
|
||||
#### Scenario: Expired command is not claimed
|
||||
|
||||
- **WHEN** a pending command has passed its expiry time before a companion client claims it
|
||||
- **THEN** the Platform marks the command expired and prevents later claim or execution
|
||||
|
||||
### Requirement: Companion clients claim and complete commands
|
||||
|
||||
The Platform SHALL let authenticated companion clients claim pending bridge commands in bounded batches and complete them only with the active claim lease and fencing token.
|
||||
|
||||
#### Scenario: Client claims pending command batch
|
||||
|
||||
- **WHEN** an online companion client polls for bridge commands for its bound server instance and profile key
|
||||
- **THEN** the Platform returns only eligible pending commands, marks them claimed, assigns leases, and includes fencing tokens
|
||||
|
||||
#### Scenario: Stale claim cannot complete command
|
||||
|
||||
- **WHEN** a companion client submits an ack or result with an expired lease, stale fencing token, or mismatched component session
|
||||
- **THEN** the Platform rejects the update and leaves the current command state protected from stale completion
|
||||
|
||||
#### Scenario: Command result is recorded
|
||||
|
||||
- **WHEN** the active claimant completes a command with a success or failure result
|
||||
- **THEN** the Platform stores sanitized result metadata, updates command status, records completion time, and emits an audit event
|
||||
|
||||
### Requirement: Operators can cancel pending or claimed commands
|
||||
|
||||
The Platform SHALL allow authorized operators to cancel bridge commands that are not already terminal and SHALL prevent cancelled commands from being executed or completed as successful.
|
||||
|
||||
#### Scenario: Pending command is cancelled
|
||||
|
||||
- **WHEN** an authorized operator cancels a pending command
|
||||
- **THEN** the Platform marks the command cancelled and excludes it from future claim batches
|
||||
|
||||
#### Scenario: Claimed command is cancelled before completion
|
||||
|
||||
- **WHEN** an authorized operator cancels a claimed command
|
||||
- **THEN** the Platform records the cancellation and rejects later success results from the old claim
|
||||
|
||||
### Requirement: Snapshots are versioned and typed
|
||||
|
||||
The Platform SHALL ingest Game Client Bridge snapshots only when their type, schema version, sequence, source component, payload shape, and retention policy match active plugin declarations.
|
||||
|
||||
#### Scenario: Client uploads declared snapshot
|
||||
|
||||
- **WHEN** a companion client uploads a snapshot that matches a declared snapshot type and schema version
|
||||
- **THEN** the Platform stores it with server instance, plugin, profile key, source session, sequence, observed time, and retention metadata
|
||||
|
||||
#### Scenario: Snapshot sequence is stale
|
||||
|
||||
- **WHEN** a companion client uploads a snapshot with a sequence older than or equal to the latest accepted sequence for the same stream
|
||||
- **THEN** the Platform rejects or quarantines the stale snapshot according to validation policy and does not replace the current projection
|
||||
|
||||
#### Scenario: Plugin page queries snapshots
|
||||
|
||||
- **WHEN** an authorized plugin page requests snapshots for an owned server instance
|
||||
- **THEN** the Platform returns bounded safe projections without raw component secrets, host paths, direct sockets, or unbounded raw dumps
|
||||
|
||||
### Requirement: Bridge traffic is isolated from Run channels
|
||||
|
||||
The Platform SHALL keep Game Client Bridge command and snapshot traffic separate from Run control heartbeat, job acknowledgement, log ingest, and artifact transfer channels.
|
||||
|
||||
#### Scenario: Large snapshot ingestion does not block control
|
||||
|
||||
- **WHEN** a companion client uploads a large but allowed snapshot payload
|
||||
- **THEN** Run control heartbeat, job acknowledgement, and log upload remain independently serviceable through their own channels
|
||||
|
||||
#### Scenario: Bridge unavailable does not disable server lifecycle
|
||||
|
||||
- **WHEN** the Game Client Bridge service is unavailable or no companion client is online
|
||||
- **THEN** existing Run lifecycle actions, log ingest, artifact transfer, and Client Manager lifecycle projections continue to operate
|
||||
|
||||
### Requirement: Browser-visible bridge DTOs are safe projections
|
||||
|
||||
The Platform SHALL expose only safe bridge declarations, command statuses, results, snapshots, availability reasons, and audit references to plugin pages.
|
||||
|
||||
#### Scenario: Plugin page loads bridge state
|
||||
|
||||
- **WHEN** a plugin page loads bridge state for a server instance
|
||||
- **THEN** the response excludes raw credentials, component keys, sessions, DSNs, host paths, direct Run endpoints, sockets, and storage provider credentials
|
||||
|
||||
### Requirement: Bridge records are retained and audited
|
||||
|
||||
The Platform SHALL apply bounded retention to bridge commands, results, snapshots, and audit references while preserving enough metadata for operator review and troubleshooting.
|
||||
|
||||
#### Scenario: Retention job expires old bridge records
|
||||
|
||||
- **WHEN** bridge records exceed configured retention limits
|
||||
- **THEN** the Platform expires or compacts old records without exposing deleted payloads through plugin page APIs
|
||||
|
||||
+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