Document plugin-owned lifecycle log rules

2026-08-04 11:44:37 +08:00
parent f028a343d7
commit de1f0d107f
2 changed files with 4 additions and 0 deletions
@@ -95,6 +95,8 @@ Do not hardcode game-specific deployment behavior in run or platform services. V

 When a game needs "install if missing, update if present, then start" behavior, implement it as plugin-owned lifecycle actions. Platform may package and dispatch those actions, and run may execute them through generic capabilities, but neither platform nor run should special-case a game by name to perform those steps.

+Do not add extra platform/frontend lifecycle states just to represent game-specific setup checks. A plugin-owned start action should verify its declared files and dependencies, create missing directories, install or update missing server bits, then start the service through the same plugin-declared lifecycle script. Run should only execute that declared script through generic supervision, hide the started process window where the operating system supports it, and return the supervised process output through the declared stdout/stderr log channels.
+
 Realtime log collection must be plugin-declared and plugin-configured. For live terminal output, prefer the plugin-declared supervised process channels (`process.stdout` / `process.stderr`) for the process that run started, and treat game-specific file tails only as plugin-declared sources for history, fallback, or explicit backfill. Do not inspect or prioritize a game log file such as `SCUM.log` merely because it exists on disk; if a plugin needs a file tail, window/console capture, startup flag, hidden window behavior, or another live-log source, declare that behavior in the plugin manifest/action/config and keep run/platform generic.

 Run-platform communication must remain channelized:
@@ -10,6 +10,8 @@ Game-specific lifecycle behavior belongs here, not in platform services or the g

 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`.

+Start scripts may perform plugin-owned environment checks before launch. If required files, directories, SteamCMD, or server binaries are missing, the plugin script should create/install/update them and then start the service in the same lifecycle path, instead of requiring new platform/frontend deployment states.
+
 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