Document platform plugin run boundaries

This commit is contained in:
npc0-hue
2026-07-31 17:41:54 +08:00
parent f23d18ea57
commit bca4f935ba
3 changed files with 22 additions and 0 deletions
+6
View File
@@ -6,6 +6,12 @@ This file applies to `plugins/`.
Plugins are game management plugins. Do not model unrelated billing, cloud sales, host provider behavior, or independent plugin backend services here.
Game-specific lifecycle behavior belongs here, not in platform services or the generic run executor. A plugin must own its install, update, pre-start checks, start command construction, stop behavior, status checks, executable paths, dependency commands, default launch flags, and game-specific app IDs.
When a game needs automatic setup, express it through plugin manifests, action specs, templates, or scripts. For example, the SCUM plugin should own the SteamCMD install/update flow, including stopping the server before update, running `steamcmd +force_install_dir ... +login anonymous +app_update 3792580 validate +quit`, and starting `SCUMServer.exe` with plugin-declared `port` and `MaxPlayers` plus the plugin default `-log`.
Do not rely on run or platform hardcoding a specific game path, Steam app ID, command line, or startup flag to make a plugin work. If a new capability is needed, declare the generic capability the plugin needs and keep the game-specific policy in the plugin.
## Structure Rules
Manifests, schemas, SDK contracts, example plugins, and test fixtures must live in dedicated directories. Do not bury action schemas or bridge types inside UI page code.