24 lines
1.5 KiB
Markdown
24 lines
1.5 KiB
Markdown
## Why
|
|
|
|
Manual generated Run execution exposed a stale lifecycle design: platform persisted `running` after the previous supervised process was gone, so a newly-started Run worker could register successfully but had no way to correct the visible server state before an operator issued another lifecycle command. The machine-side Run must be the source of observed runtime truth; platform state should converge from Run-reported process facts instead of blocking actions based only on stale stored state.
|
|
|
|
## What Changes
|
|
|
|
- Remove registration-time runtime-state reconciliation jobs for generated Run; Run reports the actual managed process state from its own lifecycle authority instead of waiting for Platform probes.
|
|
- Project `process.status` results into server lifecycle state using Run-reported `processState` values such as `running`, `stopped`, `not-started`, and `exited`.
|
|
- Prevent stale platform `running` from surviving when the active Run reports no managed process for that server.
|
|
- Keep Platform authorization/audit for explicit operator requests while making observed runtime/process state and generated Run bootstrap Run-authoritative.
|
|
|
|
## Capabilities
|
|
|
|
### New Capabilities
|
|
- `run-runtime-state-authority`: Defines how platform reconciles server lifecycle state from generated Run process observations.
|
|
|
|
### Modified Capabilities
|
|
|
|
## Impact
|
|
|
|
- Affects `platform/service` lifecycle projection, Run registration handling, and lifecycle tests.
|
|
- No new product areas, billing, provider workflow, or plugin-specific hardcoding.
|
|
- No new external dependencies.
|