feat(builder): documented launch options only, and no game-specific code
Launch options must be documented. A draft passed an option its server doesn't have; servers ignore unknown options, so it booted and passed every boot test while its setting did nothing. build now reads the pages research based the variant on, in full, and the drafter rejects any launch option in the startup command that none of them, nor the image's own scripts, mention. Shell tools' options (mkdir -p, [ -n ...]) are skipped; the check is off without sources. The builder is game-agnostic: - AUTHORING.md (the model's rules), the research prompt and the schema describe the rules without naming a game. - The draft prompt no longer includes real templates from the repo. Its format example is one invented server (no real command, options, ports or app id), checked by TestExampleTemplateFollowsTheRules. - Comments, help texts, BUILDER.md and test fixtures use invented names and values. - TestBuilderIsGameAgnostic reads every game's name and id from games/ and fails if any appears in the builder's code, tests, rules, schemas or docs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
1 parent
dd92b6be4c
commit
8623ba2d7b
16 files changed
+395
-120
No files matched your search
+7
-4
@@ -47,22 +47,25 @@ Know this before writing anything:
|
||||
|
||||
### The container user
|
||||
- Run `gbrgames inspect-image -game <id>`. If the image is built around its own user (it declares
|
||||
`USER`, or locks a home folder to a uid other than 1000), set `containerUser` to that `uid:gid`.
|
||||
Example: ARK's image needs `25000:25000`.
|
||||
`USER`, or locks a home folder to a uid other than 1000), set `containerUser` to that `uid:gid`, as
|
||||
the inspector reports it.
|
||||
|
||||
### The startup command
|
||||
- Read settings under the names the agent gives them (see above). `${RCON_PORT}` when the setting is
|
||||
`RCONPort` silently ignores the owner's value; it arrives as `RCONPORT`.
|
||||
- Use `${VAR:-default}` for anything that may be unset.
|
||||
- Only use launch options the game's documentation lists, spelled as it spells them. Servers ignore options
|
||||
they don't know, so an invented one boots fine and its setting does nothing.
|
||||
- Quote text settings where they're used: `-name "${SERVER_NAME}"`. `ARGS="-name ${SERVER_NAME}"; ./server $ARGS`
|
||||
splits "GBRHosting - My Server" into words; build optional arguments in a bash array instead
|
||||
(`args=(-name "$SERVER_NAME"); [ -n "$PASSWORD" ] && args+=(-password "$PASSWORD"); ./server "${args[@]}"`).
|
||||
- If the image installs the game itself on start, make sure a failed install is retried rather than
|
||||
starting a server that isn't there (see ARK's template).
|
||||
starting a server that isn't there: log in to SteamCMD once (`+login anonymous +quit`) before the
|
||||
install, and retry the install a few times until the server's executable exists.
|
||||
|
||||
### Memory
|
||||
- `requiredMemoryMb` is the container's hard limit. A JVM or engine heap must stay about **1 GB below**
|
||||
it: Minecraft's `MEMORY` is `3G` for `4096` MB. A heap equal to the limit is killed on start.
|
||||
it: a `3G` heap for `4096` MB. A heap equal to the limit is killed on start.
|
||||
|
||||
### Settings (`defaultConfig` and `configSchema`)
|
||||
- Take keys and default values from what the server really writes: run
|
||||
|
||||
Reference in new issue
Block a user