wtclaude
07512d846d
The docs half of Event System Phase 8. Code: RunicGateway/website#NNN.
EVENTS.md
Section D's ledger row is corrected in two places and section L gains a new
subsection recording what the build settled:
- Rule 1 needed a mechanism, because a spawn's ref does not exist until the
module answers. What goes in before the dispatch is a PLACEHOLDER keyed by the
step's idempotency key, and that is why revert() takes the key at all.
- A LEASE does not use it and gets rule 1 in a stronger form: its target is the
lease id the step already names, so `core.lease` writes the real row first --
the only moment the two-events-one-target refusal can happen before the world
has been written to.
- The unique key is held by three statuses and released by three (amended
2026-09-03). "Among non-reverted rows" was written before the six statuses had
their meanings; taken literally it makes `drifted` and `orphaned` hold a target
for ever, so one bad night would disable a lease permanently with no control
able to clear it.
- MariaDB has no partial index, so the encoding is a STORED generated column
reading `status` ALONE -- TEAMS.md 2.5's correction, because MariaDB refuses
ON DELETE SET NULL on a foreign key whose column is a base column of one.
- Cleanup is one sweep, not synthetic step rows, and it runs from one place.
- What that sweep SELECTS cost two live-walk defects in opposite directions, and
the pair is the finding worth keeping: deriving "is there anything to do" from
a summary column instead of from the rows stranded a lease outright, and then
made the retry bound mean one attempt. Both are recorded with the reasoning.
Section F gains the lease's verb and the reconcile bullet; section I's "cancel
takes { reason } and not { cleanup }" becomes what shipped; section K's role
table puts re-running cleanup in the admin-only row; section L's cancel and
cleanup-fails rows are updated; Observability names the six new log kinds; and
the API surface table's absent-routes list is now empty.
EVENTS_PLAN.md
Phase 8 marked complete in the shape Phases 0-7 use: the four org-lead
decisions, the four things the build settled, the verified numbers, and the live
walk -- including the three defects only it could find and the two properties
that needed the process to die.
MODULE_API.md
1.10.0 gains `reconcile()` and `ctx.events.reconcile()` IN PLACE rather than a
new version. A protocol owes a bump once it has landed on `main`; while it is on
`edge` it is amended in place, which is the rule the Teams workstream arrived
at, applied to a module API for the first time. The rule list grows from six to
ten: the lease's verb is core's, `until` goes down the wire, revert is
idempotent and reverting something that does not exist is a success, revert is
also called with the key and an empty list, and reconcile is optional where
revert is required.
Checked by hand
`docs` has no CI, so: every anchor in EVENTS.md resolves (checked by generating
the heading slugs and diffing), and every route, identifier, env var and file
path named here exists on the website branch -- `core.lease`,
`core.options.leases`, `ctx.events.reconcile`, `EVENT_REVERT_MAX_ATTEMPTS`,
`event_run_resources`, `live_marker`, `uq_evres_target`, the six log kinds, and
the route in both routes.manifest.json and the OpenAPI spec. Diffs are 144/21,
139/16 and 67/9 with NO CRLF artefact, verified by comparing --numstat against
the real content diff rather than trusting it.
Co-Authored-By: Claude <noreply@anthropic.com>
Runic Gateway — Documentation
Central documentation for the Runic Gateway platform. The docs here were extracted from the two code repositories (with full commit history preserved) so they live in one place, independent of either codebase.
Layout
website/ docs from the website core (Node/Express + MariaDB + React/Vite)
modules/ docs for installable game modules — one directory per module id
link/ docs from the ServUO bridge (C# plugin + Rust sidecar + Node WS)
android/ docs from the native Android client (Kotlin + Jetpack Compose)
installer/ docs for the installer that deploys a shard's bridge components
ci/ cross-cutting CI/quality notes
Setting up a shard? installer/INSTALL.md is the operator guide, and
the installer is the supported path: one binary deploys the plugin overlay, installs the uo-link
sidecar as a service, and hands you the values the website needs.
website/
| Doc | What it covers |
|---|---|
| BACKEND_DESIGN.md | API contract, DB schema, security model |
| ARCHITECTURE.md | The system diagram — how core, an installed module, the sidecar and the clients fit together |
| TEAMS.md | Teams as a platform primitive: roster, forums, notifications, Discord slash commands and voice — design of record |
| ENGAGEMENT.md | The engagement system: module-declared event triggers, rules, cooldowns, templates and the email / push / in-app delivery channels — design of record |
| HERO_EDITOR.md | Hero canvas editor feature spec |
| THEMING_AND_NAV.md | Admin-configurable theme, brand assets and navigation — build contract |
| MODULE_SYSTEM.md | Making the site game-agnostic: game logic becomes an installable module — design of record |
| MODULE_API.md | The module ↔ core contract: ctx, the register* calls, the client registry and the loader's obligations |
| UPGRADE_NOTES.md | Operator-facing, newest first — the upgrades that need an operator to do something, or that change behaviour quietly enough to be discovered by accident |
| WIKI_UPGRADE.md | Wiki subsystem upgrade notes |
| SHARD_VISIBILITY.md | Who sees which shard data — the admin-configurable audience framework |
| TRUSTED_DEVICES_MFA.md | TOTP two-factor, trusted devices and recovery codes |
| MODERATION_APPEALS.md | Moderation actions, content reports and the appeals flow |
| SPAWN_ATLAS.md | The bestiary / spawn atlas: what the shard contains, parsed from its own ServUO tree |
| CLILOCS.md | UO's id → name table: converting one from your client so items have names |
| UOFIDDLER.md | Operator runbook — step-by-step extraction from your own UO client (cliloc table, creature art) |
| MARKETPLACE.md | The player-vendor index: how it is gathered, what it costs, how to tune it |
| website-README.md | Snapshot of the website repo's README (setup/run reference) |
| test-plan.md | The website's test strategy and harness |
| API_V2_PLAN.md | Router domain split + CSP hardening. The split is complete; only the CSP enforce step remains |
| API_V2_SKELETON.md | Superseded — the /api/v2 scaffold that was never built. Kept as the record of why the split was done in place instead |
| PROJECT_TREE.md | Auto-generated snapshot of the repo's tracked file layout |
modules/
Documentation for installable game modules aggregates here rather than in each module's repo (MODULE_SYSTEM.md §2.10). The website core knows nothing about any particular game; a module is what makes it a site for one.
| Doc | What it covers |
|---|---|
| uo/ | module-uo — the Ultima Online module: what it serves, what it owns, and what an operator needs |
| uo/API.md · uo/SCHEMA.md | module-uo's own route surface and the tables it owns |
| kit-acceptance.md | The Integration Kit acceptance run — building a module by following the kit alone, and what it found |
| rust-dryrun.md | A written, deliberately unimplemented module-rust — the test that the module contract generalises past the game it was extracted from |
link/
| Doc | What it covers |
|---|---|
| INTEGRATION.md | How the website integrates with the uo-link sidecar |
| PROTOCOL_2.md | Protocol 2.0 / 2.1 design |
| v3.md | Protocol 3.0 design — shard content/standings streams + the visibility framework |
| v4.md | Protocol 4.0 — guild membership on the wire (guild.roster, guild.leave) |
| v5.md | Protocol 5 — three enrichments in one bump: house.decay's decay schedule, vendor.listing's fee state, and account.login.result. The current protocol, shipped 2026-09-01 as bundle 2026.09.01 (sidecar v2.1.0 + overlay v1.1.0) |
| ADMIN_CONTROLS.md | Staff write-plane (kick/ban/broadcast, page queue) |
| SHARD_PREREQS.md | Shard-side prerequisites for the bridge |
| PLAN.md | uo-link build plan |
| RESEARCH.md | Research notes |
| link-README.md | Snapshot of the link repo's README |
| PROJECT_TREE.md | Auto-generated snapshot of the repo's tracked file layout |
android/
| Doc | What it covers |
|---|---|
| PLAN.md | Android client build plan / milestones |
| COVERAGE_PLAN.md | Test-coverage rollout plan |
| APP_LINKS.md | Android App Links / deep-link setup |
| theme-plan.md | Theming plan |
| THEMING_AND_NAV.md | The app's half of admin-configurable theming and navigation — build contract |
| TRUSTED_DEVICES_APP_HANDOFF.md | Trusted-devices app handoff notes |
| PROJECT_TREE.md | Auto-generated snapshot of the repo's tracked file layout |
installer/
| Doc | What it covers |
|---|---|
| INSTALL.md | Start here to set up a shard — the installer deploys the plugin overlay and the uo-link sidecar, registers the service, and connects it to the website. Appendix A is the same thing by hand, still supported |
| PLAN.md | Installer design of record — phases, locked decisions, the bundle/compat-matrix model |
| PROJECT_TREE.md | Auto-generated snapshot of the repo's tracked file layout |
ci/
| Doc | What it covers |
|---|---|
| SONARQUBE.md | The SonarQube setup: project keys, how analysis runs, and how to read a report |
Provenance
website/*was extracted fromRunicGateway/websiteviagit filter-repo.link/*was extracted fromRunicGateway/linkviagit filter-repo.
Commit history and authorship for each doc are preserved. The two source repos retain a short pointer to this repo in their own READMEs; the authoritative copy of each document now lives here.
License
Runic Gateway's documentation is free: licensed under the GNU General Public License v3.0 or later — see LICENSE.md.
Copyright (C) 2026 Runic Gateway
This documentation is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY. You may redistribute and/or modify it under the terms of
the GNU General Public License as published by the Free Software Foundation,
either version 3 of the License, or (at your option) any later version.
Contributions are welcome — please read CONTRIBUTING.md (note the AI-usage disclosure requirement) and our Code of Conduct.