Complete platform management workflows

This commit is contained in:
npc0-hue
2026-07-14 16:39:37 +08:00
parent 7e05d0a4e7
commit 4f33f761a3
106 changed files with 11313 additions and 460 deletions
@@ -0,0 +1,2 @@
schema: spec-driven
created: 2026-07-13
@@ -0,0 +1,65 @@
## Context
The platform already has separate run control, job, log, and artifact channels. Plugin manifests currently declare lifecycle, file, log, artifact, and AI capabilities, but they do not describe whether a server may be reached by FTP, rsync, or run, nor do they declare run-only operations such as remote database reads or RCON. The previous SCUM codebase used FTP/SFTP workers for file upload, scum_run for server-side operations, SQLite query forwarding, log transfer, and game-client command handling; this change brings those ideas into the new platform as typed, plugin-declared capabilities.
## Goals / Non-Goals
**Goals:**
- Model remote access methods and remote run operations in the plugin manifest.
- Require installed plugins to declare remote capabilities before platform bridge or direct job dispatch can queue them.
- Keep remote file/database/RCON/log operations behind platform and run channels.
- Allow both SCUM and Minecraft plugins to declare compatible remote access needs.
- Keep job payloads bounded: logical target keys, scoped input/artifact refs, and safe result refs only.
**Non-Goals:**
- No raw FTP, rsync, database, or RCON credentials in plugin manifests or plugin pages.
- No browser-to-run, plugin-to-run, or plugin-to-database direct connection.
- No production FTP/rsync client, MySQL client, SQLite parser, or RCON protocol implementation in this change.
- No cloud host provider workflow or server rental/billing feature.
## Decisions
### Decision 1: Manifest declares methods and capabilities separately
`remoteAccess.methods` describes how a server may be reached (`ftp`, `rsync`, `run`). `remoteAccess.runCapabilities` lists the exact run operations the plugin can use. This keeps transport choice visible while still preserving the existing run capability matching model.
Alternative considered: encode everything as free-form tags. Rejected because marketplace and authorization need deterministic validation and filtering.
### Decision 2: Remote access uses a dedicated bridge action
Plugin pages use `remote.access.request` for database, RCON, log transfer, and remote file jobs. Existing `files.request` remains for generic scoped file operations; lifecycle `jobs.dispatch` remains for start/stop. The new action lets platform apply a distinct `server.remote.access` permission and capability declaration check.
Alternative considered: overload `jobs.dispatch` for every remote operation. Rejected because RCON/database/log transfer should not be authorized only by `server.lifecycle`.
### Decision 3: Direct server-bound jobs are plugin-gated
When a job includes a `serverInstanceId`, platform validates the instance plugin declares the requested capability. This prevents callers from bypassing plugin bridge and enabling remote DB/RCON/log transfer jobs on plugins that did not opt in.
Alternative considered: enforce declaration only in plugin bridge. Rejected because platform API callers can create jobs directly in tests and future admin flows.
### Decision 4: Run remote executor is bounded metadata first
Run reports remote capabilities and accepts remote jobs, but returns safe metadata/result refs rather than opening real network connections in this change. Real FTP/rsync/database/RCON adapters can later attach behind the same job envelopes without changing plugin manifests.
Alternative considered: implement protocol clients now. Rejected because credential storage, network policy, and result artifact formats need a separate change and should not be rushed into manifest plumbing.
## Risks / Trade-offs
- [Risk] Operators may expect real FTP/rsync/DB/RCON execution immediately. Mitigation: docs and result messages state this is the declared, bounded job contract; adapter implementation remains a follow-up.
- [Risk] Capability names may grow numerous. Mitigation: keep them grouped under `remote.*` and validate them centrally.
- [Risk] Existing tests using generic jobs may fail once server-bound jobs are plugin-gated. Mitigation: lifecycle/file capabilities remain declared in existing test plugin fixtures.
## Migration Plan
1. Add OpenSpec, schema, domain, DTO, validator, and service support for remote access declarations.
2. Update SCUM and add Minecraft example manifests with declared remote access.
3. Extend run protocol and runtime to validate/report remote capabilities and complete bounded remote jobs.
4. Add tests for manifest validation, platform authorization, direct job gating, and run remote job handling.
5. Run manifest validation, platform/run tests, structure check, and strict OpenSpec validation.
## Open Questions
- Which follow-up change should own real FTP/rsync credential storage and connection testing?
- Should RCON results become log entries, artifacts, or both when full adapters land?
@@ -0,0 +1,29 @@
## Why
The platform needs one safe model for remote game server access across hosted files, run-managed hosts, databases, logs, and RCON. The old SCUM stack handled FTP/SFTP, run-side process control, SQLite queries, logs, and client commands in separate paths; the new platform must make those abilities plugin-declared before they can be used.
## What Changes
- Add plugin manifest metadata for declared remote access methods: `ftp`, `rsync`, and `run`.
- Add remote run capabilities for remote file read/write, process start/stop, MySQL and SQLite query, log transfer, and RCON command dispatch.
- Add platform registry and marketplace projection fields so operators can see which remote access methods a game plugin enables.
- Add a platform-mediated bridge action for remote access requests that queues only capabilities declared by the installed plugin.
- Extend run capability reporting and bounded remote job handling so MC and SCUM plugins can opt into the same contract.
- Add first-party Minecraft and SCUM example manifests proving the shared declaration model.
## Capabilities
### New Capabilities
- `plugin-declared-remote-access`: Plugin-declared remote server access through ftp, rsync, or run with scoped run jobs for remote files, lifecycle, database reads, log transfer, and RCON.
### Modified Capabilities
- None.
## Impact
- Affects `plugins/` manifest schema, manifest validator tests, and first-party example manifests.
- Affects `platform/` domain, DTO, validators, service bridge dispatch, marketplace projections, docs, and tests.
- Affects `run/` protocol capability constants, job validation, runtime capability reporting, worker execution, docs, and tests.
- Does not add billing, cloud host sales, plugin-owned credentials, browser-to-run access, raw host paths, or raw database/RCON credentials in plugin pages.
@@ -0,0 +1,56 @@
## ADDED Requirements
### Requirement: Plugin manifests declare remote access methods
Game management plugin manifests SHALL declare remote access methods before platform exposes FTP, rsync, or run-mediated remote server operations for server instances created from that plugin.
#### Scenario: Manifest declares supported methods
- **WHEN** a plugin manifest lists `ftp`, `rsync`, or `run` under remote access methods
- **THEN** platform registry and marketplace responses MUST preserve those methods without exposing host paths, remote credentials, direct sockets, or provider secrets
#### Scenario: Unsafe remote access declaration is rejected
- **WHEN** a plugin manifest includes raw credentials, host paths, direct run socket details, or unknown remote access methods
- **THEN** plugin workspace validation and platform registration MUST reject the manifest before it becomes installable
### Requirement: Remote run operations are capability gated
Remote run operations SHALL be represented as explicit run capabilities and SHALL require both the run endpoint and the installed game plugin to declare the requested capability.
#### Scenario: Declared remote run job is queued
- **WHEN** a plugin declares a remote run capability and the selected run endpoint reports the same capability
- **THEN** platform MAY queue a bounded job for that server instance using logical target keys and scoped input or artifact refs
#### Scenario: Undeclared remote run job is denied
- **WHEN** a caller requests remote database, RCON, log transfer, or remote file work for a server instance whose plugin did not declare the requested capability
- **THEN** platform MUST reject or deny the request before creating a job
### Requirement: Remote access bridge is platform mediated
Plugin pages SHALL request remote access through a platform-mediated bridge action and MUST NOT connect directly to FTP, rsync, run, MySQL, SQLite, log storage, or RCON endpoints.
#### Scenario: Bridge queues declared remote access
- **WHEN** a plugin page has `server.remote.access` permission and requests `remote.access.request` for a declared capability
- **THEN** platform MUST authorize the action and queue the corresponding bounded run job
#### Scenario: Bridge denies undeclared remote access
- **WHEN** a plugin page requests `remote.access.request` for a capability not declared by the plugin
- **THEN** platform MUST return a safe denial and MUST NOT expose run credentials, host paths, database DSNs, RCON passwords, or remote storage endpoints
### Requirement: Run handles bounded remote jobs
Run SHALL report supported remote capabilities and complete remote job assignments with bounded progress and safe result references while keeping control, job, logs, and artifact channels separate.
#### Scenario: Run accepts remote database and RCON assignments
- **WHEN** run receives declared remote MySQL, SQLite, RCON, log transfer, or remote file assignments
- **THEN** run MUST validate bounded job metadata and return terminal results without embedding raw credentials, host paths, query result bodies, log bodies, or RCON output in the job result payload
#### Scenario: Run rejects unsafe remote job payload
- **WHEN** a remote job assignment includes an absolute path, parent traversal, raw secret, direct socket, or oversized inline content
- **THEN** run MUST reject the assignment with a bounded failure result
### Requirement: MC and SCUM plugins share the remote access model
First-party Minecraft and SCUM plugin manifests SHALL validate against the same remote access schema and declare only the capabilities each game needs.
#### Scenario: Minecraft plugin validates
- **WHEN** the Minecraft example plugin declares run-managed files, logs, and RCON access
- **THEN** plugin workspace manifest validation MUST pass
#### Scenario: SCUM plugin validates
- **WHEN** the SCUM example plugin declares FTP/rsync/run file access, run lifecycle, SQLite/MySQL database read compatibility, log transfer, and RCON access
- **THEN** plugin workspace manifest validation MUST pass
@@ -0,0 +1,40 @@
## 1. OpenSpec Contracts
- [x] 1.1 Create proposal, design, and spec for plugin-declared remote access.
- [x] 1.2 Validate the new change artifacts with `openspec validate --strict`.
## 2. Plugin Manifest Contracts
- [x] 2.1 Extend the game plugin manifest schema with `remoteAccess` methods, run capabilities, database engines, RCON, and log transfer declarations.
- [x] 2.2 Update manifest validation tests and examples so SCUM and Minecraft validate with remote access declarations.
## 3. Platform Registry and Authorization
- [x] 3.1 Add domain and DTO remote access metadata to game plugin, manifest, and marketplace projections.
- [x] 3.2 Extend platform validators for remote methods, remote run capabilities, `server.remote.access`, and `remote.access.request`.
- [x] 3.3 Gate server-bound jobs against the server instance plugin's declared capabilities.
- [x] 3.4 Add bridge execution for declared remote access requests and tests for denied undeclared capabilities.
## 4. Run Protocol and Worker
- [x] 4.1 Add remote run capability constants and validation rules for bounded remote assignments.
- [x] 4.2 Report remote capabilities from run smoke and worker mode.
- [x] 4.3 Add bounded remote job execution results that keep heavy payloads in artifact/log channels.
- [x] 4.4 Add run tests for remote DB/RCON/log/file capabilities and unsafe payload rejection.
## 5. Documentation and Verification
- [x] 5.1 Update platform, run, and plugin docs for remote access capability declarations.
- [x] 5.2 Run plugin manifest validation, platform tests, run tests, and `scripts/check-structure.sh`.
- [x] 5.3 Record verification evidence in `tasks.md`.
## Evidence
- `openspec validate add-plugin-declared-remote-access --strict` - passed; PostHog telemetry flush logged DNS warnings only after validation succeeded.
- `go test ./...` in `platform/` - passed.
- `go test ./...` in `run/` - passed.
- `npm test` in `plugins/` - passed: 14 manifest/SDK tests.
- `npm run typecheck` in `plugins/` - passed.
- `TMPDIR=/private/tmp npm run validate:manifest` in `plugins/` - passed for dev, SCUM, and Minecraft manifests.
- `scripts/check-structure.sh` - passed.
- `git diff --check` - passed.