A module is the entire game-specific half of a deployment, packaged: its routes, its screens, its database tables, its navigation rows and its slice of the API documentation. The core site holds accounts, Teams, the wiki, posts, moderation and the admin panel, and knows nothing about any game at all.
That division is not an aspiration bolted on afterwards. The Ultima Online support was extracted out of the site into a module, and every URL it had before the move it still has — which is the only version of this claim worth making.
What you get
Server routes, React screens, tables, nav rows and an OpenAPI fragment the site merges into its own spec. Nothing about it is a patch to the core site, so upgrading either half does not involve reconciling the other.
The client half ships prebuilt and the artifact is verified against a published checksum before anything is written to disk. Production runs an image you pulled; an operator who has to compile something has been handed a maintenance job.
A module whose declared interface version does not match is marked failed and the site starts without it — loudly, rather than half-loading. Disabling one closes its connections and stops its routes answering.
Uninstalling removes the module and keeps its tables, so reinstalling picks up exactly where it was. Destroying the data is a separate, opt-in choice made in its own dialog, and it says what it is about to do.
Installing
Which one you use is a question about your host, not about the module. All three end the same way: a restart, and the module's screens appear in the navigation.
{path.body}
{path.fits}
The worked example
The Ultima Online module, and the reference every module that follows is measured against. It is what turns a general-purpose community site into something that knows what a shard is — and it is the proof that the seam described on the architecture page is real, because the code on the far side of it was moved there rather than designed there.
The same list features expands, read from one file that is checked against the module's own manifest on every build.
The module talks to the sidecar beside your game server, not to the game. You deploy that side with the installer and paste four values into the admin panel; nothing here requires the game to exist, and with no server configured the site renders normally and shows it offline.
Its schema is applied by the site on every boot and its data is its own. The module declares which versions of the core interface it speaks — the site runs {' '}{platform.moduleApi} — and refuses to load against one it does not.
Versioned, tagged and published on its own cadence, independently of the site. Upgrading one does not mean upgrading the other, as long as the declared interface range still holds.
Writing your own
A four-chapter book on putting a different game on this platform — the module, the sidecar beside your game server, the plugin inside it — plus a template module that continuous integration builds against a pinned version of the core site, so the instructions cannot quietly stop working.
Because nobody outside this project has yet followed it to a working module, and that is the only test of a set of instructions that counts. The badge comes off when somebody does — that is the stated condition, not a mood, and it is written down so a future reader knows when to take it down.
Everything it teaches is real and in use. What is untested is whether it is sufficient: whether someone with no access to this project's context can get from an empty repository to a running module using it alone.