feat: 完整游戏运维功能

platform/domain/resources.md

@@ -5,7 +5,7 @@ This file defines the first platform resource contracts. Concrete Go domain stru
 ## Implemented Boundaries
 
 - Domain constants centralize allowed status, state, provider kind, relay mode, artifact owner, storage backend, and audit result values.
-- DTO responses expose `apiKeyRef` for AI providers but never raw key material.
+- DTO responses expose AI-provider secret presence only (`apiKeyConfigured`), never the stored reference or raw key material.
 - Model structs include JSON/database tags and explicit `TableName()` mappings for future persistence work.
 - `platform/repo.NewFileStore` provides durable local metadata snapshots for platform startup, while `platform/repo.NewMemoryStore` provides deterministic in-memory repository behavior for unit tests and disposable local runs.
 - Log stream metadata records the selected body backend. The current durable local body backend uses `local-segments`; future production adapters should target log-optimized stores such as `clickhouse`, `loki`, `opensearch`, or `elasticsearch` rather than row-per-line relational tables.
@@ -27,7 +27,8 @@ This file defines the first platform resource contracts. Concrete Go domain stru
 - `name`: display name.
 - `kind`: `openai-compatible`, `openai`, `claude`, `gemini`, `ollama`, or `custom`.
 - `baseUrl`: provider or relay base URL.
-- `apiKeyRef`: secret reference, never the raw key.
+- `apiKeyRef`: platform-owned secret reference accepted on writes and never returned by response DTOs.
+- `apiKeyConfigured`: response-only presence flag.
 - `models`: allowed model IDs.
 - `defaultModel`: optional default model.
 - `relayMode`: `direct`, `relay`, or `local`.
@@ -87,18 +88,30 @@ Runtime profile and distribution permissions are declared by plugins, then gated
 
 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.
 
+Run sessions persist only a token hash, generation, status, expiry, capability fingerprint, signed-request policy, and bounded replay nonce history. Component-authenticated Run sessions require HMAC-SHA256 HTTP envelopes over method, path, timestamp, nonce, and request-body hash; timestamps outside five minutes and repeated nonces are rejected.
+
+## AuthSessionRecord
+
+- `tokenHash`: SHA-256 verifier; raw bearer tokens are never persisted.
+- `userId`: owning user.
+- `status`: `active` or `revoked`.
+- `generation`: monotonically increasing user session generation.
+- `issuedAt`, `expiresAt`, `lastSeenAt`, `revokedAt`: durable lifecycle timestamps.
+
 ## RuntimeBinding
 
 - `id`: runtime binding ID.
 - `serverInstanceId`: server instance using the binding.
-- `pluginId`: installed plugin that declared the logical runtime profile.
+- `pluginId` and `pluginVersion`: installed plugin contract 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`.
+- `status`: `complete` or `incomplete`.
 
-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.
+Installed `GamePlugin` records persist the validated manifest `runtimeProfiles` contract, including discovery, lifecycle, dependency/install, log, transport, and client-manager declarations. One server binding selects one declared lifecycle profile. Platform derives allowed and required logical keys; clients cannot assert `missingKeys` or `status`.
+
+Bindings are used for action gating and future run-side profile resolution. File and MySQL metadata snapshots include them so a platform restart does not make a configured server appear complete or lose its selected profile. API responses expose only logical key names, configured/secret-backed flags, missing keys, and safe reasons. They never expose stored binding values, raw host paths, direct sockets, FTP/RCON passwords, SQL DSNs, component auth keys, or internal secret locations.
 
 ## Runtime Component Keys And Distributions
 
@@ -106,7 +119,7 @@ Bindings are used for action gating and run-side profile resolution. API respons
 - `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.
+- `RunUpdateJob`: records platform-created Run self-update orchestration with server, endpoint, artifact ID/checksum, target and previous release, job/idempotency identity, `queued/downloading/staged/restart-requested/activating/succeeded/rolled-back/failed` phase, bounded message, rollback flag, and timestamps. Platform only projects success after a signed current-session post-reconciliation health report; terminal staging alone remains `restart-requested`.
 
 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.
 
@@ -121,6 +134,8 @@ Run and client-manager keys are isolated singleton credentials. Reset replaces t
 - `required`: whether the probe is required for the runtime profile.
 - `installPlanKey`: optional typed install plan key.
 - `message`: bounded safe status.
+- `planDigest`: deterministic SHA-256 digest of the declared target-specific probe/plan and logical binding generation; install approval must match it exactly.
+- `evidence`, `completedSteps`, `jobId`: bounded terminal execution projection; no command output, path, credential, or private binding is stored in the projection.
 - `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.