2.8 KiB
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.statusjob 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
stoppedinstead of preserving stalerunning
Scenario: Run reports an unexpected exit
- WHEN a status reconciliation job succeeds with
processState=exitedandexitClassification=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.startjob succeeds but Run reportsprocessState=stopped - THEN the platform does not mark the server
running
Scenario: Stop succeeds from an already-stopped process
- WHEN a
process.stopjob succeeds withprocessState=not-started - THEN the platform marks the server
stopped