browser/openspec/changes/move-scum-feature-ownership-to-plugin/specs/scum-plugin-feature-ownership/spec.md

ADDED Requirements

Requirement: SCUM feature ownership is plugin-local

The system SHALL place SCUM-specific configuration semantics, player/gift/map/state-patch behavior, schemas, validators, Companion handlers, and feature UI modules in the SCUM plugin package. The platform SHALL expose only generic authorization, isolation, audit, storage, queue, retention, and plugin-host primitives and SHALL NOT add new SCUM-named domain services, API handlers, or frontend panels.

Scenario: A new SCUM capability is added

• WHEN a SCUM-specific configuration field, event type, command, or view is introduced
• THEN its implementation and tests are added to the SCUM plugin package while the platform change, if any, is reusable by non-SCUM plugins

Scenario: Existing platform SCUM code is migrated

• WHEN an existing SCUM service or panel is replaced by its plugin equivalent
• THEN the platform retains only a generic primitive and no hard-coded game.scum branch or SCUM component import remains in the plugin host

Requirement: Plugin-owned pages mount in the platform host

The SCUM plugin SHALL declare versioned page-module entries and their required permissions/capabilities. The platform web host SHALL mount the declared module inside the existing authenticated themed shell and SHALL pass only server-scoped, permission-filtered host context.

Scenario: Authorized administrator opens a SCUM page

• WHEN an administrator with the declared permission opens a SCUM plugin route for an assigned server
• THEN the host loads the SCUM-declared page module with that server-scoped context and does not use a platform-owned SCUM page implementation

Scenario: Page module is unavailable or incompatible

• WHEN the declared SCUM page bundle fails integrity/version/capability validation
• THEN the host shows an unavailable-page state and does not fall back to a hard-coded SCUM panel

Requirement: Feature availability requires a plugin implementation

The system SHALL expose a SCUM feature as actionable only when the installed plugin declares the feature and its Companion reports a compatible handler or event producer for the bound server version. Transitional platform records MAY be displayed as migrated read-only history but SHALL NOT imply executable capability.

Scenario: Unsupported state patch adapter

• WHEN the bound SCUM version has no verified game-state.patch handler
• THEN the plugin disables the edit control and reports that the version is unsupported without queuing a generic command

Scenario: Vehicle spawn handler is unavailable

• WHEN the bound Companion does not report the declared vehicle.spawn handler for its compatible version
• THEN the plugin keeps vehicle spawning unavailable and does not display a raw command field or queue a generic RCON command

Scenario: Historical records during migration

• WHEN records created by the transitional platform implementation exist for a bound server
• THEN the plugin can display them with migration provenance while new writes use the plugin-owned feature path