feat: 完整游戏运维功能
This commit is contained in:
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-07-17
|
||||
@@ -0,0 +1,84 @@
|
||||
## Context
|
||||
|
||||
Task 05 made lifecycle/config/file jobs real and Task 06 made logs, artifacts, metrics, backups, and remote adapters durable. Distribution APIs already create `dependencies.check`, `dependencies.install`, and `run.self-update` jobs, but Run currently returns immediate synthetic success. Platform also accepts any available same-owner-visible artifact for an update and has no Run-only artifact read route, immutable dependency-plan approval, terminal dependency projection, or update activation journal.
|
||||
|
||||
The implementation spans the main repository and the independent `run/` repository. Platform remains authoritative for user ownership/admin scope, installed plugin/version, server/runtime binding, selected endpoint, Run session/signature, attempt/lease/cancel fencing, artifact ownership, immutable plan digest, and audit. Run owns machine-local resolution, typed adapter execution, staging, replacement, health confirmation, and rollback. Plugins declare safe logical plans; platform_web receives only safe projections.
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:**
|
||||
|
||||
- Execute declared dependency probes and install plans through fixed, testable adapters with bounded time, output, retries, and cancellation.
|
||||
- Make the exact platform/architecture-specific plan reviewable and bind installation approval to its digest.
|
||||
- Persist dependency status and update phases across Platform and Run restarts.
|
||||
- Download only an approved same-server Run distribution through a signed, active-attempt-only, resumable contract.
|
||||
- Verify archive and binary bounds/checksums, preserve the current package configuration, stage durably, activate only after the terminal result is accepted, confirm startup health, and roll back on failure.
|
||||
- Keep heartbeat, job ack/result/cancel polling, logs, and artifact upload independent from slow dependency/update work.
|
||||
|
||||
**Non-Goals:**
|
||||
|
||||
- Arbitrary shell/script execution, user-supplied command vectors, generic root package management, unverified HTTP downloads, or undeclared host/credential access.
|
||||
- Production code-signing/KMS, release rings, fleet rollout, centralized binary mirrors, dependency solving, Run service-manager installation, client-manager lifecycle, plugin lifecycle, production scaling/alerts, or real AI-provider integration.
|
||||
|
||||
## Decisions
|
||||
|
||||
### Decision 1: Platform snapshots declared inputs and approves an immutable digest
|
||||
|
||||
Platform derives a safe dependency catalog from the installed plugin version, selected runtime profile, endpoint OS/architecture, and declared probes/plans. A canonical digest covers the declaration and non-secret logical binding generation. An install request must include the digest returned by the catalog. Dispatch re-resolves the declaration and rejects changed plugin versions, plan steps, target platform, bindings, endpoint, or digest before creating the job.
|
||||
|
||||
Alternative considered: accept only a plan key and resolve it at execution time. Rejected because an operator could approve one plan and execute a later plugin revision.
|
||||
|
||||
### Decision 2: Private execution inputs use active fenced Run routes
|
||||
|
||||
Dependency declarations/resolved target values and Run update manifests are not placed in browser-visible job DTOs. Run retrieves them through signed `/api/v1/run/jobs/dependency-input`, `/api/v1/run/jobs/update-input`, and `/api/v1/run/jobs/update-chunk` routes carrying endpoint, session, job, attempt, and lease. Platform uses the existing fenced-job check and requires an active matching capability. Update chunks are bounded and range-addressed; no browser download token or raw storage path is returned.
|
||||
|
||||
Alternative considered: embed all data in `Job.ExecutionInput.Content`. Rejected because it weakens type separation and increases the chance of private binding or package data entering general job projections.
|
||||
|
||||
### Decision 3: Dependency work uses a closed adapter registry
|
||||
|
||||
Run maps probe kinds and install step types to fixed implementations. Package steps map a whitelisted manager to fixed argument builders and validate package/version tokens. Verified downloads require HTTPS, a declared SHA-256 checksum, a size limit, and a scoped destination. SteamCMD uses a fixed executable/argument shape. Manual steps return a safe blocked result and never claim installation. No adapter invokes a shell, evaluates manifest text, accepts environment overrides, or returns command output/paths.
|
||||
|
||||
The executor has injected command/download/filesystem interfaces for deterministic tests; production implementations use `exec.CommandContext`, bounded HTTPS, owner-only workspaces, and atomic files.
|
||||
|
||||
Alternative considered: translate declarations into shell scripts. Rejected because shell parsing defeats the declared capability boundary.
|
||||
|
||||
### Decision 4: Dependency state is projected from terminal evidence
|
||||
|
||||
Run returns a typed execution result containing only declaration key, present/missing/installed/failed classification, bounded version evidence, completed step count, and plan digest. Platform verifies that evidence against the job snapshot before updating `DependencyStatus`. Attempts and local journals are idempotent; retry/cancel/stale results remain governed by the existing scheduler. Audit summaries never include resolved paths, commands, package-manager output, or credentials.
|
||||
|
||||
### Decision 5: Self-update is a durable two-process transaction
|
||||
|
||||
Run streams the approved distribution archive into an owner-only transaction directory, persists offset/hash metadata, verifies the final artifact checksum, safely extracts exactly one expected Run binary, and records a staged manifest. Archive traversal, links, devices, duplicate executables, excess entries, oversized bodies, target mismatch, and bundled configuration replacement are rejected.
|
||||
|
||||
After Platform accepts the successful staged job result and the Run journal has persisted the acknowledgement, the worker launches the staged binary in helper mode and exits. The helper waits for the old PID, backs up the current executable, copies the staged binary through an atomic temporary target, starts the new executable with helper-only environment removed, and waits for a startup-health marker. The new worker writes that marker and sends a signed update-health report only after registration and job reconciliation succeed; Platform keeps the safe phase at `restart-requested/activating` until that report matches the terminal update job, endpoint, attempt, lease proof, target release, and current session. Failure restores the backup and restarts the previous binary. The package's existing `config.json` remains untouched.
|
||||
|
||||
Alternative considered: replace the executable before reporting the job. Rejected because Platform could retain a running lease with no terminal result. Alternative considered: report success after merely staging. Rejected because the update record would misrepresent activation; the safe projection distinguishes `staged/restart-requested`, `activating`, `succeeded`, `rolled-back`, and `failed` phases.
|
||||
|
||||
### Decision 6: Recovery is driven by journals, not process memory
|
||||
|
||||
Dependency executions store completed step indexes and immutable digests under the scoped workspace. Update transactions store artifact offset, expected checksum, staged binary checksum, current/backup logical locations, phase, attempt, and timestamps. Startup recovery removes invalid partial data, resumes eligible downloads, confirms a healthy activated transaction, or rolls back an interrupted activation. Attempt/lease values are used for fencing but never exposed in safe status or logs.
|
||||
|
||||
### Decision 7: Endpoint target identity and channel priority remain explicit
|
||||
|
||||
Run endpoint records persist OS/architecture from hello so Platform can reject cross-target distributions and plans. Downloading dependencies or update chunks occurs inside the claimed job goroutine; heartbeat and durable log/artifact upload loops remain separate. Progress/cancel polling uses bounded contexts. Tests block download/adapters while asserting heartbeat, ack/result, and log upload deadlines.
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
- [Package managers vary across distributions and may require privilege] → Validate the endpoint OS, use manager-specific fixed arguments, surface a safe permission failure, and never auto-escalate through sudo/shell.
|
||||
- [A process can crash between staged result and helper activation] → Persist the post-ack activation request and recover it at startup; Platform distinguishes staging from confirmed version/health.
|
||||
- [Windows executable replacement differs from Unix rename behavior] → Helper copies from the staged executable after the parent exits and uses backup/temporary targets instead of renaming a running binary.
|
||||
- [A newly started binary can launch but fail registration] → New Run writes health only after successful registration/reconciliation; helper times out and restores the previous executable.
|
||||
- [Old records lack endpoint OS/architecture or plan digests] → Existing endpoints re-register before real actions become available; legacy queued placeholder jobs are not retroactively executed.
|
||||
- [Large update archives can consume disk/network] → Enforce artifact/archive/binary limits, bounded chunks, resumable offsets, owner-only roots, and cleanup after terminal retention.
|
||||
|
||||
## Migration Plan
|
||||
|
||||
1. Add backward-compatible endpoint target fields, dependency/update records, DTOs, protocols, repositories, and private routes.
|
||||
2. Require endpoint re-registration to advertise a supported OS/architecture before enabling dependency install or self-update.
|
||||
3. Publish safe dependency catalog/status and update phase projections; existing generic job views remain compatible.
|
||||
4. Enable real Run capabilities only when the typed executors and journals initialize successfully.
|
||||
5. On rollback, stop advertising the real capabilities and leave private journals/artifacts for a compatible binary to recover; do not delete or reinterpret prior Platform records.
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Production signing policy and rollout rings remain a future change; this task enforces artifact ownership, target match, content checksum, and optional signature metadata without claiming a production PKI.
|
||||
@@ -0,0 +1,32 @@
|
||||
## Why
|
||||
|
||||
Platform can currently queue dependency and Run update jobs, but Run returns synthetic success without executing a declared install step or downloading, verifying, staging, activating, and recovering an update. Operators therefore see completion for work that did not happen, and the existing job/artifact security boundaries are not yet sufficient for real machine mutation.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Resolve plugin-declared dependency probes and install plans through Platform ownership, installed-plugin, runtime-profile, binding, endpoint, platform, session, attempt, and lease checks.
|
||||
- Expose a safe, reviewable dependency catalog and require approval of the exact immutable plan digest before dispatching an install.
|
||||
- Execute only typed package, verified-download, and SteamCMD steps through fixed adapters; reject arbitrary shell, scripts, unsafe package arguments, unapproved downloads, undeclared targets, stale plans, and unsupported operating systems.
|
||||
- Persist dependency execution status/evidence and project terminal job results into bounded, redacted Platform records and UI status.
|
||||
- Add a Run-only, fenced, resumable artifact download contract for approved same-server Run distributions.
|
||||
- Download, checksum-verify, safely extract, stage, and durably journal Run updates; activate them through a post-result helper, verify startup health, and roll back on activation failure.
|
||||
- Persist Run update phases and audit outcomes without exposing host paths, Run/session/lease tokens, secret refs, credentials, PIDs, sockets, or private plan bindings.
|
||||
- Preserve control/job/log/artifact channel isolation so dependency downloads and update transfer/activation do not delay heartbeat, job acknowledgement/result, cancellation polling, or log upload.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
|
||||
- `durable-dependency-execution`: reviewable declared dependency plans, fenced Run input, typed probes/install adapters, persistence, recovery, cancellation, and safe projections.
|
||||
- `transactional-run-self-update`: approved artifact download, resumable verification, durable staging, post-result activation, startup health confirmation, rollback, and audit semantics.
|
||||
|
||||
### Modified Capabilities
|
||||
|
||||
- `run-distribution-and-client-managers`: dependency and self-update jobs now perform real bounded machine work instead of success-only hooks.
|
||||
- `artifact-transfer-channel`: authenticated Run jobs can read approved distribution artifacts in bounded resumable chunks without using browser download sessions.
|
||||
|
||||
## Impact
|
||||
|
||||
- Affects `plugins/` dependency declaration validation/SDK examples, `platform/` domain/DTO/model/repository/service/protocol/validator/API layers, projection-only `platform_web/` dependency/update status, and the independent `run/` protocol/runtime/config/shared layers.
|
||||
- Adds no arbitrary shell capability and no raw host path, credential, socket, token, lease, session hash, or secret projection to plugins or platform_web.
|
||||
- Does not implement client-manager lifecycle, dependency installation outside declared adapters, Run distribution signing infrastructure/KMS, production rollout rings/fleet orchestration, plugin lifecycle, production scaling/alerts, or real AI-provider integration.
|
||||
+16
@@ -0,0 +1,16 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Active Run update jobs can read approved artifact ranges
|
||||
The artifact channel SHALL provide a signed, bounded, resumable read contract exclusively for an active fenced `run.self-update` attempt whose artifact is an available same-server target-matched Run distribution.
|
||||
|
||||
#### Scenario: Run reads the next update range
|
||||
- **WHEN** Run presents the selected endpoint/session/job/attempt/lease and a valid offset and length
|
||||
- **THEN** Platform MUST return only that bounded artifact range plus artifact ID, offset, total size, checksum, and completion metadata
|
||||
|
||||
#### Scenario: Run requests unrelated artifact data
|
||||
- **WHEN** the job is inactive, the artifact/distribution/server/endpoint/target differs, or the range exceeds bounds
|
||||
- **THEN** Platform MUST reject the request without returning bytes, paths, credentials, browser download sessions, secret refs, or cross-owner metadata
|
||||
|
||||
#### Scenario: Update transfer is slow
|
||||
- **WHEN** an update range read or network response is blocked
|
||||
- **THEN** control, job ack/result/cancel, log ingest, and independent artifact upload routes MUST continue without waiting on the read
|
||||
+68
@@ -0,0 +1,68 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Dependency plans are declared and reviewable
|
||||
Platform SHALL derive a safe dependency catalog from the installed plugin version, selected runtime profile, complete binding, and Run target, and SHALL require approval of the exact plan digest before installation.
|
||||
|
||||
#### Scenario: Operator reviews an install plan
|
||||
- **WHEN** an authorized owner or platform administrator queries dependency actions for a server
|
||||
- **THEN** Platform MUST return declared probe keys, plan titles, target OS/architecture, typed step summaries, current safe status, and a deterministic plan digest without host paths, commands, credentials, secret refs, sockets, tokens, leases, sessions, hashes used for fencing, or PIDs
|
||||
|
||||
#### Scenario: Approved plan changes before dispatch
|
||||
- **WHEN** the plugin version, runtime profile, target, binding generation, plan steps, or digest no longer matches the reviewed plan
|
||||
- **THEN** Platform MUST reject installation and record a safe denied audit event before creating a job
|
||||
|
||||
#### Scenario: Caller crosses server ownership
|
||||
- **WHEN** a non-owner without server-admin or platform-admin scope requests a catalog, check, or install
|
||||
- **THEN** Platform MUST return the existing unauthorized/forbidden semantics and MUST NOT reveal whether private bindings or plans exist
|
||||
|
||||
### Requirement: Dependency execution input is fenced and private
|
||||
Run SHALL receive dependency declarations and resolved target values only through a signed Platform route scoped to the active endpoint, session, job, attempt, and lease.
|
||||
|
||||
#### Scenario: Active Run loads dependency input
|
||||
- **WHEN** the selected Run requests input for its active dependency attempt
|
||||
- **THEN** Platform MUST verify endpoint ownership, session/signature, job capability/state, attempt/lease, server/plugin/profile/target, immutable digest, and cancellation state before returning the bounded typed input
|
||||
|
||||
#### Scenario: Stale or cross-endpoint Run requests input
|
||||
- **WHEN** the endpoint, session, attempt, lease, server, plugin version, profile, or capability does not match the active job
|
||||
- **THEN** Platform MUST reject the request without returning declarations, bindings, host targets, or plan data
|
||||
|
||||
### Requirement: Dependency probes and installs use closed typed adapters
|
||||
Run SHALL execute only supported declared probe kinds and install step types through fixed adapters and SHALL never evaluate arbitrary shell, script text, environment overrides, or caller-supplied command vectors.
|
||||
|
||||
#### Scenario: Declared probe executes
|
||||
- **WHEN** a supported command-version, Java, Docker, package, service, Steam app, or file probe is requested for the current Run platform
|
||||
- **THEN** Run MUST resolve only the approved target, enforce timeout/output bounds, and return a safe present/missing/version classification
|
||||
|
||||
#### Scenario: Typed package plan executes
|
||||
- **WHEN** an approved package step names a supported manager, safe package token, optional safe version, and matching platform
|
||||
- **THEN** Run MUST use the fixed manager adapter, respect cancellation and timeout, persist step completion idempotently, and never invoke a shell or unapproved privilege escalation
|
||||
|
||||
#### Scenario: Verified download executes
|
||||
- **WHEN** an approved verified-download step uses HTTPS, an allowed host, a SHA-256 checksum, a bounded size, and a scoped logical destination
|
||||
- **THEN** Run MUST stream to an owner-only temporary file, verify checksum before atomic publication, and remove invalid partial data
|
||||
|
||||
#### Scenario: Unsafe or unsupported step is requested
|
||||
- **WHEN** a declaration contains shell syntax, an unsafe package/version token, HTTP or credential-bearing URL, missing checksum, undeclared target, unsupported platform/manager/type, symlink escape, or manual-only step
|
||||
- **THEN** validation or Run MUST reject it without machine mutation and return a bounded safe failure
|
||||
|
||||
### Requirement: Dependency execution is durable and auditable
|
||||
Platform and Run SHALL make dependency execution restart-safe, idempotent, cancellable, retry-bounded, and auditable.
|
||||
|
||||
#### Scenario: Run restarts during a multi-step install
|
||||
- **WHEN** Run recovers an active attempt with a matching immutable digest
|
||||
- **THEN** it MUST resume after the last durably completed idempotent step and MUST NOT repeat a completed step or accept a stale attempt
|
||||
|
||||
#### Scenario: Cancellation arrives during a blocked adapter
|
||||
- **WHEN** Platform records cancellation for the active dependency job
|
||||
- **THEN** Run MUST cancel the adapter context, stop before the next step, preserve recoverable evidence, and report a fenced cancelled result
|
||||
|
||||
#### Scenario: Terminal dependency evidence is accepted
|
||||
- **WHEN** Platform accepts a current terminal probe or install result
|
||||
- **THEN** it MUST update the durable dependency status and audit actor, server, plugin, probe/plan, attempt outcome, and safe summary without private execution details
|
||||
|
||||
### Requirement: Dependency work preserves channel deadlines
|
||||
Slow package managers and downloads SHALL NOT block Run control heartbeat, job acknowledgement/result, cancellation polling, log upload, or artifact channel progress.
|
||||
|
||||
#### Scenario: Dependency adapter is blocked
|
||||
- **WHEN** a dependency command or download remains blocked beyond a heartbeat interval
|
||||
- **THEN** heartbeat, log acknowledgement, cancellation polling, and unrelated job-channel requests MUST continue through independent bounded operations
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Dependency checks and installs are typed
|
||||
Run SHALL check dependencies through plugin-declared probes and SHALL install missing dependencies only through approved, typed, reviewable, immutable plans executed by fixed adapters.
|
||||
|
||||
#### Scenario: Dependency check reports missing runtime
|
||||
- **WHEN** Run evaluates a declared probe for a required runtime, service, package, toolchain, Steam app, Java runtime, Docker runtime, or file and finds it missing
|
||||
- **THEN** Platform MUST persist and show the safe dependency status and a reviewable platform-matched install plan when the installed plugin declares one
|
||||
|
||||
#### Scenario: Dependency install is approved
|
||||
- **WHEN** an authorized operator approves the current immutable plan digest
|
||||
- **THEN** Platform MUST queue a fenced job and Run MUST execute only the typed package, verified-download, or SteamCMD steps, persist resumable evidence, and reject arbitrary shell or stale plan input
|
||||
|
||||
#### Scenario: Dependency result is synthetic
|
||||
- **WHEN** Run has not executed and verified the declared probe or install steps
|
||||
- **THEN** it MUST NOT report the dependency present, installed, or successfully completed
|
||||
|
||||
### Requirement: Online run endpoints self-update through platform jobs
|
||||
The platform SHALL update online Run endpoints through a bounded job that reads an approved same-server target-matched distribution, and Run SHALL durably download, verify, stage, activate, health-check, and roll back the update without receiving raw shell commands.
|
||||
|
||||
#### Scenario: Online Run accepts update
|
||||
- **WHEN** the assigned endpoint is online, advertises real self-update capability, and the artifact matches its server and OS/architecture
|
||||
- **THEN** Platform MUST queue a fenced update job and Run MUST download by bounded ranges, verify checksum, stage safely, report the result, and activate only after Platform accepts that result
|
||||
|
||||
#### Scenario: Update verification fails
|
||||
- **WHEN** Run cannot verify or stage the artifact
|
||||
- **THEN** Run MUST keep the current executable and configuration, report a bounded failure, preserve heartbeat/status, and never launch the update helper
|
||||
|
||||
#### Scenario: Updated Run fails health confirmation
|
||||
- **WHEN** the replacement cannot start or authenticate/reconcile with the same identity before timeout
|
||||
- **THEN** Run MUST restore and restart the previous executable and Platform MUST project a rolled-back/failed outcome rather than success
|
||||
+74
@@ -0,0 +1,74 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Run updates use approved target-matched distributions
|
||||
Platform SHALL dispatch self-update only for an available Run distribution owned by the same server, built for the registered endpoint OS/architecture, and matching the recorded artifact checksum.
|
||||
|
||||
#### Scenario: Authorized update is queued
|
||||
- **WHEN** an authorized owner or platform administrator selects an available same-server distribution for the online endpoint
|
||||
- **THEN** Platform MUST bind the update record and job to the distribution, artifact, checksum, target, endpoint, and idempotency key and record a queued audit event
|
||||
|
||||
#### Scenario: Artifact is cross-owner or cross-target
|
||||
- **WHEN** the artifact belongs to another server/job, is not an available Run distribution, has a different checksum, or targets another OS/architecture
|
||||
- **THEN** Platform MUST reject the update before job creation without revealing artifact contents or private ownership metadata
|
||||
|
||||
### Requirement: Update artifact reads are resumable and fenced
|
||||
Run SHALL download update artifacts through a signed active-attempt-only chunk contract with bounded offsets, lengths, total size, and checksum metadata.
|
||||
|
||||
#### Scenario: Download resumes after interruption
|
||||
- **WHEN** Run restarts or a chunk request fails after a durable offset was recorded
|
||||
- **THEN** Run MUST request the next bounded range, verify every returned offset/length and the final checksum, and MUST NOT redownload already verified bytes
|
||||
|
||||
#### Scenario: Stale attempt requests a chunk
|
||||
- **WHEN** a cancelled, expired, wrong-endpoint, wrong-session, wrong-lease, or superseded attempt requests update metadata or bytes
|
||||
- **THEN** Platform MUST reject it and MUST NOT return artifact bytes, storage paths, browser tokens, secret refs, or fencing hashes
|
||||
|
||||
### Requirement: Run stages updates safely
|
||||
Run SHALL safely validate and stage exactly the expected Run executable from the approved distribution while preserving the installed package configuration.
|
||||
|
||||
#### Scenario: Valid package is staged
|
||||
- **WHEN** all artifact bytes and the archive checksum are verified
|
||||
- **THEN** Run MUST reject archive traversal/links/devices/duplicates, enforce entry and binary size limits, extract the target-matched executable into an owner-only transaction directory, verify its checksum, fsync the journal, and leave the current executable/configuration unchanged
|
||||
|
||||
#### Scenario: Package verification fails
|
||||
- **WHEN** checksum, target, format, entry bounds, executable identity, or extraction validation fails
|
||||
- **THEN** Run MUST keep the current executable, remove or quarantine invalid partial data, report a bounded failure, and remain able to heartbeat and accept cancellation
|
||||
|
||||
### Requirement: Activation occurs only after fenced result acceptance
|
||||
Run SHALL activate a staged update only after Platform accepts the terminal staged result for the current attempt and the local result acknowledgement is durable.
|
||||
|
||||
#### Scenario: Staging result is rejected
|
||||
- **WHEN** Platform rejects the result because the session, attempt, lease, cancellation state, or terminal fingerprint is stale
|
||||
- **THEN** Run MUST NOT launch the update helper or replace the executable
|
||||
|
||||
#### Scenario: Staging result is accepted
|
||||
- **WHEN** Platform accepts the current staged result
|
||||
- **THEN** Run MUST persist the post-ack activation request, launch the staged helper, stop the old worker without dropping the accepted result, and project the update as restart-requested/activating until health is confirmed
|
||||
|
||||
### Requirement: Activation is health-checked and rollback-safe
|
||||
The update helper SHALL back up, replace, launch, confirm, and finalize an update transaction, and SHALL restore the previous executable if activation fails.
|
||||
|
||||
#### Scenario: New Run becomes healthy
|
||||
- **WHEN** the new executable starts, authenticates, registers the same endpoint/server identity, reconciles jobs, and writes the transaction health marker before timeout
|
||||
- **THEN** it MUST submit a signed current-session health report fenced to the terminal update job/attempt/lease, the helper MUST mark the transaction succeeded, retain bounded rollback evidence, and Platform MUST confirm the endpoint's new release/checksum in the safe update projection only after accepting that report
|
||||
|
||||
#### Scenario: Replacement or health confirmation fails
|
||||
- **WHEN** copy/rename/start fails, the new process exits, identity differs, or health is not confirmed before timeout
|
||||
- **THEN** the helper MUST atomically restore the backup where possible, restart the previous executable, mark rolled-back/failed recovery state, and never claim update success
|
||||
|
||||
#### Scenario: Run restarts with an interrupted transaction
|
||||
- **WHEN** startup finds a durable downloading, staged, activating, or rollback transaction
|
||||
- **THEN** it MUST resume the safe phase, clean invalid state, or roll back deterministically without applying a different artifact or stale attempt
|
||||
|
||||
### Requirement: Update status and audit projections are safe
|
||||
Platform_web and plugins SHALL receive only bounded update identity, artifact checksum, target, phase, progress, timestamps, rollback outcome, endpoint version/release, and safe audit summaries.
|
||||
|
||||
#### Scenario: Update status is queried
|
||||
- **WHEN** an authorized user opens server runtime status
|
||||
- **THEN** the response MUST omit host/executable/staging/backup paths, raw artifact bodies, credentials, Run tokens, session/lease values or hashes, secret refs, helper PIDs, sockets, and private package configuration
|
||||
|
||||
### Requirement: Update transfer and activation preserve channel deadlines
|
||||
Slow update downloads and helper preparation SHALL NOT block control heartbeat, job acknowledgement/result, cancellation polling, logs, or unrelated artifact uploads.
|
||||
|
||||
#### Scenario: Update download is slow
|
||||
- **WHEN** update chunk transfer is delayed or the artifact is large
|
||||
- **THEN** heartbeat, active job lease renewal, cancellation polling, log upload, and unrelated result reporting MUST continue through separate bounded loops
|
||||
@@ -0,0 +1,45 @@
|
||||
## 1. Contracts And Persistence
|
||||
|
||||
- [x] 1.1 Add Platform domain, DTO, model, repository, protocol, validator, and safe projection contracts for dependency catalogs/snapshots/results and Run update manifests/chunks/phases.
|
||||
- [x] 1.2 Persist Run endpoint OS/architecture, dependency execution evidence, plan digests, and update transaction/rollback status through memory, file, and MySQL snapshot repositories.
|
||||
- [x] 1.3 Add independent Run protocol/runtime/config/shared types for private dependency input, resumable update reads, typed evidence, and durable update journals without importing main-repository source.
|
||||
|
||||
## 2. Platform Authorization And Orchestration
|
||||
|
||||
- [x] 2.1 Implement authorized dependency catalog/status queries with deterministic safe plan digests and exact installed-plugin/profile/target/binding projections.
|
||||
- [x] 2.2 Require current plan-digest approval for installs and dispatch only declared platform-matched probes/plans to the selected online endpoint.
|
||||
- [x] 2.3 Implement signed, session/attempt/lease/cancel-fenced Run dependency-input, update-input, and bounded update-chunk routes with same-server distribution and target checks.
|
||||
- [x] 2.4 Project accepted terminal dependency/update evidence into durable status/phase/audit records while rejecting stale, cross-owner, cross-endpoint, cross-target, or conflicting results.
|
||||
|
||||
## 3. Real Dependency Execution
|
||||
|
||||
- [x] 3.1 Implement Run probe adapters for supported declared command/version, Java/Docker/package/service/Steam/file checks with bounded redacted evidence.
|
||||
- [x] 3.2 Implement fixed package-manager, verified HTTPS download, and SteamCMD install adapters with no shell, safe tokens/hosts/checksums/paths, timeouts, and cancellation.
|
||||
- [x] 3.3 Add durable dependency journals, step idempotency, retry/restart recovery, digest fencing, safe failures for manual/unsupported steps, and tests.
|
||||
|
||||
## 4. Transactional Run Self-Update
|
||||
|
||||
- [x] 4.1 Implement bounded resumable update download with durable offsets, per-range/final checksum verification, cancellation, and restart recovery.
|
||||
- [x] 4.2 Implement safe zip/tar extraction of the expected target binary, archive/binary limits, owner-only staging, configuration preservation, and durable transaction manifests.
|
||||
- [x] 4.3 Implement post-result-ack helper activation, parent exit coordination, backup/atomic replacement, helper-environment cleanup, startup identity/health confirmation, rollback, and interrupted-transaction recovery.
|
||||
- [x] 4.4 Add Run self-update tests for wrong artifact/target/checksum, partial resume, stale fencing, result rejection, activation success, health timeout rollback, and journal restart.
|
||||
|
||||
## 5. Plugins And Platform Web
|
||||
|
||||
- [x] 5.1 Tighten plugin manifest/SDK dependency declarations and example plans for fixed adapters, approved download hosts/checksums, step bounds, and unsafe shell/URL/token rejection.
|
||||
- [x] 5.2 Add platform_web safe dependency catalog/status and Run update phase/checksum/rollback/audit views using existing black-mecha/magical-girl components and existing 401/403 behavior.
|
||||
|
||||
## 6. Regression And Verification
|
||||
|
||||
- [x] 6.1 Add Platform/Run regression coverage for owner/endpoint/signature/session/attempt/lease/target rejection, persistence/recovery/idempotency/cancel, redaction, and blocked transfer/adapter channel isolation.
|
||||
- [x] 6.2 Update protocol/API/domain documentation with implemented limits and explicitly excluded client-manager lifecycle, production signing/fleet rollout/scaling/alerts/plugin lifecycle, and real AI-provider integration.
|
||||
- [x] 6.3 Run plugin manifest/SDK tests, Platform tests, platform_web tests/typecheck/build, independent Run tests, strict OpenSpec validation, structure, shell/compose checks, and both repository diff checks; record only passing evidence.
|
||||
|
||||
## Verification Evidence
|
||||
|
||||
- `plugins`: `npm run validate:manifest`, `npm run typecheck`, and `npm test` passed (18 tests).
|
||||
- `platform`: `go test ./...` passed across api/config/domain/dto/model/repo/service/validator.
|
||||
- `platform_web`: `npm test` passed (104 tests), `npm run typecheck`, and `npm run build` passed.
|
||||
- independent `run`: `go test ./...` passed across api/config/protocol/runtime/spool.
|
||||
- `openspec validate implement-dependency-installation-and-run-self-update --strict` passed.
|
||||
- `scripts/check-structure.sh`, `bash -n scripts/*.sh`, `docker compose config`, `git diff --check`, and `git -C run diff --check` passed.
|
||||
Reference in New Issue
Block a user