admin343/browser
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Make generated run lifecycle autonomous

Browse Source
This commit is contained in:
npc0-hue
2026-08-06 18:57:42 +08:00
parent acec5e4367
commit 4e78957a60
22 changed files with 583 additions and 236 deletions
Download Patch File Download Diff File Expand all files Collapse all files
openspec/changes/make-run-runtime-state-authoritative/specs/run-runtime-state-authority/spec.md
+6 -6
View File
@@ -1,15 +1,15 @@
## ADDED Requirements
### Requirement: Generated Run registration reconciles observed process state
When a generated Run registers for a bound server instance, the platform SHALL enqueue a scoped `process.status` reconciliation job when the stored server state says the game process is running or failed and no active lifecycle job already covers that server. The reconciliation job SHALL use the plugin-declared status action and the same scoped workspace metadata as normal lifecycle jobs.
### 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 is checked after manual Run startup
#### 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 enqueues one `process.status` job for that server and Run endpoint
- **THEN** the platform does not enqueue a `process.status` job solely from registration
#### Scenario: Existing active lifecycle job avoids duplicate status checks
#### 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 does not enqueue an additional status reconciliation 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`.