2.0 KiB
Context
scum_new_web and scum_robot establish the useful operator shape: players can be searched and narrowed by squad, squads expose their rosters, maps use layers and marker inspection, and gifts distinguish definitions from a player's receipt history. The existing browser repository already has typed SCUM observations and gift workflows, so the design extends those contracts instead of importing the old direct-access path.
Decisions
Projection views compose existing facts
The frontend reads users, squads, squad members, vehicles, flags, map points, observed timed-gift events, and platform gift APIs. It joins those responses only for display. A user action creates existing typed operations or gift grants; it never mutates a projection in the browser.
Plugin data packs own version-sensitive game data
The SCUM manifest names a v57 gift-item catalog and map geometry data asset. The platform resolves a requested gift item through the installed server plugin and game version. Updating SCUM changes the plugin package, not platform code.
Observed events have a distinct target table
finished_timed_gift_spawner represents a completed in-game timed-gift event. It is stored as scum_gift_events; game_gift_catalogs, revisions, and grants remain platform-owned operational data. This removes the ambiguous old scum_gift_catalogs observation table.
Map is geometric, not a copied game asset
The plugin supplies world bounds and axis direction. The web client projects points into that normalized frame and exposes player, vehicle, base, and flag layers. No copyrighted tile bundle is copied. Trajectory playback remains dependent on independently collected track points.
Verification
- Go tests covering observed-gift target and plugin-resolved gift items.
- Plugin typecheck, tests, and manifest validation.
- Frontend typecheck, tests, and build.
scripts/check-structure.shandopenspec validate align-scum-operations-with-reference-tools --strict.