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

feat: move distribution builds to platform Docker builder

Browse Source
This commit is contained in:
npc0-hue
2026-07-30 19:25:50 +08:00
parent 1e004dc9ec
commit e614a17fe3
45 changed files with 4492 additions and 294 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+20
View File
@@ -10,6 +10,12 @@ The platform's required first-party areas are 首页、服务器管理、插件
The platform_web visual direction is a unified magical-girl crystal-moonlight game operations console. Preserve the style rules in `platform_web/AGENTS.md` and `platform_web/theme/README.md`; do not replace it with generic opaque SaaS cards or unrelated visual systems without a future OpenSpec change. Global magical ultimate effects belong in `platform_web/components/MagicalParticleLayer.tsx`, not in page-local fixed decoration spans or one-off backdrop CSS.
## Server Creation Rules
Creating a server instance must require only the game plugin type and the server name. Do not require the owner to pick a deployment target, run endpoint, or runtime profile at creation time: the run executor does not exist yet at that point, so any such field can only be filled incorrectly.
The binding between a server instance and its run endpoint is established when the generated run registers itself, not by pre-selecting an existing endpoint in the creation form. Deployment target and runtime profile selection may exist only as optional actions on an already-created instance, never as creation prerequisites.
## Project Roots
- `platform/` contains backend platform code.
@@ -87,6 +93,20 @@ Run-platform communication must remain channelized:
Large file transfer must not block control heartbeat, job ack/result, or log upload.
## Distribution Build Ownership Rules
Distribution building is a platform-side responsibility. The platform must be able to build a run package for any server instance without depending on a privileged worker run endpoint being registered and online. Do not route `distribution.build` execution through machine-side run endpoints, and do not derive build availability from a run endpoint advertising that capability.
Platform-side builds must execute in a platform-owned Docker builder using a pinned image, with build workspaces isolated per plugin and per job. Builder readiness is a platform-level probe; when it is unavailable, the reported reason must name the platform builder rather than a run endpoint capability.
A generated run carries credentials scoped to one server instance and must never hold distribution-build authority. This restriction is a security boundary, not a fallback path: it must not be relaxed to unblock building. Fix the build path instead.
Component auth keys must stay inside the platform for builder-executed builds. Do not return plaintext auth keys to machine-side run endpoints for distribution builds.
## Local Run Distribution Testing
For local testing, when a generated `run.exe` must be made available to a remote server, start a temporary file server from the build output directory with `python3 -m http.server 8000`. Download the artifact through `https://bt.npc0.com/` followed by its relative file path, then download that file again on the machine where `run` will execute. This is a test-only distribution path; do not treat the temporary HTTP server or tunnel as a production artifact-delivery service.
## AI Provider Rules
AI provider keys and base URLs belong to `platform/`. Plugins may request AI assistance only through platform-mediated capabilities. Plugin page must never receive raw AI keys.