redo of steam workshop

docs/modules/SERVER_CONTENT_MANAGER.md

@@ -22,6 +22,7 @@ Known tables used by the module:
 
 - `addons`
 - `server_content_workshop`
+- `server_content_workshop_catalog`
 - `server_content_manifest`
 - `server_content_install_history`
 
@@ -35,7 +36,7 @@ The module can already represent several content types, including:
 - config packs
 - future profile-type content
 
-For Workshop items, the current flow lets users enter Workshop IDs or full Steam Workshop URLs and routes the install through module pages and agent-side scripts.
+For Workshop items, the current flow lets users enter Workshop IDs or full Steam Workshop URLs and routes the install through module pages, staged manifests, and Panel-bundled scripts executed through existing agent primitives.
 
 ## Workshop Phase 1 Flow
 
@@ -47,9 +48,11 @@ For Workshop items, the current flow lets users enter Workshop IDs or full Steam
 6. Panel parses IDs, rejects invalid entries, and records rows in `server_content_workshop`.
 7. Panel writes a manifest to `{SERVER_HOME}/gsp_server_content/workshop_manifest.json`.
 8. Panel syncs the bundled Linux or Cygwin script into `{SERVER_HOME}/gsp_server_content/scripts/workshop/`.
-9. Agent executes the script with the manifest path.
+9. Agent executes the script with the manifest path through the existing authenticated `exec` RPC.
 10. Script runs SteamCMD, copies Workshop content into the configured target path, copies DayZ/Arma `.bikey` files when applicable, and writes a log under `gsp_server_content`.
 
+The agents are intentionally generic executors in this design. New Workshop business logic should not be added to `Agent-Windows` or `Agent_Linux`; use `remote_writefile`, `exec`, log reads, and normal start/stop/restart primitives instead.
+
 Current script fallback behavior:
 
 - Admin-defined custom scripts are supported when they exist on the agent.
@@ -92,10 +95,34 @@ SteamCMD requirements:
 
 The legacy `steam_workshop` monitor button is intentionally suppressed so users are not sent to the deprecated standalone module.
 
+## Current User Controls
+
+The `workshop_content.php` page supports:
+
+- direct install by numeric ID or Steam Workshop URL
+- installed item list
+- enable/disable selected items
+- update selected items
+- remove selected items
+- download selected items without installing immediately
+- update all saved Workshop items
+- per-item update policy storage
+- known/common item catalog sorted by name, install count, published date, last updated, or last installed
+
+Update policies are stored as data for Scheduler/automation:
+
+- `manual`
+- `scheduled`
+- `update_now`
+- `update_and_restart`
+- `download_only`
+- `install_on_restart`
+
 ## Current Limitations
 
 - Workshop and content metadata is still partial.
-- Load order and enable/disable are tracked but not wired into startup-parameter generation yet.
+- Load order is tracked but not yet reorderable through a polished drag-and-drop UI.
+- Enable/disable is tracked but not wired into startup-parameter generation yet.
 - Async install job progress should be more visible.
 - Install strategies are still being broadened and need consistent game-specific rules.
 - DayZ/Arma style key-copy is implemented for Phase 1; startup-param behavior still needs a stronger canonical implementation.

docs/modules/config_games.md

@@ -80,6 +80,12 @@ Validate changes with:
 php Panel/modules/config_games/tests/validate_server_configs.php
 ```
 
+Important rules:
+
+- Place `workshop_support` after `game_name` and before `server_exec_name`.
+- Do not add loose top-level tags such as `workshop_app_id`; helper code may tolerate them for old configs, but schema-valid XML should use the canonical block.
+- XML declares capability only. Server Content Manager owns the Panel-side install orchestration and uses agents only for generic file/command execution.
+
 ## Suggested Future Improvements
 
 - extend XML capability model