Document platform plugin run boundaries
This commit is contained in:
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user