## ADDED Requirements

### Requirement: Generated Run startup is autonomous
Generated Run packages SHALL carry a bounded autonomous lifecycle plan that lets Run bootstrap the server from plugin-declared lifecycle assets without waiting for Platform to enqueue `process.start`, `process.install`, or `process.status` work after registration.

#### Scenario: Generated Run registers after startup
- **WHEN** a server-scoped generated Run registers with valid component authentication
- **THEN** Platform accepts the registration and does not enqueue lifecycle or status jobs solely because the registration occurred

#### Scenario: Generated Run package starts locally
- **WHEN** the generated Run executable starts on its host
- **THEN** Run can read the embedded autonomous lifecycle plan and execute plugin-declared init, dependency verification/install, install-if-needed, readiness/status, and start behavior locally

#### Scenario: Generated Run reports autonomous bootstrap result
- **WHEN** Run completes an autonomous lifecycle bootstrap action from the embedded plan
- **THEN** Run reports the terminal lifecycle result to Platform without requiring a Platform job claim, acknowledgement, lease token, or job result

### Requirement: Platform follows Run-reported lifecycle facts
Platform SHALL treat persisted server lifecycle state as a projection of Run-reported lifecycle facts, heartbeats, logs, and terminal process reports rather than as authoritative observed process truth.

#### Scenario: Run reports no managed process
- **WHEN** Run reports that the server process is stopped, not started, or exited
- **THEN** Platform updates the visible server projection from that Run-owned fact instead of preserving stale `running` state

#### Scenario: Run reports a live managed process
- **WHEN** Run reports that the managed process is running
- **THEN** Platform projects the server as running based on the Run report

#### Scenario: Run reports through the signed lifecycle report channel
- **WHEN** a registered Run submits a terminal lifecycle report for its bound server instance
- **THEN** Platform validates the active Run session and server binding, records audit evidence, and updates the visible server projection from the reported process facts

### Requirement: Plugins declare game-specific lifecycle behavior
Plugins SHALL declare lifecycle action refs, dependency probes, install plans, runtime profiles, log sources, and deployment templates needed by Run, and Platform SHALL NOT hardcode game-specific install, update, status, or startup behavior.

#### Scenario: SCUM lifecycle bootstrap
- **WHEN** a SCUM generated Run package is built
- **THEN** Platform packages the plugin-declared lifecycle refs and deployment inputs without hardcoding SCUM executable names, Steam app IDs, ports, or install directories in Platform code

### Requirement: Run registration is binding and authentication only
Generated Run registration SHALL authenticate the component, bind or confirm the dedicated endpoint identity, upsert endpoint metadata, and issue a control session, but SHALL NOT be used as a Platform-side lifecycle bootstrap dispatcher.

#### Scenario: Guided draft generated Run registers
- **WHEN** a guided draft server's generated Run registers
- **THEN** the server remains awaiting Run-owned lifecycle reports and Platform does not create a bootstrap start job

#### Scenario: Stale running generated Run registers
- **WHEN** a generated Run registers for a server whose persisted state is `running`
- **THEN** Platform does not create a registration-time `process.status` reconciliation job and instead waits for Run-owned status/lifecycle reporting