wtclaude
58b435be70
Phase 2 PR 4 of MODULE_SYSTEM.md §2.7. Records what §1.8's three entangled files and §1.9's extension slot actually became, and four decisions taken with them. MODULE_API.md §2.4: - registerNotificationStreams takes the catalog ALONE. `mapEvent` was a leftover from before §1.8's push inversion was settled — a module owns fromShardEvent and calls publish() with an id it resolved, so core never needs a second route to the same place. It follows that the public-safety filter is module-internal, which is the right home: the kinds, the streams and the filter become one file that moves together. - the entry shape is two booleans, not a single `scope` — that object is the body of GET /auth/me/notifications/streams and a shipped Android client reads both. - registerAnnounceLeg gains `label`, so a module's leg renders in the admin panel with no client change; and legs became `announce_job_legs` ROWS, because a module cannot ALTER a core table and a registered leg had nowhere to live. - every call STAGES; nothing commits until the module as a whole is known good. New §6.5 — the eight grandfathered names (seven stream ids, one leg id), allowed to `uo` alone by explicit allowlist, the same shape as the loader's legacy table prefixes. Grandfathering rather than dropping the rule is what keeps it real for every module written after this one. New §6.6 — an extension slot is invisible to static analysis, so core needs §6.1's fragment merge for its OWN slot fills, a phase earlier than the plan expected. Moving the six users-detail routes behind the slot deleted 407 lines from swagger-output.json while printing `Success`. Which slots and where each hangs are both derived — from the registry and from the live express stack — because a written-down copy drifts. MODULE_SYSTEM.md §1.8 / §1.9 record the outcome per file, and §2.7 the progress. BACKEND_DESIGN.md and website-README.md follow the moved files; the PUBLIC_KINDS reference at §"visibility" named the wrong file and is corrected to utils/shardBroadcast.js. 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 shard website (Node/Express + MariaDB + React/Vite)
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 |
| 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 |
| WIKI_UPGRADE.md | Wiki subsystem upgrade notes |
| SHARD_VISIBILITY.md | Who sees which shard data — the admin-configurable audience framework |
| 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) |
| PROJECT_TREE.md | Auto-generated snapshot of the repo's tracked file layout |
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 |
| 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 |
| 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 |
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.