wtclaude
e86b04567f
The website merged runtime admin theming, brand assets and nav overrides to main (website#126 / docs#109). The app reads exactly one field of it -- brand.accent -- and renders a hardcoded APP_MENU, so an admin who re-skins the site and restructures the header sees none of it on the phone. Adds docs/android/THEMING_AND_NAV.md as the design of record for M12, and the PLAN.md §9 entry that anchors it. Plan only: no app code, no backend work. Everything consumed is already live on website/main. The points that shaped it: - The app's ui/theme/Color.kt palette is already, value for value, the runic-gateway preset -- M5 was drawn from the same theme.css the preset was later extracted from. So "an untouched instance is unchanged" carries over as a testable ColorScheme equality assertion, not an approximation. - Radii apply as a ratio against that baseline, not as literal dp. The app's Shapes came from the M5 mockup and genuinely differ (medium 12dp vs --radius-card 10px); a literal mapping would restyle the untouched app the day this ships, and copying the app's scale into the server would be a second source of truth. - Fonts are bundled, not downloadable: the Play Store font provider makes a de-Googled device fall back silently. Seven families join the bundled Cinzel. - Nav overrides are keyed by website paths, so the app needs a path -> route table -- the one new cross-repo coupling here. An override for a path the app does not surface in its menu is ignored: a nav override may never introduce navigation. - The gates are untouched. MenuAccess and MenuEntry.feature still run after the merge, so hidden:false cannot un-hide what a role or the shard's visibility config withholds. - Read the resolved theme/brand fields, never the raw theme_visual/brand_assets rows that ride along in the same payload -- re-deriving a palette from them would be a second resolveThemeTokens in Kotlin, guaranteed to drift. Nine phases into a fresh edge in both repos, reaching main as one edge -> main merge, the same shape the website side used. Phase 0 must change nothing on screen. Phase 7 (the authenticated navs) is marked optional: nav_player reaches two app rows and nav_admin two, which is a thin return for a new authenticated fetch and its cache teardown. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TgfKv5cz5pbY3dPeofSE5a
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 |
| 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.