Make generated run lifecycle autonomous
This commit is contained in:
+16
@@ -0,0 +1,16 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Generated Run build input includes autonomous lifecycle plan
|
||||
The platform-owned distribution builder SHALL receive a generated Run autonomous lifecycle plan for `run` component packages and SHALL keep that plan inside platform-side build input rather than requiring a machine-side Run endpoint to claim lifecycle bootstrap work.
|
||||
|
||||
#### Scenario: Platform builder assembles Run package input
|
||||
- **WHEN** an owner requests Run generation for a server instance
|
||||
- **THEN** the platform builder input and generated workspace seed include plugin lifecycle action refs, selected profile key, dependency probes, install plans, process log sources, deployment revision, and redacted deployment execution inputs for that server
|
||||
|
||||
#### Scenario: Client-manager build input
|
||||
- **WHEN** an owner requests client-manager generation
|
||||
- **THEN** the build input does not include a server Run autonomous lifecycle plan
|
||||
|
||||
#### Scenario: Build input remains platform-owned
|
||||
- **WHEN** a machine-side Run endpoint attempts to claim or read a platform-owned distribution build
|
||||
- **THEN** Platform denies that access and does not expose the plaintext component auth key or autonomous lifecycle plan through the machine job channel
|
||||
+41
@@ -0,0 +1,41 @@
|
||||
## 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
|
||||
Reference in New Issue
Block a user