42 lines
3.0 KiB
Markdown
42 lines
3.0 KiB
Markdown
## 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
|
|
|
|
### 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
|
|
|
|
### 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
|