wtclaude
3f12e5f49c
Phases 1 and 2 now live on the installer repo's `edge` branch, so PLAN.md's status, the config-path section, and the operator guide all move with them. PLAN.md - Status: phases 1 and 2 built. The `edge -> main` cutover now follows Phase 3 rather than Phase 2, because INSTALL.md §4 describes the patch tier as part of the run and a release that answers "not implemented" to all of it is the same half-capable binary that kept Phase 1 off `main`. - §2.3: the service definition always pins the config path, but only Linux pins the database. On Windows config and data share a directory, so the sidecar's own anchoring rule already lands it correctly — and `sc.exe` offers no per-service environment, only a machine-wide one that every process inherits and that outlives an uninstall. - New "Phase 2 as built" section: the virtual service account, the config lockdown and why its two halves straddle registration, `--verify` running no part of the sidecar half, the protocol check against the installed binary, `RUNICGATEWAY_STATE_DIR` relocating the binary and suppressing service registration, degrading to a printed recipe with no root/LocalSystem fallback, and the token never entering install.json. - §8 question 1 (Windows service mechanism) resolved: `sc create`, as recommended — plus the service identity the recommendation did not anticipate. INSTALL.md - Status banner: what is built, and that the patch tier is the remaining gap. - §2: the illustrated run matches the sidecar block the binary actually prints. - §3: a table of how each platform pins config and database, the dedicated service account on both, and the fact that sidecar.toml's permissions are restricted because it holds the auth token. - Appendix A4: the Windows recipe now matches what the installer does — `--config` in binPath (single-quoted so PowerShell keeps the inner quotes), `obj=` for the virtual account, the icacls lockdown before and grants after, and no machine-wide environment variables. - Troubleshooting: a row for a run that could not register a service, and one for a service that starts and immediately stops. 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
website/
| Doc | What it covers |
|---|---|
| BACKEND_DESIGN.md | API contract, DB schema, security model |
| HERO_EDITOR.md | Hero canvas editor feature spec |
| 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 | Operator guide — installing Runic Gateway on a ServUO shard, connecting it to the website, and diagnosing it. Includes the by-hand path, which works today |
| 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.