feat: the module skeleton and every bundle seam

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

server/router/admin/rust.controller.js

@@ -0,0 +1,132 @@
+// ── Admin · Rust — the handlers ───────────────────────────────────────────
+//
+// The write side of the module. Three things every handler here owes:
+//
+//  1. **Never return the token.** Not in a response, not in an error, not in an
+//     activity-log detail. It is accepted, encrypted and forgotten.
+//  2. **Record the change.** `core.activity.log` writes core's own admin audit
+//     row. These handlers edit the credential that reaches a game host; "who
+//     changed this" has no second place it is recorded.
+//  3. **Answer rather than throw.** An unhandled rejection reaches core's error
+//     handler and gets core blamed for a fault in this module.
+
+const core = require('../../core')
+
+const db = require('../../model/servers/servers.db')
+const servers = require('../../model/servers/servers.model')
+const sidecar = require('../../sidecarClient')
+
+const log = core.logger('admin')
+
+async function listServers(req, res) {
+  try {
+    res.json({ servers: await servers.listForAdmin() })
+  } catch (err) {
+    log.error('failed to read the server list', { error: err.message })
+    res.status(500).json({ error: 'Failed to read the server list' })
+  }
+}
+
+async function putServer(req, res) {
+  const { id } = req.params
+  const { name, sidecarBaseUrl, sidecarToken, protocol, enabled, sortOrder } = req.body
+
+  try {
+    const existing = await db.getServer(id)
+
+    // A NEW server with no token is a row that can never reach its sidecar, and
+    // the operator will read the resulting "unreachable" as a network problem.
+    // Refusing it up front costs one round trip and saves that hunt. An EXISTING
+    // row is a different case: omitting the token is how you say "leave it".
+    if (!existing && !sidecarToken) {
+      return res.status(400).json({ error: 'A new server needs its sidecar token' })
+    }
+
+    await db.upsertServer({
+      id,
+      name,
+      sidecarBaseUrl,
+      // `encryptToken` returns null for an empty value, and `upsertServer` reads
+      // null as "do not write this column". The two halves of that rule are in
+      // different files on purpose: the model decides what a blank means, the SQL
+      // decides what null does, and neither has to know the other's reason.
+      sidecarTokenEnc: servers.encryptToken(sidecarToken),
+      protocol: protocol === undefined ? sidecar.PROTOCOL_VERSION : protocol,
+      enabled: enabled === undefined ? true : enabled,
+      sortOrder: sortOrder === undefined ? 0 : sortOrder,
+    })
+
+    await core.activity.log({
+      req,
+      action: 'rust.server.save',
+      detail: {
+        server: id,
+        created: !existing,
+        sidecarBaseUrl,
+        // Whether the credential was rotated, never the credential.
+        tokenChanged: Boolean(sidecarToken),
+      },
+    })
+
+    return res.status(204).end()
+  } catch (err) {
+    log.error('failed to save a server', { server: id, error: err.message })
+    return res.status(500).json({ error: 'Failed to save the server' })
+  }
+}
+
+async function deleteServer(req, res) {
+  const { id } = req.params
+
+  try {
+    const existing = await db.getServer(id)
+    if (!existing) return res.status(404).json({ error: 'No such server' })
+
+    await db.deleteServer(id)
+    await core.activity.log({ req, action: 'rust.server.delete', detail: { server: id } })
+
+    return res.status(204).end()
+  } catch (err) {
+    log.error('failed to delete a server', { server: id, error: err.message })
+    return res.status(500).json({ error: 'Failed to delete the server' })
+  }
+}
+
+/**
+ * Probe one sidecar and report what came back.
+ *
+ * This is the route that tells a wrong URL from a wrong token from a mismatched
+ * protocol, and that distinction is the whole reason it exists: all three present
+ * to an operator as "the site says my server is offline", and each has a
+ * different fix. The status string from `sidecarClient` is carried through
+ * verbatim so the panel can say which.
+ */
+async function testServer(req, res) {
+  const { id } = req.params
+
+  try {
+    const row = await db.getServer(id)
+    if (!row) return res.status(404).json({ error: 'No such server' })
+
+    const result = await sidecar.health(servers.withToken(row))
+
+    await core.activity.log({
+      req,
+      action: 'rust.server.test',
+      detail: { server: id, ok: result.ok, status: result.status },
+    })
+
+    return res.json({
+      ok: result.ok,
+      status: result.status,
+      // `data` is the sidecar's own health document on success and the mismatch
+      // detail on a 409. Both are safe to show: neither carries a credential.
+      sidecar: result.data || null,
+    })
+  } catch (err) {
+    log.error('failed to probe a sidecar', { server: id, error: err.message })
+    return res.status(500).json({ error: 'Failed to probe the sidecar' })
+  }
+}
+
+module.exports = { listServers, putServer, deleteServer, testServer }

server/router/admin/rust.router.js

@@ -0,0 +1,89 @@
+// ── Admin · Rust ──────────────────────────────────────────────────────────
+//
+// Mounted at `/api/v1/admin/rust`. The tier's gate is already applied: `admin`
+// sits behind `noindex, isLoggedIn, requireRole('admin','editor','moderator')`.
+//
+// **That gate is broader than these routes should be.** Editing a server row
+// means editing the credential that reaches a game host, which is an
+// administrator's job and not a moderator's — so the routes that write add
+// `requireRole('admin')` on top of the tier. A module adds per-route gates over
+// the tier gate and never re-implements it; this is what adding one looks like.
+//
+// ── The token is write-only ───────────────────────────────────────────────
+//
+// `sidecarToken` is accepted and never returned. The list route reports
+// `hasToken` instead, because a blank field otherwise means both "unset" and
+// "set, and not being shown to you". An empty string on a save leaves the stored
+// value alone — an operator renaming a server must not have to re-paste a
+// credential, and a form that posts its own blank field would otherwise erase one
+// on every unrelated edit.
+
+const core = require('../../core')
+
+const express = core.express
+const admin = require('./rust.controller')
+const { requireRole, validate } = core.middleware
+const { body, param } = core.validator
+
+const adminRustRouter = express.Router()
+
+adminRustRouter.get(
+  '/servers',
+  // #swagger.tags = ['Admin · Rust']
+  // #swagger.summary = 'Every configured Rust server'
+  // #swagger.description = 'The operator’s server rows with their sidecar URLs, whether a token is stored, and whether each sidecar was reachable on the last poll. The token itself is never returned.'
+  /* #swagger.responses[200] = { description: 'The configured servers', content: { "application/json": { schema: { $ref: "#/components/schemas/RustAdminServerList" } } } } */
+  admin.listServers,
+)
+
+adminRustRouter.put(
+  '/servers/:id',
+  // #swagger.tags = ['Admin · Rust']
+  // #swagger.summary = 'Create or update a Rust server'
+  // #swagger.description = 'Writes one server row. `sidecarToken` is write-only — send it to set or rotate the credential, and omit it or send an empty string to leave the stored one untouched. The id is the slug every URL under the module carries.'
+  /* #swagger.responses[204] = { description: 'Saved' } */
+  /* #swagger.responses[400] = { description: 'Invalid body' } */
+  requireRole('admin'),
+  param('id')
+    .matches(/^[a-z0-9][a-z0-9-]{0,63}$/)
+    .withMessage('id must be lowercase letters, digits and hyphens'),
+  body('name').isString().trim().isLength({ min: 1, max: 120 }),
+  // A base URL is validated for SHAPE and not for reachability: an operator
+  // configures a sidecar before installing it about half the time, and refusing
+  // the row because nothing answers yet would make the obvious order of
+  // operations impossible.
+  body('sidecarBaseUrl').isURL({ require_tld: false, protocols: ['http', 'https'] }),
+  body('sidecarToken').optional({ values: 'falsy' }).isString().isLength({ max: 512 }),
+  body('protocol').optional().isInt({ min: 1, max: 1000 }).toInt(),
+  body('enabled').optional().isBoolean().toBoolean(),
+  body('sortOrder').optional().isInt({ min: -1000, max: 1000 }).toInt(),
+  validate,
+  admin.putServer,
+)
+
+adminRustRouter.delete(
+  '/servers/:id',
+  // #swagger.tags = ['Admin · Rust']
+  // #swagger.summary = 'Remove a Rust server'
+  // #swagger.description = 'Deletes the server row and the observed state that hangs off it. It does not touch the sidecar or the game host — those are removed with the installer.'
+  /* #swagger.responses[204] = { description: 'Deleted' } */
+  requireRole('admin'),
+  param('id').isString().isLength({ min: 1, max: 64 }),
+  validate,
+  admin.deleteServer,
+)
+
+adminRustRouter.post(
+  '/servers/:id/test',
+  // #swagger.tags = ['Admin · Rust']
+  // #swagger.summary = 'Probe a server’s sidecar'
+  // #swagger.description = 'Calls the sidecar’s health endpoint with the stored credential and reports what came back — whether it answered, whether the bridge plugin is connected to it, and which protocol version it speaks. This is the one route that tells a wrong URL from a wrong token from a mismatched version.'
+  /* #swagger.responses[200] = { description: 'What the sidecar said', content: { "application/json": { schema: { $ref: "#/components/schemas/RustSidecarProbe" } } } } */
+  /* #swagger.responses[404] = { description: 'No such server' } */
+  requireRole('admin'),
+  param('id').isString().isLength({ min: 1, max: 64 }),
+  validate,
+  admin.testServer,
+)
+
+module.exports = adminRustRouter

server/router/player/rust.controller.js

@@ -0,0 +1,22 @@
+// ── Player · Rust — the handlers ──────────────────────────────────────────
+//
+// See the router for why this tier is thin in phase 1. The one thing it must not
+// do is reshape the list itself: it calls the same model the public tier does, so
+// the two answers cannot drift while they are meant to be the same.
+
+const core = require('../../core')
+
+const servers = require('../../model/servers/servers.model')
+
+const log = core.logger('player')
+
+async function listServers(req, res) {
+  try {
+    res.json({ servers: await servers.listPublic() })
+  } catch (err) {
+    log.error('failed to read the server list', { error: err.message })
+    res.status(500).json({ error: 'Failed to read the server list' })
+  }
+}
+
+module.exports = { listServers }

server/router/player/rust.router.js

@@ -0,0 +1,41 @@
+// ── Player · Rust ─────────────────────────────────────────────────────────
+//
+// Mounted at `/api/v1/player/rust`. The tier's gate is already applied: `player`
+// sits behind `noindex, requireAuth`, so every handler here has a signed-in user
+// and none of them re-implements that check.
+//
+// ── Why this tier exists in phase 1, and what it honestly holds ───────────
+//
+// R14 puts this module on all three tiers from the start, and the loader holds
+// `module.json`'s `mounts` against what is actually registered in **both**
+// directions — a declared prefix that never gets a router fails the load. So the
+// declaration and the registration land together or not at all.
+//
+// What this tier will carry is the signed-in view of a server: the viewer's own
+// linked Steam identity, their own presence, their own entitlements. None of that
+// exists yet — identity is a later phase — so the one route here answers the
+// server list as the signed-in caller sees it, which is currently the same list
+// the public tier serves.
+//
+// That is deliberately a real route and not a placeholder: it is the URL the app
+// and the SPA will call, and it starts answering correctly now rather than
+// changing address later. What it must not become is a second copy of the public
+// shape — it delegates to the same model, so the two cannot drift.
+
+const core = require('../../core')
+
+const express = core.express
+const servers = require('./rust.controller')
+
+const playerRustRouter = express.Router()
+
+playerRustRouter.get(
+  '/servers',
+  // #swagger.tags = ['Player · Rust']
+  // #swagger.summary = 'The Rust servers, for a signed-in player'
+  // #swagger.description = 'The same servers the public list carries, answered on the authenticated tier. It is the address a signed-in client calls, so that per-player detail can be added here without moving it. Requires a session.'
+  /* #swagger.responses[200] = { description: 'The server list', content: { "application/json": { schema: { $ref: "#/components/schemas/RustServerList" } } } } */
+  servers.listServers,
+)
+
+module.exports = playerRustRouter

server/router/public/rust.controller.js

@@ -0,0 +1,27 @@
+// ── Public · Rust — the handlers ──────────────────────────────────────────
+//
+// Thin on purpose: read the request, call a model, answer. Everything worth
+// testing is in the model, which needs no express and no database to test.
+//
+// **A handler must not throw past express.** Core mounts this router inside its
+// own tier router, so an unhandled rejection here reaches core's error handler
+// and answers 500 — survivable, but it means an operator sees core blamed for a
+// fault in this module. Catch, log through `core.logger` (so the line carries the
+// module id), and answer something honest.
+
+const core = require('../../core')
+
+const servers = require('../../model/servers/servers.model')
+
+const log = core.logger('public')
+
+async function listServers(req, res) {
+  try {
+    res.json({ servers: await servers.listPublic() })
+  } catch (err) {
+    log.error('failed to read the server list', { error: err.message })
+    res.status(500).json({ error: 'Failed to read the server list' })
+  }
+}
+
+module.exports = { listServers }

server/router/public/rust.router.js

@@ -0,0 +1,44 @@
+// ── Public · Rust ─────────────────────────────────────────────────────────
+//
+// Mounted at `/api/v1/public/rust` by `index.js`. One express Router, built from
+// CORE's express (`core.express`) — never from a `require('express')` of your
+// own, which would not resolve from here anyway (MODULE_API.md §7.2).
+//
+// **The tier's gate is already on.** This router sits inside core's public tier,
+// which is behind nothing by design. Per-route middleware goes on top, and
+// `siteMode` is the one worth understanding: it is what makes a route respect the
+// operator's maintenance switch. Core applies it to its own content routes and
+// deliberately does not apply it to its status endpoints, because status is
+// exactly what an operator wants visible *during* maintenance.
+//
+// The server list is content, not status — it is the module's landing page — so
+// it takes `siteMode`.
+//
+// ── About the `#swagger` comments ─────────────────────────────────────────
+//
+// They are not documentation *of* the code; they are the source the OpenAPI
+// fragment is generated from (`npm run swagger`, §2.8). swagger-autogen reads
+// them as JavaScript literals it evaluates, so a QUOTE CHARACTER inside a
+// single-quoted description ends the string early — and the failure is silent:
+// the value is truncated at that character while the generator prints success.
+// Use a typographic apostrophe (’) in prose. A backtick is fine.
+
+const core = require('../../core')
+
+const express = core.express
+const servers = require('./rust.controller')
+const { siteMode } = core.middleware
+
+const rustRouter = express.Router()
+
+rustRouter.get(
+  '/servers',
+  // #swagger.tags = ['Public · Rust']
+  // #swagger.summary = 'Every Rust server this site follows'
+  // #swagger.description = 'The operator’s configured Rust servers and what each one last reported. Answers with `online: false` and `stale: true` rather than failing when a game server or its sidecar is unreachable — the site’s availability does not depend on the game’s.'
+  /* #swagger.responses[200] = { description: 'The server list', content: { "application/json": { schema: { $ref: "#/components/schemas/RustServerList" } } } } */
+  siteMode,
+  servers.listServers,
+)
+
+module.exports = rustRouter