admin343/browser
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Make generated run lifecycle autonomous

Browse Source
This commit is contained in:
npc0-hue
2026-08-06 18:57:42 +08:00
parent acec5e4367
commit 4e78957a60
22 changed files with 583 additions and 236 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+5 -5
View File
@@ -85,17 +85,17 @@ Do not define business structs inside functions. Do not define request/response
The external run executor must not expose host paths, raw credentials, or direct sockets to plugins or platform_web.
Platform, plugin, and run lifecycle ownership must stay separated. Platform records desired lifecycle intent and persisted projections, not observed process truth:
Platform, plugin, and run lifecycle ownership must stay separated. Run is the lifecycle authority for machine execution; Platform records desired lifecycle intent, registration/auth, audit, generated package inputs, and persisted projections from Run-reported facts, not observed process truth:
- Platform owns server instances, plugin manifest validation, distribution builds, run registration binding, authorization, desired lifecycle job dispatch, and persisted lifecycle projections.
- Plugins own game-specific lifecycle behavior: install, update, pre-start checks, start arguments, stop logic, status probes, executable paths, Steam app IDs, and game-specific dependency commands.
- Run owns generic machine execution and the observed runtime/process state it supervises: scoped file operations, bounded process execution/supervision, declared capability enforcement, logs, artifacts, and channel transport.
- Platform owns server instances, plugin manifest validation, platform-side distribution builds, generated Run package inputs, run registration binding, authorization/audit, and persisted lifecycle projections.
- Plugins own game-specific lifecycle declarations: init/install/update/pre-start checks, dependency probes/install plans, start arguments, stop logic, status/readiness probes, executable paths, Steam app IDs, and game-specific dependency commands.
- Run owns generic machine lifecycle execution and the observed runtime/process state it supervises: local bootstrap from generated package plans, scoped file operations, bounded process execution/supervision, declared capability enforcement, logs, artifacts, and channel transport.
Observed machine/runtime status must flow from run reports, heartbeats, supervised process facts, and job/log channels. Platform must not treat stale persisted server state, such as `running`, as authoritative when evaluating the current machine process state.
Do not hardcode game-specific deployment behavior in run or platform services. Values such as `SCUMServer.exe`, Steam app `3792580`, `steamcmd +app_update`, SCUM install directories, `-port`, `-MaxPlayers`, or `-log` belong in the SCUM plugin's manifests, action specs, templates, or scripts.
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.
When a game needs "install if missing, update if present, then start" behavior, implement it as plugin-owned lifecycle actions and package those declarations into the generated Run autonomous lifecycle plan. Run executes the plan through generic capabilities; 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.