Rebuild SCUM plugin data ownership
This commit is contained in:
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-08-14
|
||||
@@ -0,0 +1,22 @@
|
||||
# Design
|
||||
|
||||
## Ownership
|
||||
|
||||
Platform owns authentication, server-instance authorization, durable storage mechanics, collection scoping, and transaction boundaries. It does not interpret collection payloads.
|
||||
|
||||
The SCUM plugin owns collection names such as `scum_users`, schemas, upsert keys, data transformations, gifts, map geometry, and UI behavior. It declares database/file/log work in the manifest; Platform dispatches those declarations to Run, and Run executes on the machine.
|
||||
|
||||
## Generic Platform Data Contract
|
||||
|
||||
The generic record is scoped by `pluginId`, `serverInstanceId`, `collection`, and `key`, with an opaque JSON `value` and timestamps. The platform validates scope and authorization only. A page bridge exposes list/get/put/delete generic collection methods to plugin bundles.
|
||||
|
||||
## SCUM Data Flow
|
||||
|
||||
1. The plugin declares v57 SQLite queries plus config/log parsers in its own versioned assets.
|
||||
2. Platform dispatches the selected declared operation to Run; no browser or plugin supplies a machine path or SQL string at request time.
|
||||
3. Plugin-shaped results are stored in scoped `scum_*` collections through the generic store.
|
||||
4. The SCUM page reads those collections through the generic bridge and applies all SCUM-specific presentation and gift logic locally.
|
||||
|
||||
## Compatibility
|
||||
|
||||
Recent SCUM-specific Platform routes, types, repository tables, and game-gift APIs are removed. The retained generic bridge remains usable by other game plugins without SCUM imports or switches.
|
||||
@@ -0,0 +1,18 @@
|
||||
# Rebuild SCUM Plugin-Owned Data
|
||||
|
||||
## Why
|
||||
|
||||
The previous SCUM data implementation placed game-specific projections, gift rules, and browser callbacks in Platform. That couples every SCUM version change to Platform releases and makes the implementation larger than the required relay role.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Replace the recent SCUM direct-data and game-gift additions with a generic plugin data store and generic plugin-page data bridge.
|
||||
- Keep SCUM SQLite, configuration, and log access plugin-declared and dispatched through Platform to Run.
|
||||
- Put SCUM `scum_*` collection names, record shapes, gift catalog/grant behavior, map rendering inputs, and feature UI in the SCUM plugin package.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- Platform exposes no SCUM-, squad-, map-, or gift-specific data API/service/model added by this change.
|
||||
- The SCUM plugin can read and write its scoped platform collections for users, squads, activity, gifts, and map points through generic bridge calls.
|
||||
- Version-specific SQL/config/log declarations remain in the SCUM manifest and assets.
|
||||
- Existing generic lifecycle and machine-job dispatch behavior remains intact.
|
||||
@@ -0,0 +1,25 @@
|
||||
## 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
|
||||
|
||||
### 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
|
||||
@@ -0,0 +1,9 @@
|
||||
# Tasks
|
||||
|
||||
- [x] Revert the direct-data and reference-alignment commits while retaining unrelated local-debug fixes.
|
||||
- [x] Add a generic scoped plugin data record model, repository, service, DTO, and HTTP API in Platform.
|
||||
- [x] Add generic collection actions to the plugin-page host and browser API client.
|
||||
- [ ] Restore SCUM v57 SQL, config, log, and gift assets in the plugin package.
|
||||
- [ ] Rebuild the SCUM plugin page to use only generic collection bridge actions for users, squads, activity, gifts, and map points.
|
||||
- [ ] Remove obsolete SCUM-specific Platform/frontend data and gift surfaces that conflict with plugin ownership.
|
||||
- [ ] Add focused backend, plugin, and frontend tests; run structure and OpenSpec validation.
|
||||
Reference in New Issue
Block a user