feat(template): a module that builds and loads — Phase 5 slice 1

The kit's `template/`: a complete, minimal Runic Gateway module a reader copies,
renames, and runs before reading a chapter. Slice 0 landed the workflow that runs
it; this is the tree that workflow was written against, so the `template` job
arms itself with no edit to the guard.

Installed into a real core it adds one public page at `/examplegame/status`, a nav
row pointing at it, one API route described in an OpenAPI fragment core merges,
one table created by an idempotent schema fragment and dropped by a purge file,
and both lifecycle hooks. That is deliberately less than a real module does; what
it is complete about is the shape — every seam used once, with the reasoning next
to it.

Four decisions, settled with the org lead:

1. **Public tier only, plus the lifecycle hooks.** §2.11.1 d1's "one public route",
   plus enough to show the whole vertical seam once. Admin and player tiers become
   worked examples quoted from module-uo in chapter 2 rather than two thirds of a
   tree the reader deletes on day one.
2. **The release workflow ships as a file, in BOTH flavours** — `.gitea/` and
   `.github/`. Neither runs where it sits (a workflow is only read from a
   repository root) and each arms itself when the reader's copy is its own repo.
   Packaging is the part of a module that cannot be guessed at, and the kit's
   audience is outside this org, so assuming Gitea would have been assuming our
   own deployment. Core installs from a URL and does not care where the release
   lives — only that the host is on the operator's `MODULE_SOURCE_HOSTS`.
3. **A rename checklist that CI verifies**, not a rename script. `template/README.md`
   carries the table; `scripts/checkRenameSites.js` holds it against the tree in
   both directions — an unlisted file that still carries the placeholder fails, and
   so does a listed file that no longer does. The second half is the one usually
   left out and the more valuable: a row that has stopped matching reads as
   instructions to edit something that is not there. Same rule core's identifier
   check follows about its own exemptions. It has its own ten-test suite, run by
   CI as `node --test`, because a check that has never been shown to fail is a
   check nobody knows the state of.
4. **A neutral invented game.** One deviation from the literal answer, forced by
   decision 3: the id is `examplegame`, not `example`. The checklist check is a
   text search, and `example` occurs in ordinary English ("for example") all over
   prose that is not a rename site — a placeholder that cannot occur by accident is
   what makes the check answerable instead of a source of false alarms someone
   learns to ignore.

**The pin moves to the 1.4.0 bump** (website `edge` 1b692bf), which is what
`template/module.json` declares as `coreApi`. Slice 0 pinned its parent, before
1.4.0 existed, so `checkCoreApi.js` arms for the first time here — it asserts
EQUALITY, and its failing on the next contract bump is the system working.

Also in CI: the client tests now run AFTER the build (two of them read the built
chunk and skip without one — run first, the job reports green while asking nothing
about the artifact that ships), and `check:swagger` verifies the committed
fragment is current.

## The finding: an UPDATE that changes nothing does not touch ON UPDATE CURRENT_TIMESTAMP

Every suite passed, both guards passed, the chunk built, the module loaded into a
real core and the page rendered correctly. Two hours later the same page said the
world was offline, and it was wrong.

`updated_at` was declared `ON UPDATE CURRENT_TIMESTAMP`, and MariaDB fires that
only when an UPDATE actually CHANGES a value. The boot refresh writes the same
numbers every thirty seconds — which is exactly what a quiet game looks like — so
the timestamp froze at the first write, the row crossed the freshness window, and
the model correctly reported a stale row as offline. Verified against the live
database: two hours of refreshes, `updated_at` still the boot timestamp.

No test in this repo could see it. The model takes its clock as an argument, and
nothing in a suite runs the same UPDATE twice against a real database. It is only
visible as a page that was right when you looked at it and wrong an hour later.

The writer now sets `updated_at = CURRENT_TIMESTAMP` explicitly and the column
drops the clause that was not doing what it looked like it was doing; both carry
the reasoning. Re-verified end to end: the timestamp advances every interval and
the API reports fresh.

Falling out of the fix, the schema fragment gained the rule the reader hits next:
**changing a table is an ALTER, never an edit to its CREATE** — `CREATE TABLE IF
NOT EXISTS` does nothing when the table exists, so an edited column definition
takes effect on a fresh install and on no existing one, which is the worst
possible split because your development database is usually the fresh one.

## Verified

- 29 server tests, 18 client tests, 10 kit-script tests; `check:imports`,
  `check:externals`, `check:swagger` and `checkCoreApi` all green, run in CI's own
  order from a clean `npm ci`.
- Browser smoke (MODULE_API.md §7.7) against a real core built from the pinned
  ref: module `started`, published on `/api/v1/public/modules`, chunk served
  `no-cache` with the right MIME from the entry's directory while `module.json`
  and the server source 404, script tag injected after core's bundle, the page
  rendering inside core's own chrome, the nav row interleaved into the public
  header between Wiki and About, SPA navigation into it from another page, the
  module's path and schema and tag merged into `/api/docs.json`, and
  `[examplegame] registered against core API 1.4.0` in the console with no CSP
  report and no React error.

Refs: MODULE_SYSTEM.md §2.11.1 (slice 1), MODULE_API.md §2.x, §3.x, §5.1, §7.7.

Co-Authored-By: Claude <noreply@anthropic.com>

template/client/vite.config.js

@@ -0,0 +1,137 @@
+// ── The client half's library build ────────────────────────────────────────
+//
+// Produces `dist/entry.js`: one prebuilt ES module that core injects as a
+// same-origin `<script type="module" src>` before `</body>`. The operator never
+// builds anything (MODULE_SYSTEM.md §1.14), so this config is not a developer
+// convenience — it is how the artifact that ships is made, and CI runs it.
+//
+// The normative contract is MODULE_API.md §3.6. Three mechanical details in here
+// were each found the hard way and are worth reading before changing anything.
+//
+// **1. `resolve.alias` uses the ARRAY form with anchored regexes.** Vite's object
+// form does PREFIX matching, so a `react` key also rewrites `react/jsx-runtime`
+// — silently, to the wrong shim, and the chunk then fails at its first element
+// with a message about `jsx` not being a function. `^react$` and
+// `^react/jsx-runtime$` cannot collide.
+//
+// **2. The aliases replace `external`; they do not accompany it.** §3.6 shows
+// both, and they do not compose: Rollup asks `external` BEFORE Vite's alias
+// resolver runs, so a specifier listed there is marked external and never
+// aliased. The chunk then ships bare `import 'react'` specifiers, which the
+// browser cannot resolve without an import map — and core's `script-src 'self'`
+// forbids the inline script an import map has to be. (`output.globals` would
+// have covered iife/umd and does nothing for an ES module.) The first real module
+// shipped with both, built cleanly, and emitted exactly that chunk;
+// `scripts/checkExternals.js` is what caught it. So: alias only, and nothing in
+// `external`.
+//
+// **3. What `external` was there to guard is guarded by `assertSharedNotBundled`
+// below.** The risk it was covering is real — an alias that misses means a
+// second React welded into the chunk, which loads fine and then throws about an
+// invalid hook call somewhere unrelated. A resolution-time assertion catches
+// that precisely, at build time, instead of by looking for fingerprints in
+// minified output afterwards.
+
+import { defineConfig } from 'vite'
+import react from '@vitejs/plugin-react'
+import { fileURLToPath } from 'node:url'
+
+const shim = (name) => fileURLToPath(new URL(`./src/shim/${name}.js`, import.meta.url))
+
+// The shared dependencies, in one place: what a module must never bundle, and
+// the shim it is aliased to instead. Adding to this list means adding to
+// `window.__rg` in core, which is a MODULE_API minor bump — not a decision this
+// file can make on its own.
+export const SHARED = [
+  { specifier: 'react', shim: 'react' },
+  { specifier: 'react/jsx-runtime', shim: 'jsx-runtime' },
+  // A production `vite build` emits the non-dev runtime, but the plugin picks
+  // per mode and a `--mode development` build would reach for this one. Aliased
+  // rather than left to chance: the shim re-exports `jsxDEV` too.
+  { specifier: 'react/jsx-dev-runtime', shim: 'jsx-runtime' },
+  { specifier: 'react-dom', shim: 'react-dom' },
+  { specifier: 'react-dom/client', shim: 'react-dom' },
+  { specifier: 'react-router-dom', shim: 'react-router-dom' },
+]
+
+// The packages whose real source must never end up in the chunk.
+//
+// Stated independently of SHARED, and that is the whole point — an earlier
+// version derived this from the alias list "so the two cannot disagree", which
+// meant deleting an alias also deleted the guard against the thing that alias
+// prevented. The guard then reported nothing on a chunk with react-router welded
+// into it. What may not be bundled is a fact about core's `window.__rg`, not a
+// function of what this config happens to alias; `test/build.test.js` asserts
+// every SHARED specifier is covered here, which is the direction the dependency
+// belongs in.
+//
+// `react-router` and `@remix-run/router` are react-router-dom's own internals.
+// They cannot appear while the alias holds — nothing resolves through to them —
+// so naming them costs nothing and closes the case where a module imports one
+// directly and gets a second navigation context in a page that otherwise works.
+export const SHARED_PACKAGES = ['react', 'react-dom', 'react-router-dom', 'react-router', '@remix-run/router']
+
+/**
+ * Fail the build if a shared dependency's real source is about to be bundled.
+ *
+ * This is the safety net, and it is a resolution-time one on purpose. The
+ * alternative — grepping the built chunk for a fingerprint — has to guess at
+ * strings that survive minification, and guesses at that are how a check ends up
+ * passing on a chunk that carries a second React. Here there is nothing to
+ * guess: if a module id resolved into `node_modules/react`, an alias missed, and
+ * the alias that missed is named in the error.
+ *
+ * It hooks `transform` rather than `load`, and that is not interchangeable:
+ * `load` is FIRST-WINS, so an earlier plugin returning the module's contents
+ * means this hook is never called for it. Written against `load` this guard sat
+ * in the build doing nothing, and a deliberately-broken alias produced a 24 kB
+ * chunk with react-router welded into it and a green build — which is the exact
+ * failure it exists to prevent. `transform` runs for every module, every time.
+ */
+function assertSharedNotBundled() {
+  return {
+    name: 'examplegame:assert-shared-not-bundled',
+    enforce: 'post',
+    transform(code, id) {
+      const normalised = id.split('\\').join('/')
+      const hit = SHARED_PACKAGES.find((pkg) => normalised.includes(`/node_modules/${pkg}/`))
+      if (hit) {
+        this.error(
+          `"${hit}" resolved into node_modules (${normalised}). It must be aliased to a shim that ` +
+          're-exports from window.__rg — there is exactly one React in the page and core owns it ' +
+          '(MODULE_API.md §3.2, §3.6). Check resolve.alias in vite.config.js.',
+        )
+      }
+      return null
+    },
+  }
+}
+
+export default defineConfig({
+  plugins: [react(), assertSharedNotBundled()],
+  resolve: {
+    alias: SHARED.map(({ specifier, shim: name }) => ({
+      find: new RegExp(`^${specifier.replace(/[/\\^$*+?.()|[\]{}]/g, '\\$&')}$`),
+      replacement: shim(name),
+    })),
+  },
+  build: {
+    lib: {
+      entry: fileURLToPath(new URL('./src/entry.jsx', import.meta.url)),
+      formats: ['es'],
+      // Unhashed, deliberately: `module.json` names this file, and a hashed name
+      // would have to be discovered at runtime. Core answers the cache question
+      // instead, serving it `no-cache` so a revalidation catches a new build
+      // (MODULE_API.md §3.1).
+      fileName: () => 'entry.js',
+    },
+    outDir: 'dist',
+    emptyOutDir: true,
+    // No inline bootstrap, for the same reason core disables it: an inline
+    // script is refused under `script-src 'self'`, and the failure is a chunk
+    // that never evaluates with a CSP report as the only clue.
+    modulePreload: { polyfill: false },
+    // `rollupOptions.external` is deliberately EMPTY — see note 2 at the top.
+    rollupOptions: { external: [] },
+  },
+})