browser/platform/api/routes.md

Platform API Route Catalog

Route declarations and handler comments live in platform/api. Request, response, list, and error contracts live in platform/dto; handlers must call platform/service.Core rather than repositories directly.

Implemented Core Resource Routes

All routes use JSON request and response bodies. Collection routes support GET for lists and POST for create. Detail routes support GET by ID. Unsupported methods return dto.ErrorResponse with 405.

Resource	Collection	Detail	DTO contracts
Users	GET /api/v1/users, POST /api/v1/users	GET /api/v1/users/{id}, PUT /api/v1/users/{id}	UserCreateRequest, UserUpdateRequest, UserResponse, UserListResponse
AI providers	GET /api/v1/ai-providers, POST /api/v1/ai-providers, POST /api/v1/ai/invocations, POST /api/v1/ai/config-suggestions	GET /api/v1/ai-providers/{id}, PUT /api/v1/ai-providers/{id}	AIProviderCreateRequest, AIProviderUpdateRequest, redacted AIProviderResponse, AIProviderListResponse, AIInvocationRequest, AIInvocationResponse, LlmConfigSuggestionRequest, LlmConfigSuggestionResponse
Game plugins	GET /api/v1/game-plugins, POST /api/v1/game-plugins	GET /api/v1/game-plugins/{id}	GamePluginCreateRequest, GamePluginResponse, GamePluginListResponse
Plugin marketplace	GET /api/v1/plugin-marketplace/plugins	GET /api/v1/plugin-marketplace/plugins/{id}, POST /api/v1/plugin-marketplace/plugins/{id}/state	MarketplacePluginResponse, MarketplacePluginListResponse, MarketplacePluginStateRequest
Plugin bridge	POST /api/v1/plugin-bridge/authorize, POST /api/v1/plugin-bridge/execute	n/a	PluginBridgeAuthorizeRequest, PluginBridgeAuthorizeResponse, PluginBridgeExecuteRequest, PluginBridgeExecuteResponse
Server instances	GET /api/v1/server-instances, POST /api/v1/server-instances	GET /api/v1/server-instances/{id}, PUT /api/v1/server-instances/{id}, DELETE /api/v1/server-instances/{id}	ServerInstanceCreateRequest, ServerInstanceUpdateRequest, ServerInstanceResponse, ServerInstanceListResponse
Server runtime distribution	n/a	GET /api/v1/server-instances/{id}/runtime/actions, POST /api/v1/server-instances/{id}/run/generate, POST /api/v1/server-instances/{id}/run/download, POST /api/v1/server-instances/{id}/run/key/reset, POST /api/v1/server-instances/{id}/run/update, GET /api/v1/server-instances/{id}/run/update, POST /api/v1/server-instances/{id}/client-managers/generate, POST /api/v1/server-instances/{id}/client-managers/download, POST /api/v1/server-instances/{id}/client-managers/key/reset, GET /api/v1/server-instances/{id}/dependencies, POST /api/v1/server-instances/{id}/dependencies/check, POST /api/v1/server-instances/{id}/dependencies/install, GET /api/v1/server-instances/{id}/logs/live, POST /api/v1/server-instances/{id}/logs/backfill	ServerRuntimeActionsResponse, RunDistributionGenerateRequest, RunDistributionResponse, RunUpdateRequest, RunUpdateJobResponse/RunUpdateJobListResponse, ClientManagerBuildRequest, ClientManagerDistributionResponse, ClientManagerDownloadRequest, ComponentKeyResetRequest, ComponentKeyResponse, DependencyCatalogResponse, DependencyJobRequest, LogBackfillRequest
Metrics	GET /api/v1/metrics/platform, GET /api/v1/metrics/server-instances	n/a	PlatformResourceUsageResponse, ServerMetricsResponse, ServerMetricsListResponse
Server config	n/a	GET /api/v1/server-instances/{id}/config, POST /api/v1/server-instances/{id}/config/diff, POST /api/v1/server-instances/{id}/config/approve	ServerConfigResponse, ServerConfigDiffPreviewRequest, ServerConfigDiffPreviewResponse, ServerConfigWriteApprovalRequest, ServerConfigWriteDispatchResponse
File operations	POST /api/v1/file-operations/dispatch	n/a	FileOperationDispatchRequest, FileOperationDispatchResponse
Server administrators	GET /api/v1/server-instances/{id}/administrators/candidates, POST /api/v1/server-instances/{id}/administrators	DELETE /api/v1/server-instances/{id}/administrators/{userId}	ServerMemberRequest, ServerMemberResponse, ServerMemberListResponse, ServerInstanceResponse
Run endpoints	GET /api/v1/run/endpoints, POST /api/v1/run/endpoints	GET /api/v1/run/endpoints/{id}	RunEndpointCreateRequest, RunEndpointResponse, RunEndpointListResponse
Jobs	GET /api/v1/jobs, POST /api/v1/jobs	GET /api/v1/jobs/{id}	JobCreateRequest, JobResponse, JobListResponse
Artifacts	GET /api/v1/artifacts, POST /api/v1/artifacts	GET /api/v1/artifacts/{id}, POST /api/v1/artifacts/{id}/download, GET /api/v1/artifacts/{id}/content	ArtifactCreateRequest, ArtifactResponse, ArtifactListResponse, ArtifactDownloadReferenceResponse, ArtifactContentRequest
Log streams	GET /api/v1/log-streams, POST /api/v1/log-streams	GET /api/v1/log-streams/{id}	LogStreamCreateRequest, LogStreamResponse, LogStreamListResponse
Audit events	GET /api/v1/audit-events, POST /api/v1/audit-events	GET /api/v1/audit-events/{id}	AuditEventCreateRequest, AuditEventResponse, AuditEventListResponse

Client Manager lifecycle routes are grouped under the server instance and return only the safe installation projection: GET /api/v1/server-instances/{id}/client-managers, GET .../{profileKey}, and typed POST routes for deploy, control, update, retry, revoke-session, and confirmed uninstall. Component-only POST /api/v1/client-managers/register and /heartbeat use the separate signed component identity/session contract. Run-only input/chunk routes are fenced by the active Run job lease. None of these DTOs return raw component keys, bearer sessions, secret refs/values, host paths, PIDs, sockets, or endpoint addresses.

Implemented Query Filters

• GET /api/v1/users?status=active
• GET /api/v1/ai-providers?kind=openai&status=active
• GET /api/v1/game-plugins?serverType=scum&status=installed
• GET /api/v1/plugin-marketplace/plugins?serverType=scum&status=installed&capability=logs.read&keyword=scum
• GET /api/v1/server-instances?pluginId=server.scum&runEndpointId=run-local&state=draft
• GET /api/v1/server-instances?state=deleted
• GET /api/v1/metrics/server-instances
• GET /api/v1/run/endpoints?status=online
• GET /api/v1/jobs?serverInstanceId=server-1&runEndpointId=run-local&state=queued
• GET /api/v1/artifacts?ownerKind=job&ownerId=job-1&state=uploading
• GET /api/v1/log-streams?serverInstanceId=server-1&streamKey=stdout
• GET /api/v1/audit-events?actorId=user-1&resourceKind=server-instance&resourceId=server-1&result=success

Implemented Authentication And Current User Actions

• POST /api/v1/auth/register: accept RegisterRequest; the first registered account becomes an active platform administrator with an authenticated session, while later registrations create pending low-privilege users and return AuthSessionResponse with status=pending and no session token.
• POST /api/v1/auth/login: accept LoginRequest and authenticate an active user by ID or email. Strict production routes set an HttpOnly SameSite cookie and omit the raw token from JSON; explicit CLI callers may request a bearer response with X-Auth-Token-Response: bearer.
• POST /api/v1/auth/logout: invalidate the active bearer session token and return 204.
• POST /api/v1/auth/rotate: durably revoke the current bearer generation and return a new bounded session token and expiry.
• GET /api/v1/users/current: return CurrentUserResponse for the bearer session.
• PUT /api/v1/users/current/profile: update bounded current-user profile fields using UserProfileBody.
• PUT /api/v1/users/current/theme: persist current-user console theme preferences using UserThemePreferenceRequest.

Bearer sessions are stored as SHA-256 verifiers with issued/expiry/revocation timestamps and rotation generation; raw tokens are never written to FileStore/MySQLStore snapshots. Browser sessions use HttpOnly SameSite cookies, while explicit CLI bearer mode returns the token once. Production router construction requires authentication for sensitive API paths, reserves user/provider/plugin install/Run endpoint/audit/global create operations for platform administrators, and repeats server/job/log/artifact ownership checks in services. After the first account exists, public registration defaults to pending plus server-scoped roles and does not grant platform administrator privileges. A bootstrap administrator is created only when PLATFORM_BOOTSTRAP_ADMIN_PASSWORD is explicitly configured; local debug scripts provide their own development-only value.

Implemented Role-Scoped Server Access

• User-facing server instance list, detail, create, and lifecycle routes require a bearer session.
• Platform administrators can view and manage all server instances.
• Server owners and server administrators can only view and manage server instances they own or administer.
• Server instance responses include bounded ownerUserId and adminUserIds membership metadata.
• GET /api/v1/server-instances/{id}/administrators/candidates: lets the server owner list active non-platform-admin users that can be invited.
• POST /api/v1/server-instances/{id}/administrators: lets the server owner invite an active non-platform-admin user using ServerMemberRequest.
• DELETE /api/v1/server-instances/{id}/administrators/{userId}: lets the server owner remove a server-scoped administrator. The route never deletes the user account.

Server owner membership actions hide and reject platform administrators. Server administrators cannot invite or remove administrators unless they also own the target server.

Implemented Observability And Config Read Actions

• GET /api/v1/metrics/platform: returns bounded platform CPU, memory, disk, source, and timestamp metadata for platform administrators.
• GET /api/v1/metrics/server-instances: returns bounded per-server metrics only for server instances visible to the authenticated user.
• GET /api/v1/server-instances/{id}/config: returns logical server config content, format, key, config version, and update timestamp for an authorized server instance.

Observability and config read responses are read-only. They do not expose host filesystem paths, raw credentials, direct run sockets, storage backend credentials, raw AI provider keys, or run session tokens.

Implemented Config Write And File Dispatch Actions

• POST /api/v1/server-instances/{id}/config/diff: accepts ServerConfigDiffPreviewRequest, validates server access, expected config version, logical config key, bounded proposed content, and returns a platform-computed ServerConfigDiffPreviewResponse without creating a run job.
• POST /api/v1/server-instances/{id}/config/approve: accepts ServerConfigWriteApprovalRequest, revalidates the reviewed diff, rejects stale/no-change/unsafe writes, and queues a scoped config.write job using ServerConfigWriteDispatchResponse.
• POST /api/v1/file-operations/dispatch: accepts FileOperationDispatchRequest, validates server visibility plus optional plugin permissions, rejects unsafe targets, and queues files.read or files.write jobs using logical keys and refs.

Config write and file dispatch responses expose only logical target keys, scoped input/artifact refs, and bounded job metadata. They do not expose host filesystem paths, raw credentials, direct sockets, run session tokens, raw AI provider keys, or inline large file contents.

Implemented AI Provider Management Actions

• POST /api/v1/ai-providers/{id}/status: enable or disable one provider using AIProviderStatusRequest.
• POST /api/v1/ai-providers/{id}/test: invoke the configured provider client with a bounded health request and return only a redacted AIProviderTestResponse.
• GET /api/v1/ai-providers/{id}/models: return configured model names using AIProviderModelsResponse.
• POST /api/v1/ai/invocations: accept AIInvocationRequest, authorize explicit purposes, select an active provider, invoke a mockable provider client, and return AIInvocationResponse with bounded recommendation text, usage metadata, optional reviewable config recommendation, and safe errors.
• POST /api/v1/ai/config-suggestions: compatibility route for console config assistance. It uses the mediated invocation service with purpose=config.suggest and returns LlmConfigSuggestionResponse for the existing review/approval workflow.

AI invocation is platform-mediated. PLATFORM_AI_PROVIDER_MODE=live uses the Platform-owned HTTP client and environment secret resolver; local verification explicitly uses mock. Invocation responses do not expose provider base URLs, API key refs, raw keys, bearer tokens, host paths, run sockets, or storage credentials. Config suggestions persist an expiring diff and never dispatch run-side writes before separate approval. AI Provider management responses also return only baseUrlConfigured and apiKeyConfigured; an empty base URL or secret reference in an update preserves the Platform-owned value instead of round-tripping it through the browser.

AI provider management responses expose apiKeyConfigured only. Create/update requests may carry a controlled secret reference, and a blank update preserves an existing configured secret; the stored reference is not returned to the browser.

Implemented Game Plugin Registry Actions

• POST /api/v1/game-plugins/register-manifest: accept GamePluginManifestRegistrationRequest, validate a game management plugin manifest, and persist installed registry metadata using GamePluginResponse.

Plugin registry responses include identity, description, version, server type/display metadata, manifest and create-form schema references, required run capabilities, declared scoped permissions, aggregate platform permissions, lifecycle action references, plugin pages, tags, AI purposes, validation violations for invalid records, and install status. They do not expose raw host paths, raw credentials, direct run sockets, or raw AI provider keys.

Implemented Plugin Marketplace Actions

• GET /api/v1/plugin-marketplace/plugins: list bounded marketplace plugin summaries projected from installed registry metadata. Optional filters include status, serverType, capability, and keyword.
• GET /api/v1/plugin-marketplace/plugins/{id}: return one marketplace plugin detail using manifest-backed registry metadata.
• POST /api/v1/plugin-marketplace/plugins/{id}/state: accept MarketplacePluginStateRequest with install, enable, or disable and update registry install state only.

Marketplace responses include game management plugin identity, version, display metadata, server type, installed state, capabilities, pages, permissions, tags, AI purposes, and validation violations. They are a platform registry projection, not a commerce catalog, and they do not include billing, pricing, ratings, reviews, cloud host sales, raw credentials, host paths, direct run sockets, package bytes, or raw AI provider keys.

Marketplace state actions are metadata-only in this change. install and enable mark the registered plugin installed; disable marks it disabled. These actions do not download external packages, create run jobs, execute plugin code, write files, or contact external services.

Marketplace catalog state remains separate from production lifecycle installations. Server-bound install/enable/disable/upgrade/rollback/retire operations use the production lifecycle routes below.

Production Operations Governance

• GET /api/v1/production/capacity: return bounded endpoint capacity, durable job pressure, backlog counts, pressure codes, and active-alert count visible to the session.
• POST /api/v1/production/capacity/admission: evaluate server binding, endpoint heartbeat/capability, job limits, queue pressure, and spool pressure without dispatching work.
• GET /api/v1/alerts: list durable alerts with state/source/severity filters.
• POST /api/v1/alerts/{id}/acknowledge, /resolve, and /retry: persist one scoped alert transition or source retry with actor/audit evidence.
• GET /api/v1/plugin-lifecycles: list server-bound plugin lifecycle installations.
• POST /api/v1/plugin-lifecycles/{pluginId}/actions: validate manifest declaration, compatibility, confirmation, idempotency, and capacity before creating one durable Run job.
• GET /api/v1/ai/config-diffs: list reviewable AI config recommendations visible to the session.
• POST /api/v1/ai/config-diffs/{id}/approve: revalidate actor/server/config revision/checksum/expiry and dispatch exactly one bounded config.write job.

These responses expose logical IDs, counts, states, pressure codes, safe diagnostics, and job/audit links only. They never project raw credentials, provider transport configuration, Run sessions/endpoints, host paths, PIDs, sockets, DSNs, or RCON material.

Implemented Plugin Bridge Actions

• POST /api/v1/plugin-bridge/authorize: accepts PluginBridgeAuthorizeRequest and returns whether an installed plugin page may use one declared bridge action with the effective route permissions.
• POST /api/v1/plugin-bridge/execute: accepts PluginBridgeExecuteRequest, repeats backend validation and authorization, and executes only mapped platform-mediated actions. Supported execution currently includes server context reads, lifecycle job dispatch for declared run capabilities, log cursor metadata queries, scoped file dispatch, artifact open references, and platform-mediated AI invocation.

Bridge execution responses are typed envelopes with requestId, plugin/page/server scope, action, status, result refs, and safe error codes. They do not expose bearer tokens, run sockets, host filesystem paths, raw credentials, storage backend credentials, provider base URLs, raw AI provider keys, or unbounded file/log contents.

Artifact bridge execution returns safe metadata and platform content routes only. It does not return artifact bytes through the bridge message and does not expose run endpoints, storage adapter paths, presigned backend URLs, host paths, or credentials.

Implemented Server Lifecycle Actions

• POST /api/v1/server-instances/workflows/create: accepts ServerLifecycleCreateRequest. A legacy runEndpointId creates and dispatches through the existing endpoint. A deploymentTargetId creates a target-bound draft with a reserved dedicated Run identity; no install job is dispatched until that Run registers and deploy is requested.
• POST /api/v1/server-instances/{id}/start: accept ServerLifecycleCommandRequest, validate state/config version/run capability, and queue a process.start job using ServerLifecycleResponse.
• POST /api/v1/server-instances/{id}/stop: accept ServerLifecycleCommandRequest, validate state/config version/run capability, and queue a process.stop job using ServerLifecycleResponse.

Lifecycle workflow responses include accepted status, action, bounded server instance metadata, and bounded job metadata. They do not expose run credentials, host paths, raw credentials, AI provider keys, direct sockets, plugin action file contents, or large result bodies.

Implemented Runtime Distribution And Client Manager Actions

• GET /api/v1/server-instances/{id}/runtime-binding: returns the visible server's selected profile and redacted logical binding readiness. Values are represented only by configured/secret-backed flags.
• PUT /api/v1/server-instances/{id}/runtime-binding: lets the server owner or a platform administrator select a declared profile and patch safe logical refs. Undeclared keys, unsafe paths/sockets/credentials, and changes to an existing active binding are rejected.
• GET /api/v1/server-instances/{id}/runtime/actions: returns the current user-visible runtime action matrix for the server, including run endpoint status, action availability, and safe unavailable reasons.
• POST /api/v1/server-instances/{id}/run/generate: accepts RunDistributionGenerateRequest, creates or reuses the server's current encrypted run key, writes that key into the secret-bearing generated package config, publishes an artifact, and returns RunDistributionResponse with checksum, key generation, artifact ID, and redacted secret ref only.
• POST /api/v1/server-instances/{id}/run/download: opens the latest available run package through ArtifactDownloadReferenceResponse after server-scoped authorization.
• POST /api/v1/server-instances/{id}/run/key/reset: resets the server's single active run key, increments generation, revokes previous run packages, and returns ComponentKeyResponse.
• POST /api/v1/server-instances/{id}/run/update: accepts RunUpdateRequest with an approved artifact ID/checksum and queues a bounded run.self-update job through RunUpdateJobResponse.
• GET /api/v1/server-instances/{id}/run/update: lists safe update phase, target, progress message, artifact checksum, release identity, rollback, and audit summary for the authorized server.
• POST /api/v1/server-instances/{id}/client-managers/generate: accepts ClientManagerBuildRequest, validates the plugin-declared client-manager profile and target platform, injects a distinct current client-manager key into the package config, publishes a downloadable artifact, and returns ClientManagerDistributionResponse.
• POST /api/v1/server-instances/{id}/client-managers/download: accepts ClientManagerDownloadRequest and opens the latest authorized client-manager artifact through ArtifactDownloadReferenceResponse.
• POST /api/v1/server-instances/{id}/client-managers/key/reset: accepts ComponentKeyResetRequest, resets only the named client-manager component key, increments generation, revokes older client-manager packages, and returns ComponentKeyResponse.
• GET /api/v1/server-instances/{id}/dependencies: returns the target-matched plugin/profile dependency catalog, current safe probe status/evidence, typed plan summaries, and deterministic immutable plan digests.
• POST /api/v1/server-instances/{id}/dependencies/check: accepts DependencyJobRequest and queues a dependencies.check run job for a declared logical probe key.
• POST /api/v1/server-instances/{id}/dependencies/install: accepts DependencyJobRequest with an install plan key and the exact catalog planDigest; stale/missing digests are denied before job creation.
• GET /api/v1/server-instances/{id}/logs/live: returns safe live log stream metadata for the selected server using LogStreamListResponse.
• POST /api/v1/server-instances/{id}/logs/backfill: accepts LogBackfillRequest, queues a logs.backfill job with source key, checkpoint ref, limit, and idempotency metadata, and keeps log bodies out of job results.

Runtime distribution and client-manager APIs require the current bearer session, server visibility, plugin-declared permissions, complete runtime bindings where required, and run endpoint capability support for run-side jobs. Responses and audit summaries expose artifact IDs, job IDs, checksums, key generations, fingerprints, status, and redacted secret://runtime-keys/.../current refs only. They do not expose raw run keys, client-manager keys, FTP passwords, database DSNs, RCON passwords, host paths, direct sockets, run endpoint private addresses, build workspace paths, or large inline logs.

POST /api/v1/server-instances/workflows/create requires profileKey and initial bindings. Platform validates completeness and persists the binding before dispatching the install job; the job targetKey identifies the selected declared profile. Existing servers without a binding remain readable, but lifecycle and runtime-dependent actions return a safe configuration-required reason.

Private Run Dependency And Update Routes

The following signed routes are Run-only and never part of browser/plugin DTOs: POST /api/v1/run/jobs/dependency-input, POST /api/v1/run/jobs/protected-request-input, POST /api/v1/run/jobs/update-input, POST /api/v1/run/jobs/update-chunk, and POST /api/v1/run/jobs/update-health. They require the current endpoint/session signature; input/chunk calls additionally require active attempt/lease/cancel fencing. Protected-request input additionally requires the current fencing token and returns approved text exactly once for the server-bound logical transport; the text is not persisted in a job, bridge command, journal, response projection, or audit summary. Update chunks are bounded to 1 MiB and resolve only an available same-server target-matched Run distribution. Health reports are accepted only after the terminal staged job, matching attempt/lease proof, current online endpoint release, and reconciliation-capable session are verified. These routes never return raw artifact paths, browser download tokens, host paths, credentials, secret refs, or session/lease hashes.

Implemented Run Control Actions

• POST /api/v1/run/control/hello: accept RunControlHelloRequest, create or update run endpoint metadata, and return RunControlHelloResponse with a platform-issued session token.
• POST /api/v1/run/control/heartbeat: accept RunControlHeartbeatRequest, require the active session token, update heartbeat metadata, and return RunControlHeartbeatResponse with the next heartbeat hint and optional capability refresh request.

Run control actions carry only lightweight metadata: endpoint ID, display name, version, status, capability fingerprint/list, capacity, session token, and timing hints. They do not carry job bodies, logs, artifact chunks, host paths, raw credentials, or direct sockets. Control is the highest-priority run-facing channel; artifact/file transfer pressure must not delay heartbeat processing or mutate endpoint capacity through heavy payload fields.

Implemented Run Job Actions

• POST /api/v1/run/jobs/claim: accept RunJobClaimRequest, validate the active Run session, sweep expired endpoint work, and durably claim one eligible queued/retrying job with a monotonic per-job attempt, hashed lease credential, ack deadline, and execution lease.
• POST /api/v1/run/jobs/ack: accept RunJobAckRequest, fence endpoint/session generation/attempt/lease, reject late acknowledgements, and move the current attempt into running state.
• POST /api/v1/run/jobs/progress: accept RunJobProgressRequest, reject stale sequences and expired/old attempts, persist bounded progress, and renew the current execution lease.
• POST /api/v1/run/jobs/result: accept RunJobResultRequest and write an idempotent terminal result or durable retry-wait transition with capped exponential backoff.
• POST /api/v1/run/jobs/cancel: accept fenced RunJobCancelPollRequest and return durable pending cancellation intent for the current attempt.
• POST /api/v1/run/jobs/reconcile: accept persisted Run journal evidence (jobId, attempt, leaseToken), rebind only matching active attempts to the current authenticated session generation, persist reconciliation metadata, retry/cancel platform-active missing work, and return confirmed assignments plus discard IDs.
• POST /api/v1/run/jobs/protected-request-input: accept ProtectedRequestExecutionInputRequest, fence endpoint/session/attempt/lease/token, and return one approved, unexpired SQL, RCON, or management-program request only for its exact server-bound logical transport. The route never returns credentials, DSNs, paths, sockets, raw connections, or host shell material.
• POST /api/v1/jobs/{id}/cancel: authorize the server owner/administrator or platform administrator and durably record cancellation intent; queued/retrying work becomes cancelled immediately while active work completes through fenced Run polling/result.

Run job actions carry bounded job metadata only: job ID, run endpoint ID, server instance ID, capability, idempotency key, lease token, attempt/retry limits, deadlines, progress, terminal state, message, error code, result reference, and timing hints. Raw lease tokens exist only on the signed Run job channel; platform persistence stores their hashes. User-facing Job responses expose safe attempt, retry, cancel, terminal, and reconcile projections but never raw/hashed leases, Run sessions, secret refs, host paths, sockets, or credentials. Job ack/progress/result/cancel/reconcile calls remain lightweight and independently valid while log batches or artifact/file chunks are queued, slow, or retrying. Equivalent duplicate terminal results remain idempotent under channel pressure.

Implemented Log Ingest Actions

• POST /api/v1/run/logs/batches: accept LogBatchIngestRequest, validate run session and stream metadata, store contiguous entries, update LogStream.LatestSeq, and return LogBatchIngestResponse with the acknowledged range.
• POST /api/v1/log-streams/query: accept LogStreamCursorRequest and return LogStreamCursorResponse with bounded ordered entries after a cursor.

Log ingest actions carry durable log metadata and bounded entries only: run endpoint ID, session token, stream identity, source, sequence range, compression metadata, checksum, entries, and cursor limits. They do not carry artifact chunks, host paths, raw credentials, direct sockets, or unbounded inline data. Log ingest is durable and independently retried. Artifact/file transfer backlog must not prevent log acknowledgement, duplicate acknowledgement, cursor state updates, or spool cleanup.

Platform storage is configured by PLATFORM_STORAGE_BACKEND. The default file backend writes metadata snapshots to PLATFORM_METADATA_PATH and log bodies to segmented files in PLATFORM_LOG_DIR; memory remains available for tests and ephemeral local runs. Relational stores such as MySQL/Postgres are reserved for metadata, stream cursors, indexes, retention state, and audit trails. High-volume log bodies for hundreds or thousands of servers should use a log-optimized backend behind LogBodyStore, such as ClickHouse, Loki, OpenSearch/Elasticsearch, or object-storage segments.

Implemented Run Artifact Actions

• POST /api/v1/run/artifacts/open: accept ArtifactTransferOpenRequest, validate active run session and scoped artifact owner, create or reuse uploading artifact metadata, and return ArtifactTransferOpenResponse with transfer resume state.
• POST /api/v1/run/artifacts/chunks: accept ArtifactChunkUploadRequest, validate chunk range and checksum, store idempotent chunk state, and return ArtifactChunkUploadResponse with acknowledged chunk indexes.
• POST /api/v1/run/artifacts/status: accept ArtifactTransferStatusRequest and return ArtifactTransferStatusResponse with received chunks and next missing chunk index.
• POST /api/v1/run/artifacts/complete: accept ArtifactTransferCompleteRequest, verify all chunks and final checksum, mark the artifact available, and return ArtifactTransferCompleteResponse.

Run artifact actions carry bounded upload metadata and chunk payloads only: run endpoint ID, session token, transfer ID, artifact ID, owner metadata, chunk indexes, byte ranges, checksums, and JSON chunk payload bytes. They do not carry control heartbeat metadata beyond session identity, job result bodies, logs, host paths, raw credentials, direct sockets, or plugin/browser storage credentials. Artifact/file transfer is lower priority than control, job lifecycle metadata, and durable log ingest. Slow or retrying chunks must not block heartbeat, job ack/result delivery, cancellation/reconcile calls, or log batch acknowledgement; lightweight routes reject heavy transfer payloads rather than storing them.

Implemented Browser Artifact Download Actions

• GET /api/v1/artifacts/{id}: returns authorized artifact metadata for the current bearer session.
• POST /api/v1/artifacts/{id}/download: returns ArtifactDownloadReferenceResponse with filename, content type, size, checksum, expiry, supported chunk size, and a platform-owned downloadUrl.
• GET /api/v1/artifacts/{id}/content: returns a bounded byte range using offset/limit query parameters or a Range: bytes=start-end header. Responses include Content-Length, Accept-Ranges, optional Content-Range, X-Artifact-Checksum, X-Artifact-Content-Checksum, and X-Artifact-Storage headers.

Browser artifact downloads require an available artifact plus user access to the owning job/server context. Platform/plugin-owned artifacts are limited to platform administrators until a future storage policy adds narrower ownership. Current content reads use the private durable artifact body store; external object storage adapters are deferred behind the same service contract. Browser and plugin pages receive only platform routes and integrity metadata, never raw storage backend URLs, host paths, direct run sockets, run tokens, bearer tokens, or storage credentials.

Durable Observability And Scoped Remote Adapters

• POST /api/v1/run/metrics/batches: accepts a signed bounded metric batch for the Run endpoint's server instances and returns an acknowledgement count.
• GET /api/v1/metrics/server-instances/history: returns a bounded owner-scoped metric history by server instance and optional time/limit query.
• GET|POST /api/v1/backups and GET /api/v1/backups/{id}: expose or create safe backup metadata, checksum, artifact reference, retention, and recovery state; body bytes and storage paths remain private.
• GET|POST /api/v1/server-instances/{id}/remote-adapters: lists manifest-declared adapter capabilities or queues an owner-authorized fenced adapter job using logical target keys. Requests never carry arbitrary shell, socket, host, or credential data.

Metric, backup, log, and artifact records use the configured durable metadata/body stores. Control, job, log, artifact, metric, and remote adapter traffic remain independent channels; slow artifact or adapter retries do not share lightweight heartbeat or job result payloads.

Error Contract

API errors use dto.ErrorResponse:

• 400: malformed JSON or validation failure.
• 401: missing or invalid bearer session token.
• 403: valid credentials for an account that is pending, disabled, or otherwise forbidden.
• 404: missing resource or missing dependency reported by the service layer.
• 409: duplicate resource ID.
• 405: unsupported method on an implemented route.
• 500: unexpected platform error.

Deferred Route Groups

These route groups remain documented future work beyond the currently implemented routes:

• Authorization policy routes beyond role-scoped navigation and bearer session identity.
• Run control transport beyond hello and heartbeat, including heartbeat reconciliation policies.
• External metrics collectors, browser tail transport, external log body backends, and AI log analysis windows.
• External artifact storage backends, presigned URLs, and production throttling policies. Run self-update range reads and local artifact upload are implemented, but production mirrors/signing are not.
• Plugin page iframe packaging and remote hosting policies beyond SDK-mediated bridge contracts.
• Live AI provider connectivity tests and remote model discovery.
• Production Run distribution signing/KMS, fleet rollout rings, client-manager lifecycle, plugin lifecycle, production scaling/alerts, and real AI-provider integration.
• Server restart/delete routes beyond the currently implemented lifecycle, metadata update, and archive actions.

Core Service Boundary

• platform/service.Core owns create/list/get workflows and cross-resource invariants.
• platform/repo.Store owns repository access and currently has a durable file-backed implementation for local startup plus an in-memory implementation for tests.
• platform/validator owns local resource validation and dependency compatibility checks.
• Handlers must never expose run credentials, host paths, or raw AI provider keys.