Run stdout/stderr records provide bounded semantic player events. See UE4SS_CAPABILITY.md for the runtime boundary; this Companion never infers events from arbitrary log lines.

The production command is plugin-owned and runs as the SCUM Client Manager. It registers the deployed component, keeps heartbeats alive, dispatches declared companion commands, reads SCUM SQLite data, and stores trajectory samples directly into the shared platform MySQL database from the companion process.

Trajectory samples keep the raw SCUM world coordinates (world_x, world_y, world_z). The companion does not project or convert coordinates before storage; any map pixel calculation is display-only in the plugin page.

The production process reads two environment variables supplied by the supervisor:

SCUM_COMPONENT_PROOF: component registration proof material from the protected package.
SCUM_DB_FILE: the local SCUM SQLite database file to sample.
PLATFORM_MYSQL_DSN: the shared platform MySQL connection string used by plugin storage. It is read from the process environment, not written into config.yaml.

Package

Build the production command from this directory:

go build -o scum_client.exe ./cmd/scum-companion

Place the generated config.yaml beside the executable. The command intentionally has no --config flag and reads only that sidecar filename from its working directory. config.yaml.example documents the generated shape; deployed identity and generation values must come from the fenced Client Manager lifecycle input.

The Platform base URL must be a trusted HTTPS origin. The client uses host system certificate roots, requires TLS 1.2 or newer, and does not follow redirects. Local acceptance therefore needs a hostname and certificate already trusted by the machine account running the package. The certificate SAN must cover the configured hostname or IP; a certificate for localhost does not cover 127.0.0.1 unless that IP is also present. Do not use HTTP fallback, certificate-skip flags, custom root overrides, or other verification bypasses for local testing.

The supervisor supplies the component proof through the environment variable named by proof.materialEnv. Bind it from the protected component package at process start. Do not place the proof in config.yaml, command arguments, command-line environment assignments, shell history, documentation, or logs.

If trajectory.enabled is true but SCUM_DB_FILE or PLATFORM_MYSQL_DSN is missing, the companion stays registered and reports degraded health instead of silently exiting. This keeps diagnostics reachable while operators fix the machine environment.

Smoke Fixture

cmd/scum-companion-smoke remains a non-production one-shot fixture. It proves the Platform Client Manager and Game Client Bridge integration without adding SCUM behavior to Run. The smoke command registers the deployed component, sends one heartbeat, claims at most one command, processes only companion.diagnostics, and uploads one typed companion.health snapshot.

Use it only with a dedicated non-production server instance whose bridge queue contains no shared or production work. The claim API cannot filter by command type, so this smoke command must never target a shared or production queue.

Before starting it, confirm that the isolated queue is otherwise empty and queue exactly one companion.diagnostics command through the Platform SCUM operations page. Use the bounded payload includeWindowState=false and maxEntries=1. Do not pass an operator session or API token to the companion process.

Build the smoke command from this directory:

go build -o scum-companion-smoke ./cmd/scum-companion-smoke

The process environment must also set SCUM_COMPANION_SMOKE_SCOPE to isolated-non-production. This value is a non-secret safety acknowledgement; configure it in the supervisor rather than placing component proof material on a command line.

Run the executable from the package working directory:

./scum-companion-smoke

The JSON output contains only claimed/completed/unsupported counts, command IDs, and the accepted snapshot ID. It never prints the component proof, component session, command payloads, host paths, or transport details. The run proceeds only when exactly one live companion.diagnostics command with a valid bounded payload is claimed. Zero, multiple, expired, malformed, or unsupported commands stop the smoke immediately; they are not acknowledged, completed, or executed, and no snapshot is uploaded. Platform lease fencing remains authoritative.

Each invocation uploads health to a fresh bounded smoke-<random> stream with sequence 1. This avoids reusing production stream state and remains safe across process restarts without storing a host path or local sequence file.