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

Move game log processing into SCUM companion

Browse Source
This commit is contained in:
npc0-hue
2026-09-02 10:18:27 +08:00
parent 7d9c1b7e9e
commit 40ac46ba17
14 changed files with 328 additions and 232 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+12 -14
View File
@@ -16,8 +16,6 @@ Until the primary first-party workflows are implemented end-to-end and the produ
Before 1.0, prioritize making the actual user-facing flows work fully. Remove or avoid audit/restriction scaffolding when it blocks, distracts from, or outpaces the core implementation. Reintroduce audit, compliance, or restrictive governance only after an explicit future product decision for a completed flow.
Until the primary flows are running end-to-end, do not block implementation behind restrictive policy scaffolding, capability allowlists, delivery acknowledgements, audit gates, or placeholder governance. The governing rule is: make the first-party feature work in the product first, then harden it later only when explicitly requested.
## Project Roots
- `platform/` contains backend platform code.
@@ -35,7 +33,7 @@ Until the primary flows are running end-to-end, do not block implementation behi
- If native MCP tool wrappers return `unsupported call`, do not keep retrying the same wrapper. Read the server-management plugin MCP config and call the local MCP JSON-RPC gateway (`initialize`, `tools/list`, `tools/call`) from a small Node script; never print or commit MCP headers, tokens, host credentials, or raw `.mcp.json` contents.
- If local access to the MCP gateway fails with `EPERM` on `127.0.0.1`, request sandbox escalation for that MCP gateway call instead of falling back to raw SSH.
- On Windows targets, assume `ssh_exec` may run under `cmd`; for PowerShell diagnostics, send `powershell -NoProfile -NonInteractive -ExecutionPolicy Bypass -EncodedCommand <utf16le-base64>` to avoid quoting/glob problems.
- For SCUM current-service discovery, run bounded read-only scripts on `枣庄服务器` itself and return only redacted aggregates/fingerprints. Do not download or parse `SCUM.db` on the platform/plugin/browser side; product evidence must flow through Platform durable jobs and Run typed/redacted envelopes.
- For SCUM current-service discovery, run bounded read-only scripts on `枣庄服务器` itself and return bounded typed results. Do not download or parse `SCUM.db` on the platform/plugin/browser side; product evidence must flow through Platform durable jobs and Run typed envelopes. Do not apply game-specific redaction to plugin-declared result fields or player records. Logs are opaque terminal data: Run and Platform must not inspect, parse, filter, redact, transform, or derive player/plugin records from stdout, stderr, or declared file-tail payloads. The SCUM plugin companion may consume its declared log streams, perform the one game-specific parse/redaction pass, and create or update its own users and business records; Platform and Run must never do that work.
The machine-side run executor lives in the independent repository `git@git.npc0.com:admin343/run.git`; do not re-add a `run/` source tree to this repository.
@@ -91,31 +89,31 @@ Do not define business structs inside functions. Do not define request/response
The external run executor must not expose host paths, raw credentials, or direct sockets to plugins or platform_web.
Platform, plugin, and run lifecycle ownership must stay separated. Run is the machine-side state machine for execution; Platform records desired lifecycle intent, registration/auth, generated package inputs, and persisted lifecycle projections from Run-reported facts, not observed process truth:
Platform, plugin, and run lifecycle ownership must stay separated. Run is the lifecycle authority for machine execution; Platform records desired lifecycle intent, registration/auth, generated package inputs, and persisted projections from Run-reported facts, not observed process truth:
- Platform owns server instances, plugin manifest validation, platform-side distribution builds, generated Run package inputs, run registration binding, authorization, persisted lifecycle projections, and live transport relay between Run, plugins, and platform_web.
- Plugins own game-specific lifecycle declarations: init/install/update/pre-start checks, dependency probes/install plans, start arguments, stop logic, status/readiness probes, executable paths, Steam app IDs, game-specific dependency commands, game-log storage, game-log analysis, and console-page log stream fan-out to the frontend.
- Run owns generic machine lifecycle execution and the observed runtime/process state it supervises: local bootstrap from generated package plans, scoped file operations, bounded process execution/supervision, current process output push, artifacts, and channel transport. Run must behave as a state machine, not as a durable log database or log-delivery authority.
- Platform owns server instances, plugin manifest validation, platform-side distribution builds, generated Run package inputs, run registration binding, authorization, and persisted lifecycle projections.
- Plugins own game-specific lifecycle declarations: init/install/update/pre-start checks, dependency probes/install plans, start arguments, stop logic, status/readiness probes, executable paths, Steam app IDs, and game-specific dependency commands.
- Run owns generic machine lifecycle execution and the observed runtime/process state it supervises: local bootstrap from generated package plans, scoped file operations, bounded process execution/supervision, declared capability enforcement, logs, artifacts, and channel transport.
Observed machine/runtime status must flow from run reports, heartbeats, supervised process facts, and job/control events. Platform must not treat stale persisted server state, such as `running`, as authoritative when evaluating the current machine process state.
Observed machine/runtime status must flow from run reports, heartbeats, supervised process facts, and job/log channels. Platform must not treat stale persisted server state, such as `running`, as authoritative when evaluating the current machine process state. Run must preserve plugin-declared game records without per-game content redaction. Supervised stdout/stderr and declared file tails are opaque verbatim channels: Run and Platform only persist, relay, or display them; they never content-filter or use them to produce player/plugin data. A plugin companion may parse its own declared stream and publish typed plugin-owned records through the component boundary. This does not grant plugins or the browser a direct host-path, credential, or socket API outside the log channel.
Do not hardcode game-specific deployment behavior in run or platform services. Values such as `SCUMServer.exe`, Steam app `3792580`, `steamcmd +app_update`, SCUM install directories, `-port`, `-MaxPlayers`, or `-log` belong in the SCUM plugin's manifests, action specs, templates, or scripts.
When a game needs "install if missing, update if present, then start" behavior, implement it as plugin-owned lifecycle actions and package those declarations into the generated Run autonomous lifecycle plan. Run executes the plan through generic capabilities; neither Platform nor Run should special-case a game by name to perform those steps.
Do not add extra platform/frontend lifecycle states just to represent game-specific setup checks. A plugin-owned start action should verify its declared files and dependencies, create missing directories, install or update missing server bits, then start the service through the same plugin-declared lifecycle script. Run should only execute that declared script through generic supervision, hide the started process window where the operating system supports it, and push the current supervised process output through the declared stdout/stderr live log relay without caching or delivery acknowledgement.
Do not add extra platform/frontend lifecycle states just to represent game-specific setup checks. A plugin-owned start action should verify its declared files and dependencies, create missing directories, install or update missing server bits, then start the service through the same plugin-declared lifecycle script. Run should only execute that declared script through generic supervision, hide the started process window where the operating system supports it, and return the supervised process output through the declared stdout/stderr log channels.
Realtime log collection must be plugin-declared and plugin-configured. Run only pushes current log/output events that it is observing now; it must not care whether the server side has accepted them, must not maintain durable local log caches, and must not block lifecycle/control/job progress on log delivery. Platform only forwards live log traffic and should not store, analyze, acknowledge, sequence-gate, or own game-log history. The SCUM plugin owns SCUM log storage, analysis, and forwarding live console streams to platform_web when the operator opens the console page.
Realtime log collection must be plugin-declared and plugin-configured. For live terminal output, prefer the plugin-declared supervised process channels (`process.stdout` / `process.stderr`) for the process that run started, and treat game-specific file tails only as plugin-declared sources for history, fallback, or explicit backfill. Do not inspect or prioritize a game log file such as `SCUM.log` merely because it exists on disk; if a plugin needs a file tail, window/console capture, startup flag, hidden window behavior, or another live-log source, declare that behavior in the plugin manifest/action/config and keep run/platform generic.
Run-platform communication must remain channelized, but logs are best-effort live traffic rather than durable platform-owned delivery:
Run-platform communication must remain channelized:
- Control is lightweight and high priority.
- Jobs carry lifecycle and bounded operations.
- Logs are current best-effort push/relay only: no Run durable spool, no Run resend backlog, no platform sequence acknowledgement dependency, and no platform-owned log persistence. If a game needs stored logs or analysis, implement it in that game plugin.
- Logs use durable batch ingest with local spool and sequence acknowledgement.
- Artifacts use chunked and resumable transfer with lower priority than logs/control.
- Optional game client bridge is separate from run lifecycle and live log relay.
- Optional game client bridge is separate from run lifecycle and log ingest.
Large file transfer must not block control heartbeat, job ack/result, or live log relay.
Large file transfer must not block control heartbeat, job ack/result, or log upload.
## Distribution Build Ownership Rules