refactor(scum): use runtime capability probes

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

@@ -1,38 +1,37 @@
 ## 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
+The SCUM plugin SHALL own SCUM schemas, allowlists, migration adapters,
+Companion behavior, and feature UI. The platform SHALL retain only reusable
+authorization, isolation, auditing, queues, storage, and generic plugin-host
+primitives. `platform_web` SHALL not import SCUM code or branch on `game.scum`.
 
-#### 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
+#### Scenario: Page mounting
 
-### 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.
+- **WHEN** an authorized administrator opens the installed plugin route
+- **THEN** the generic host mounts the declared plugin bundle with only
+  server-scoped permission 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
+### Requirement: Feature availability is runtime scoped
 
-#### 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
+The plugin SHALL expose a feature as actionable only when its declared
+Companion handler or event producer is currently available for that server.
+Availability SHALL not be gated by a game or adapter version/build/revision.
 
-### 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: One adapter fails
 
-#### 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
+- **WHEN** a schema probe for state patching fails
+- **THEN** state patching is unavailable with a typed reason while other
+  declared capabilities remain independently available
 
-#### 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
+### Requirement: Transitional records are read-only migration input
 
-#### 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
+Platform records MAY be displayed with provenance while plugin-owned records
+become authoritative per server and feature. Migration flags SHALL be scoped
+to the server and feature, never to a game version.
+
+#### Scenario: Migration flag is absent
+
+- **WHEN** no unique server-feature migration flag is present
+- **THEN** historical records remain readable and plugin writes stay disabled