## Context

The platform already supports registry-backed game plugins, marketplace projection, server lifecycle workflows, run-side lifecycle jobs, and browser-visible server controls. The missing piece is a concrete SCUM plugin package that follows those contracts instead of relying on the generic `game.example` development fixture.

## Goals / Non-Goals

**Goals:**

- Provide a SCUM plugin directory with manifest, create form schema, lifecycle action templates, and platform-hosted page declarations.
- Keep lifecycle requests platform-mediated and safe: plugin metadata must expose only logical action refs, capabilities, page keys, and permissions.
- Prove one SCUM plugin can be registered, discovered in the marketplace, and used to create at least two SCUM server instances.
- Preserve the existing platform_web management console style and reuse the generic server/plugin surfaces.

**Non-Goals:**

- No real commercial SCUM binary download or production hosting orchestration.
- No direct browser/plugin connection to run endpoints.
- No cloud-provider, host-sales, billing, or unrelated marketplace behavior.

## Decisions

### Decision 1: SCUM plugin is a first-party local example plugin

The plugin lives under `plugins/examples/scum-server-plugin` and follows the same manifest and validation schema as other game management plugins.

### Decision 2: Lifecycle templates use safe local fixture commands

The action templates use bounded executable names and arguments accepted by the run lifecycle executor. They prove install/start/stop wiring without exposing real host paths or requiring a SCUM dedicated server binary.

### Decision 3: Platform and frontend reuse existing plugin contracts

No new platform_web route or visual system is introduced. The SCUM plugin declares overview/config/log pages, and the existing marketplace/server management/plugin bridge surfaces render those declarations with the current theme-aware console components.

## Risks / Mitigations

- [Risk] The SCUM proof could be mistaken for production SCUM hosting. Mitigation: describe it as a local fixture plugin and keep action templates bounded.
- [Risk] Adding another plugin could drift from manifest safety rules. Mitigation: default validation now checks both example and SCUM manifests.
- [Risk] Browser-facing surfaces could expose unsafe details. Mitigation: local debug smoke rejects forbidden fragments from registration, marketplace, server, job, log, and artifact responses.