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

client/src/api.js

@@ -0,0 +1,57 @@
+// ── This module's own API bindings ────────────────────────────────────────
+//
+// Core hands out the request PRIMITIVE and nothing above it (MODULE_API.md
+// §3.5): same-origin `/api/v1`, cookies included, JSON in and out, and an
+// `ApiError` thrown on any non-2xx. The paths are this module's, because the
+// routes at the other end are — `server/router/**` in this repo serves them.
+//
+// **Do not build your own fetch wrapper.** The primitive is what carries the
+// session cookie, the CSRF handling and the error shape core's `ErrorState`
+// knows how to render. A module that calls `fetch` directly gets none of that
+// and finds out one page at a time.
+//
+// Keeping the bindings in one file, ordered the way the routers are, is
+// convention rather than contract — but the two halves of every call live in
+// different directories and nothing checks them against each other, so anything
+// that makes a mismatch easy to see is worth doing.
+
+import rg from './core.js'
+
+const { request: req, BASE } = rg.api
+
+// ── public ────────────────────────────────────────────────────────────────
+// Token-free, same-origin reads. Paths are relative to `/api/v1`, so this hits
+// `/api/v1/public/rust/servers` — the route `server/router/public/rust.router.js`
+// registers under the `/rust` prefix `module.json` declares.
+export const servers = {
+  list: () => req('/public/rust/servers'),
+}
+
+// ── player ────────────────────────────────────────────────────────────────
+// The same list, on the authenticated tier. It exists so that per-player detail
+// can be added at an address clients are already calling; today the two answers
+// are identical and the server delegates to one model so they cannot drift.
+export const playerServers = {
+  list: () => req('/player/rust/servers'),
+}
+
+// ── admin ─────────────────────────────────────────────────────────────────
+// **`sidecarToken` goes up and never comes back.** The list answers `hasToken`,
+// and a save that omits the field leaves the stored credential alone — so an
+// admin form must send it only when the operator typed one, rather than sending
+// its own empty field on every save.
+export const admin = {
+  listServers: () => req('/admin/rust/servers'),
+  saveServer: (id, body) =>
+    req(`/admin/rust/servers/${encodeURIComponent(id)}`, { method: 'PUT', body }),
+  deleteServer: (id) =>
+    req(`/admin/rust/servers/${encodeURIComponent(id)}`, { method: 'DELETE' }),
+  testServer: (id) =>
+    req(`/admin/rust/servers/${encodeURIComponent(id)}/test`, { method: 'POST' }),
+}
+
+// Exported for the rare caller that needs the base itself — an `<img src>`, a
+// download link, an EventSource. Reach for `request` first.
+export { BASE }
+
+export default { servers, playerServers, admin, BASE }

client/src/core.js

@@ -0,0 +1,85 @@
+// ── What core hands this module, on the client side ────────────────────────
+//
+// The client twin of `server/core.js`, and deliberately much simpler than it.
+// Every page imports its layout, its state components and its hooks from here,
+// so the boundary is one file. The normative contract is MODULE_API.md §3.2 and
+// §3.4.
+//
+// **Why this is a plain read and the server's is a lazy accessor.** On the
+// server, `ctx` arrives at `register(ctx)` — after every `require` has already
+// run — so `server/core.js` has to defer resolution to call time or a router
+// would capture `undefined` at file scope. There is no such gap here.
+// `window.__rg` is published by core's own bundle (client/src/modules/shared.js),
+// and every module chunk is a deferred script the server injects *after* that
+// bundle's tag, so by the time the first line of this file executes the global
+// is already there. Reading it once, at module scope, is safe — and it means a
+// component keeps the ordinary `import { PageHeader } from '…'` shape rather
+// than being wrapped in an accessor that would cost it its identity.
+//
+// The absent-global case is handled by `shim/rg.js`, which every shim beside it
+// also goes through — the shims touch the global before this file does, so a
+// check here would be unreachable.
+
+import { createElement } from 'react'
+import { createRoot } from 'react-dom/client'
+import { Link } from 'react-router-dom'
+import { rg as shared } from './shim/rg.js'
+
+const rg = shared()
+
+// ── The shared-dependency self-check ───────────────────────────────────────
+//
+// Keep this. There are two BUILD guards on the same rule — `assertSharedNotBundled`
+// in vite.config.js at resolution time, and `scripts/checkExternals.js` on the
+// finished artifact — and both reason about the chunk in isolation. Neither can
+// see the one failure that only exists once the chunk meets a core: a
+// `window.__rg` whose React is not the React that rendered the page.
+//
+// Identity is the only question worth asking. A second React satisfies every
+// type check, renders its first element happily, and then throws about an invalid
+// hook call somewhere unrelated — in a component that has nothing to do with it.
+if (createElement !== rg.react.createElement || createRoot !== rg.reactDom.createRoot || Link !== rg.router.Link) {
+  console.error(
+    '[rust] the bindings this chunk imported are not the ones core published — it has bundled ' +
+    'its own copy of a shared dependency. Check the aliases in vite.config.js (MODULE_API.md §3.6).',
+  )
+}
+
+// The curated kit (§3.4). Nine exports, and it is CLOSED: layout, headings, the
+// three data-page states, the fetch hook, read-only access to the session and the
+// site's settings, and `Slot`. Anything else your pages need — tables, tabs, an
+// editor — you bundle yourself, in a `components/` directory of your own.
+//
+// `Slot` is the one that is not a widget. It renders a place THIS module declared
+// for core to fill (`entry.jsx`, and `routes/public/Clan.jsx` where two are used):
+// the inverted direction of the extension-slot mechanism, added in 1.6.0. It is in
+// the shared kit rather than reimplementable for the reason the whole kit exists —
+// a second error boundary with different behaviour would be a second bug, and what
+// this one contains is CORE's content failing inside YOUR page.
+//
+// Closed is a real constraint and it is the price of the boundary being worth
+// anything: adding a member is a minor `MODULE_API_VERSION` bump, and changing an
+// existing prop on a kit component is a major one. Use them, though. A module page that
+// ships its own layout is a page that stops looking like the site it is installed
+// in, and drifts further every time core changes.
+export const {
+  PublicLayout,
+  PageHeader,
+  Loading,
+  ErrorState,
+  EmptyState,
+  useAsync,
+  useAuth,
+  useSite,
+  Slot,
+} = rg.ui
+
+// The registry, for entry.jsx. Everything else here is read by pages.
+export const registry = rg.registry
+
+// The core API version this module was loaded against. Logged by entry.jsx —
+// `module.json`'s `coreApi` range is checked by the loader before this file is
+// ever served, so there is nothing to re-check, only something to report.
+export const coreApiVersion = rg.version
+
+export default rg

client/src/entry.jsx

@@ -0,0 +1,78 @@
+// ── The client entry point ────────────────────────────────────────────────
+//
+// Core serves `dist/entry.js` from this module's directory and injects it into
+// its own HTML as a same-origin `<script type="module" src>` before `</body>`.
+// This file registers what the module has; core renders it. Normative:
+// MODULE_API.md §3.3.
+//
+// **Registration is synchronous and happens at evaluation time.** Module scripts
+// are deferred, so this runs after core's bundle — which is where `window.__rg`
+// is published — and before core's first render. There is no subscription and no
+// late registration: a module that registered asynchronously would register after
+// the route table had been read, and the symptom is a page that redirects home
+// with nothing logged anywhere.
+//
+// So everything below is a plain top-level call and every page is a STATIC
+// import. Lazy-loading the routes is the natural instinct for a chunk that grows,
+// and it is the one thing this seam cannot have.
+
+import { registry, coreApiVersion } from './core.js'
+
+import Servers from './routes/public/Servers.jsx'
+
+// The module id, exactly as `module.json` spells it. Core keys the registry by it
+// and prefixes every route path with it.
+const ID = 'rust'
+
+// ── Routes ────────────────────────────────────────────────────────────────
+//
+// Paths are relative to the module's namespace and core prefixes them. Whatever
+// is written here, a public route lands at `/<id>/<path>`, an admin route at
+// `/admin/<id>/<path>` and a player route at `/player/<id>/<path>`. A module
+// cannot write the segment its routes hang under, which is the point: two modules
+// installed side by side cannot collide, and an operator can see from a URL which
+// module served it.
+//
+// So this page is at `/rust/servers`.
+//
+// **Note what is NOT here: an auth wrapper.** `gate: { roles: [...] }` is
+// available and core applies it as its own `RoleGate`; supplying your own is not
+// possible, because the sidebar and the route table have to agree about who may
+// see what, and they only do if one thing decides.
+//
+// R8's landing page is the server list, and `/rust/servers/:id` hangs beneath it.
+// The detail route is a later phase's, and it is deliberately not stubbed here: a
+// registered route that renders nothing is a 200 with a blank page, which is
+// worse than the 404 an unregistered one gives.
+registry.registerRoutes(ID, {
+  public: [{ path: 'servers', element: <Servers /> }],
+})
+
+// ── Nav ───────────────────────────────────────────────────────────────────
+//
+// A registered row is an ORDINARY row from here on. It interleaves into core's
+// own navigation, and an operator can reorder it, relabel it or hide it from the
+// admin nav editor exactly as they can core's — because the interleave happens
+// before the override merge, and the override layer is keyed by `to`.
+//
+// Three fields worth knowing before you need them:
+//
+//   • `order` places the row among core's, which are keyed by their index. A row
+//     with NO order appends after them, rather than defaulting to 0 — otherwise
+//     "I didn't ask for a position" would mean "put me first".
+//   • `group` (admin sidebar) names an existing core group; an unknown name
+//     appends a new group at the end rather than dropping the row.
+//   • `icon` is a component, and core supplies no fallback. Public header rows
+//     carry no icons, so there is none here — but an admin or player row without
+//     one is the only row in its sidebar with no glyph, which reads as breakage.
+registry.registerNav(ID, {
+  area: 'public',
+  items: [{ label: 'Servers', to: '/rust/servers' }],
+})
+
+// `module.json`'s `coreApi` range was checked by the loader before this file was
+// ever served, so there is nothing to re-check here. Log it anyway: a mismatch
+// between the core that validated the manifest and the core that published this
+// global is otherwise invisible from the browser, which is where the client half
+// actually fails.
+console.info(`[${ID}] registered against core API ${coreApiVersion}`)

client/src/routes/public/Servers.jsx

@@ -0,0 +1,105 @@
+// ── The server list ───────────────────────────────────────────────────────
+//
+// An ordinary React component. Nothing about being inside a module changes how
+// you write one — the only differences are where React comes from (core, via the
+// aliases in `vite.config.js`, so the import below looks completely normal and is
+// not) and where the chrome comes from (`../../core.js`, the shared UI kit).
+//
+// **Render `PublicLayout` yourself.** Core wraps public routes in its maintenance
+// gate and nothing else, so a page that omits the layout renders bare — no
+// header, no footer, no site chrome — which looks like a bug and is the contract
+// (§3.3). Admin and player routes are the other way round: core wraps those.
+//
+// **And pass a `shell`.** The layout is the chrome; `shell` is the body — the
+// centred column, the vertical padding, and the thing that holds the footer at
+// the bottom of the viewport. Widths are 'narrow', 'mid' and 'wide'; name a
+// width, never a class, because the classes belong to core's stylesheet.
+//
+// This is the phase-1 version of the landing page R8 calls for. It lists servers
+// and links nowhere yet — `/rust/servers/:id` is the next phase's work — so it is
+// deliberately a table and not a design.
+
+import { EmptyState, ErrorState, Loading, PageHeader, PublicLayout, useAsync } from '../../core.js'
+import api from '../../api.js'
+
+// A relative time that does not need a date library. `Intl.RelativeTimeFormat`
+// is in every browser core supports, and one fewer dependency in the chunk is
+// one fewer thing an operator ships.
+const RELATIVE = new Intl.RelativeTimeFormat(undefined, { numeric: 'auto' })
+
+function ago(iso) {
+  if (!iso) return 'never'
+  const seconds = Math.round((new Date(iso).getTime() - Date.now()) / 1000)
+  const [unit, size] = Math.abs(seconds) < 3600 ? ['minute', 60] : ['hour', 3600]
+  return RELATIVE.format(Math.round(seconds / size), unit)
+}
+
+export default function Servers() {
+  // `useAsync` is core's fetch/loading/error hook, and the components below are
+  // its states. Using them rather than rolling your own is what makes a module
+  // page indistinguishable from a core one while it loads and while it fails.
+  const { data, loading, error } = useAsync(() => api.servers.list(), [])
+  const servers = data ? data.servers : []
+
+  return (
+    <PublicLayout shell="mid">
+      <PageHeader
+        // `lead`, not `subtitle`. PageHeader takes `eyebrow`, `title`, `lead` and
+        // `center`, and an unknown prop on a React component is silently dropped
+        // — so a page written with `subtitle` renders its title and nothing else,
+        // on a site where every core page has a line under its heading.
+        title="Servers"
+        lead="Every Rust server this community runs, as each one last reported itself"
+      />
+
+      {loading && <Loading />}
+      {error && <ErrorState error={error} />}
+
+      {/* An operator who has configured no servers is not an error and not an
+          empty game — it is an install that is not finished. Saying so beats a
+          blank page that looks like a failure. */}
+      {data && servers.length === 0 && (
+        <EmptyState
+          title="No servers yet"
+          message="An administrator adds a Rust server, and its sidecar, from the admin panel."
+        />
+      )}
+
+      {servers.length > 0 && (
+        <div style={{ display: 'grid', gap: '0.75rem' }}>
+          {servers.map((server) => (
+            <div
+              key={server.id}
+              style={{
+                display: 'flex',
+                justifyContent: 'space-between',
+                alignItems: 'baseline',
+                gap: '1rem',
+                padding: '0.75rem 0',
+                borderBottom: '1px solid rgba(128,128,128,0.25)',
+              }}
+            >
+              <div>
+                <strong>{server.name}</strong>
+                {server.level ? <span style={{ opacity: 0.7 }}> · {server.level}</span> : null}
+                <div style={{ opacity: 0.7, fontSize: '0.9em' }}>
+                  {/* `stale` is a first-class part of the answer rather than
+                      something the page infers from a timestamp. The server
+                      decides what counts as stale, because the server is what
+                      knows how often a sidecar is supposed to check in. */}
+                  Last reported {ago(server.updatedAt)}
+                  {server.stale ? ' — out of date, so it is shown as offline.' : '.'}
+                </div>
+              </div>
+              <div style={{ whiteSpace: 'nowrap' }}>
+                {server.online
+                  ? `${server.players}${server.maxPlayers ? ` / ${server.maxPlayers}` : ''} online`
+                  : 'Offline'}
+              </div>
+            </div>
+          ))}
+        </div>
+      )}
+    </PublicLayout>
+  )
+}

client/src/shim/jsx-runtime.js

@@ -0,0 +1,16 @@
+// `react/jsx-runtime`, from core.
+//
+// Every .jsx file this module compiles becomes imports from `react/jsx-runtime`
+// under the automatic runtime, which is the default the tooling assumes. Those
+// have to resolve to CORE's React like every other import — a second jsx runtime
+// bound to a second React is the same one-React violation as bundling `react`
+// itself, only harder to see, because it shows up as a hook dispatcher error in
+// a component that looks fine.
+
+import { rg } from './rg.js'
+
+const jsxRuntime = rg().jsxRuntime
+
+export const { jsx, jsxs, jsxDEV, Fragment } = jsxRuntime
+
+export default jsxRuntime.default ?? jsxRuntime

client/src/shim/react-dom.js

@@ -0,0 +1,14 @@
+// `react-dom/client`, from core.
+//
+// A module never calls `createRoot` — core owns the root and the module renders
+// inside it. This exists because a transitive import can still reach for
+// react-dom, and one that resolved to a bundled copy would put a second
+// renderer in the page.
+
+import { rg } from './rg.js'
+
+const reactDom = rg().reactDom
+
+export default reactDom.default ?? reactDom
+
+export const { createRoot, hydrateRoot, flushSync, createPortal } = reactDom

client/src/shim/react-router-dom.js

@@ -0,0 +1,32 @@
+// `react-router-dom`, from core.
+//
+// The sharpest of the four, because router state is not just a library — it is
+// one live navigation context. A module with its own copy would get a router
+// whose `useParams` returns nothing and whose `<Link>` navigates the browser
+// instead of the SPA, on a page that otherwise renders perfectly.
+
+import { rg } from './rg.js'
+
+const router = rg().router
+
+export default router.default ?? router
+
+export const {
+  BrowserRouter,
+  Link,
+  NavLink,
+  Navigate,
+  Outlet,
+  Route,
+  Routes,
+  createSearchParams,
+  generatePath,
+  matchPath,
+  useLocation,
+  useMatch,
+  useNavigate,
+  useOutletContext,
+  useParams,
+  useResolvedPath,
+  useSearchParams,
+} = router

client/src/shim/react.js

@@ -0,0 +1,50 @@
+// The shared React, taken from core rather than bundled.
+//
+// Why a shim file exists at all (MODULE_API.md §3.6, and the spike proved it the
+// hard way): Rollup's `external` alone emits a bare `import 'react'` into the
+// chunk, which the browser cannot resolve without an import map — and an import
+// map has to be an inline `<script type="importmap">`, which core's
+// `script-src 'self'` forbids. `output.globals` does not help either; it is
+// iife/umd only, and this is an ES module. So each shared dependency is aliased
+// to a two-line module that re-exports from the global core published before any
+// module chunk evaluated.
+//
+// The named re-exports are not decoration: `import { useState } from 'react'`
+// compiles to a named import, and a module with only a default export would fail
+// at link time in the browser with a message about the binding, not about this.
+
+import { rg } from './rg.js'
+
+const react = rg().react
+
+export default react.default ?? react
+
+export const {
+  Children,
+  Component,
+  Fragment,
+  StrictMode,
+  Suspense,
+  cloneElement,
+  createContext,
+  createElement,
+  forwardRef,
+  isValidElement,
+  lazy,
+  memo,
+  useCallback,
+  useContext,
+  useDebugValue,
+  useDeferredValue,
+  useEffect,
+  useId,
+  useImperativeHandle,
+  useInsertionEffect,
+  useLayoutEffect,
+  useMemo,
+  useReducer,
+  useRef,
+  useState,
+  useSyncExternalStore,
+  useTransition,
+} = react

client/src/shim/rg.js

@@ -0,0 +1,29 @@
+// The one place this module reads `window.__rg`, and the one place that says
+// something useful when it is not there.
+//
+// Every shim beside this file, and `src/core.js`, go through here. That is not
+// tidiness — it removes an ordering dependency that was genuinely fragile. ES
+// modules evaluate dependencies in the source order of their import statements,
+// so "put the friendly check in the file that is imported first" is a guarantee
+// that survives exactly until someone sorts the imports. Whichever module the
+// bundler happens to reach first, it reaches `window.__rg` through this.
+//
+// A missing global means core did not publish its shared dependencies before
+// this chunk evaluated: an injection or ordering fault in CORE (MODULE_API.md
+// §3.1), not a fault in this module. Without this, the first symptom is
+// "Cannot read properties of undefined (reading 'react')" thrown from a file
+// called react.js, which reads like the module bundled React wrong — the
+// opposite of what happened.
+export function rg() {
+  const shared = window.__rg
+  if (!shared) {
+    throw new Error(
+      '[rust] window.__rg is missing — core did not publish its shared dependencies before this ' +
+      'chunk evaluated. That is an injection or ordering fault in core (MODULE_API.md §3.1), not a ' +
+      'fault in this module.',
+    )
+  }
+  return shared
+}
+
+export default rg