wtclaude
862c328176
module-rust, id 'rust', built from the Integration Kit's template. Phase 1's job
is the kit's own argument: get every seam working at once with almost nothing in
them, so that afterwards you break exactly one at a time.
What is here:
* /rust on all three tiers, because the loader holds module.json's mounts against
what is registered in BOTH directions -- so the declaration and the
registration land together or not at all. The player tier is honestly thin: it
answers the server list on the authenticated tier, delegating to the same model
the public tier uses so the two cannot drift while they are meant to be the
same. It is the address the app will call, registered now rather than moved
later.
* Two tables. rust_servers is configuration an operator writes; rust_server_state
is what a sidecar reported. Separate tables because they have different
writers, lifetimes and audiences -- and because purging observed state while
keeping the configuration is a thing an operator will want.
* Per-server sidecar tokens through ctx.secretBox, write-only in the API. The
admin list reports hasToken and never the credential, and an empty token on a
save leaves the stored one alone -- a form that posts its own blank field would
otherwise erase a credential every time somebody renamed a server.
* A real sidecar client. It never throws: every call answers {ok, status, data},
and the status is what tells a wrong URL from a wrong token from a mismatched
protocol -- all three present as 'the site says my server is offline' and each
has a different fix.
* The five guards, green: check:imports, check:swagger, check:externals, and both
suites.
What is deliberately NOT registered: the Team provider, triggers, audiences,
engagement seeds, notification streams, the four event catalogues, and the two
extension slots. Each arrives with the phase that has something real to put in
it, and a test asserts their absence so that removing it is deliberate. A
declared trigger nothing emits and a declared slot nothing fills are both
surfaces an operator can configure and then wait on, which is worse than an
absent one because the absence is visible.
Two corrections to the kit's template, both feedback for a later phase:
* registration.test.js read one page BY NAME to check declared slots are
rendered, so a module declaring none dies on ENOENT before reaching the loop
that would have been empty. It now scans every file under src/routes.
* test/_fakes.js supplied validator: {}. An admin router that builds validation
chains at file scope cannot be required with that, so the fake holds the real
express-validator -- for the same reason it holds a real express Router.
The kit was right about noGameConnection.test.js: its header predicts that a
module adding a sidecar client will see the check go red, names sidecarClient.js
as the file to allow, and says narrow it rather than delete it. That is exactly
what happened on the first run, and the fix was the one line the header names.
Installed into a real core and verified: the module reaches 'started', publishes
its capability, serves its chunk, and renders a server whose server.hello
originated in a live Rust server.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4
4.3 KiB
Module-Rust
The Rust module for the Runic Gateway platform: everything that
makes a Runic Gateway site a site for Rust. It installs into a website core as
modules/rust/ and is the platform's second game module, after
Module-uo.
It is also the first module built from the Integration Kit rather than extracted from the website — which makes it the kit's acceptance test from the inside.
The repository name is not the module id. This ships a module whose id is rust, because the
contract requires id to equal the directory core loads it from (modules/rust/), and that id is
the prefix of every table and every mount.
What it is, in one diagram
Rust server + Oxide (RunicGateway/Rust-Plugins)
│ loopback TCP, the plugin dials out
▼
rust-link sidecar (RunicGateway/Rust-Link) one per game server
│ HTTPS + WebSocket, bearer token
▼
this module, inside a website core one client per server
│ same-origin JSON
▼
browser · Android app
One server, one sidecar. A community running six Rust servers runs six pairs and configures six rows here; the website core never learns there is more than one.
What ships today
| Surface | Route |
|---|---|
| Public | GET /api/v1/public/rust/servers — every server and what it last reported |
| Player | GET /api/v1/player/rust/servers — the same, on the authenticated tier |
| Admin | GET/PUT/DELETE /api/v1/admin/rust/servers and POST …/:id/test |
| Page | /rust/servers |
Two tables, rust_servers (configuration) and rust_server_state (what each sidecar reported).
The rest of the module — identity, site-owned permissions, Teams from Rust's clans, notifications, events, the live map, Discord commands — arrives phase by phase. Nothing is registered before it has something behind it: a declared trigger nothing emits and a declared slot nothing fills are both surfaces an operator can configure and then wait on, which is worse than an absent one.
Build and check
npm ci --prefix server && npm test --prefix server
npm run check:imports --prefix server
npm run check:swagger --prefix server
npm ci --prefix client && npm run build --prefix client
npm run check:externals --prefix client && npm test --prefix client
Build the client BEFORE running its tests — two of them read the built chunk and skip when there is none, so a run in the other order passes while asking nothing about the artifact that ships.
Regenerate the OpenAPI fragment whenever a route or an annotation changes:
npm run swagger --prefix server # writes swagger-fragment.json; commit it
Install it into a core
Copy the whole tree to <website>/modules/rust/ and restart. Copy, do not symlink — the loader
lists directory entries and asks each whether it is a directory; a symlink answers no and the module
is skipped in complete silence.
Then, in Admin → Rust, add a server: its name, the sidecar's base URL, and the token the sidecar
printed on first start (rust-link-sidecar --print-config). The token is write-only — it is
stored encrypted through core's own secret box and never returned to any client; the panel reports
only whether one is set.
POST /api/v1/admin/rust/servers/:id/test probes a sidecar and reports what came back in one word.
That is the route that tells a wrong URL from a wrong token from a mismatched protocol version —
all three present as "the site says my server is offline" and each has a different fix.
The protocol is a contract
PROTOCOL_VERSION in server/sidecarClient.js is sent on every request as X-RustLink-Version,
and a sidecar speaking a different one answers 409 rather than serving something this module will
mis-parse. It must agree with the sidecar's own constant and with overlay.toml in the plugin repo.
Canonical spec:
docs/rust-link/PROTOCOL.md.
The module's own design of record is
docs/modules/rust/PLAN.md.
Licence
GPL-3.0-or-later. See LICENSE.md.