woekshop phase 1

docs/modules/CONFIG_GAMES.md

@@ -0,0 +1,53 @@
+# Config Games
+
+Workspace reference: [`GSP-WORKSPACE.md`](../../../GSP-WORKSPACE.md)
+
+This file is the prompt-facing entry point for the Config Games module. The historical lower-case document remains at [`config_games.md`](config_games.md).
+
+## Purpose
+
+Config Games owns game XML definitions, XML schema validation, startup parameter templates, mod definitions, port metadata, and game capability declarations used by Panel modules.
+
+## Workshop XML Source Of Truth
+
+Steam Workshop support is configured by game XML, not Server Content admin rows.
+
+Canonical structure:
+
+```xml
+<workshop_support>
+  <enabled>1</enabled>
+  <provider>steam</provider>
+  <steam_app_id>107410</steam_app_id>
+  <workshop_app_id>107410</workshop_app_id>
+  <download_method>steamcmd</download_method>
+  <install_strategy>arma_mod_folder</install_strategy>
+  <install_path>{SERVER_ROOT}/{MOD_FOLDER}</install_path>
+  <startup_param_format>-mod={MOD_LIST}</startup_param_format>
+  <mod_separator>;</mod_separator>
+  <mod_prefix>@</mod_prefix>
+  <copy_keys enabled="1">
+    <source_pattern>{MOD_PATH}/keys/*.bikey</source_pattern>
+    <target_path>{SERVER_ROOT}/keys</target_path>
+  </copy_keys>
+  <post_install_action></post_install_action>
+</workshop_support>
+```
+
+Rules:
+
+- `workshop_support` belongs after `game_name` and before `server_exec_name`.
+- `workshop_app_id` is required for customer Workshop installs.
+- `install_path` defaults to `{SERVER_ROOT}/workshop/{MOD_FOLDER}` unless the install strategy is Arma/DayZ-style, where `{SERVER_ROOT}/{MOD_FOLDER}` is used.
+- `post_install_action` is an admin-owned action/template identifier, not customer shell input.
+- Static Workshop script paths are not part of the XML contract.
+- Server Content Manager generates per-job scripts and calls generic agent execution.
+
+## Validation
+
+Validate all game XML definitions with:
+
+```bash
+php Panel/modules/config_games/tests/validate_server_configs.php
+```
+

docs/modules/SERVER_CONTENT_MANAGER.md

@@ -42,24 +42,24 @@ For Workshop items, the current flow lets users enter Workshop IDs or full Steam
 
 ## Workshop Phase 1 Flow
 
-1. Admin creates a Server Content template with install method `steam_workshop`.
-2. Admin configures the Workshop App ID on the template or relies on the game XML/profile fallback.
+1. Admin enables Workshop by adding a canonical `workshop_support` block to the game XML.
+2. Server Content Manager detects that capability from the selected server's XML.
 3. User opens `Server Content` from the game monitor.
-4. User selects the Steam Workshop Mods category.
-5. User enters one or more Workshop URLs or numeric IDs.
+4. User selects the Steam Workshop Mods category. A Server Content template is no longer required just to expose Workshop for XML-enabled games.
+5. User enters one or more Workshop URLs or numeric IDs, searches the local catalog, or opens Steam's app-scoped Workshop search from the page.
 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 writes a generated per-job shell script into `{SERVER_HOME}/gsp_server_content/jobs/workshop/`.
 9. The generated job script creates a temporary SteamCMD runscript containing `workshop_download_item <appid> <workshop_id> validate`.
 10. Agent executes the generated script with the manifest path through the existing authenticated `exec` RPC.
-11. Script runs SteamCMD with `+runscript`, copies Workshop content into the configured target path, copies DayZ/Arma `.bikey` files when applicable, and writes a log under `gsp_server_content`.
+11. Script runs SteamCMD with `+runscript`, copies Workshop content into the XML-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 job-script behavior:
 
 - Server Content Manager generates a new job script for each Workshop action.
-- Admin-defined static Workshop script paths are deprecated and ignored by the primary path.
+- Game XML does not define static Workshop script paths.
 - Default script names such as `generic_steam_workshop_windows_cygwin.sh` must not be checked as bare files on the agent.
 - Agents need only the generic `writefile` and `exec` primitives.
 
@@ -68,7 +68,7 @@ Current default install paths:
 - Generic Steam Workshop content: `{SERVER_ROOT}/workshop/{MOD_FOLDER}`
 - DayZ / Arma strategy content: `{SERVER_ROOT}/{MOD_FOLDER}` for root `@<workshop_id>` folder compatibility
 
-Game XML fallback should use the canonical `workshop_support` block:
+Game XML must use the canonical `workshop_support` block:
 
 ```xml
 <workshop_support>
@@ -86,10 +86,11 @@ Game XML fallback should use the canonical `workshop_support` block:
     <source_pattern>{MOD_PATH}/keys/*.bikey</source_pattern>
     <target_path>{SERVER_ROOT}/keys</target_path>
   </copy_keys>
+  <post_install_action></post_install_action>
 </workshop_support>
 ```
 
-The Panel helper parser reads this block first and only tolerates old direct tags as an internal compatibility fallback.
+The Panel helper parser reads this block as the source of truth. Server Content admin forms do not collect Workshop app IDs, install paths, launch parameter additions, optional mod folder names, or static Workshop scripts.
 
 SteamCMD requirements:
 
@@ -104,6 +105,9 @@ The legacy `steam_workshop` monitor button is intentionally suppressed so users
 The `workshop_content.php` page supports:
 
 - direct install by numeric ID or Steam Workshop URL
+- keyword/tag search against the local catalog
+- app-scoped Steam Workshop search links for the selected game
+- a list of Workshop-enabled games matching the current search terms
 - installed item list
 - enable/disable selected items
 - update selected items
@@ -111,7 +115,7 @@ The `workshop_content.php` page supports:
 - 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
+- known/common item catalog sorted by name, Workshop ID, install count, published date, last updated, or last installed
 
 Update policies are stored as data for Scheduler/automation:
 
@@ -131,6 +135,7 @@ Update policies are stored as data for Scheduler/automation:
 - 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.
 - Cache and cleanup policy need a clearer product design.
+- Direct Steam Web API keyword/tag search is not implemented yet; the current search page uses local catalog records and links out to Steam's Workshop search.
 
 ## Where To Start Reading
 

docs/modules/config_games.md

@@ -74,7 +74,9 @@ Key fields:
 - `startup_param_format`
 - `mod_separator`
 - `mod_prefix`
+- `mod_folder_format`
 - `copy_keys`
+- `post_install_action`
 
 Validate changes with:
 
@@ -85,7 +87,9 @@ 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.
+- Do not add loose top-level tags such as `workshop_app_id`; schema-valid XML must use the canonical block.
+- Do not add static Workshop script tags. Server Content Manager generates per-job scripts and uses generic agent execution.
+- Do not configure Workshop App ID, target path, mod folder, or launch parameter fields in Server Content admin rows. These values come from this XML 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