The kit was pinned to website 963d734 -- MODULE_API 1.6.0, the Teams cutover --
and the platform is on 1.9.0. Three registrations and two calls arrived in
between, and a reader building against this book would have found no mention of
any of them: a module can now declare what its game can announce, and never who
is told.
Moving `ci/core-ref.json` is the mechanism for exactly this. The pin is now
66bb3b9a (website `main`, the engagement cutover) and `template/module.json`
declares `^1.9.0`.
What chapter 2 gained, under "Telling core something happened":
* a TRIGGER is a payload contract, not a notification stream -- the two share
one id namespace and are constantly confused;
* `ceiling` is required, has no default, and is a CONTAINMENT tree rather than
a size ladder (a `staff` ceiling does not permit `owner`);
* an AUDIENCE resolver returns user ids and nothing else, resolves to NOBODY
on failure, and takes CONSTANT params -- the constraint worth knowing before
you design around it;
* templates re-ensure per seedVersion, rule groups are offered ONCE per group
key, so a rule appended to an existing group reaches fresh installs only;
* `ctx.events.emit` binds the owner and is fire-and-forget; `ctx.inbox.push`
is the direct write, for when there is nothing for an operator to decide.
The template builds all of it: one trigger, one audience over the clan roster it
already had, one seeded body and one seeded rule group, and an emitter in
`boot.js` that fires on the TRANSITION rather than on the poll. Seven new tests,
including the audience that resolves to nobody when its query throws.
Three claims were wrong and are corrected here rather than shipped:
* core validates `subjectKey` against the declared variables and refuses the
module; the draft taught a cooldown keyed on `undefined`, which the check
exists to prevent and a reader will never see.
* `emit` throws OUTSIDE production and only drops-and-logs inside it. Teaching
the second half alone leaves a developer meeting a throw the book says
cannot happen.
* the seeded body itself was malformed -- heading `level: 2` where the block
registry takes 'h2', and no block ids at all.
The third is the one worth keeping: `registerEngagementSeeds` checks that
`blocks` is a non-empty array and stops, so that body would have registered,
seeded, and failed the first time an operator opened it. Found by running the
template's `register()` through core's real registry at the pinned ref -- which
CI does not do, and cannot: the template job checks the version and runs the
template against fakes. A fake accepts what core refuses. The gap is now named
in the chapter, beside the code, and in the pin's own comment, and the rule that
bit has a test that fails on it.
Also: `checkLinks` skipped `.core/`. Bumping this pin means cloning core into
that directory first, and the walk then reported nine broken links in someone
else's README. CI never saw it -- the clone happens in the `template` job and
the check runs in `prose` -- so it was a failure only a person could meet.
Co-Authored-By: Claude <noreply@anthropic.com>
The template module
A Runic Gateway module that builds, loads, and does almost nothing. Copy it, rename it, and you have a running module before you have read a chapter.
Installed into a core, it adds:
- three public pages —
/examplegame/status,/examplegame/clansand one clan at/examplegame/clans/:externalId— and nav rows pointing at the first two; - three API routes under
/api/v1/public/worldand/api/v1/public/clans, described in an OpenAPI fragment core merges into its own/api/docs; - three tables, prefixed
examplegame_, created by an idempotent schema fragment and dropped by a purge file; - a Team provider, which makes this module the authoritative source of Teams for the deployment — the one registration where core calls YOU and waits;
- three inverted extension slots, declared by this module on the clan page for core to fill;
- both lifecycle hooks, so there is something to see at boot and at shutdown.
That is deliberately less than your module will do. What it is complete about is the shape: every seam a real module uses is here once, with the reasoning next to it, and CI proves the whole thing still builds against a pinned core.
The tree
module.json what core reads first — id, version, coreApi, mounts
server/
index.js register(ctx, api) — the entire server-side handshake
core.js the lazy accessors over ctx; read this second
boot.js onBoot / onShutdown
db/schema.sql idempotent, replayed every boot
db/purge.sql destructive, run only by an explicit admin purge
model/worldStatus/ the .db.js / .model.js pair
model/clans/ the Team provider, its SQL, and the audience rule
router/public/ two routers, two controllers, the #swagger annotations
swagger/doc.js tags and schemas the annotations refer to
scripts/checkImports.js the module boundary, enforced
scripts/swaggerFragment.js generates swagger-fragment.json from your own routes
test/ the suites — start with entry.test.js
client/
vite.config.js the library build: anchored aliases, external: []
src/entry.jsx registers routes, nav and declared slots at evaluation time
src/core.js what core hands you: the UI kit (nine exports)
src/shim/ the four shared dependencies, re-exported from core
src/routes/public/ the pages — Clan.jsx is the one with slots in it
scripts/checkExternals.js asks the BUILT chunk whether a bare import survived
test/ build.test.js and registration.test.js
.gitea/workflows/release.yml packaging CI — Gitea
.github/workflows/release.yml the same, for GitHub. Keep one, delete the other.
swagger-fragment.json generated; commit it
Neither workflow runs while it sits inside the kit — a workflow is only read from a repository root. They arm themselves when your copy is a repository of its own.
Build it
npm ci --prefix server
npm test --prefix server
npm run check:imports --prefix server
npm ci --prefix client
npm run build --prefix client # → client/dist/entry.js, the chunk that ships
npm run check:externals --prefix client
npm test --prefix client # build FIRST: two of these tests read the chunk
npm test in client/ passes with no build, by skipping the tests that need one.
That is on purpose — the suite has to be runnable before the build — and it means
a CI job that tests without building is a job asking nothing. Build first.
Regenerate the OpenAPI fragment whenever a route or an annotation changes:
npm run swagger --prefix server # writes swagger-fragment.json
npm run check:swagger --prefix server # fails if it is stale
Install it
Three supported ways, and none of them builds anything on the operator's machine:
- Admin → Modules, pasting the URL of an install manifest — the JSON the release workflow attaches beside the tarball. This is how an operator installs your module.
- The
MODULESenvironment variable,<id>@<version>=<manifest URL>, for a deployment that declares its module set rather than clicking it. - A directory on the volume. Copy this whole tree to
<website>/modules/<id>/and restart. The fastest loop while you are developing.
For (3): copy, do not symlink. The loader lists directory entries and a symlink is not a directory, so a linked module is skipped in silence.
Rename it
Change id in module.json first, then work down the list. Nothing here is
subtle, and the suites catch most of a half-finished job: schema.test.js fails
the moment a table name stops matching the id, and registration.test.js fails
when a nav row stops matching its route.
Your id must match ^[a-z][a-z0-9-]{1,31}$, must equal the directory name core
loads you from, and becomes your table prefix — so no hyphen unless you enjoy
backticking table names.
| File | What to change |
|---|---|
module.json |
id, name, version, the mounts prefix, capabilities |
.gitea/workflows/release.yml |
GITEA_HOST and REPO, under the # CHANGE THESE banner — the only two, and they are wrong until you do. (The .github/ flavour needs nothing: GitHub supplies GITHUB_REPOSITORY and friends.) |
server/package.json |
package name and description |
server/core.js |
the message every accessor throws |
server/index.js |
the trigger, audience, template and rule-group ids — all four are namespaced with your module id, and core refuses them otherwise |
server/boot.js |
the placeholder world name |
server/db/schema.sql |
every table name — the prefix must be your id |
server/db/purge.sql |
the same table names |
server/model/worldStatus/worldStatus.db.js |
the TABLE constant |
server/model/clans/clanProvider.db.js |
the CLANS and MEMBERS table constants |
server/model/clans/clanProvider.model.js |
pageUrlTemplate — it must match the route client/src/entry.jsx registers |
server/router/public/world.router.js |
the #swagger.tags name |
server/router/public/clans.router.js |
the #swagger.tags name |
server/swagger/doc.js |
the tag, and the Examplegame… schema prefix |
server/scripts/swaggerFragment.js |
the generated fragment's info.title |
server/test/_fakes.js |
ctx.moduleId |
server/test/entry.test.js |
the trigger id the world-status test asserts |
server/test/worldStatus.test.js |
the fixture's world name |
server/test/clanProvider.test.js |
the fixture's world name |
server/package-lock.json |
regenerated — npm install --prefix server |
client/package.json |
package name and description |
client/vite.config.js |
the guard plugin's name |
client/src/core.js |
the console tag on the identity check |
client/src/shim/rg.js |
the console tag on the missing-global error |
client/src/entry.jsx |
ID, every route path and nav to, and the three declareModuleSlot names — core enforces that a slot is namespaced under your id |
client/src/routes/public/Clans.jsx |
the link to the clan page |
client/src/routes/public/Clan.jsx |
the three <Slot name> values and their moduleId |
client/test/registration.test.js |
the example path in the comment |
client/package-lock.json |
regenerated — npm install --prefix client |
swagger-fragment.json |
regenerated — npm run swagger --prefix server |
That table is checked. scripts/checkRenameSites.js at the root of this kit
compares it against the tree on every pull request: a file that still mentions the
placeholder and is not listed fails the build, and so does a listed file with
nothing left to rename. A checklist nobody verifies is a checklist that is wrong
by the second edit.
Two things you do not rename: the mount prefixes /world and /clans need
not be your id (the server's prefix namespace is shared with core's — /status,
/settings, /version, /contact and /teams are already taken, which is why
the clan router is not mounted at the obvious name), and the world / clan
naming throughout is ordinary vocabulary you should replace with your own domain's
when you replace the feature. clan in particular is the point rather than the
placeholder: core's word is Team, yours is whatever your game says, and the
provider exists because core cannot pick one.
Licence
GPL-3.0-or-later, like everything else in this project — see LICENSE.md. This directory is meant to be copied and made yours; it carries that licence, and so does anything derived from it.