browser/openspec/changes/move-scum-deployment-lifecycle-to-plugin/design.md

Design

The lifecycle boundary becomes:

• Platform validates the selected plugin, resolves the plugin lifecycle action reference, packages plugin action assets into generated run workspaces, and dispatches a generic lifecycle job with typed inputs.
• The SCUM plugin owns Windows scripts/action specs that check whether SCUMServer.exe exists, install or update through SteamCMD, stop before update, write plugin-declared config values, and start with plugin-declared port/MaxPlayers plus the plugin default -log.
• Run executes the referenced action through generic primitives. It never branches on game.scum, SCUMServer.exe, or app 3792580.

SCUM Plugin Action Model

The SCUM install action is the authoritative setup action. It runs before first start and may also be reused as a pre-start update action. The action checks for SteamCMD, downloads it if missing, stops the SCUM process when an update is needed, runs:

./steamcmd.exe +force_install_dir C:/scumserver +login anonymous +app_update 3792580 validate +quit

Then the start action runs:

C:/scumserver\SCUM\Binaries\Win64\SCUMServer.exe -port=<gamePort> -MaxPlayers=<maxPlayers> -log

The concrete path may come from server deployment inputs, but the SCUM executable relative path, app id, SteamCMD arguments, and -log default are plugin assets, not platform/run code.

Platform Changes

Platform no longer freezes a ServerDeploymentPlan for SCUM or requires deployment.scum.v1. It keeps generic deployment definitions and dispatches plugin action refs. Deployment projections can still show queued/running/failed lifecycle state from generic receipts, but detailed SCUM evidence is plugin-generated output/log/artifact data, not a platform-owned SCUM evidence schema.

Run Changes

Run removes the SCUM deployment executor and SCUM capability advertisement. Assignments carrying serverDeploymentPlan are rejected as legacy unsupported input. Generic lifecycle template execution remains, including managed process start/stop/status, file operations, logs, and artifacts.

Risks / Trade-Offs

• Existing tests expecting SCUM evidence need to shift to plugin-action dispatch assertions.
• The first plugin script implementation must be careful about Windows quoting and idempotency.
• If future games need richer setup flows, add generic action primitives or structured lifecycle DSL features without moving game policy into run.