Make generated run lifecycle autonomous
This commit is contained in:
npc0-hue
@@ -18,7 +18,7 @@ Named control DTOs:
|
||||
- `RunCapabilityReport`
|
||||
- `RunCapacityReport`
|
||||
|
||||
Control payloads must remain small and must not include logs, artifact chunks, host paths, raw credentials, direct sockets, or long task results. Hello creates or updates run endpoint metadata and issues an in-memory platform session token. A server-scoped generated Run must use the endpoint identity reserved for its server; Platform rejects a valid component key presented for another endpoint. Heartbeat requires that active session token and may request capability refresh when the fingerprint changes.
|
||||
Control payloads must remain small and must not include logs, artifact chunks, host paths, raw credentials, direct sockets, or long task results. Hello creates or updates run endpoint metadata and issues an in-memory platform session token. A server-scoped generated Run must use the endpoint identity reserved for its server; Platform rejects a valid component key presented for another endpoint. Registration is binding/authentication only for generated Run bootstrap and must not enqueue lifecycle or status jobs merely because Run appeared. Heartbeat requires that active session token and may request capability refresh when the fingerprint changes.
|
||||
|
||||
Capacity reports include bounded `maxJobs`, `runningJobs`, `queuedJobs`, `logBacklogBatches`, `artifactBacklogChunks`, and enumerated pressure codes. They report queue and spool counts only, never log bodies, artifact chunks, machine paths, PIDs, sockets, credentials, or transport endpoints.
|
||||
|
||||
@@ -51,12 +51,18 @@ Named job DTOs:
|
||||
|
||||
Jobs must carry bounded metadata such as `jobId`, `runEndpointId`, `serverInstanceId`, `capability`, `idempotencyKey`, lease token, attempt, progress, terminal state, message, error code, and result reference. Job payloads must not carry logs, artifact chunks, host paths, raw credentials, direct sockets, or large inline result bodies.
|
||||
|
||||
Plugin lifecycle assignments may add only a validated plugin identifier, enumerated lifecycle operation, target version, and logical workspace scope. Install, enable, disable, upgrade, rollback, retire, and dependency-check remain Platform-authorized jobs; assignments cannot carry arbitrary shell, provider configuration, raw credentials, host paths, PIDs, sockets, DSNs, or RCON secrets.
|
||||
Plugin lifecycle assignments may add only a validated plugin identifier, enumerated lifecycle operation, target version, and logical workspace scope. Explicit operator-requested install, enable, disable, upgrade, rollback, retire, dependency-check, and bounded lifecycle commands remain Platform-authorized jobs. Generated Run package startup is not dependent on registration-time job assignment; it is driven by the autonomous lifecycle plan embedded by the platform builder. Assignments cannot carry arbitrary shell, provider configuration, raw credentials, host paths, PIDs, sockets, DSNs, or RCON secrets.
|
||||
|
||||
Approved `config.write` and bounded `files.read`/`files.write` assignments carry logical keys, scoped refs, and compare-and-swap revision/checksum inputs. Run executes them inside its scoped workspace with atomic writes and returns bounded logical result metadata; resolved machine paths remain Run-local.
|
||||
|
||||
Job ack, progress, cancellation polling, reconciliation, and terminal result calls are lightweight lifecycle metadata. They must remain valid while artifact chunks or log retries are pending, and duplicate equivalent terminal results remain idempotent under channel pressure.
|
||||
|
||||
## Generated Run autonomous lifecycle plan
|
||||
|
||||
Platform-owned Run distribution builds embed an autonomous lifecycle plan for the server-scoped generated Run. The plan carries the server/plugin identity, selected runtime profile, target OS/architecture/release, plugin lifecycle action refs, dependency probes/install plans, process log sources, optional DLL extension plans, runtime bindings, and redacted deployment inputs. The builder includes the same JSON as internal build input and as `.platform/autonomous-lifecycle-plan.json` in the generated workspace seed. Run reads this package-local plan on startup and performs plugin-declared init, dependency verification/install, install-if-needed, readiness/status, and start behavior locally before reporting observed state back to Platform.
|
||||
|
||||
The plan is build input for the generated package, not a machine-side job-channel payload. Generated Run registration must not be treated as a trigger to enqueue `process.start`, `process.install`, or `process.status` work; Platform state converges from Run heartbeats, logs, lifecycle reports, supervised process facts, and terminal job/report messages. Platform and Run must not add game-specific hardcoding to interpret the plan.
|
||||
|
||||
## Log Ingest
|
||||
|
||||
Implemented HTTP JSON routes:
|
||||
|
||||
@@ -15,12 +15,12 @@ The plugin marketplace API is a platform-facing projection over this installed r
|
||||
|
||||
## Server Instance
|
||||
|
||||
A server instance is created from one installed game management plugin and bound to one run endpoint.
|
||||
A server instance is created from one installed game management plugin and is later bound to the generated Run endpoint when that Run registers. Platform stores the instance and projections; Run owns observed lifecycle execution on the machine.
|
||||
|
||||
### States
|
||||
|
||||
- `draft`: instance record exists but the first bootstrap job has not completed.
|
||||
- `installing`: the first plugin-owned bootstrap job is active.
|
||||
- `draft`: instance record exists and is awaiting Run-owned lifecycle bootstrap or reports.
|
||||
- `installing`: Run reports that plugin-owned install/bootstrap work is active.
|
||||
- `ready`: install/bootstrap succeeded without starting a supervised process, and the server can start.
|
||||
- `running`: server process is running.
|
||||
- `stopped`: server process is stopped.
|
||||
@@ -36,9 +36,9 @@ A server instance is created from one installed game management plugin and bound
|
||||
|
||||
## Lifecycle Actions
|
||||
|
||||
- `create`: validate plugin, create instance record, dispatch the plugin-owned bootstrap job.
|
||||
- `start`: dispatch process start job through the bound run endpoint.
|
||||
- `stop`: dispatch process stop job through the bound run endpoint.
|
||||
- `create`: validate plugin and create the instance record without requiring a run endpoint, deployment target, or runtime profile.
|
||||
- `start`: record/authorize operator intent and route bounded control to the bound Run when applicable; generated Run startup is driven by its package-local autonomous lifecycle plan.
|
||||
- `stop`: record/authorize operator intent and route bounded control to the bound Run when applicable.
|
||||
- `restart`: dispatch stop/start or plugin-defined restart job.
|
||||
- `update`: dispatch server update job and record version/result.
|
||||
- `delete`: stop server when needed, preserve or remove artifacts according to policy, mark deleted.
|
||||
@@ -48,7 +48,7 @@ A server instance is created from one installed game management plugin and bound
|
||||
- `GET /api/v1/plugin-marketplace/plugins` lists plugin marketplace summaries from registry metadata with status, server type, capability, and keyword filters.
|
||||
- `GET /api/v1/plugin-marketplace/plugins/{id}` returns one registry-backed marketplace detail.
|
||||
- `POST /api/v1/plugin-marketplace/plugins/{id}/state` applies metadata-only `install`, `enable`, or `disable` state changes.
|
||||
- `POST /api/v1/server-instances/workflows/create` validates an installed plugin, a compatible run endpoint, a non-empty idempotency key, and required lifecycle action references. It creates the instance in `installing` state and queues either `process.install` or, for guided deployments whose selected lifecycle profile supports supervised start, `process.start` so the plugin start script can install-if-missing and stream process logs.
|
||||
- `POST /api/v1/server-instances/workflows/create` validates an installed plugin, server name, idempotency key, and plugin-declared create inputs when provided. It creates the instance without requiring a deployment target, run endpoint, or runtime profile. Generated Run packages carry the autonomous lifecycle plan that Run consumes on startup; registration confirms binding/auth and does not enqueue bootstrap lifecycle jobs.
|
||||
- `POST /api/v1/server-instances/{id}/start` validates the instance is `ready` or `stopped`, checks the expected config version, verifies the plugin start action and run endpoint `process.start` capability, and queues a start job.
|
||||
- `POST /api/v1/server-instances/{id}/stop` validates the instance is `running`, checks the expected config version, verifies the plugin stop action and run endpoint `process.stop` capability, and queues a stop job.
|
||||
- `GET /api/v1/server-instances/{id}/config` returns logical read-only config content for an authorized server instance with config version, format, key, source, and update timestamp metadata.
|
||||
@@ -65,9 +65,9 @@ Config write approval and file dispatch are platform-mediated. They carry logica
|
||||
|
||||
Marketplace state actions update only registry install state. They do not download packages, dispatch run jobs, execute plugin bridge code, write server files, expose package bytes, or contact external services. Package acquisition and runtime execution remain deferred to explicit future changes.
|
||||
|
||||
## Lifecycle Job Projection
|
||||
## Lifecycle Projection
|
||||
|
||||
Terminal run job results update the associated server instance when the job capability is a lifecycle capability:
|
||||
Platform-visible lifecycle state is a projection from Run-reported facts. Terminal run job results update the associated server instance when the job capability is a lifecycle capability for explicit Platform-authorized operations:
|
||||
|
||||
- `process.install` + `succeeded` marks the instance `ready`.
|
||||
- `process.start` + `succeeded` marks the instance `running`.
|
||||
|
||||
Reference in New Issue
Block a user