## ADDED Requirements

### Requirement: Generic Plugin Collection Storage
Platform SHALL persist opaque plugin records scoped by plugin identifier, server instance identifier, collection name, and record key.

#### Scenario: SCUM stores a user projection
- **WHEN** the SCUM plugin writes key `7656119...` to its `scum_users` collection for an authorized server instance
- **THEN** Platform stores the opaque record without interpreting SCUM fields
- **AND** another plugin or server instance cannot read the record through the scoped API

#### Scenario: Plugin updates a collection atomically
- **WHEN** an authorized plugin page submits a transaction containing collection puts and deletes
- **THEN** Platform validates the complete transaction before applying it
- **AND** the repository exposes the resulting records as one collection change

### Requirement: Plugin-Owned SCUM Domain
The SCUM plugin SHALL own its collection names, record schemas, gift behavior, map behavior, and version-specific data extraction assets.

#### Scenario: SCUM version changes
- **WHEN** a SCUM database or log format changes
- **THEN** the SCUM plugin updates its versioned query/parser assets
- **AND** Platform does not require a SCUM business-logic change

### Requirement: Machine Data Relay
SCUM machine SQLite, configuration, and log operations SHALL remain plugin-declared and Platform-dispatched to Run.

#### Scenario: Declared SQLite read
- **WHEN** a SCUM page requests a declared data refresh
- **THEN** Platform routes the declared operation through Run
- **AND** neither the page nor Platform's generic collection API accepts a raw host path or arbitrary SQLite statement

#### Scenario: Run reports declared query rows
- **WHEN** Run completes a declared SQLite query with a structured `rows` result
- **THEN** Platform uses only the plugin-declared collection, upsert keys, and column mappings to persist the rows
- **AND** Platform does not branch on the game, query key, collection name, or row fields