Files

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.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