## ADDED Requirements

### Requirement: Generated Run registration does not dispatch observed-state probes
When a generated Run registers for a bound server instance, the platform SHALL NOT enqueue a scoped `process.status` reconciliation job merely because the stored server state says the game process is running or failed. Registration SHALL confirm identity, binding, and session state only; observed process state SHALL come from Run-owned lifecycle/status reports.

#### Scenario: Stale running state waits for Run report after manual Run startup
- **WHEN** a generated Run registers for a server whose stored state is `running`
- **THEN** the platform does not enqueue a `process.status` job solely from registration

#### Scenario: Existing active lifecycle job remains untouched
- **WHEN** a generated Run registers while the same server already has an active lifecycle job
- **THEN** the platform leaves the existing job unchanged and does not add a registration-time status probe

### Requirement: Run process status is authoritative for observed lifecycle state
The platform SHALL project terminal `process.status` results from Run into the server instance state. A Run-reported `processState` of `running` SHALL mark the server `running`; `stopped` or `not-started` SHALL mark it `stopped`; `exited` SHALL mark it `failed` unless the exit classification is an operator stop such as `requested-stop`, `forced-stop`, or `already-stopped`, in which case it SHALL mark the server `stopped`.

#### Scenario: Run reports no managed process
- **WHEN** a status reconciliation job succeeds with `processState=not-started`
- **THEN** the platform marks the server `stopped` instead of preserving stale `running`

#### Scenario: Run reports an unexpected exit
- **WHEN** a status reconciliation job succeeds with `processState=exited` and `exitClassification=unexpected-exit`
- **THEN** the platform marks the server `failed`

#### Scenario: Run reports a live process
- **WHEN** a status reconciliation job succeeds with `processState=running`
- **THEN** the platform marks the server `running`

### Requirement: Lifecycle command state changes use Run execution facts
For lifecycle start and stop jobs, the platform SHALL use Run execution facts when projecting server state. A successful `process.start` result SHALL mark `running` only when Run reports `processState=running`; a successful `process.stop` result SHALL mark `stopped` when Run reports `stopped`, `not-started`, or an operator-stopped `exited` state.

#### Scenario: Start succeeds without a running process fact
- **WHEN** a `process.start` job succeeds but Run reports `processState=stopped`
- **THEN** the platform does not mark the server `running`

#### Scenario: Stop succeeds from an already-stopped process
- **WHEN** a `process.stop` job succeeds with `processState=not-started`
- **THEN** the platform marks the server `stopped`