Phase 16c of the events plan. The landing page is updated when the shape of the
project changes, and a subsystem that lets staff schedule an unattended change to
a live game world is one.
* **A new bullet in "How they fit together"**, beside the engagement one it sits
next to: an event is written once as phases and steps, published as an
immutable version and executed unattended. What matters on a front page is the
posture rather than the feature list — everything arrives switched off, caps are
enforced in the database rather than in a role check, cleanup is generated from
a ledger rather than authored, and an event does not edit the world but holds a
**lease** the game restores on its own deadline even if the site never speaks to
it again. The game keeps its own switch, separate from the staff write plane.
* **Protocol 5 → 7** in the four values the installer prints. That block is what a
reader copies into Admin → Shard, so a stale number there is the one that costs
somebody an afternoon.
* **module-uo v1.1.0 → v1.2.2** in the manifest URL and the `MODULES=` line.
* `docs/website/EVENTS.md` added to "Where to go next".
Verified against the platform rather than assumed: the protocol number is
`link/sidecar/src/main.rs` and `servuo-plugins/overlay.toml` on `main`, and
v1.2.2 is the current Module-uo release, whose own notes name
`module-uo-1.2.2.json` as the manifest to paste.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4
The engagement cutover landed on 2026-09-01 and three things on this page stopped
being true with it.
The capability itself is the reason for the change: the site now talks to its
players, and an operator decides when. It is a headline capability by the org
lead's call, which is the condition ENGAGEMENT.md Phase 13 step 8 attaches to
touching this file at all -- a landing page that lists every feature is a landing
page nobody reads.
The bullet leads with the operator rather than the mechanism, and names the one
property that is a security boundary rather than a feature: a trigger declares
the widest audience a rule may ever be given, so a sensitive game event cannot be
mailed to everyone by a misconfiguration.
The other two are cutover outputs and would mislead an operator directly:
* the installer's sample output prints "Protocol version 4"; the paired bundle
is 2026.09.01 and the wire is 5.
* the quick start pins module-uo v1.0.1 in both the manifest URL and the
MODULES= line; v1.1.0 is the release that carries the shard triggers.
Co-Authored-By: Claude <noreply@anthropic.com>
The landing page is the project's front door, and both of its
copy-pasteable values were stale.
The installer handoff block printed "Protocol version 3". That block
exists to be typed into Admin -> Shard, and protocol 4 shipped on
2026-08-19 as sidecar v2.0.0 and overlay v1.0.0. A stale number there
comes back from the sidecar as a 409, which INSTALL.md's own
troubleshooting table notes "looks exactly like your shard going
offline".
The module quick start still pointed at the v0.3.0 install manifest and
MODULES=uo@0.3.0. module-uo is on v1.0.1; asset names verified against
the release.
Co-Authored-By: Claude <noreply@anthropic.com>
The quick start carried a caveat telling a visitor that the Modules screen it
had just described was not on `main` yet, and that a checkout served the Ultima
Online features from core directly. The cutover merged on 2026-08-12
(website#150), so both halves of that are now false and the caveat contradicts
the page around it.
Replaced rather than deleted: a reader who saw the old note deserves to know it
resolved, and the sentence that replaces it is the one fact the front page owes
about the change - a `main` checkout is a game-agnostic core, and Ultima Online
arrives as the module the section above tells you to install.
Nothing else on the page needed touching. It was written describing the module
system as the shape of the project rather than as work in progress, which is
what left exactly one paragraph to retire.
Co-Authored-By: Claude <noreply@anthropic.com>
The org landing page still opened with "A website + game bridge for private
Ultima Online (ServUO) shards" and listed six repositories. The module system
made the first untrue and Phase 5 made the second wrong by two: Module-uo and
Integration-kit.
Reframed rather than patched. Runic Gateway is a website platform for game
communities that knows nothing about any particular game; everything
game-specific arrives as an installable module, and Ultima Online is the first
one. The repo table splits accordingly — the platform (website, Android-app,
docs, Integration-kit) and UO support (Module-uo, link, servuo-plugins,
installer) — and "How they fit together" now leads with the three layers any
game needs (plugin, sidecar, module) before the UO specifics, including the rule
that the website process never opens a connection to a game server.
Quick start gains step 2: install a module. Paste a release's install-manifest
URL into Admin -> Modules, or declare MODULES=<id>@<version>=<url> on a
compose-managed host. Both were checked against server/.env.example rather than
written from memory.
One honest blockquote says the module system lives on the website's `edge`
branch until the cutover, so nobody clones `main` looking for a Modules screen
that is not there yet.
Co-Authored-By: Claude <noreply@anthropic.com>
Last touched 2026-07-23, before the installer repo existed.
- Six repos, not five: add installer to the table.
- Quick start: steps 2 (cargo build the sidecar) and 3 (see the plugin
repo for deploy steps) collapse into one installer run, which is how a
shard is actually set up now. The by-hand path is kept as a note.
- Day-two commands and the note that the installer does not install
itself, so nobody looks for `runicgateway` on PATH.
- Mention what shipped since: the player-vendor marketplace, the spawn
atlas, the admin-configurable shard visibility framework, and the
account-security layer (TOTP + trusted devices, link-only SSO, bot
scoring).
- "Where to go next" leads with INSTALL.md; the link and servuo-plugins
entry is now about working on them rather than deploying them.
Verified rather than assumed: JDK 17 and min SDK 29 still match
app/build.gradle.kts, and Node 20+ still matches the website README and
its Dockerfile.
Co-Authored-By: Claude <noreply@anthropic.com>
Re-commit the org profile as plain markdown. The prior commit passed
pre-encoded content, which the API base64-encoded a second time and
rendered as gibberish.
Co-Authored-By: Claude <noreply@anthropic.com>
Weave the native Android client through the profile README: fifth row in
the pieces table, a second client branch in the architecture diagram, a
"how it fits" note (API-only client, self-configuring URL, ntfy push, no
Play Services), a Quick start section, a where-to-go-next pointer, and a
CI badge.
Co-Authored-By: Claude <noreply@anthropic.com>
