feat: 完整游戏运维功能
This commit is contained in:
npc0-hue
+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
|
||||
Reference in New Issue
Block a user