admin343/browser
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add SCUM file management workbench

Browse Source
This commit is contained in:
npc0-hue
2026-08-04 11:33:34 +08:00
parent 2921edb401
commit f028a343d7
36 changed files with 1384 additions and 158 deletions
Download Patch File Download Diff File Expand all files Collapse all files
platform/domain/resources.md
+9 -6
View File
@@ -114,10 +114,13 @@ Installed `GamePlugin` records persist the validated manifest `runtimeProfiles`
Plugin lifecycle assets are registered as manifest-declared files plus a
content-bearing registration payload. Platform packages those assets into
generated Run workspaces so plugin action refs such as `actions/install.json`
and script refs such as `bin/scum-start.cmd` are available before the first
install/start job. Game-specific install/update/start policy, including SCUM
SteamCMD app IDs and launch flags, stays in the plugin asset bundle rather than
in platform services or Run executors.
and helper refs such as `bin/scum-install-update.cmd` are available before the
first bootstrap job. Guided deployments whose selected lifecycle profile
supports `process.start` may bootstrap through the plugin-owned start action so
the script can install-if-missing and then launch the supervised process whose
stdout/stderr feed the live terminal. Game-specific install/update/start policy,
including SCUM SteamCMD app IDs and launch flags, stays in the plugin asset
bundle rather than in platform services or Run executors.
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.
@@ -161,8 +164,8 @@ Dependency checks and installs are queued as run jobs with logical `dependencies
Lifecycle workflow jobs use fixed capabilities:
- `process.install`: dispatched by server create workflow and projects successful terminal results to `ready`.
- `process.start`: dispatched by server start workflow and projects successful terminal results to `running`.
- `process.install`: dispatched by install bootstrap workflows and projects successful terminal results to `ready`.
- `process.start`: dispatched by server start workflow or guided supervised bootstrap and projects successful terminal results to `running`.
- `process.stop`: dispatched by server stop workflow and projects successful terminal results to `stopped`.
- `run.self-update`: dispatched by runtime distribution APIs with an approved artifact ref and checksum.
- `dependencies.check`: dispatched by dependency check APIs for a declared probe key.