chore(modules): declare the UO module for the UOMysticmoon instance #149

wtclaude · 2026-08-12T22:57:16Z

wtclaude commented

2026-08-12 22:57:16 +00:00

Cutover prep. Lands on edge so the edge → main cutover carries it.

Why

The cutover puts a game-agnostic core on main, so the image UOMysticmoon deploys stops carrying any UO code of its own. Everything that instance is actually for — the shard pages, the player's characters, vendors and houses, Admin → Shard, and the uo-link connection itself — arrives as RunicGateway/Module-uo or does not arrive at all.

Declaring it in the tenant template (rather than leaving it to Admin → Modules) is decision 2 of the cutover: a compose host should arrive at its own module set at boot, and this instance has a shard to be down for. The panel path would leave the site game-less between the image roll and someone clicking install.

What

One block in .env.uomysticmoon.example, beside the other values that pin this instance to production:

MODULES=uo@0.3.0=https://gitea.whitlocktech.com/RunicGateway/Module-uo/releases/download/v0.3.0/module-uo-0.3.0.json

plus a commented note that UOLINK_* are defaults only — an instance that has already saved Admin → Shard keeps its encrypted uo_link_config row across the extraction, because the module's schema fragment is CREATE TABLE IF NOT EXISTS.

No new machinery. MODULES and its no-op-without-network behaviour shipped in phase 4 slice 3; MODULE_SOURCE_HOSTS already defaults to the host this URL names; core's .env.example documents the variable and deliberately leaves it commented. Only the tenant template is opinionated, which is exactly the split the module system exists to make.

Verified rather than assumed

The declared manifest resolves anonymously — 200, valid content, sha256 present. The production container has no Gitea credentials, so this is the thing that had to be checked, and the tarball is anonymous too.
coreApi is ^1.3.0, satisfied by core's MODULE_API_VERSION 1.5.0.
Read the boot path rather than trusting the state names: a fresh row lands installed, and lifecycle.boot() only skips a module whose row is explicitly disabled — so a first boot with this declared starts the module, with no manual Enable.

What this does NOT do

It does not touch the live host. The deploy .env on the production host needs the same line added by hand at the deploy — that file is not in this repo and I cannot reach it.

Risk

Documentation-only in effect: no code, no schema, no route change. .env.uomysticmoon.example is a template nothing reads at runtime.

🤖 AI-assisted: written with Claude Code (Claude Opus 5).

Cutover prep. Lands on `edge` so the `edge` → `main` cutover carries it. ## Why The cutover puts a **game-agnostic core** on `main`, so the image UOMysticmoon deploys stops carrying any UO code of its own. Everything that instance is actually for — the shard pages, the player's characters, vendors and houses, Admin → Shard, and the uo-link connection itself — arrives as `RunicGateway/Module-uo` or does not arrive at all. Declaring it in the tenant template (rather than leaving it to Admin → Modules) is decision 2 of the cutover: a compose host should arrive at its own module set at boot, and this instance has a shard to be down for. The panel path would leave the site game-less between the image roll and someone clicking install. ## What One block in `.env.uomysticmoon.example`, beside the other values that pin this instance to production: ``` MODULES=uo@0.3.0=https://gitea.whitlocktech.com/RunicGateway/Module-uo/releases/download/v0.3.0/module-uo-0.3.0.json ``` plus a commented note that `UOLINK_*` are defaults only — an instance that has already saved Admin → Shard keeps its encrypted `uo_link_config` row across the extraction, because the module's schema fragment is `CREATE TABLE IF NOT EXISTS`. **No new machinery.** `MODULES` and its no-op-without-network behaviour shipped in phase 4 slice 3; `MODULE_SOURCE_HOSTS` already defaults to the host this URL names; core's `.env.example` documents the variable and deliberately leaves it commented. Only the *tenant* template is opinionated, which is exactly the split the module system exists to make. ## Verified rather than assumed - The declared manifest resolves **anonymously** — `200`, valid content, `sha256` present. The production container has no Gitea credentials, so this is the thing that had to be checked, and the tarball is anonymous too. - `coreApi` is `^1.3.0`, satisfied by core's `MODULE_API_VERSION` **1.5.0**. - Read the boot path rather than trusting the state names: a fresh row lands `installed`, and `lifecycle.boot()` only skips a module whose row is explicitly `disabled` — so a first boot with this declared **starts** the module, with no manual Enable. ## What this does NOT do It does not touch the live host. The deploy `.env` on the production host needs the same line added by hand at the deploy — that file is not in this repo and I cannot reach it. ## Risk Documentation-only in effect: no code, no schema, no route change. `.env.uomysticmoon.example` is a template nothing reads at runtime. --- 🤖 AI-assisted: written with Claude Code (Claude Opus 5).

wtclaude added 1 commit 2026-08-12 22:57:18 +00:00

chore(modules): declare the UO module for the UOMysticmoon instance

PR Checks / bot-install (pull_request) Successful in 18s

Details

PR Checks / client-build (pull_request) Successful in 27s

Details

PR Checks / server-tests (pull_request) Successful in 31s

Details

953d0c25f6

The module-system cutover puts a game-agnostic core on `main`, so the image
UOMysticmoon deploys stops carrying any UO code of its own. Everything that
instance is actually for — the shard pages, the player's characters, vendors and
houses, Admin -> Shard and the uo-link connection — arrives as RunicGateway/Module-uo
or does not arrive at all.

Declare it in the tenant template, next to the other values that pin this
instance to production, so an operator copying the file gets a working shard
rather than a working site with no game on it. The compose host resolves the set
itself at boot (MODULE_SYSTEM.md 2.7.2 decision 4), which is what keeps the site
from being game-less between the image roll and someone clicking install in
Admin -> Modules.

Nothing here is new machinery: MODULES and its no-op-without-network behaviour
shipped in phase 4 slice 3, MODULE_SOURCE_HOSTS already defaults to the host
this URL names, and core's .env.example documents the variable and deliberately
leaves it commented out. Only this instance's template is opinionated, which is
the split the module system exists to make.

Verified the declared manifest resolves anonymously (200, coreApi ^1.3.0 against
core's MODULE_API_VERSION 1.5.0) — the container fetches it with no credentials.

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

whitlocktech merged commit 3669696532 into edge

2026-08-12 22:57:44 +00:00

whitlocktech referenced this issue from a commit

2026-08-12 22:57:45 +00:00

Merge pull request 'chore(modules): declare the UO module for the UOMysticmoon instance' (#149) from chore/declare-uo-module-for-uomm into edge

whitlocktech deleted branch chore/declare-uo-module-for-uomm

2026-08-12 22:57:45 +00:00

wtclaude referenced this pull request

2026-08-12 23:00:40 +00:00

feat(modules)!: the module system cutover — a game-agnostic core reaches main #150

Sign in to join this conversation.