# Server deployment lifecycle

`deployment.plan.v1` gates only generic custom-command deployment execution:
Platform sends a protected `RunJobAssignmentResponse.executionInput.deployment`
when a server uses `custom-command` mode and Run executes the operator-reviewed
argv-oriented command inside its local policy.

Guided or existing-server game setup is plugin-owned. Platform dispatches the
plugin-declared lifecycle action reference, such as `actions/install.json`, and
may include generic deployment context (`mode`, `profileKey`, `serverRoot`, and
`createInputs`) so the plugin action can resolve its own behavior. Platform does
not create a game-specific `serverDeploymentPlan`, and SCUM no longer requires a
`deployment.scum.v1` capability.

## Capability and policy

Run advertises normal lifecycle capabilities (`process.install`,
`process.start`, `process.stop`, `process.status`) and generic primitives such as
scoped files, logs, artifacts, dependency helpers, and custom deployment plan
execution. A Run that supports shell commands advertises its local shell policy
out of band with operator configuration. Platform must not infer shell support
from command text. Empty `shell` means argv-oriented execution.

## Plugin-owned game lifecycle

Game plugins own concrete game policy: install/update commands, app ids,
executable refs, default launch flags, stop-before-update behavior, and startup
argument construction. For SCUM, the plugin action assets own the SteamCMD flow:
stop `SCUMServer.exe` when updating, keep SteamCMD outside the server install
root, run
`steamcmd.exe +force_install_dir <serverRoot> +login anonymous +app_update 3792580 +quit`,
and start `<serverRoot>\\SCUM\\Binaries\\Win64\\SCUMServer.exe -port=<gamePort> -MaxPlayers=<maxPlayers> -log`.

Generated Run distributions carry validated plugin lifecycle assets into the
server-scoped workspace. Run materializes those assets at startup and executes
them through generic action template handling; it does not branch on game ids,
Steam app ids, SCUM executable paths, or launch flags.

## Required local preflight

Before a custom-command action, Run validates the selected protected deployment
body:

- absolute server root and working directory are allowed only where permitted by
  local Run policy;
- selected shell kind and custom-command policy are enabled;
- no raw command, path, secret, socket address, or credential is emitted in a
  result, diagnostic, log batch, or artifact name.

For plugin-owned actions, Run validates scoped action template paths, executable
asset refs, bounded environment variables, and lifecycle action/capability
matches. Deployment create inputs may be exposed to the action as bounded
environment variables such as `SERVER_CREATE_GAMEPORT`; protected command text is
not exposed unless the server explicitly uses custom-command mode.

## Safe progress reports

Run reports bounded progress with `percent`, `phase`, and a safe message. The
allowed phase vocabulary is `queued`, `claimed`, `preflight`, `scan`, `install`,
`configure`, `mapping`, `start`, and `health`. On failure it reports a stable
safe error code and summary, never the supplied path or command text.

Platform treats Run preflight as authoritative. It does not open a direct shell,
SSH connection, raw socket, or host filesystem to compensate for a failed
preflight.