Complete platform management workflows
This commit is contained in:
npc0-hue
@@ -48,16 +48,21 @@ This file defines the first platform resource contracts. Concrete Go domain stru
|
||||
- `createFormSchemaRef`: create form schema reference.
|
||||
- `requiredRunCapabilities`: run capabilities required by this plugin.
|
||||
- `declaredPermissions`: scoped manifest permission keys used by plugin bridge and marketplace views.
|
||||
- `permissions`: aggregate platform ability declarations for AI, logs, files, jobs, and artifacts.
|
||||
- `permissions`: aggregate platform ability declarations for AI, logs, files, jobs, artifacts, and remote access.
|
||||
- `lifecycleActions`: manifest action contract references for install/start/stop and optional restart/status.
|
||||
- `pages`: plugin-local page metadata with scoped permission requirements.
|
||||
- `tags`: bounded catalog tags.
|
||||
- `aiPurposes`: platform-mediated AI purposes such as config suggestions or log diagnosis.
|
||||
- `remoteAccess`: plugin-declared remote access methods (`ftp`, `rsync`, `run`), run capabilities, database engines, RCON, and log transfer flags.
|
||||
- `validationViolations`: safe validation findings for invalid plugin records.
|
||||
- `status`: `installed`, `disabled`, `invalid`, or `updating`.
|
||||
|
||||
Manifest registration uses `GamePluginManifestRegistrationRequest` at `POST /api/v1/game-plugins/register-manifest`. Platform validation repeats plugin workspace safety checks and rejects raw host paths, direct run sockets, raw credentials, and raw AI/provider keys before metadata reaches the registry.
|
||||
|
||||
Remote access jobs are enabled only when both the selected run endpoint reports the capability and the server instance's installed plugin declares it. Plugin pages must use `remote.access.request` with `server.remote.access`; platform rejects undeclared database, RCON, log transfer, or remote file capabilities before creating jobs.
|
||||
|
||||
Runtime profile and distribution permissions are declared by plugins, then gated again by platform routes and services. `server.run.distribution` enables run package generation/download/reset/update operations, `server.dependencies.manage` enables dependency check/install jobs, and `server.client-manager.manage` enables plugin-declared companion client-manager generation/download/reset operations. Plugin metadata stores only declarations and safe refs; raw run/client-manager keys and transport credentials are stored through platform secret resources, never in plugin records.
|
||||
|
||||
## ServerInstance
|
||||
|
||||
- `id`: server instance ID.
|
||||
@@ -80,6 +85,46 @@ Manifest registration uses `GamePluginManifestRegistrationRequest` at `POST /api
|
||||
- `capacity`: current queue and resource summary.
|
||||
- `lastHeartbeatAt`: last control heartbeat time.
|
||||
|
||||
Run control hello can include server/component identity from a generated package config. When `serverInstanceId`, `pluginId`, `componentKind`, `componentKey`, and `keyGeneration` are present, platform authenticates the provided key against the current encrypted component key before issuing a session token. Stale generations after reset are rejected without returning raw key material.
|
||||
|
||||
## RuntimeBinding
|
||||
|
||||
- `id`: runtime binding ID.
|
||||
- `serverInstanceId`: server instance using the binding.
|
||||
- `pluginId`: installed plugin that declared the logical runtime profile.
|
||||
- `profileKey`: declared lifecycle/runtime profile key.
|
||||
- `mode`: runtime mode such as `local-process`, `hosted-ftp-rcon`, `ftp-only`, or `custom-client`.
|
||||
- `bindings`: logical binding keys to operator-provided settings.
|
||||
- `missingKeys`: logical keys that must be completed before dependent actions are available.
|
||||
- `status`: `complete`, `incomplete`, or `invalid`.
|
||||
|
||||
Bindings are used for action gating and run-side profile resolution. API responses and logs must use logical keys and safe reasons only; they must not expose raw host paths, direct sockets, FTP/RCON passwords, SQL DSNs, or component auth keys.
|
||||
|
||||
## Runtime Component Keys And Distributions
|
||||
|
||||
- `EncryptedComponentKey`: stores exactly one active encrypted key per server/component plus hash, fingerprint, redacted secret ref, generation, status, and reset time.
|
||||
- `RunDistribution`: records a generated run package for one server, target OS/architecture, package format, artifact ID, checksum, key generation, secret ref, and status.
|
||||
- `ClientManagerDistribution`: records a generated plugin-declared client-manager package with profile key, repository/source revision metadata, build job ID, artifact ID, checksum, key generation, secret ref, and status.
|
||||
- `ClientManagerBuildJob`: records source checkout/build status, target platform, artifact ID, checksum, redacted build log ref, key generation, and status.
|
||||
- `RunUpdateJob`: records platform-created run self-update orchestration with server, run endpoint, artifact ID, checksum, job ID, idempotency key, and status.
|
||||
|
||||
Run and client-manager keys are isolated singleton credentials. Reset replaces the encrypted database value, increments generation, marks older distributions revoked, and requires regenerating and redeploying that component. API DTOs may expose key generation, fingerprint, status, artifact ID, checksum, job ID, and `secret://runtime-keys/.../current` refs, but never the raw key.
|
||||
|
||||
## DependencyStatus
|
||||
|
||||
- `id`: dependency status ID.
|
||||
- `serverInstanceId`: server instance checked by run.
|
||||
- `pluginId`: plugin that declared the probe.
|
||||
- `probeKey`: logical dependency probe key.
|
||||
- `targetOs`, `targetArch`: target platform metadata.
|
||||
- `state`: dependency state such as present, missing, failed, or unknown.
|
||||
- `required`: whether the probe is required for the runtime profile.
|
||||
- `installPlanKey`: optional typed install plan key.
|
||||
- `message`: bounded safe status.
|
||||
- `checkedAt`, `updatedAt`: observation times.
|
||||
|
||||
Dependency checks and installs are queued as run jobs with logical `dependencies/...` or `dependencies/install/...` target keys. Install jobs must use typed plugin-declared plans and must not carry arbitrary shell snippets.
|
||||
|
||||
## Job
|
||||
|
||||
- `id`: job ID.
|
||||
@@ -96,6 +141,10 @@ Lifecycle workflow jobs use fixed capabilities:
|
||||
- `process.install`: dispatched by server create workflow and projects successful terminal results to `ready`.
|
||||
- `process.start`: dispatched by server start workflow and projects successful terminal results to `running`.
|
||||
- `process.stop`: dispatched by server stop workflow and projects successful terminal results to `stopped`.
|
||||
- `run.self-update`: dispatched by runtime distribution APIs with an approved artifact ref and checksum.
|
||||
- `dependencies.check`: dispatched by dependency check APIs for a declared probe key.
|
||||
- `dependencies.install`: dispatched by dependency install APIs for a declared typed install plan.
|
||||
- `logs.backfill`: dispatched by historical log APIs for a declared source key and checkpoint ref.
|
||||
|
||||
Failed or cancelled lifecycle jobs project the server instance to `failed`. Active start/stop jobs are visible through job metadata; this change does not add separate `starting` or `stopping` server states.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user