chore: add open-source governance files (GPLv3 + contributing docs)

Add standard open-source project files:
- LICENSE.md — GNU GPL v3.0 or later (verbatim)
- CONTRIBUTING.md — setup, workflow, and required AI-usage disclosure
- CONTRIBUTORS.md — maintainers, contributors, AI-assistance policy
- CODE_OF_CONDUCT.md — Contributor Covenant 2.1
- SECURITY.md — private vulnerability reporting
- .gitea/ISSUE_TEMPLATE/* + PULL_REQUEST_TEMPLATE.md
- README: License section (Copyright (C) 2026 Runic Gateway)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XmHdsbnLzDMAVQkAoTQSBe

.gitea/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,41 @@
+---
+name: Bug report
+about: Report something that is broken or behaving unexpectedly
+title: "[bug] "
+labels:
+  - bug
+---
+
+## Summary
+
+<!-- A clear, concise description of the bug. -->
+
+## Steps to reproduce
+
+1.
+2.
+3.
+
+## Expected behavior
+
+<!-- What you expected to happen. -->
+
+## Actual behavior
+
+<!-- What actually happened. Include exact error messages and logs if you have them. -->
+
+## Environment
+
+- Component / repo:
+- Version or commit:
+- OS / runtime (Node, Rust, ServUO, browser…):
+- Deployment (Docker Compose, local dev, bare metal…):
+
+## Additional context
+
+<!-- Screenshots, config (with secrets redacted), anything else that helps. -->
+
+<!--
+  Security issue? Do NOT file it here. See SECURITY.md and email
+  whitlocktech@gmail.com instead.
+-->

.gitea/ISSUE_TEMPLATE/config.yaml

@@ -0,0 +1,5 @@
+blank_issues_enabled: true
+contact_links:
+  - name: Security vulnerability
+    url: https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/SECURITY.md
+    about: Please do not open a public issue for security problems — report them privately by email instead (see SECURITY.md).

.gitea/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,23 @@
+---
+name: Feature request
+about: Suggest an idea, enhancement, or new capability
+title: "[feature] "
+labels:
+  - enhancement
+---
+
+## Problem / motivation
+
+<!-- What are you trying to do? What's missing or painful today? -->
+
+## Proposed solution
+
+<!-- What you'd like to see happen. -->
+
+## Alternatives considered
+
+<!-- Other approaches you thought about, and why you prefer the one above. -->
+
+## Additional context
+
+<!-- Mockups, links, related issues, affected component/repo, etc. -->

.gitea/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,33 @@
+<!--
+  Thanks for contributing to Runic Gateway!
+  Please fill out the sections below and check every box before requesting review.
+-->
+
+## What & why
+
+<!-- What does this PR change, and why? Link any related issue: "Closes #123". -->
+
+## How it was tested
+
+<!-- Commands you ran, manual steps, screenshots. -->
+
+## Checklist
+
+- [ ] I have read [CONTRIBUTING.md](CONTRIBUTING.md).
+- [ ] The change builds and existing tests/checks pass locally.
+- [ ] I have added or updated tests/docs where it makes sense.
+- [ ] My commits are reasonably scoped with clear messages.
+
+## AI-assisted contributions (required)
+
+This project **requires disclosure of AI tool usage**. Please pick one:
+
+- [ ] No AI tools were used to produce this contribution.
+- [ ] AI tools were used. Tool(s): `___________`. I have reviewed and understand
+      every change, and take responsibility for it. AI-authored commits are
+      marked with a `Co-Authored-By` / `Assisted-By` trailer.
+
+## License
+
+- [ ] I agree that my contribution is licensed under this project's license
+      (**GNU GPL v3.0 or later**), and I have the right to contribute it.

CODE_OF_CONDUCT.md

@@ -0,0 +1,133 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, caste, color, religion, or sexual
+identity and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the overall
+  community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or advances of
+  any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email address,
+  without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will communicate reasons for moderation
+decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official email address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders responsible for enforcement at
+**whitlocktech@gmail.com**.
+
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series of
+actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or permanent
+ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior, harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within the
+community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.1, available at
+[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
+
+Community Impact Guidelines were inspired by
+[Mozilla's code of conduct enforcement ladder][Mozilla CoC].
+
+For answers to common questions about this code of conduct, see the FAQ at
+[https://www.contributor-covenant.org/faq][FAQ]. Translations are available at
+[https://www.contributor-covenant.org/translations][translations].
+
+[homepage]: https://www.contributor-covenant.org
+[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
+[Mozilla CoC]: https://github.com/mozilla/diversity
+[FAQ]: https://www.contributor-covenant.org/faq
+[translations]: https://www.contributor-covenant.org/translations

CONTRIBUTING.md

@@ -0,0 +1,73 @@
+# Contributing to Runic Gateway — Documentation
+
+Thanks for your interest in contributing! This repo is the **central
+documentation** for the Runic Gateway platform — design docs, the protocol spec,
+integration guides, and research, extracted from the code repos so they live in
+one place.
+
+By participating you agree to abide by our
+[Code of Conduct](CODE_OF_CONDUCT.md).
+
+## Ways to contribute
+
+- **Report an error** (something wrong, outdated, or unclear) or **request new
+  documentation** through the
+  [issue tracker](https://gitea.whitlocktech.com/RunicGateway/docs/issues)
+  (issue templates are provided).
+- **Fix or expand the docs** by opening a pull request (see below).
+- **Never** report a security vulnerability in a public issue — see
+  [SECURITY.md](SECURITY.md).
+
+## Working on the docs
+
+Everything here is Markdown — no build step. Just edit the relevant file and
+preview it in any Markdown viewer (or on Gitea).
+
+```
+website/   docs for the shard website (Node/Express + MariaDB + React/Vite)
+link/      docs for the ServUO bridge (C# plugin + Rust sidecar)
+```
+
+Guidelines:
+
+- Keep documents in the folder matching their subsystem (`website/` or `link/`).
+- These docs are the **authoritative** copy of the protocol and design; when you
+  change behavior in a code repo, update the matching doc here in the same or a
+  follow-up PR so the spec and implementation stay in sync.
+- Use relative links between docs, and check that any links you add resolve.
+- Prefer clear prose and tables over screenshots where possible.
+
+## Branch & PR workflow
+
+1. Branch from `main` with a descriptive name (`docs/…`, `fix/…`, `chore/…`).
+2. Keep changes focused; small PRs are easier to review.
+3. Push and open a pull request against `main`. Fill out the PR template,
+   including the **AI-assisted contributions** disclosure.
+4. A maintainer will review; address feedback with follow-up commits.
+
+### Commit messages
+
+We use [Conventional Commits](https://www.conventionalcommits.org/) —
+`type(scope): summary` (e.g. `docs(link): clarify town-crier caps`).
+
+## AI-assisted contributions (disclosure required)
+
+This project is developed openly with AI assistance, and we ask the same
+transparency of everyone. **If you used an AI tool** (Claude, Copilot, ChatGPT,
+Cursor, etc.) to help produce a contribution, you must disclose it:
+
+- Tick the AI-usage box in the pull-request template and name the tool(s).
+- Mark AI-authored commits with a trailer, e.g.
+  `Co-Authored-By: Claude <noreply@anthropic.com>` or `Assisted-By: <tool>`.
+- You remain responsible for every line you submit: review it, understand it,
+  and make sure it is accurate and that you have the right to contribute it.
+
+Disclosed AI assistance is welcome. Undisclosed AI-generated contributions are
+not, and may be closed.
+
+## License
+
+Runic Gateway is licensed under the **GNU General Public License v3.0 or later**
+(see [LICENSE.md](LICENSE.md)). By submitting a contribution you agree that it is
+licensed under the same terms (inbound = outbound) and that you have the right to
+contribute it.

CONTRIBUTORS.md

@@ -0,0 +1,31 @@
+# Contributors
+
+Runic Gateway is built and maintained by the people and tools listed here.
+Thank you to everyone who has contributed.
+
+## Maintainers
+
+- **whitlocktech** <whitlocktech@gmail.com> — project lead and maintainer
+
+## Contributors
+
+<!--
+  Add yourself here when your contribution is merged — alphabetical by name or
+  handle. One line each:
+
+  - **Name or handle** (optional link) — what you contributed
+-->
+
+- _Your name could be here — see [CONTRIBUTING.md](CONTRIBUTING.md)._
+
+## AI-assisted development
+
+Parts of Runic Gateway were developed with the assistance of AI coding tools,
+including **Claude** (Anthropic) via Claude Code. AI-assisted commits are
+attributed in their commit trailers (e.g. `Co-Authored-By: Claude ...`).
+
+In keeping with this project's transparency policy, **all contributors must
+disclose their use of AI tools** on any contribution — see the
+"AI-assisted contributions" section of [CONTRIBUTING.md](CONTRIBUTING.md).
+Disclosed AI assistance is welcome; undisclosed AI-generated contributions are
+not.

LICENSE.md

@@ -0,0 +1,674 @@
+                    GNU GENERAL PUBLIC LICENSE
+                       Version 3, 29 June 2007
+
+ Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+                            Preamble
+
+  The GNU General Public License is a free, copyleft license for
+software and other kinds of works.
+
+  The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works.  By contrast,
+the GNU General Public License is intended to guarantee your freedom to
+share and change all versions of a program--to make sure it remains free
+software for all its users.  We, the Free Software Foundation, use the
+GNU General Public License for most of our software; it applies also to
+any other work released this way by its authors.  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+them if you wish), that you receive source code or can get it if you
+want it, that you can change the software or use pieces of it in new
+free programs, and that you know you can do these things.
+
+  To protect your rights, we need to prevent others from denying you
+these rights or asking you to surrender the rights.  Therefore, you have
+certain responsibilities if you distribute copies of the software, or if
+you modify it: responsibilities to respect the freedom of others.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must pass on to the recipients the same
+freedoms that you received.  You must make sure that they, too, receive
+or can get the source code.  And you must show them these terms so they
+know their rights.
+
+  Developers that use the GNU GPL protect your rights with two steps:
+(1) assert copyright on the software, and (2) offer you this License
+giving you legal permission to copy, distribute and/or modify it.
+
+  For the developers' and authors' protection, the GPL clearly explains
+that there is no warranty for this free software.  For both users' and
+authors' sake, the GPL requires that modified versions be marked as
+changed, so that their problems will not be attributed erroneously to
+authors of previous versions.
+
+  Some devices are designed to deny users access to install or run
+modified versions of the software inside them, although the manufacturer
+can do so.  This is fundamentally incompatible with the aim of
+protecting users' freedom to change the software.  The systematic
+pattern of such abuse occurs in the area of products for individuals to
+use, which is precisely where it is most unacceptable.  Therefore, we
+have designed this version of the GPL to prohibit the practice for those
+products.  If such problems arise substantially in other domains, we
+stand ready to extend this provision to those domains in future versions
+of the GPL, as needed to protect the freedom of users.
+
+  Finally, every program is threatened constantly by software patents.
+States should not allow patents to restrict development and use of
+software on general-purpose computers, but in those that do, we wish to
+avoid the special danger that patents applied to a free program could
+make it effectively proprietary.  To prevent this, the GPL assures that
+patents cannot be used to render the program non-free.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+                       TERMS AND CONDITIONS
+
+  0. Definitions.
+
+  "This License" refers to version 3 of the GNU General Public License.
+
+  "Copyright" also means copyright-like laws that apply to other kinds of
+works, such as semiconductor masks.
+
+  "The Program" refers to any copyrightable work licensed under this
+License.  Each licensee is addressed as "you".  "Licensees" and
+"recipients" may be individuals or organizations.
+
+  To "modify" a work means to copy from or adapt all or part of the work
+in a fashion requiring copyright permission, other than the making of an
+exact copy.  The resulting work is called a "modified version" of the
+earlier work or a work "based on" the earlier work.
+
+  A "covered work" means either the unmodified Program or a work based
+on the Program.
+
+  To "propagate" a work means to do anything with it that, without
+permission, would make you directly or secondarily liable for
+infringement under applicable copyright law, except executing it on a
+computer or modifying a private copy.  Propagation includes copying,
+distribution (with or without modification), making available to the
+public, and in some countries other activities as well.
+
+  To "convey" a work means any kind of propagation that enables other
+parties to make or receive copies.  Mere interaction with a user through
+a computer network, with no transfer of a copy, is not conveying.
+
+  An interactive user interface displays "Appropriate Legal Notices"
+to the extent that it includes a convenient and prominently visible
+feature that (1) displays an appropriate copyright notice, and (2)
+tells the user that there is no warranty for the work (except to the
+extent that warranties are provided), that licensees may convey the
+work under this License, and how to view a copy of this License.  If
+the interface presents a list of user commands or options, such as a
+menu, a prominent item in the list meets this criterion.
+
+  1. Source Code.
+
+  The "source code" for a work means the preferred form of the work
+for making modifications to it.  "Object code" means any non-source
+form of a work.
+
+  A "Standard Interface" means an interface that either is an official
+standard defined by a recognized standards body, or, in the case of
+interfaces specified for a particular programming language, one that
+is widely used among developers working in that language.
+
+  The "System Libraries" of an executable work include anything, other
+than the work as a whole, that (a) is included in the normal form of
+packaging a Major Component, but which is not part of that Major
+Component, and (b) serves only to enable use of the work with that
+Major Component, or to implement a Standard Interface for which an
+implementation is available to the public in source code form.  A
+"Major Component", in this context, means a major essential component
+(kernel, window system, and so on) of the specific operating system
+(if any) on which the executable work runs, or a compiler used to
+produce the work, or an object code interpreter used to run it.
+
+  The "Corresponding Source" for a work in object code form means all
+the source code needed to generate, install, and (for an executable
+work) run the object code and to modify the work, including scripts to
+control those activities.  However, it does not include the work's
+System Libraries, or general-purpose tools or generally available free
+programs which are used unmodified in performing those activities but
+which are not part of the work.  For example, Corresponding Source
+includes interface definition files associated with source files for
+the work, and the source code for shared libraries and dynamically
+linked subprograms that the work is specifically designed to require,
+such as by intimate data communication or control flow between those
+subprograms and other parts of the work.
+
+  The Corresponding Source need not include anything that users
+can regenerate automatically from other parts of the Corresponding
+Source.
+
+  The Corresponding Source for a work in source code form is that
+same work.
+
+  2. Basic Permissions.
+
+  All rights granted under this License are granted for the term of
+copyright on the Program, and are irrevocable provided the stated
+conditions are met.  This License explicitly affirms your unlimited
+permission to run the unmodified Program.  The output from running a
+covered work is covered by this License only if the output, given its
+content, constitutes a covered work.  This License acknowledges your
+rights of fair use or other equivalent, as provided by copyright law.
+
+  You may make, run and propagate covered works that you do not
+convey, without conditions so long as your license otherwise remains
+in force.  You may convey covered works to others for the sole purpose
+of having them make modifications exclusively for you, or provide you
+with facilities for running those works, provided that you comply with
+the terms of this License in conveying all material for which you do
+not control copyright.  Those thus making or running the covered works
+for you must do so exclusively on your behalf, under your direction
+and control, on terms that prohibit them from making any copies of
+your copyrighted material outside their relationship with you.
+
+  Conveying under any other circumstances is permitted solely under
+the conditions stated below.  Sublicensing is not allowed; section 10
+makes it unnecessary.
+
+  3. Protecting Users' Legal Rights From Anti-Circumvention Law.
+
+  No covered work shall be deemed part of an effective technological
+measure under any applicable law fulfilling obligations under article
+11 of the WIPO copyright treaty adopted on 20 December 1996, or
+similar laws prohibiting or restricting circumvention of such
+measures.
+
+  When you convey a covered work, you waive any legal power to forbid
+circumvention of technological measures to the extent such circumvention
+is effected by exercising rights under this License with respect to
+the covered work, and you disclaim any intention to limit operation or
+modification of the work as a means of enforcing, against the work's
+users, your or third parties' legal rights to forbid circumvention of
+technological measures.
+
+  4. Conveying Verbatim Copies.
+
+  You may convey verbatim copies of the Program's source code as you
+receive it, in any medium, provided that you conspicuously and
+appropriately publish on each copy an appropriate copyright notice;
+keep intact all notices stating that this License and any
+non-permissive terms added in accord with section 7 apply to the code;
+keep intact all notices of the absence of any warranty; and give all
+recipients a copy of this License along with the Program.
+
+  You may charge any price or no price for each copy that you convey,
+and you may offer support or warranty protection for a fee.
+
+  5. Conveying Modified Source Versions.
+
+  You may convey a work based on the Program, or the modifications to
+produce it from the Program, in the form of source code under the
+terms of section 4, provided that you also meet all of these conditions:
+
+    a) The work must carry prominent notices stating that you modified
+    it, and giving a relevant date.
+
+    b) The work must carry prominent notices stating that it is
+    released under this License and any conditions added under section
+    7.  This requirement modifies the requirement in section 4 to
+    "keep intact all notices".
+
+    c) You must license the entire work, as a whole, under this
+    License to anyone who comes into possession of a copy.  This
+    License will therefore apply, along with any applicable section 7
+    additional terms, to the whole of the work, and all its parts,
+    regardless of how they are packaged.  This License gives no
+    permission to license the work in any other way, but it does not
+    invalidate such permission if you have separately received it.
+
+    d) If the work has interactive user interfaces, each must display
+    Appropriate Legal Notices; however, if the Program has interactive
+    interfaces that do not display Appropriate Legal Notices, your
+    work need not make them do so.
+
+  A compilation of a covered work with other separate and independent
+works, which are not by their nature extensions of the covered work,
+and which are not combined with it such as to form a larger program,
+in or on a volume of a storage or distribution medium, is called an
+"aggregate" if the compilation and its resulting copyright are not
+used to limit the access or legal rights of the compilation's users
+beyond what the individual works permit.  Inclusion of a covered work
+in an aggregate does not cause this License to apply to the other
+parts of the aggregate.
+
+  6. Conveying Non-Source Forms.
+
+  You may convey a covered work in object code form under the terms
+of sections 4 and 5, provided that you also convey the
+machine-readable Corresponding Source under the terms of this License,
+in one of these ways:
+
+    a) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by the
+    Corresponding Source fixed on a durable physical medium
+    customarily used for software interchange.
+
+    b) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by a
+    written offer, valid for at least three years and valid for as
+    long as you offer spare parts or customer support for that product
+    model, to give anyone who possesses the object code either (1) a
+    copy of the Corresponding Source for all the software in the
+    product that is covered by this License, on a durable physical
+    medium customarily used for software interchange, for a price no
+    more than your reasonable cost of physically performing this
+    conveying of source, or (2) access to copy the
+    Corresponding Source from a network server at no charge.
+
+    c) Convey individual copies of the object code with a copy of the
+    written offer to provide the Corresponding Source.  This
+    alternative is allowed only occasionally and noncommercially, and
+    only if you received the object code with such an offer, in accord
+    with subsection 6b.
+
+    d) Convey the object code by offering access from a designated
+    place (gratis or for a charge), and offer equivalent access to the
+    Corresponding Source in the same way through the same place at no
+    further charge.  You need not require recipients to copy the
+    Corresponding Source along with the object code.  If the place to
+    copy the object code is a network server, the Corresponding Source
+    may be on a different server (operated by you or a third party)
+    that supports equivalent copying facilities, provided you maintain
+    clear directions next to the object code saying where to find the
+    Corresponding Source.  Regardless of what server hosts the
+    Corresponding Source, you remain obligated to ensure that it is
+    available for as long as needed to satisfy these requirements.
+
+    e) Convey the object code using peer-to-peer transmission, provided
+    you inform other peers where the object code and Corresponding
+    Source of the work are being offered to the general public at no
+    charge under subsection 6d.
+
+  A separable portion of the object code, whose source code is excluded
+from the Corresponding Source as a System Library, need not be
+included in conveying the object code work.
+
+  A "User Product" is either (1) a "consumer product", which means any
+tangible personal property which is normally used for personal, family,
+or household purposes, or (2) anything designed or sold for incorporation
+into a dwelling.  In determining whether a product is a consumer product,
+doubtful cases shall be resolved in favor of coverage.  For a particular
+product received by a particular user, "normally used" refers to a
+typical or common use of that class of product, regardless of the status
+of the particular user or of the way in which the particular user
+actually uses, or expects or is expected to use, the product.  A product
+is a consumer product regardless of whether the product has substantial
+commercial, industrial or non-consumer uses, unless such uses represent
+the only significant mode of use of the product.
+
+  "Installation Information" for a User Product means any methods,
+procedures, authorization keys, or other information required to install
+and execute modified versions of a covered work in that User Product from
+a modified version of its Corresponding Source.  The information must
+suffice to ensure that the continued functioning of the modified object
+code is in no case prevented or interfered with solely because
+modification has been made.
+
+  If you convey an object code work under this section in, or with, or
+specifically for use in, a User Product, and the conveying occurs as
+part of a transaction in which the right of possession and use of the
+User Product is transferred to the recipient in perpetuity or for a
+fixed term (regardless of how the transaction is characterized), the
+Corresponding Source conveyed under this section must be accompanied
+by the Installation Information.  But this requirement does not apply
+if neither you nor any third party retains the ability to install
+modified object code on the User Product (for example, the work has
+been installed in ROM).
+
+  The requirement to provide Installation Information does not include a
+requirement to continue to provide support service, warranty, or updates
+for a work that has been modified or installed by the recipient, or for
+the User Product in which it has been modified or installed.  Access to a
+network may be denied when the modification itself materially and
+adversely affects the operation of the network or violates the rules and
+protocols for communication across the network.
+
+  Corresponding Source conveyed, and Installation Information provided,
+in accord with this section must be in a format that is publicly
+documented (and with an implementation available to the public in
+source code form), and must require no special password or key for
+unpacking, reading or copying.
+
+  7. Additional Terms.
+
+  "Additional permissions" are terms that supplement the terms of this
+License by making exceptions from one or more of its conditions.
+Additional permissions that are applicable to the entire Program shall
+be treated as though they were included in this License, to the extent
+that they are valid under applicable law.  If additional permissions
+apply only to part of the Program, that part may be used separately
+under those permissions, but the entire Program remains governed by
+this License without regard to the additional permissions.
+
+  When you convey a copy of a covered work, you may at your option
+remove any additional permissions from that copy, or from any part of
+it.  (Additional permissions may be written to require their own
+removal in certain cases when you modify the work.)  You may place
+additional permissions on material, added by you to a covered work,
+for which you have or can give appropriate copyright permission.
+
+  Notwithstanding any other provision of this License, for material you
+add to a covered work, you may (if authorized by the copyright holders of
+that material) supplement the terms of this License with terms:
+
+    a) Disclaiming warranty or limiting liability differently from the
+    terms of sections 15 and 16 of this License; or
+
+    b) Requiring preservation of specified reasonable legal notices or
+    author attributions in that material or in the Appropriate Legal
+    Notices displayed by works containing it; or
+
+    c) Prohibiting misrepresentation of the origin of that material, or
+    requiring that modified versions of such material be marked in
+    reasonable ways as different from the original version; or
+
+    d) Limiting the use for publicity purposes of names of licensors or
+    authors of the material; or
+
+    e) Declining to grant rights under trademark law for use of some
+    trade names, trademarks, or service marks; or
+
+    f) Requiring indemnification of licensors and authors of that
+    material by anyone who conveys the material (or modified versions of
+    it) with contractual assumptions of liability to the recipient, for
+    any liability that these contractual assumptions directly impose on
+    those licensors and authors.
+
+  All other non-permissive additional terms are considered "further
+restrictions" within the meaning of section 10.  If the Program as you
+received it, or any part of it, contains a notice stating that it is
+governed by this License along with a term that is a further
+restriction, you may remove that term.  If a license document contains
+a further restriction but permits relicensing or conveying under this
+License, you may add to a covered work material governed by the terms
+of that license document, provided that the further restriction does
+not survive such relicensing or conveying.
+
+  If you add terms to a covered work in accord with this section, you
+must place, in the relevant source files, a statement of the
+additional terms that apply to those files, or a notice indicating
+where to find the applicable terms.
+
+  Additional terms, permissive or non-permissive, may be stated in the
+form of a separately written license, or stated as exceptions;
+the above requirements apply either way.
+
+  8. Termination.
+
+  You may not propagate or modify a covered work except as expressly
+provided under this License.  Any attempt otherwise to propagate or
+modify it is void, and will automatically terminate your rights under
+this License (including any patent licenses granted under the third
+paragraph of section 11).
+
+  However, if you cease all violation of this License, then your
+license from a particular copyright holder is reinstated (a)
+provisionally, unless and until the copyright holder explicitly and
+finally terminates your license, and (b) permanently, if the copyright
+holder fails to notify you of the violation by some reasonable means
+prior to 60 days after the cessation.
+
+  Moreover, your license from a particular copyright holder is
+reinstated permanently if the copyright holder notifies you of the
+violation by some reasonable means, this is the first time you have
+received notice of violation of this License (for any work) from that
+copyright holder, and you cure the violation prior to 30 days after
+your receipt of the notice.
+
+  Termination of your rights under this section does not terminate the
+licenses of parties who have received copies or rights from you under
+this License.  If your rights have been terminated and not permanently
+reinstated, you do not qualify to receive new licenses for the same
+material under section 10.
+
+  9. Acceptance Not Required for Having Copies.
+
+  You are not required to accept this License in order to receive or
+run a copy of the Program.  Ancillary propagation of a covered work
+occurring solely as a consequence of using peer-to-peer transmission
+to receive a copy likewise does not require acceptance.  However,
+nothing other than this License grants you permission to propagate or
+modify any covered work.  These actions infringe copyright if you do
+not accept this License.  Therefore, by modifying or propagating a
+covered work, you indicate your acceptance of this License to do so.
+
+  10. Automatic Licensing of Downstream Recipients.
+
+  Each time you convey a covered work, the recipient automatically
+receives a license from the original licensors, to run, modify and
+propagate that work, subject to this License.  You are not responsible
+for enforcing compliance by third parties with this License.
+
+  An "entity transaction" is a transaction transferring control of an
+organization, or substantially all assets of one, or subdividing an
+organization, or merging organizations.  If propagation of a covered
+work results from an entity transaction, each party to that
+transaction who receives a copy of the work also receives whatever
+licenses to the work the party's predecessor in interest had or could
+give under the previous paragraph, plus a right to possession of the
+Corresponding Source of the work from the predecessor in interest, if
+the predecessor has it or can get it with reasonable efforts.
+
+  You may not impose any further restrictions on the exercise of the
+rights granted or affirmed under this License.  For example, you may
+not impose a license fee, royalty, or other charge for exercise of
+rights granted under this License, and you may not initiate litigation
+(including a cross-claim or counterclaim in a lawsuit) alleging that
+any patent claim is infringed by making, using, selling, offering for
+sale, or importing the Program or any portion of it.
+
+  11. Patents.
+
+  A "contributor" is a copyright holder who authorizes use under this
+License of the Program or a work on which the Program is based.  The
+work thus licensed is called the contributor's "contributor version".
+
+  A contributor's "essential patent claims" are all patent claims
+owned or controlled by the contributor, whether already acquired or
+hereafter acquired, that would be infringed by some manner, permitted
+by this License, of making, using, or selling its contributor version,
+but do not include claims that would be infringed only as a
+consequence of further modification of the contributor version.  For
+purposes of this definition, "control" includes the right to grant
+patent sublicenses in a manner consistent with the requirements of
+this License.
+
+  Each contributor grants you a non-exclusive, worldwide, royalty-free
+patent license under the contributor's essential patent claims, to
+make, use, sell, offer for sale, import and otherwise run, modify and
+propagate the contents of its contributor version.
+
+  In the following three paragraphs, a "patent license" is any express
+agreement or commitment, however denominated, not to enforce a patent
+(such as an express permission to practice a patent or covenant not to
+sue for patent infringement).  To "grant" such a patent license to a
+party means to make such an agreement or commitment not to enforce a
+patent against the party.
+
+  If you convey a covered work, knowingly relying on a patent license,
+and the Corresponding Source of the work is not available for anyone
+to copy, free of charge and under the terms of this License, through a
+publicly available network server or other readily accessible means,
+then you must either (1) cause the Corresponding Source to be so
+available, or (2) arrange to deprive yourself of the benefit of the
+patent license for this particular work, or (3) arrange, in a manner
+consistent with the requirements of this License, to extend the patent
+license to downstream recipients.  "Knowingly relying" means you have
+actual knowledge that, but for the patent license, your conveying the
+covered work in a country, or your recipient's use of the covered work
+in a country, would infringe one or more identifiable patents in that
+country that you have reason to believe are valid.
+
+  If, pursuant to or in connection with a single transaction or
+arrangement, you convey, or propagate by procuring conveyance of, a
+covered work, and grant a patent license to some of the parties
+receiving the covered work authorizing them to use, propagate, modify
+or convey a specific copy of the covered work, then the patent license
+you grant is automatically extended to all recipients of the covered
+work and works based on it.
+
+  A patent license is "discriminatory" if it does not include within
+the scope of its coverage, prohibits the exercise of, or is
+conditioned on the non-exercise of one or more of the rights that are
+specifically granted under this License.  You may not convey a covered
+work if you are a party to an arrangement with a third party that is
+in the business of distributing software, under which you make payment
+to the third party based on the extent of your activity of conveying
+the work, and under which the third party grants, to any of the
+parties who would receive the covered work from you, a discriminatory
+patent license (a) in connection with copies of the covered work
+conveyed by you (or copies made from those copies), or (b) primarily
+for and in connection with specific products or compilations that
+contain the covered work, unless you entered into that arrangement,
+or that patent license was granted, prior to 28 March 2007.
+
+  Nothing in this License shall be construed as excluding or limiting
+any implied license or other defenses to infringement that may
+otherwise be available to you under applicable patent law.
+
+  12. No Surrender of Others' Freedom.
+
+  If conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot convey a
+covered work so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you may
+not convey it at all.  For example, if you agree to terms that obligate you
+to collect a royalty for further conveying from those to whom you convey
+the Program, the only way you could satisfy both those terms and this
+License would be to refrain entirely from conveying the Program.
+
+  13. Use with the GNU Affero General Public License.
+
+  Notwithstanding any other provision of this License, you have
+permission to link or combine any covered work with a work licensed
+under version 3 of the GNU Affero General Public License into a single
+combined work, and to convey the resulting work.  The terms of this
+License will continue to apply to the part which is the covered work,
+but the special requirements of the GNU Affero General Public License,
+section 13, concerning interaction through a network will apply to the
+combination as such.
+
+  14. Revised Versions of this License.
+
+  The Free Software Foundation may publish revised and/or new versions of
+the GNU General Public License from time to time.  Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+  Each version is given a distinguishing version number.  If the
+Program specifies that a certain numbered version of the GNU General
+Public License "or any later version" applies to it, you have the
+option of following the terms and conditions either of that numbered
+version or of any later version published by the Free Software
+Foundation.  If the Program does not specify a version number of the
+GNU General Public License, you may choose any version ever published
+by the Free Software Foundation.
+
+  If the Program specifies that a proxy can decide which future
+versions of the GNU General Public License can be used, that proxy's
+public statement of acceptance of a version permanently authorizes you
+to choose that version for the Program.
+
+  Later license versions may give you additional or different
+permissions.  However, no additional obligations are imposed on any
+author or copyright holder as a result of your choosing to follow a
+later version.
+
+  15. Disclaimer of Warranty.
+
+  THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
+OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
+THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
+IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
+ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+  16. Limitation of Liability.
+
+  IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
+THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
+GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
+USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
+DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
+EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGES.
+
+  17. Interpretation of Sections 15 and 16.
+
+  If the disclaimer of warranty and limitation of liability provided
+above cannot be given local legal effect according to their terms,
+reviewing courts shall apply local law that most closely approximates
+an absolute waiver of all civil liability in connection with the
+Program, unless a warranty or assumption of liability accompanies a
+copy of the Program in return for a fee.
+
+                     END OF TERMS AND CONDITIONS
+
+            How to Apply These Terms to Your New Programs
+
+  If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+  To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+state the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This program is free software: you can redistribute it 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.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+Also add information on how to contact you by electronic and paper mail.
+
+  If the program does terminal interaction, make it output a short
+notice like this when it starts in an interactive mode:
+
+    <program>  Copyright (C) <year>  <name of author>
+    This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+    This is free software, and you are welcome to redistribute it
+    under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License.  Of course, your program's commands
+might be different; for a GUI interface, you would use an "about box".
+
+  You should also get your employer (if you work as a programmer) or school,
+if any, to sign a "copyright disclaimer" for the program, if necessary.
+For more information on this, and how to apply and follow the GNU GPL, see
+<https://www.gnu.org/licenses/>.
+
+  The GNU General Public License does not permit incorporating your program
+into proprietary programs.  If your program is a subroutine library, you
+may consider it more useful to permit linking proprietary applications with
+the library.  If this is what you want to do, use the GNU Lesser General
+Public License instead of this License.  But first, please read
+<https://www.gnu.org/licenses/why-not-lgpl.html>.

README.md

@@ -0,0 +1,58 @@
+# 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)
+```
+
+### `website/`
+| Doc | What it covers |
+|---|---|
+| [BACKEND_DESIGN.md](website/BACKEND_DESIGN.md) | API contract, DB schema, security model |
+| [HERO_EDITOR.md](website/HERO_EDITOR.md) | Hero canvas editor feature spec |
+| [WIKI_UPGRADE.md](website/WIKI_UPGRADE.md) | Wiki subsystem upgrade notes |
+| [website-README.md](website/website-README.md) | Snapshot of the website repo's README (setup/run reference) |
+
+### `link/`
+| Doc | What it covers |
+|---|---|
+| [INTEGRATION.md](link/INTEGRATION.md) | How the website integrates with the uo-link sidecar |
+| [PROTOCOL_2.md](link/PROTOCOL_2.md) | Protocol 2.0 / 2.1 design |
+| [ADMIN_CONTROLS.md](link/ADMIN_CONTROLS.md) | Staff write-plane (kick/ban/broadcast, page queue) |
+| [SHARD_PREREQS.md](link/SHARD_PREREQS.md) | Shard-side prerequisites for the bridge |
+| [PLAN.md](link/PLAN.md) | uo-link build plan |
+| [RESEARCH.md](link/RESEARCH.md) | Research notes |
+| [link-README.md](link/link-README.md) | Snapshot of the link repo's README |
+
+## Provenance
+
+- `website/*` was extracted from `RunicGateway/website` via `git filter-repo`.
+- `link/*` was extracted from `RunicGateway/link` via `git 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](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](CONTRIBUTING.md) (note
+the **AI-usage disclosure** requirement) and our
+[Code of Conduct](CODE_OF_CONDUCT.md).

SECURITY.md

@@ -0,0 +1,50 @@
+# Security Policy
+
+Thank you for helping keep Runic Gateway and its users safe.
+
+## Reporting a vulnerability
+
+**Please do not report security vulnerabilities through public issues, pull
+requests, or the wiki.** A public report tips off attackers before a fix is
+available.
+
+Instead, report privately by email to:
+
+**whitlocktech@gmail.com**
+
+Please include as much of the following as you can:
+
+- The repository and component affected.
+- The type of issue (e.g. authentication bypass, injection, secret exposure,
+  remote code execution, denial of service).
+- Step-by-step instructions to reproduce, and a proof-of-concept if you have one.
+- The impact — what an attacker could do with it.
+- Any suggested remediation.
+
+You will receive an acknowledgement of your report, typically within a few days.
+We will keep you informed as we investigate and work toward a fix, and we are
+happy to credit you in the release notes once the issue is resolved (let us know
+if you would prefer to remain anonymous).
+
+## Scope
+
+Runic Gateway is a self-hosted platform made up of several components:
+
+| Component | Repo | Network exposure |
+|---|---|---|
+| Website (site + admin + API) | `RunicGateway/website` | Internet-facing (behind a reverse proxy) |
+| uo-link sidecar | `RunicGateway/link` | The only network-facing part of the game bridge |
+| ServUO plugin | `RunicGateway/servuo-plugins` | Loopback only — dials the sidecar on `127.0.0.1` |
+| Documentation | `RunicGateway/docs` | Content only |
+
+Because instances are self-hosted, the security of any given deployment also
+depends on how it is configured and operated — strong secrets (`JWT_SECRET`,
+`SECRET_ENC_KEY`, database and admin passwords), a correctly configured reverse
+proxy and `TRUST_PROXY`, and keeping the shard itself unreachable from the
+internet (only the sidecar should be exposed). See each repo's README for the
+security model.
+
+## Supported versions
+
+This project is developed continuously and does not maintain long-term release
+branches. Security fixes land on `main`; please run a recent build.

link/ADMIN_CONTROLS.md

@@ -2,7 +2,7 @@
 
 **Status:** Research + design. No code written yet.
 **Date:** 2026-07-12
-**Codebase:** ServUO 57.4, `C:\Users\colby\Desktop\servuo`, net48 / x64, Expansion **EJ**.
+**Codebase:** ServUO 57.4, `<servuo>`, net48 / x64, Expansion **EJ**.
 **Companion to** [`PLAN.md`](PLAN.md) (the read/event plane) and [`INTEGRATION.md`](INTEGRATION.md) (the website API). This document covers the **write plane**: staff actions the website should be able to take against the live shard.
 
 ---
@@ -269,7 +269,7 @@ Every one: enforce the **Owner floor** on the target (refuse `AccessLevel >= CoO
 
 ## 7. Verification log (all resolved)
 
-All resolved by source inspection (ServUO checkout at `C:\Users\colby\Desktop\servuo`). No live-shard run was needed — every path below is unambiguous in the code, and a mute smoke-test would in any case require a real UO client to log in and speak.
+All resolved by source inspection (ServUO checkout at `<servuo>`). No live-shard run was needed — every path below is unambiguous in the code, and a mute smoke-test would in any case require a real UO client to log in and speak.
 
 1. **`Mobile.Squelched` persists — confirmed durable.** Serialized unconditionally (`Server/Mobile.cs:6489` write) and read back in the version ladder at case 9 (`:6013`), so it survives relog **and** a full server restart; no need to persist it ourselves. It gates `OnSaid` (`:7591` → *"You can not say anything, you have been muted."*). Two consequences for the plan: (a) it is **per-Mobile (per-character), not per-account** — "mute the account" means squelch each resident character; (b) it works on **offline** characters too, since logged-off mobiles stay resident in `World`. Phase 3 mute is therefore durable and offline-capable out of the box.
 2. **Kicking all sessions — settled.** Enumerate `NetState.Instances` (`Server/Network/NetState.cs:583`, a `ReadOnlyCollection<NetState>`), filter on `ns.Account == acct` (`:574`), and `Dispose()` each. This is **strictly better than walking the account's characters' `NetState`**: a client sitting at character-select has a `NetState` with an `Account` but *no* mobile, and only the `Instances` sweep catches it. `admin.kick` and the live-session cleanup in `admin.ban` both use this.
@@ -302,7 +302,7 @@ All resolved by source inspection (ServUO checkout at `C:\Users\colby\Desktop\se
 | `overlay/Scripts/Custom/Bridge/BridgePages.cs` | New (Phase 2). Streams/snapshots/answers the `PageQueue`. |
 | `overlay/Config/Bridge.cfg` | Add `AdminWriteEnabled` (default off), `AdminAccessFloor` (default `CoOwner`), and the caps. |
 | `sidecar/src/web.rs` | New REST routes (`POST /admin/*`, `/pages/*`) → inbound lines; map replies to status codes. |
-| `docs/INTEGRATION.md` | Document the new endpoints + the `admin.audit` / `page.*` events. |
+| `INTEGRATION.md` | Document the new endpoints + the `admin.audit` / `page.*` events. |
 | *(website, separate repo)* | Admin/moderator-gated UI + a durable moderation log that records both its own actions and inbound `admin.audit` frames. |
 
 The Phase-1 **verbs** need no core or stock edit — every web-initiated action is an existing script-layer API called from the new `BridgeAdmin.cs` overlay. The only non-overlay change is the **one-line `CommandLogging` event** (`patches/commandlogging-event.patch`), needed solely so *in-game* bans/kicks forward their resolved target to the website (§5.5); it reuses the Phase-7 `patches/` mechanism and touches nothing else.

link/INTEGRATION.md

@@ -239,6 +239,82 @@ Category-specific fields on `champ.update`:
 
 The events are live deltas; for the current board of all spawns at once, use `GET /champs` (§6) — that's what you render on connect, then keep live with these events.
 
+#### Guilds (Protocol 2.0)
+
+Guilds expose only one in-game event (a member joining), so the roster is polled (`GuildSweepSeconds`, default 60s) and diffed. Like champion spawns, `guild.update` is a **full-state upsert** emitted only on change — treat a guild id you've never seen as "newly created", and drop one on `guild.remove`. `guild.join` is the one real-time event, on top of the board.
+
+| kind | fields | notes |
+|------|--------|-------|
+| `guild.update` | `id`, `name`, `abbr`, `members`, `online`, `alliance` (or null), `leader` (actor object or null) | A guild's roster/leader/alliance changed, or its first sight this connection. A **leave** shows up here as `members` dropping. |
+| `guild.remove` | `id` | The guild disbanded (leader gone) or was removed. Drop the row. |
+| `guild.join` | `id`, `name`, `abbr`, `who` (actor object) | Real-time: a player joined a guild (`EventSink.JoinGuild`). |
+
+The `leader`/`who` **actor object** is `{serial, name, acct?, webId?, player}` — `acct`/`webId` present when the mobile has an account / a linked website user.
+
+```json
+{"kind":"guild.update","id":1042,"name":"The Silver Hand","abbr":"TSH","members":14,
+ "online":3,"alliance":"Britannian Pact",
+ "leader":{"serial":"0x1A2B","name":"Darrow","acct":"whitlocktech","webId":"9931","player":true},
+ "t":1752489280000}
+{"kind":"guild.join","id":1042,"name":"The Silver Hand","abbr":"TSH",
+ "who":{"serial":"0x77","name":"Bran","acct":"bran","player":true},"t":1752489281000}
+```
+
+Render the current board from `GET /guilds` (§6) on connect, then keep it live with these events.
+
+#### Town governors (Protocol 2.0)
+
+In modern ServUO the "mayor" of a town is the **City Loyalty Governor**. The set of cities is polled (`CitySweepSeconds`, default 300s); each city emits `city.update` (full-state upsert) only when its governor, governor-elect, or election phase changes. **No events at all unless the shard runs the City Loyalty system.**
+
+| kind | fields | notes |
+|------|--------|-------|
+| `city.update` | `city`, `governor` (actor or null), `governorElect` (actor or null), `electionPhase`, `candidates`, `autoPickAt` (ISO-8601 UTC, when an election is ongoing) | A city's governance changed. Derive "the governor changed" by comparing to your stored board. |
+
+`electionPhase` is one of `none` / `nominate` / `vote` / `pending`. Cities: Moonglow, Britain, Jhelom, Yew, Minoc, Trinsic, SkaraBrae, NewMagincia.
+
+```json
+{"kind":"city.update","city":"Britain","electionPhase":"none","candidates":0,
+ "governor":{"serial":"0x1A2B","name":"Darrow","acct":"whitlocktech","webId":"9931","player":true},
+ "governorElect":null,"t":1752489280000}
+```
+
+Render the current board from `GET /governors` (§6) on connect, then keep it live with these events.
+
+#### Presence (Protocol 2.0)
+
+Who's online and where. A population snapshot is polled (`PresenceSweepSeconds`, default 30s) and emitted **only when it changes**; region transitions arrive in real time.
+
+| kind | fields | notes |
+|------|--------|-------|
+| `presence.online` | `count`, `byFacet` `{map: n}`, `byRegion` `{region: n}` | The current online population. Emitted when the count or any breakdown changes. `GET /online` gives the latest; `GET /history?kind=presence.online` the time series. |
+| `region.enter` | `from` (or null), `to` (or null), `map`, `who` (actor object) | A player crossed into a new named region. `from`/`to` are region names (`Wilderness` is unnamed). Cheap "who's where" feed. |
+
+```json
+{"kind":"presence.online","count":42,"byFacet":{"Felucca":12,"Trammel":30},
+ "byRegion":{"Britain":18,"Wilderness":9,"Despise":2},"t":1752489280000}
+{"kind":"region.enter","from":"Britain","to":"Despise","map":"Felucca",
+ "who":{"serial":"0x1A2B","name":"Darrow","acct":"whitlocktech","player":true},"t":...}
+```
+
+#### Houses (Protocol 2.0)
+
+The house registry — one row per house, complementing the `house.decay` *transition* feed (§ above). Polled (`HousingSweepSeconds`, default 300s) and diffed like the other boards.
+
+| kind | fields | notes |
+|------|--------|-------|
+| `house.update` | `serial`, `name`, `owner` (actor or null), `coOwners`, `friends`, `region`, `map`, `x`,`y`,`z`, `decay`, `price`, `builtOn`, `lastRefreshed` | A house's owner/region/decay/co-owners changed, or first sight this connection. `decay` is the level name (e.g. `LikeNew`). `price` is the placement value — **stock ServUO has no "for sale" flag**, so this is not a listing. |
+| `house.remove` | `serial` | The house was demolished or no longer exists. Drop the row. |
+
+```json
+{"kind":"house.update","serial":"0x40001234","name":"The Silver Anvil","decay":"LikeNew",
+ "price":432100,"map":"Felucca","x":1420,"y":1631,"z":0,"region":"Britain",
+ "owner":{"serial":"0x1A2B","name":"Darrow","acct":"whitlocktech","player":true},
+ "coOwners":2,"friends":5,"builtOn":"2026-01-02T00:00:00Z","lastRefreshed":"2026-07-10T00:00:00Z",
+ "t":1752489280000}
+```
+
+Render from `GET /houses` (§6) on connect, then keep live with these events.
+
 ---
 
 ## 5. REST — read queries
@@ -269,7 +345,9 @@ Full character sheet: stats, all trained skills, worn equipment with flattened i
     { "serial":"0x4002B3","layer":"OneHanded","itemId":5046,"hue":0,"cliloc":1023721,
       "weapon":{"minDamage":16,"maxDamage":18},
       "mods":{"WeaponDamage":50,"HitLightning":40} }
-  ]
+  ],
+  "titles": { "selected": 0, "fameKarma": "Lord", "skill": "Grandmaster Swordsman",
+              "reward": ["1154060", "The Bold"] }
 }
 ```
 
@@ -277,6 +355,7 @@ Field notes:
 - `skills[].base` is trained value, `value` includes item/temp bonuses, `cap` is the cap. **Do not assume `base <= cap`** — GM characters can exceed it.
 - `equipment[].mods` is a flattened map of every non-zero AOS attribute on the item (weapon or armor). Empty `{}` for plain items.
 - Item names are usually **clilocs**, not strings: use `name` when present, otherwise resolve `cliloc` against a UO cliloc table on the site.
+- `titles` (Protocol 2.0): `selected` is the index into `reward` currently displayed (`-1` if none). `fameKarma`/`skill` are computed display titles, omitted when the character has none. `reward` entries may be a **cliloc number as a string** or a literal string — resolve numeric ones against your cliloc table, same as item names.
 - Errors: unknown account → **404** `{"kind":"bridge.error","reason":"unknown account"}`; bad slot → **404**/**400** similarly.
 
 ### Account roster
@@ -398,6 +477,28 @@ DELETE /towncrier/{id}
 
 Caps apply (line count/length, active entries, duration); an over-cap post returns `towncrier.error`.
 
+### Publish / remove Town Cryer **news** (Protocol 2.1)
+
+Distinct from the scrolling-crier lines above: this puts a full article — title, HTML body, image, and a "more info" URL — into the in-game **Town Cryer News gump**, and (by default) has the criers proclaim the **title** in-world.
+
+```
+POST /news
+{ "id": "42", "title": "Double XP Weekend",
+  "body": "<CENTER>Double XP Weekend</CENTER><BR><BR>Starts Friday 7PM.",
+  "image": 1614, "url": "https://yoursite/news/42" }
+```
+→ **200** `{"kind":"news.ok","id":"42"}`. Re-posting the same `id` **replaces** the prior article in place.
+
+- `id`, `title` required. `body` (HTML supported), `image` (a UO gump id; a neutral scroll if omitted), `url` (a browser button in the gump) optional.
+- `announce` defaults to **true** — the criers proclaim the title. Send `"announce": false` to post silently (e.g. a correction).
+
+```
+DELETE /news/{id}
+```
+→ **200** `{"kind":"news.ok","id":"42"}`, or **404** `{"kind":"news.error","reason":"unknown id"}`.
+
+Caps apply (title/body length, max active articles). The **website is the source of truth**: the shard rebuilds its news list on restart and does not persist yours, so the sidecar automatically re-pushes your articles (silently) whenever the shard reconnects. Stock ServUO news is left intact — your articles are tracked separately.
+
 ### Staff moderation — the write plane
 
 Account and session moderation against the live shard. **These are privileged.** The sidecar does
@@ -512,6 +613,51 @@ GET /champs
 
 A row survives a sidecar restart (it's in SQLite), so the board reflects the last-known state even during a shard outage. A `sea` boss appears when summoned and is removed when slain.
 
+### Guild board (Protocol 2.0)
+
+```
+GET /guilds
+→ { "guilds": [ {"kind":"guild.update","id":1042,"name":"The Silver Hand","abbr":"TSH",
+      "members":14,"online":3,"alliance":"Britannian Pact",
+      "leader":{"serial":"0x1A2B","name":"Darrow","acct":"whitlocktech","webId":"9931","player":true},
+      "t":1752489280000}, ... ] }
+```
+
+Every guild's latest roster snapshot at once — the live board. Served from the sidecar's projection (no shard round-trip), kept current by the `guild.*` stream (§4). Render on load, then subscribe. Each entry is exactly a `guild.update` payload; ordered by name. Survives a sidecar restart.
+
+### Governor board (Protocol 2.0)
+
+```
+GET /governors
+→ { "cities": [ {"kind":"city.update","city":"Britain","electionPhase":"none","candidates":0,
+      "governor":{"serial":"0x1A2B","name":"Darrow","acct":"whitlocktech","player":true},
+      "governorElect":null,"t":1752489280000}, ... ] }
+```
+
+Every city's latest governance snapshot — the live board, kept current by the `city.update` stream (§4). Empty if the shard does not run the City Loyalty system. Ordered by city.
+
+### Online population (Protocol 2.0)
+
+```
+GET /online
+→ {"kind":"presence.online","count":42,"byFacet":{"Felucca":12,"Trammel":30},
+   "byRegion":{"Britain":18,"Wilderness":9},"t":1752489280000}
+```
+
+The current online population — total plus per-facet and per-region breakdowns. The latest `presence.online` snapshot (from SQLite, so it survives a sidecar restart); keep it live with the `presence.online` stream (§4). `count: 0` with empty maps if the shard hasn't reported yet. For the population time series, `GET /history?kind=presence.online`.
+
+### House registry (Protocol 2.0)
+
+```
+GET /houses
+→ { "houses": [ {"kind":"house.update","serial":"0x40001234","name":"The Silver Anvil",
+      "decay":"LikeNew","price":432100,"map":"Felucca","x":1420,"y":1631,"z":0,"region":"Britain",
+      "owner":{"serial":"0x1A2B","name":"Darrow","acct":"whitlocktech","player":true},
+      "coOwners":2,"friends":5,"builtOn":"...","lastRefreshed":"...","t":...}, ... ] }
+```
+
+Every house's latest snapshot — owner→houses map. Served from the sidecar's projection, kept current by the `house.*` stream (§4). Ordered by name. Survives a sidecar restart.
+
 ---
 
 ## 7. Status codes

link/PLAN.md

@@ -2,7 +2,7 @@
 
 **Status:** Design, grounded in **measurements taken on this shard**, not estimates.
 **Date:** 2026-07-10
-**Codebase:** ServUO 57.4, `C:\Users\colby\Desktop\servuo`, net48 / x64, Expansion **EJ**.
+**Codebase:** ServUO 57.4, `<servuo>`, net48 / x64, Expansion **EJ**.
 **Supersedes** the speculative parts of `BRIDGE_FINDINGS.md`. See [§8](#8-corrections-to-bridge_findingsmd) for where that document is wrong.
 
 Test scaffolding used to produce this plan lives in `Scripts/Custom/BridgeSeeder.cs` (world population) and `Scripts/Custom/BridgeProbe.cs` (timing). Both are gated behind `Config/Bridge.cfg` flags and default to off. **Neither is part of the bridge.** Delete before production.

link/PROTOCOL_2.md

@@ -1,8 +1,8 @@
 # Protocol 2.0 — Provisioning & World-State Streams
 
-**Status:** Part A **built** on branch `feat/protocol2-account-provisioning` (2026-07-17), compiles clean both sides. Part B is design.
+**Status:** Parts A + B (phases 1–4) **built and smoke-tested live** on branch `feat/protocol2-account-provisioning` (2026-07-17) — booted ServUO + the real sidecar and exercised every endpoint (see §15). Part B phase 5 (Factions/VvV) deferred by owner decision.
 **Date:** 2026-07-17
-**Codebase:** ServUO 57.4, `C:\Users\colby\Desktop\servuo`, net48 / x64, Expansion **EJ**.
+**Codebase:** ServUO 57.4, `<servuo>`, net48 / x64, Expansion **EJ**.
 **Companion to** [`PLAN.md`](PLAN.md) (read/event plane), [`ADMIN_CONTROLS.md`](ADMIN_CONTROLS.md) (staff write plane), and [`INTEGRATION.md`](INTEGRATION.md) (website API).
 
 Protocol 1.0 shipped the read/event plane, the request/reply plane, `[link` account linking, town-crier, the player-vendor-sale core edit, the admin write plane, and the help-page queue.
@@ -208,7 +208,7 @@ Per the 2026-07-17 decision, **this is not in 2.0's committed scope.** When an a
 | `overlay/Config/Bridge.cfg` + `.example` | **Extend.** The §6 keys, defaults documented. |
 | `sidecar/src/web.rs` | **Extend.** `POST /accounts/create` (forwards `ip` from the body untouched), `DELETE /link/:account`; `respond_account` status mapping (409 on collision, 429 on IP cap, 400 on missing IP); scrub password from any logged/broadcast value. |
 | `sidecar/src/store.rs` | **Extend.** `record_unlink` (clear the mirrored link row) beside the existing `record_link`. |
-| `docs/INTEGRATION.md` | **Extend.** Document `POST /accounts/create`, `DELETE /link/{account}`, and the `account.audit` event. |
+| `INTEGRATION.md` | **Extend.** Document `POST /accounts/create`, `DELETE /link/{account}`, and the `account.audit` event. |
 | *(website, separate repo)* | Signup form → `POST /accounts/create`; unlink control → `DELETE /link/{account}`; consume `account.audit`. |
 
 No new core/stock edits in committed scope — `account.create`/`unlink` are all script-layer (`new Account`, `SetTag`/`RemoveTag`) called from the new overlay. The only core edit contemplated (the `AccountCreated` event, §7) is explicitly deferred.
@@ -333,7 +333,7 @@ Everything below is grounded in a hook or a cheap sweep in *this* server. Ranked
 | `overlay/Scripts/Custom/Bridge/BridgeSweeps.cs` | **Extend / mirror.** New sweep timers (guild, city, presence), re-armable via `[bridge reload`, one-shot via `[bridge sweepnow`, counters in `[bridge status` — same shape as the existing sweeps. |
 | `overlay/Config/Bridge.cfg` | **Extend.** `GuildSweepSeconds`, `CitySweepSeconds`, `PresenceSweepSeconds` (+ enable flags). |
 | `sidecar/src/store.rs` + `web.rs` | **Extend.** Persist the snapshots that back boards (guild roster, governors, population history); `GET /guilds`, `/governors`, `/online` served from the store so they survive a shard outage, exactly like `/champs` and `/economy` do today. |
-| `docs/INTEGRATION.md` | **Extend.** New event catalog entries + the read endpoints. |
+| `INTEGRATION.md` | **Extend.** New event catalog entries + the read endpoints. |
 
 ---
 
@@ -380,11 +380,11 @@ If the website mirrors rosters/links (it does — `store.record_link`), it must
 
 ## 13. Part B phasing
 
-1. **Guilds + governors.** `BridgeSocial.cs` (guild sweep + `JoinGuild`) and `BridgeGovernance.cs` (city sweep), their `GuildSweepSeconds`/`CitySweepSeconds` config, and the `world.systems` frame. Ship with their REST snapshots (`GET /guilds`, `/governors`, §12.2) from day one — a diff stream without its snapshot is half-built.
-2. **Presence.** Who's-online/population sweep + region presence (`OnEnterRegion`) → `GET /online`, population history in the store.
-3. **Housing registry.** Extend the decay sweep to a full owner→houses list + houses-for-sale → `GET /houses`. (Selected from the §11 menu.)
-4. **Titles.** `char.profile` `titles` block (§10.3) — no new stream, folds into `BridgeProfile`.
-5. **Factions/VvV** — only after confirming which system the shard runs; stream just the enabled one.
+1. ~~**Guilds + governors.**~~ **Built (2026-07-17), compiles clean both sides.** `BridgeSocial.cs` (guild sweep + `JoinGuild` → `guild.update`/`guild.remove`/`guild.join`) and `BridgeGovernance.cs` (city sweep → `city.update`, gated on `CityLoyaltySystem.Enabled`), `GuildSweepSeconds` (60s) / `CitySweepSeconds` (300s) config, both wired into `[bridge reload|sweepnow|status`. Sidecar `guilds`/`governors` board tables + `GET /guilds`, `/governors` served from the store (the §12.2 snapshot rule). Shared `BridgeJson.Actor` writer (serial/name/acct/webId/player). **Deviation from the §10 sketch:** the wire uses full-state `guild.update`/`city.update` upserts (website derives "created"/"governor changed" from the board) rather than discrete `guild.created`/`city.governor` events — this avoids a reconnect re-emit looking like a storm of creations, matching the proven `champ.update` model. *Live end-to-end run still pending.*
+2. ~~**Presence.**~~ **Built (2026-07-17), compiles clean both sides.** `BridgePresence.cs`: a `presence.online` sweep (total + per-facet + per-region, emitted on change) and real-time `region.enter` (`EventSink.OnEnterRegion`, player-filtered). `PresenceSweepSeconds` (30s), wired into `[bridge`. `GET /online` serves the latest snapshot from the event store (population series via `/history?kind=presence.online`). *Live run pending.*
+3. ~~**Housing registry.**~~ **Built (2026-07-17), compiles clean both sides.** `BridgeHousing.cs`: a house sweep over `BaseHouse.AllHouses` → `house.update`/`house.remove` (owner, region, location, decay, co-owners, friends, price), complementing the existing `house.decay` transition feed. `HousingSweepSeconds` (300s), wired into `[bridge`. Sidecar `houses` board + `GET /houses`. (Stock ServUO has no "for sale" flag, so this is owner→houses; `price` is the placement value, not a listing.) *Live run pending.*
+4. ~~**Titles.**~~ **Built (2026-07-17), compiles clean.** `char.profile` gains a `titles` block (`selected`, `fameKarma`, `skill`, `reward[]`) from `PlayerMobile` accessors — no new stream, folds into `BridgeProfile`. *Live run pending.*
+5. **Factions/VvV** — **deferred** (owner decision): only after confirming which system the shard runs; stream just the enabled one.
 
 Cross-cutting, lands with Phase 1: the **protocol bump to 2** (§12.1) and the **snapshot-companion rule** (§12.2). The provisioning siblings (§12.3) and mirror-hygiene (§12.4) attach to Part A's phasing since they extend the `account.*` surface.
 
@@ -443,6 +443,106 @@ Key points, all grounded:
 | `overlay/Scripts/Custom/Bridge/BridgeReports.cs` | **New.** Core-thread report sweep calling `Reports.Compile*` + `Reports.StaffHistory`; serialize to `report.*`; re-armable via `[bridge reload`, one-shot via `[bridge sweepnow`. |
 | `overlay/Config/Bridge.cfg` | **Extend.** `ReportSweepSeconds` (+ enable flag). |
 | `sidecar/src/store.rs` + `web.rs` | **Extend.** Persist the report snapshots; `GET /reports/{skills,general,staff}` served from the store (survives shard outage, like `/champs`). |
-| `docs/INTEGRATION.md` | **Extend.** `report.*` events + endpoints; note they supersede the stock FTP/HTML reports and `WebStatus`. |
+| `INTEGRATION.md` | **Extend.** `report.*` events + endpoints; note they supersede the stock FTP/HTML reports and `WebStatus`. |
 
 > **Recommendation:** fold this in as **Part B, Phase 6** (after the world-state streams), scoped to skill distribution + staff/page-queue history first. It is low-effort (public methods, existing sweep pattern) and directly answers "get the admin reports onto the site instead of a file" — by tapping the data the engine already computes and never letting it become a file at all.
+
+---
+
+## 15. Smoke test — live run (2026-07-17)
+
+Deployed the overlay to the ServUO checkout, booted the shard and the real sidecar (protocol 2, `plugin_connected: true`), and exercised every new surface over REST against the live game. All green.
+
+**Part A — provisioning (through the real shard):**
+
+| Check | Result |
+|-------|--------|
+| `POST /accounts/create` (fresh IP) | **200** `account.ok`, account created + linked |
+| duplicate name | **409** `account already exists` |
+| per-IP cap | shard's real `AccountsPerIp=3` enforced: 3rd from one IP allowed, **4th → 429** `ip account limit reached` |
+| loopback IP with `RequireIpForCreate` | **400** `client ip required` (fails closed) |
+| `GET /link/{acct}` after create | **200**, linked to the website id |
+| `DELETE /link/{acct}` | **200** `unlink`; lookup then **404** |
+
+**Part B — world-state boards (through the real shard):**
+
+| Endpoint | Result |
+|----------|--------|
+| `GET /houses` | **28 houses**, full owner/decay/co-owner/built-on data (shard → `house.update` → board → REST) |
+| `GET /governors` | **9 cities**, `governor: null`/`electionPhase: none` on this unseeded world |
+| `GET /guilds` | `[]` — no guilds on this world; the sweep ran without error |
+| `GET /online` | `count: 0` — headless (no UO client), snapshot emitted and stored |
+| `GET /char/{acct}/0` | full profile incl. the new `titles` block |
+
+**Not exercised (needs a live UO client, not a headless boot):** `presence.online` with real players, `region.enter`, real-time `guild.join`, and `char.vitals`. And `guild.join`/guild board content needs a guild to exist. These are inherent to a clientless smoke test — the board *plumbing* is proven by `/houses`, which uses the identical path.
+
+**One operational note surfaced:** the boot-time `Dynamic` script recompile **cannot replace `Scripts.dll` while the server is running**, because the Scripts build tries to copy the locked `ServUO.exe` and fails (the `PLAN.md §3` trap). The fix used here: build `Scripts/Scripts.csproj` once with the server **stopped**, then boot — the offline build produces a fresh `Scripts.dll` the boot then loads. Rely on this, not the in-process rebuild, when deploying new bridge code. The shard's world save was left untouched (hard-kill, no autosave), so the test accounts did not persist.
+
+---
+
+## 16. Town Cryer news — website articles into the news gump (Protocol 2.1)
+
+**Status:** **Built and smoke-tested live** (2026-07-17). `BridgeNews.cs` (pure overlay, no stock edit) + `POST /news` / `DELETE /news/{id}` + reconnect replay. Verified against a booted shard: `news.add` (full + title-only) → `news.ok`, missing title → 400, idempotent replace, `news.remove` → `news.ok`, unknown id → `news.error`, no shard exceptions, and the **reconnect replay** confirmed (after a shard restart the stored article was re-pushed with `announce:false` and re-accepted). The gump rendering itself is verified by source inspection (needs a UO client to view).
+
+There are **two** distinct town-crier surfaces in ServUO, and 2.0 has so far touched only the first:
+
+1. **The scrolling crier** (`GlobalTownCrierEntryList`) — the wandering Town Crier NPC that *says* short announcement lines. Protocol 1.0 phase 6 (`BridgeTownCrier.cs`, `towncrier.add`/`remove`) already drives this.
+2. **The Town Cryer News gump** (`TownCryerSystem.NewsEntries`) — the paged news UI with title + body + image + a "more info" URL per article. **Nothing drives this yet.** This section adds it.
+
+The ask: a website news article should land as a full article in the **news gump** (2), and the crier should also *say* just the **title** through the existing say feature (1) — so players get the audible "Hear ye!" proclamation while the full write-up lives in the gump.
+
+### 16.1 The hook (verified in the shard's source)
+
+- **`TownCryerSystem.NewsEntries`** (`TownCryerSystem.cs:40`) — `public static List<TownCryerNewsEntry>`. The setter is private, but the **list is public and mutable**, so it can be inserted into and removed from directly.
+- **`TownCryerNewsEntry(TextDefinition title, TextDefinition body, int gumpImage, Type questType, string url)`** (`TownCryerNewsEntry.cs`) — public ctor. Pass `questType: null` for website news.
+- **The display gumps already handle string content**, so no gump edits are needed:
+  - List view (`TownCryerGump.cs:97-103`): `if (entry.Title.Number > 0) AddHtmlLocalized(...) else AddLabelCropped(..., entry.Title)`.
+  - Detail view (`TownCryerNewsGump.cs:27-42`): `if (Entry.Body.Number > 0) AddHtmlLocalized(...) else AddHtml(..., Entry.Body.String, ..., true)` — a **string body renders as HTML** (so `<CENTER>…</CENTER><BR><BR>…` works), `AddImage(..., Entry.GumpImage)`, and `InfoUrl` becomes a `LaunchBrowser` button.
+- **Stock news is live on this shard.** `TownCryerSystem.Initialize()` adds ~18 hardcoded `uo.com` entries whenever `TownCryerSystem.Enabled` (`TownCryerSystem.cs:93-120`) — *not* gated by `UsePreloadedMessages` (that only gates a reload command). So the list is not empty, and our sync must not clobber it (see §16.3).
+
+### 16.2 Evaluating the pasted guidance
+
+The pasted analysis is **substantially correct** and useful — it identifies the right hook (`NewsEntries`), the right constructor, the cliloc-vs-string branching the gump already does, the image/url fields, and the important instinct to keep stock news separate. Two adjustments for *this* architecture:
+
+- **No stock patch is needed.** The pasted plan adds `AddNewsEntry` / `ClearExternalNews` methods to the stock `TownCryerSystem.cs`. That file is stock ServUO, so editing it would ship as a `patches/` diff (like `PlayerVendorSale`). We can avoid that entirely: because `NewsEntries` is a **public mutable list**, the bridge overlay inserts and removes directly — `TownCryerSystem.NewsEntries.Insert(0, entry)` / `.Remove(entry)` — and keeps the "which entries are ours" bookkeeping in an **overlay-side list**, not in a new field on the stock class. This is exactly how `BridgeTownCrier` already mutates `GlobalTownCrierEntryList` from the overlay. Pure overlay, zero stock edits.
+- **Track our entries to keep stock intact.** Rather than the pasted `ExternalNewsEntries` field on the stock class, the overlay holds `List<TownCryerNewsEntry> _ours`. On a sync we `Remove` our previous entries from `NewsEntries` and insert the new set — the stock `uo.com` articles are never touched. `MaxNewsEntries` is 100 (`TownCryerSystem.cs:26`); the overlay caps its own contribution well under that.
+
+Everything else in the pasted note stands, and the "this is one of the easier integrations — you're replacing the content provider" framing is right.
+
+### 16.3 The two surfaces, tied together
+
+On an inbound article the bridge does two things on the Core thread:
+
+1. **News gump** — build `new TownCryerNewsEntry(new TextDefinition(title), new TextDefinition(body), image, null, url)` and `Insert(0, …)` at the top of `TownCryerSystem.NewsEntries`, tracking it in `_ours`; trim `_ours` past the cap by removing the oldest (from both `_ours` and `NewsEntries`).
+2. **Say the title** — reuse the scrolling-crier path (`GlobalTownCrierEntryList`, as `BridgeTownCrier` does) to announce a single line, the **title only**, for a short duration, so the crier proclaims it in-world. **On by default**; set `announce: false` on an article to suppress it (e.g. a silent correction that should not re-proclaim).
+
+### 16.4 Protocol
+
+```jsonc
+// website → sidecar → shard
+{"kind":"news.add","id":"42","title":"Double XP Weekend",
+ "body":"<CENTER>Double XP Weekend</CENTER><BR><BR>Starts Friday 7PM.",
+ "image":1614,"url":"https://uomysticmoon.com/news/42"}
+// announce defaults to true; add "announce":false to suppress the crier proclamation
+{"kind":"news.remove","id":"42"}
+```
+
+- Correlated by `id` (echoed on the reply), like town-crier. Re-adding an `id` **replaces** the prior entry (find-by-id in `_ours`, remove, re-insert) — idempotent.
+- `title` required; `body`/`image`/`url` optional (a title-only blurb is valid). `image` defaults to a neutral scroll gump id when absent.
+- Caps (defense in depth, mirroring `TownCrier*`): title/body length, max external entries. Replies `news.ok` / `news.error`.
+- Sidecar: `POST /news` (add/replace), `DELETE /news/{id}`. Same `respond`-style status mapping as town-crier.
+
+### 16.5 Restart & re-sync (the source-of-truth rule)
+
+`NewsEntries` is **not persisted** by ServUO — it is rebuilt at every boot from stock `Initialize()` plus whatever we have inserted since. So our external articles vanish on a shard restart until re-pushed. The **website is the source of truth**: the sidecar re-sends the current external news set on every shard (re)connect, the same discipline §12.2 uses for the diff boards. (The sidecar persists the external set in its store so it can replay it without the website being up.)
+
+### 16.6 Where the code goes
+
+| File | Responsibility |
+|------|----------------|
+| `overlay/Scripts/Custom/Bridge/BridgeNews.cs` | **New.** `news.add` / `news.remove`: insert/remove `TownCryerNewsEntry` in the public `NewsEntries` list, track `_ours`, cap; optional title announcement via `GlobalTownCrierEntryList`; replies + caps. No stock edit. |
+| `overlay/Config/Bridge.cfg` | **Extend.** `NewsMaxTitleLength`, `NewsMaxBodyLength`, `NewsMaxExternal`, default announce duration. |
+| `sidecar/src/web.rs` + `store.rs` | **Extend.** `POST /news`, `DELETE /news/{id}`; persist the external-news set; replay it on shard (re)connect. |
+| `INTEGRATION.md` | **Extend.** The `news.*` verbs + endpoints. |
+
+No core or stock ServUO change — the whole integration rides the public `TownCryerSystem.NewsEntries` list and the existing crier say path.

link/RESEARCH.md

@@ -3,7 +3,7 @@
 **Status:** Research only, no implementation.
 **Architecture:** Rust sidecar owns a bidirectional WebSocket + JSON endpoint for the website; ServUO links to it over a **local loopback socket**. Tracking players/stats/gold/economy/NPC+player-vendor sales, IDOC/house decay, in-game **`[link`** account linking, and website→game town-crier news. See **Part II** (design/transport/tracking/link), **Part III** (player-vendor, IDOC, town crier, config), and **Part IV** (full character profiles — gear/skills/stats, online & offline, up to 5/account).
 **Date:** 2026-07-07
-**Codebase:** ServUO 57.4 (this repo, `C:\Users\colby\Desktop\servuo`), target framework **.NET Framework 4.8 / x64**.
+**Codebase:** ServUO 57.4 (this repo, `<servuo>`), target framework **.NET Framework 4.8 / x64**.
 **Method:** Grounded in this repo's source. Where the running server would normally be used to confirm behavior, see the note in [§0](#0-note-on-empirical-verification) — the shard was **not running** at research time, so live-boot verification was deliberately skipped and replaced with source-level proof plus evidence from this repo's own crash logs. A ready-to-run empirical probe is included in [Appendix A](#appendix-a-drop-in-empirical-probe-run-this-yourself).
 
 ---

link/SHARD_PREREQS.md

@@ -1,6 +1,6 @@
 # Shard prerequisites
 
-Repairs the target shard (`C:\Users\colby\Desktop\servuo`, ServUO 57.4) required before the bridge could load. These are **deletions and edits of existing files**, so they cannot be expressed as an overlay copy. They are recorded here, and where practical as diffs under `patches/`.
+Repairs the target shard (`<servuo>`, ServUO 57.4) required before the bridge could load. These are **deletions and edits of existing files**, so they cannot be expressed as an overlay copy. They are recorded here, and where practical as diffs under `patches/`.
 
 Applied 2026-07-10. Backups on the Desktop: `servuo_saves_backup_2026-07-10_032608`, `servuo_bin_backup_2026-07-10_032608`, `servuo_removed_files_2026-07-10`.
 

link/link-README.md

@@ -0,0 +1,94 @@
+# uo-link
+
+ServUO ⇄ Rust sidecar bridge. The shard emits newline-delimited JSON over a loopback TCP socket; the sidecar owns the WebSocket the website consumes.
+
+```
+ServUO plugin (C#, net48)  ──loopback TCP, newline-JSON──►  Rust sidecar  ──WebSocket/JSON──►  website
+      (Core-thread reads)  ◄──inbound commands─────────────┘  (owns WS, auth, buffering, fan-out)
+```
+
+The shard never speaks WebSocket. Every world read happens on the Core thread; the socket is touched only by a dedicated writer thread draining a bounded queue.
+
+## Layout
+
+| Path | What |
+|------|------|
+| `overlay/` | Mirrors the ServUO server root. Everything here — and **only** this — copies over an install. |
+| `patches/` | Unified diffs against stock ServUO for files we must modify rather than add. |
+| `sidecar/` | The Rust sidecar: terminates the loopback link to the shard, exposes WS + REST to the website. See `sidecar/README.md`. |
+| `tools/` | Never deployed. Test scaffolding and anything else that must not reach a server. |
+| `INTEGRATION.md` | **Website integration guide** — the WebSocket feed, REST endpoints, auth, event catalog, and examples. Start here to build the front end. |
+| `PLAN.md` | Implementation plan, measured performance budget, and the full data catalog. |
+| `RESEARCH.md` | Original source-level research. Partly superseded — see the corrections table in `PLAN.md` §8. |
+| `SHARD_PREREQS.md` | Repairs the target shard needed before any of this could load. |
+| `deploy.ps1` | Copies `overlay/` into a server root. `-Verify` diffs instead of writing. |
+
+Anything under `overlay/` is authoritative. Do not edit files in the server tree directly — edit here and deploy.
+
+## Deploy
+
+```powershell
+.\deploy.ps1 -ServerPath <servuo> -Verify   # show what would change
+.\deploy.ps1 -ServerPath <servuo>           # write
+```
+
+## Status
+
+| Phase | State |
+|------:|-------|
+| 0 — build fix (`Scripts.csproj`) | **done, verified end-to-end** |
+| 1 — transport (`BridgeLink`) | **done, acceptance in `PLAN.md` §11** |
+| 2 — event streams (`BridgeEvents`) | **done, acceptance in `PLAN.md` §12** |
+| 3 — sweeps (`BridgeSweeps`) | **done, acceptance in `PLAN.md` §13** |
+| 4 — request/response (`BridgeRequests`) | **done, acceptance in `PLAN.md` §14** |
+| 5 — `[link` account linking (`BridgeAccountLink`) | **done, acceptance in `PLAN.md` §15** |
+| 6 — town-crier inbound (`BridgeTownCrier`) | **done, acceptance in `PLAN.md` §16** |
+| 7 — `PlayerVendorSale` core event (`patches/` + `BridgeVendorSale`) | **done, acceptance in `PLAN.md` §17** |
+
+Every phase on the ServUO side is complete. Phases 0–6 are drop-in (`overlay/`); Phase 7 is the one core change, shipped as `patches/`. Remaining work is the Rust sidecar.
+
+Cheat-detection signals are not a separate phase — they are folded into the streams above: `cheat.fastwalk`, `audit.set`, `audit.command`, and `vendor.sale` (buyer + owner for laundering detection).
+
+## Phase 0 — what it fixes
+
+`ScriptCompiler.Compile()` runs `dotnet build Scripts/Scripts.csproj -c Release`, prints the output, and **never checks the exit code**, then `Assembly.LoadFrom("Scripts.dll")` and returns `true`. Because that build passed no `Platform`, MSBuild defaulted to `AnyCPU`, and `Scripts.csproj` gated both `OutputPath` and `DefineConstants` on `Configuration|Platform == Release|x64`. So:
+
+- the DLL landed in `Scripts/bin/Release/` while the core loads `Scripts.dll` from the base directory, and
+- `TRACE;NEWTIMERS;ServUO` went undefined, so XmlSpawner compiled its non-ServUO branches.
+
+Runtime script compilation therefore had no effect, silently. `overlay/Scripts/Scripts.csproj` conditions both property groups on `Configuration` alone.
+
+`Server.csproj` is deliberately left alone: nothing under `Server/` uses those symbols, and giving it `OutputPath=..\` would make the boot-time build try to overwrite the running `ServUO.exe`.
+
+## The plugin (Phase 1)
+
+`overlay/Scripts/Custom/Bridge/`:
+
+| File | Responsibility |
+|------|----------------|
+| `BridgeConfig.cs` | Reads `Config/Bridge.cfg` in `Configure()`, before `World.Load`. |
+| `BridgeJson.cs` | Outbound JSON by hand (Core thread, so no reflection serializer). Inbound via `JavaScriptSerializer`. |
+| `BridgeLink.cs` | The socket. Link thread owns it; a bounded drop-oldest queue fronts it; a reader thread marshals inbound lines to the Core thread. |
+| `BridgeBoot.cs` | Lifecycle, inbound dispatch, `[bridge status\|reload\|ping]`. |
+| `BridgeEvents.cs` | EventSink subscriptions (Phase 2). Read-only, player-filtered, never emits secrets. |
+| `BridgeSweeps.cs` | Polled streams (Phase 3): vitals, house decay on transition, economy supply. Core-thread timers. |
+| `BridgeProfile.cs` | Read-model builders (Phase 4): full character profile, account roster. Core-thread reads. |
+| `BridgeRequests.cs` | Inbound request handlers (Phase 4): `char.request`, `account.roster`, `vendor.snapshot`, with `bridge.error` replies. |
+| `BridgeAccountLink.cs` | `[link` account linking (Phase 5): one-time code, `link.confirm`, `WebsiteUserId` account tag. |
+| `BridgeTownCrier.cs` | Town-crier news (Phase 6): inbound `towncrier.add` / `remove` into the global crier list, with abuse caps. |
+
+`Emit()` is called from the Core thread. It enqueues and returns — it never touches the socket, never blocks, never allocates a syscall. **A wedged or absent sidecar cannot stall the shard**, and that is the property everything else depends on.
+
+## Testing
+
+`tools/stub_sidecar.ps1` is a loopback listener that logs every line the shard sends. Run it, boot the shard, watch `server.hello` arrive. It survives a just-killed instance (SO_REUSEADDR) and won't die on a transient error.
+
+```powershell
+.\tools\stub_sidecar.ps1 -Port 7788 -Log .\sidecar.log
+```
+
+`tools/stub_sidecar_request.ps1` additionally *sends* inbound requests (`char.request`, `account.roster`, `vendor.snapshot`, plus an error case) right after the shard connects, and logs the replies — the harness used to validate Phase 4.
+
+Note: the throwaway PowerShell sidecars are fragile — they get reaped and contend on their log file. The real Rust sidecar replaces them; don't read their flakiness as a shard problem. The shard buffers non-perishable events through any outage and reconnects on its own (observed reconnecting 5× unattended in one session).
+
+`tools/scaffolding/` holds the world seeder and the performance probe. Neither is deployed — `deploy.ps1` only copies `overlay/`. They produced the budget in `PLAN.md` §1. See `tools/scaffolding/README.md`.

website/BACKEND_DESIGN.md

@@ -0,0 +1,329 @@
+# UOMysticmoon Website — Backend Design
+
+> Phase 1 of 3: **backend design** → Claude Design (frontend mockup) → coding.
+> This document is the contract the later phases build against.
+
+Public contact email: **UOMysticmoon@gmail.com**
+
+---
+
+## 1. Stack & top-level decisions
+
+| Concern | Decision | Rationale |
+|---|---|---|
+| Runtime | Node.js + Express | serverlinkr pattern |
+| Database | MariaDB (own container) | spec; `mariadb` pool, parameterized SQL, no ORM (keeps the lightweight `model`/`db` split from serverlinkr) |
+| Auth | JWT in an **httpOnly cookie** | spec says "JWT auth" + "secure cookies when HTTPS"; httpOnly keeps the token out of JS (XSS-safe), `SameSite=Strict` covers CSRF for a same-origin admin panel |
+| Frontend | React + Vite, same repo, served by Express in prod | spec |
+| Hashing | bcrypt (`bcryptjs`) | spec; matches serverlinkr |
+| Deploy | Docker Compose (app + db) behind Pangolin | spec |
+
+**Adapting serverlinkr → this project**
+- `*.mongo.js` (mongoose) → `*.db.js` (MariaDB queries), exactly as the spec names them.
+- Drop the session/passport hybrid (`express-session`, `passport`, `passport-local`, `connect-mongo`). Pure stateless JWT instead — simpler and matches "JWT auth".
+- Routes grouped by **access level** (auth / public / admin) per spec, instead of serverlinkr's per-entity routers. Models stay grouped by **entity**.
+
+---
+
+## 2. Folder structure
+
+Skeleton from the spec, with a small number of justified additions marked **(+)**.
+
+```
+server/
+  .env.example
+  package.json
+  db/
+    schema.sql                  (+) DDL, also auto-run by the MariaDB container
+    seed.js                     (+) seed wiki pages, default settings, first admin
+  src/
+    server.js                   bootstrap: ensure schema, then listen on 0.0.0.0
+    app.js                      express app + middleware wiring
+    router/
+      api.router.js             mounts /v1
+      v1/
+        v1.router.js            mounts /auth /public /admin
+        auth/    auth.routes.js    + auth.controller.js
+        public/  public.routes.js  + public.controller.js
+        admin/   admin.routes.js   + admin.controller.js
+    model/
+      users/     users.model.js    + users.db.js
+      posts/     posts.model.js     + posts.db.js     (news/five-on-friday/newsletter/screenshots)
+      wiki/      wiki.model.js      + wiki.db.js
+      settings/  settings.model.js  + settings.db.js
+      activity/  activity.model.js  + activity.db.js  (+) admin activity log
+    middleware/                 (+)
+      siteMode.js               LIVE/MAINTENANCE gate for public content
+      noindex.js                X-Robots-Tag: noindex,nofollow on admin
+      rateLimit.js              login limiter
+      validate.js               express-validator error handler
+    utils/
+      auth.js                   JWT sign/verify, isLoggedIn middleware
+      db.js                     MariaDB pool + ensureSchema()
+      mailer.js                 (+) nodemailer; mailto fallback if SMTP unset
+client/                         built in Phase 2/3 (React + Vite)
+Dockerfile
+docker-compose.yml
+.env.example
+.gitignore
+```
+
+**Why the additions:** the spec's feature list requires an activity log, a maintenance-mode
+gate, login rate limiting, admin `noindex`, and SMTP email — none fit cleanly in the four
+listed models/two utils. They're isolated in `middleware/` + one `activity` model +
+`utils/mailer.js`, and the spec explicitly says the layout is "expandable."
+
+---
+
+## 3. Database schema (MariaDB)
+
+`utf8mb4` throughout. Created idempotently on boot (`ensureSchema()`) **and** shipped as
+`db/schema.sql` for the container's `/docker-entrypoint-initdb.d`.
+
+### users
+| col | type | notes |
+|---|---|---|
+| id | INT PK AUTO_INCREMENT | |
+| username | VARCHAR(32) UNIQUE NOT NULL | |
+| password_hash | VARCHAR(72) NOT NULL | bcrypt; **never** returned by the API |
+| role | ENUM('admin','editor') NOT NULL DEFAULT 'admin' | room to grow |
+| created_at | DATETIME DEFAULT CURRENT_TIMESTAMP | |
+| last_login_at | DATETIME NULL | shown in user management |
+
+### posts  — one table, four categories
+| col | type | notes |
+|---|---|---|
+| id | INT PK AUTO_INCREMENT | |
+| category | ENUM('news','five_on_friday','newsletter','screenshot') NOT NULL | |
+| title | VARCHAR(200) NOT NULL | |
+| slug | VARCHAR(220) NULL | optional clean URL |
+| excerpt | VARCHAR(400) NULL | list teaser |
+| body | MEDIUMTEXT NULL | markdown/HTML; main text for news/5oF/newsletter |
+| image_url | VARCHAR(500) NULL | required for `screenshot`, optional hero elsewhere |
+| published | TINYINT(1) NOT NULL DEFAULT 0 | publish/unpublish toggle |
+| author_id | INT NULL FK→users(id) | ON DELETE SET NULL |
+| created_at | DATETIME DEFAULT CURRENT_TIMESTAMP | |
+| updated_at | DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP | |
+| published_at | DATETIME NULL | set when first published; list order |
+
+Index: `(category, published, published_at DESC)`.
+
+### wiki_pages
+| col | type | notes |
+|---|---|---|
+| id | INT PK AUTO_INCREMENT | |
+| slug | VARCHAR(120) UNIQUE NOT NULL | e.g. `new-player-guide` |
+| title | VARCHAR(200) NOT NULL | |
+| body | MEDIUMTEXT NULL | markdown/HTML |
+| updated_by | INT NULL FK→users(id) | |
+| created_at / updated_at | DATETIME | |
+
+Seeded with the 8 spec categories: `new-player-guide, maps-atlas, systems, items, monsters, crafting, lore, rules`.
+
+### settings  — key/value, expandable
+| col | type | notes |
+|---|---|---|
+| `key` | VARCHAR(64) PK | |
+| value | TEXT NULL | |
+| updated_by | INT NULL FK→users(id) | |
+| updated_at | DATETIME ON UPDATE CURRENT_TIMESTAMP | |
+
+Seeded keys: `site_mode` (default `maintenance`), `site_mode_changed_at`,
+`site_mode_changed_by`, `maintenance_message`, `status_message`, `homepage_teaser`,
+`contact_email` (=UOMysticmoon@gmail.com), `site_title`.
+
+### activity_log  — append-only
+| col | type | notes |
+|---|---|---|
+| id | INT PK AUTO_INCREMENT | |
+| user_id | INT NULL FK→users(id) | |
+| action | VARCHAR(64) NOT NULL | e.g. `auth.login`, `site_mode.change`, `post.create` |
+| detail | TEXT NULL | JSON string of what changed |
+| ip | VARCHAR(45) NULL | from `req.ip` (needs `trust proxy`) |
+| created_at | DATETIME DEFAULT CURRENT_TIMESTAMP | |
+
+---
+
+## 4. API contract
+
+Base path `/api/v1`. JSON in/out. Auth via httpOnly cookie (`isLoggedIn` reads it; also
+accepts `Authorization: Bearer` for API testing).
+
+### /auth  (auth.routes.js → auth.controller.js)
+| Method | Path | Auth | Body | Purpose |
+|---|---|---|---|---|
+| POST | `/login` | — (rate-limited) | `{username,password}` | verify, set cookie, log `auth.login`, update `last_login_at` |
+| POST | `/logout` | cookie | — | clear cookie |
+| GET | `/me` | cookie | — | current user (no hash) or 401 — client bootstraps auth state |
+
+No public `register`. First admin is bootstrapped by `seed.js` from env (see §6). Further
+admins are created under `/admin/users`.
+
+### /public  (public.routes.js → public.controller.js) — all GET, no auth
+| Method | Path | Notes |
+|---|---|---|
+| GET | `/settings` | whitelisted public keys only (mode, maintenance_message, status_message, homepage_teaser, contact_email, site_title) |
+| GET | `/status` | status message + current mode |
+| GET | `/posts/:category` | published only; `category` ∈ news\|five-on-friday\|newsletter\|screenshots |
+| GET | `/posts/:category/:idOrSlug` | single published post |
+| GET | `/wiki` | list of pages (slug + title) |
+| GET | `/wiki/:slug` | single page |
+| POST | `/contact` | (rate-limited) send mail via SMTP; if unconfigured, respond `{fallback:"mailto", email}` |
+
+Public content GETs pass through the **siteMode** gate (§5).
+
+### /admin  (admin.routes.js → admin.controller.js) — all behind `isLoggedIn` + `noindex`
+| Method | Path | Purpose |
+|---|---|---|
+| GET | `/dashboard` | current mode, last change time + who, content counts, recent activity |
+| PUT | `/site-mode` | `{mode}` → update settings, stamp who/when, log `site_mode.change` |
+| GET | `/posts?category=` | all posts incl. unpublished |
+| POST | `/posts` | create |
+| GET | `/posts/:id` | one |
+| PUT | `/posts/:id` | edit |
+| DELETE | `/posts/:id` | delete |
+| PATCH | `/posts/:id/publish` | `{published}` toggle (sets `published_at`) |
+| POST | `/posts/upload` | multipart image upload (multer) → `{image_url}` for screenshots |
+| GET | `/wiki` · GET `/wiki/:slug` | read incl. unpublished |
+| POST | `/wiki` · PUT `/wiki/:slug` · DELETE `/wiki/:slug` | manage pages |
+| GET | `/settings` · PUT `/settings` | read all / update `{key:value,...}` |
+| GET | `/activity?limit=&offset=` | paginated activity log |
+| GET | `/users` · POST `/users` · PUT `/users/:id` · DELETE `/users/:id` | user mgmt (can't delete self / last admin; password hashed on write) |
+
+Every admin write logs to `activity_log`.
+
+---
+
+## 5. Site mode (LIVE / MAINTENANCE)
+
+State in `settings.site_mode` (`live`|`maintenance`), default **maintenance**.
+
+`middleware/siteMode.js`, applied only to **public content** routes:
+- `live` → pass through.
+- `maintenance` → respond **503** with `{mode:"maintenance", message}` **unless** the request
+  carries a valid admin cookie (admin preview). This hides content server-side, not just in
+  the UI.
+
+Always reachable regardless of mode: static assets / SPA shell, `/api/v1/auth/*`, all
+`/api/v1/admin/*`. So admin login + panel + the maintenance "coming soon" page always load.
+
+**Client behavior (Phase 3):** reads `GET /public/settings`; if `maintenance` and not an
+admin previewing, render the polished dark coming-soon page (message + contact email).
+Admin "preview live" simply hits the content APIs with the admin cookie, which bypass the gate.
+
+Dashboard reads `site_mode` + `site_mode_changed_at`/`_by` for "current mode + last change +
+who"; `activity_log` provides the history feed.
+
+---
+
+## 6. Auth & security
+
+- **JWT** signed with `JWT_SECRET`, `expiresIn=JWT_EXPIRES_IN` (default `1d`); payload `{id,username,role}`.
+- **Cookie**: `httpOnly`, `sameSite=Lax`, `path=/`, and **`secure` decided per-request** (`COOKIE_SECURE=auto` → `secure: req.secure`). This is the key to dual access: the cookie is `Secure` when reached through Pangolin (HTTPS, `X-Forwarded-Proto: https`) but **not** `Secure` when reached directly over the LAN IP on plain HTTP — so login works in both. `COOKIE_SECURE=true|false` can force it. Requires `trust proxy` (below). `localhost:5173` (Vite) and `localhost:3000` are same-site, so the cookie flows in dev too.
+- **bcrypt** hashing (cost 10+); plaintext passwords never stored, logged, or returned.
+- **Rate limiting** (`express-rate-limit`) on `/auth/login` and `/public/contact`.
+- **Validation** (`express-validator`) on all writes; centralized error handler.
+- **helmet** with a CSP suited to the SPA (self + inline styles as needed; image sources for uploads/hero).
+- **Admin not indexed**: `X-Robots-Tag: noindex, nofollow` on `/api/v1/admin` and the admin SPA routes; `robots.txt` disallows `/admin`.
+- **No directory browsing** (express.static doesn't list; no `serve-index`).
+- **No hardcoded credentials**: first admin via `seed.js` reading `ADMIN_USERNAME`/`ADMIN_PASSWORD` from env (created only if no users exist); `.env` git-ignored, `.env.example` committed.
+- **`app.set('trust proxy', 1)`** so secure cookies, `req.ip`, and rate-limiting work behind Pangolin.
+- **CORS**: same-origin in prod (SPA served by Express). Dev only: allow `CLIENT_ORIGIN` (Vite, `http://localhost:5173`) with `credentials:true`.
+
+---
+
+## 7. Email
+
+`utils/mailer.js` (nodemailer) sends through **Gmail over OAuth2 (SMTP XOAUTH2)**, configured in
+Admin → Settings → Email — not env. The mailbox is authorized by an in-app "Connect Gmail" consent
+flow (`/admin/email/*`) that captures a refresh token, stored AES-GCM-encrypted in the `email_config`
+singleton (never returned over the API). The OAuth client id/secret are reused from the `google`
+auth-providers row. Recipient is the `contact_email` site setting. If email is unconfigured/disabled,
+`POST /public/contact` returns `{fallback:"mailto", email}` so the client renders a `mailto:` link
+instead. Errors never leak credentials.
+
+---
+
+## 7.5 Logging & observability
+
+`utils/logger.js` — a small dependency-free logger with **two transports, console + file**,
+and four levels (`error`/`warn`/`info`/`debug`). Each line is timestamped and tagged by
+subsystem (`[server]`, `[http]`, `[db]`, `[auth]`, `[admin]`, `[ratelimit]`, …).
+
+- **Console**: color on a TTY, plain in Docker; verbosity = `LOG_LEVEL` (default `info`).
+- **File**: plain text appended to `LOG_DIR/LOG_FILE` (default `<server>/logs/app.log`,
+  `/app/logs/app.log` in Docker, bind-mounted to `./logs`); verbosity = `FILE_LOG_LEVEL`
+  (default `debug`, so the file keeps a complete record while the console stays readable).
+  Toggle with `LOG_TO_FILE`. The stream is flushed on graceful shutdown.
+- **HTTP access logs** via morgan piped into the logger: real client IP (`trust proxy`),
+  authenticated admin username, method, URL, status, response time, size.
+- **Captured events**: startup config banner, schema/seed steps, login success/failure,
+  rate-limit hits, site-mode changes, maintenance-gate blocks (debug), all errors with
+  stack traces (5xx), and SIGINT/SIGTERM shutdown. Passwords and request bodies are never
+  logged. `unhandledRejection`/`uncaughtException` are caught and logged.
+
+## 8. Deployment
+
+**docker-compose.yml** — two services on a private network:
+- `db`: `mariadb:11`, env `MARIADB_DATABASE/USER/PASSWORD/ROOT_PASSWORD`, volume
+  `dbdata:/var/lib/mysql`, mounts `schema.sql` into `/docker-entrypoint-initdb.d`, healthcheck.
+- `app`: builds the Dockerfile (installs client+server, builds Vite, serves via Express),
+  `env_file: .env`, `DB_HOST=db`, `depends_on: db (healthy)`, volume `uploads:/app/uploads`,
+  `ports: "3000:3000"` — **binds 0.0.0.0** (no `127.0.0.1:` prefix) so Pangolin reaches it.
+- Volumes: `dbdata`, `uploads`.
+
+Express listens on `0.0.0.0:${PORT||3000}`. Pangolin terminates TLS and proxies to `app`.
+
+**.env.example** (committed; real `.env` ignored):
+```
+NODE_ENV=production
+PORT=3000
+DB_HOST=db
+DB_PORT=3306
+DB_NAME=uomysticmoon
+DB_USER=uomm
+DB_PASSWORD=
+DB_ROOT_PASSWORD=
+JWT_SECRET=
+JWT_EXPIRES_IN=1d
+COOKIE_SECURE=true
+COOKIE_NAME=uomm_token
+ADMIN_USERNAME=
+ADMIN_PASSWORD=
+# Email: configured in Admin → Settings → Email (Gmail OAuth2), not via env
+CLIENT_ORIGIN=http://localhost:5173
+```
+
+`.gitignore`: `node_modules/`, `.env`, `_reference/`, `client/dist/`, `uploads/`.
+
+---
+
+## 9. Dependencies (server)
+
+`express, cors, helmet, morgan, dotenv, mariadb, jsonwebtoken, bcryptjs, cookie-parser,
+express-rate-limit, express-validator, multer, nodemailer` · dev: `nodemon`.
+Removed vs serverlinkr: `mongoose, mongodb, connect-mongo, express-session, passport,
+passport-local`.
+
+---
+
+## 10. Spec coverage
+
+| Spec requirement | Covered by |
+|---|---|
+| Public pages (`/`, `/site/*`, `/wiki/*`) | `/public/*` API + Phase-3 SPA routes; content from `posts`/`wiki`/`settings` |
+| News / 5-on-Friday / Newsletter / Screenshots | `posts` table, `category` column; admin CRUD + publish |
+| Wiki 8 categories, editable later | `wiki_pages` seeded with 8 slugs; admin CRUD |
+| Status page | `settings.status_message` + mode via `/public/status` |
+| Admin dashboard (mode, last change, who) | `/admin/dashboard` + settings stamps + activity log |
+| Site mode toggle | `PUT /admin/site-mode` + `siteMode` middleware |
+| Admin activity log | `activity_log` + `/admin/activity` |
+| Admin user management | `/admin/users` CRUD |
+| Site settings editing | `/admin/settings` |
+| JWT, bcrypt, rate limit, secure cookies, noindex, no dir browsing, no hardcoded creds, .env | §6 |
+| Maintenance page, admin always in, static always loads, admin preview | §5 |
+| SMTP via env, mailto fallback | §7 |
+| Docker Compose + MariaDB + Pangolin, 0.0.0.0 bind | §8 |
+| Design tokens / hero | reused from existing `assets/css/mysticmoon.css` + hero PNG in Phase 2/3 |
+| Expandable | key/value settings, role enum, modular routers/models |
+```

website/HERO_EDITOR.md

@@ -0,0 +1,134 @@
+# UOMysticmoon — Hero Canvas Editor Spec
+
+> Branch: **`hero-feature`**. Build contract for the WYSIWYG portal-hero editor.
+> Derived from the design doc *Hero Canvas Editor — Design Document*, **corrected
+> to match the current codebase** and with the open questions resolved.
+> Same workflow as the wiki upgrade: design → phased build → verify.
+
+## 1. Goal
+
+Let staff compose the portal hero (background image, overlay opacity, and floating
+elements — text, CTA buttons, moon, badge, image) in-browser, then preview and
+publish — no source edits. Layout persists as JSON in the existing `settings` table.
+
+## 2. Locked decisions
+
+| # | Decision |
+|---|---|
+| Scope | **Full v1** — background/overlay, all element types, drag/resize/z-order, draft→preview→publish (built in phases) |
+| CTA buttons | **First-class `buttons` element type** (independently positioned), not baked into a text block |
+| First run | **Pre-populate** the canvas with today's hero (headline, subtitle, teaser, CTAs) as editable elements so nothing changes visually until edited |
+| Drag | **Native Pointer Events** (mouse/touch/pen), zero dependencies |
+| Font size | Stored in **px** (fixed reference canvas) |
+| Image compression | **None** server-side; client warns when a file is > ~1 MB |
+| Preview | `?preview=1` renders the **draft** by reading it through the authenticated admin settings endpoint |
+| Other pages | Out of scope for v1 (design allows a per-page key later) |
+
+## 3. Corrections to the design doc (current-code reality)
+
+1. **Public settings is a whitelist, not `getAll()`.** `GET /api/v1/public/settings`
+   → `settings.getPublic()` → `PUBLIC_KEYS` in
+   [settings.model.js](server/src/model/settings/settings.model.js). The doc's
+   "no backend changes / picked up automatically" is wrong. **Fix:** add
+   `hero_layout` to `PUBLIC_KEYS` (one line). `hero_layout_draft` stays out
+   (admin-only) — which is why preview reads the draft via `api.admin.getSettings()`.
+2. **Moon is a reusable component** ([MoonDot.jsx](client/src/components/MoonDot.jsx),
+   props `size`/`glow`), used in logo/login/maintenance — not "only the header."
+   The `moon` element reuses it; it gains an optional `color`.
+3. **Route vs. nav live in different files.** `/admin/hero` route →
+   [App.jsx](client/src/App.jsx); sidebar link/title → `NAV`/`TITLES` in
+   [AdminLayout.jsx](client/src/routes/admin/AdminLayout.jsx).
+4. **Admin content area is `maxWidth: 1000px`** — the editor canvas renders
+   scaled-to-fit; percentage positions stay faithful.
+
+Everything else in the doc matches (hardcoded `HERO_BG` + CTAs + `homepage_teaser`
+in [Portal.jsx](client/src/routes/public/Portal.jsx); `updateSettings` accepts
+arbitrary keys; `/admin/uploads` exists; default hero asset present; TEXT settings
+columns — no schema change).
+
+## 4. Data model — no schema change
+
+Two `settings` keys (TEXT): `hero_layout` (live) and `hero_layout_draft` (admin).
+
+```jsonc
+{
+  "version": 1,
+  "background": { "image_url": null, "position_x": "left", "position_y": "center", "size": "cover" },
+  "overlay": { "opacity": 0.72 },
+  "elements": [
+    { "id": "uuid", "type": "text_block|buttons|moon|badge|image",
+      "x": 50, "y": 42, "z": 1, "anchor": "center", "props": { /* per type */ } }
+  ]
+}
+```
+
+Positions are **% of canvas** (reference width 1080, matching `.shell`), so the
+layout adapts across viewports without breakpoint data. `version` is validated
+(`=== 1`) before use; anything else falls back.
+
+### Element props
+
+| Type | Props |
+|---|---|
+| `text_block` | `lines: [{ text, tag(h1/h2/p/span), fontSize(px), color, weight }]`, `align` |
+| `buttons` | `items: [{ label, to, variant(primary/ghost) }]`, `align`, `gap` |
+| `moon` | `size`, `glow`, `color` |
+| `badge` | `text`, `bgColor`, `textColor`, `borderRadius` |
+| `image` | `src`, `width`(%), `alt` |
+
+## 5. Backend changes
+- **One line:** add `'hero_layout'` to `PUBLIC_KEYS`. No new routes/controllers —
+  layout saves through the existing `PUT /admin/settings`; images via `/admin/uploads`.
+
+## 6. Frontend changes
+- **New** `client/src/components/HeroElement.jsx` — renders one element by type
+  (shared by the live portal and the editor canvas).
+- **New** `client/src/routes/admin/views/HeroEditor.jsx` — canvas + element tray +
+  properties panel; native-pointer drag/resize; background/overlay panel; snap grid;
+  auto-save draft, preview, publish, revert.
+- **Edit** [Portal.jsx](client/src/routes/public/Portal.jsx) — parse `hero_layout`
+  (or draft when `?preview=1` + admin), render elements, fall back to a
+  `DEFAULT_LAYOUT` built from today's hero so the page is unchanged until edited.
+- **Edit** [AdminLayout.jsx](client/src/routes/admin/AdminLayout.jsx) (nav) +
+  [App.jsx](client/src/App.jsx) (route `/admin/hero`).
+- **Edit** [MoonDot.jsx](client/src/components/MoonDot.jsx) — optional `color`.
+- **No** `client/src/api/client.js` changes needed beyond what exists
+  (`admin.updateSettings`, `admin.getSettings`, `admin.upload`).
+
+## 7. Phased build (each phase: build → verify in preview → commit)
+
+- **Phase 0 — Spec** ✅ this document.
+- **Phase 1 — Data path & renderer** ✅ (verified 2026-06-28). `hero_layout`
+  whitelisted; `HeroElement.jsx`; Portal renders the layout with a `DEFAULT_LAYOUT`
+  fallback. Default render matches the old hero; publishing a layout re-renders;
+  draft key not exposed publicly. Shared helpers moved to `client/src/lib/heroLayout.js`.
+- **Phase 2 — Editor shell + background/overlay** ✅ (verified 2026-06-28).
+  `/admin/hero` view + sidebar nav; canvas live-preview; background upload + 3×3
+  position + overlay opacity; debounced draft auto-save; publish; `?preview=1`
+  reads the draft (admin) with a banner; revert. Verified: overlay/position update
+  the canvas, auto-save writes the draft, publish writes live, preview shows the
+  draft while the normal portal shows live.
+- **Phase 3 — Elements: select / drag / text_block / buttons** ✅ (verified
+  2026-06-28). Element tray (+ Text / + Buttons); click-to-select with outline;
+  native Pointer Events drag (% of canvas); Delete key + panel delete; z-order
+  (send back / bring forward); text_block line editor (text/tag/size/color/bold,
+  add/remove lines, align) and buttons editor (label/path/variant, add/remove).
+  Verified: select shows the line editor, editing a line updates the canvas live,
+  drag moved 50%→65%, add→3/delete→2 elements, empty-canvas click deselects.
+- **Phase 4 — moon + badge + image + resize + snap grid** ✅ (verified 2026-06-28).
+  Tray adds moon/badge/image; property panels (moon: size/glow/color; badge:
+  text/colors/radius; image: upload/width/alt); corner resize handle (image→width%,
+  moon→size, text→box width); 8px snap-grid toggle with overlay; image placeholder
+  until a file is chosen. Verified: each type adds + edits, resize moved a moon
+  64→104px, snap grid shows, and a published moon+badge render on the live portal.
+
+**Status: v1 feature-complete.** All phases verified end-to-end; ready for PR.
+Deferred (noted in the design doc as follow-ups): 8-point resize (only a corner
+handle for now), per-viewport layouts, server-side image compression.
+
+## 8. Edge cases (from the doc, carried forward)
+- `JSON.parse` wrapped in try/catch + `version` check → fall back to `DEFAULT_LAYOUT`.
+- Element ids via `crypto.randomUUID()` (never array index).
+- Empty `elements` → render `DEFAULT_LAYOUT` so the hero is never blank.
+- Last-write-wins on concurrent admin edits (acceptable for this shard).
+- Client-side warning for background files > ~1 MB (no hard block; 8 MB server cap).

website/WIKI_UPGRADE.md

@@ -0,0 +1,366 @@
+# UOMysticmoon Website — Wiki Upgrade Spec
+
+> Branch: **`wiki-upgrade`**. This document is the contract for upgrading the CMS
+> wiki from a flat single-table page store into a feature-complete wiki.
+> It follows the project workflow: **design (this doc) → build in phases → verify**.
+>
+> Companion to [`BACKEND_DESIGN.md`](BACKEND_DESIGN.md); reuses its stack, auth,
+> logging, and Docker decisions unchanged.
+
+---
+
+## 1. Goal & scope
+
+Turn the wiki into something that behaves like a typical wiki, while staying inside
+the existing Node/Express + MariaDB + React/Vite architecture and the **staff-only**
+auth model (admin/editor — no new roles, no public contributions).
+
+**In scope**
+
+| Feature | Summary |
+|---|---|
+| Rich-text editing | TipTap (ProseMirror) WYSIWYG in the admin; outputs HTML |
+| Sanitization | Server-side allowlist on save **and** client-side on render (fixes today's stored-XSS gap) |
+| Categories / sections | First-class `wiki_categories` table; replaces hardcoded frontend blurbs |
+| Drafts & publish | `published` + `published_at`, mirroring the `posts` pattern |
+| Tags | Many-to-many tags with filtering |
+| Internal links | `[[slug]]`-style links authored in the editor; red-link detection |
+| Backlinks | "Linked from" list, maintained on save |
+| Inline images | Reuse/generalize the existing multer upload for in-body images |
+| Search | MariaDB `FULLTEXT` over title + body |
+| Revision history | Per-save snapshots with view / diff / restore |
+
+**Out of scope (this branch)**
+
+- Public/player editing or suggestion workflow, moderation/review queues.
+- New roles or per-page ACLs (all staff with a login can edit all pages).
+- Real-time collaborative editing, comments/discussion pages, file attachments
+  other than images, page templates/transclusion, multilingual pages.
+
+**Decisions locked from planning**
+
+- Editor: **TipTap**, storing **HTML** (not Markdown, not JSON).
+- Search: **MariaDB FULLTEXT** (no new infrastructure).
+- Revision history and search are **included** (recommended additions beyond the
+  minimum requested set).
+- Authoring is **admin + editor** (`isLoggedIn`); no anonymous edits.
+
+---
+
+## 2. Current state (baseline being replaced)
+
+| Layer | Today | File |
+|---|---|---|
+| Schema | flat `wiki_pages(slug,title,body,updated_by,timestamps)` | [server/db/schema.sql:31](server/db/schema.sql) |
+| Model | thin CRUD by slug | [server/src/model/wiki/wiki.db.js](server/src/model/wiki/wiki.db.js), [wiki.model.js](server/src/model/wiki/wiki.model.js) |
+| Public API | `GET /public/wiki`, `GET /public/wiki/:slug` | [public.controller.js:53](server/src/router/v1/public/public.controller.js) |
+| Admin API | `GET/POST/PUT/DELETE /admin/wiki[...]` | [admin.controller.js:163](server/src/router/v1/admin/admin.controller.js), [admin.routes.js:68](server/src/router/v1/admin/admin.routes.js) |
+| Public UI | card grid (hardcoded blurbs + Roman numerals), article w/ auto-TOC | [Wiki.jsx](client/src/routes/wiki/Wiki.jsx), [WikiArticle.jsx](client/src/routes/wiki/WikiArticle.jsx) |
+| Admin UI | raw-HTML `<textarea>` modal | [WikiAdmin.jsx](client/src/routes/admin/views/WikiAdmin.jsx), [WikiEditor.jsx](client/src/routes/admin/views/WikiEditor.jsx) |
+| API client | `api.wiki`, `api.admin.*Wiki` | [client/src/api/client.js:52](client/src/api/client.js) |
+
+**Known issues this upgrade resolves**
+
+- **Stored XSS**: body is raw HTML rendered with `dangerouslySetInnerHTML` and never
+  sanitized ([WikiArticle.jsx:91](client/src/routes/wiki/WikiArticle.jsx)).
+- Category blurbs and ordering are **faked in the component** ([Wiki.jsx:11](client/src/routes/wiki/Wiki.jsx)), not data.
+- No drafts (every save is instantly public), no history, no search, no tags, no links.
+
+---
+
+## 3. Data model
+
+`utf8mb4`, InnoDB throughout. All changes are **additive and idempotent** so
+`ensureSchema()` upgrades existing databases on boot with no data loss. New columns
+are nullable or have safe defaults; **existing pages default to `published = 1`** so
+nothing disappears on deploy.
+
+### 3.1 `wiki_categories` (new)
+
+| col | type | notes |
+|---|---|---|
+| id | INT PK AI | |
+| slug | VARCHAR(120) UNIQUE NOT NULL | e.g. `guides` |
+| title | VARCHAR(200) NOT NULL | |
+| description | VARCHAR(400) NULL | card teaser on the wiki index |
+| sort_order | INT NOT NULL DEFAULT 0 | manual ordering |
+| created_at / updated_at | DATETIME | standard stamps |
+
+### 3.2 `wiki_pages` (altered)
+
+Add to the existing table:
+
+| col | type | notes |
+|---|---|---|
+| category_id | INT NULL FK→wiki_categories(id) ON DELETE SET NULL | |
+| excerpt | VARCHAR(400) NULL | card/search teaser (replaces hardcoded blurbs) |
+| published | TINYINT(1) NOT NULL DEFAULT 1 | draft/publish toggle |
+| published_at | DATETIME NULL | set on first publish |
+| sort_order | INT NOT NULL DEFAULT 0 | ordering within a category |
+| FULLTEXT idx_wiki_search (title, body) | | search |
+
+### 3.3 `wiki_tags` + `wiki_page_tags` (new)
+
+```
+wiki_tags( id PK, slug VARCHAR(120) UNIQUE, label VARCHAR(120) )
+wiki_page_tags( page_id FK→wiki_pages ON DELETE CASCADE,
+                tag_id  FK→wiki_tags  ON DELETE CASCADE,
+                PRIMARY KEY(page_id, tag_id) )
+```
+
+### 3.4 `wiki_links` (new) — backlinks index
+
+Rebuilt for a page on every save by parsing its body for internal links.
+
+| col | type | notes |
+|---|---|---|
+| source_page_id | INT FK→wiki_pages ON DELETE CASCADE | |
+| target_slug | VARCHAR(120) NOT NULL | may point at a not-yet-created page (red link) |
+| INDEX idx_wiki_links_target (target_slug) | | backlink lookups |
+
+Backlinks for page X = `SELECT source pages WHERE target_slug = X.slug AND source is published`.
+
+### 3.5 `wiki_revisions` (new) — history
+
+| col | type | notes |
+|---|---|---|
+| id | INT PK AI | |
+| page_id | INT FK→wiki_pages ON DELETE CASCADE | |
+| title / body / excerpt | snapshot of content at save time | |
+| category_id | INT NULL | snapshot |
+| editor_id | INT NULL FK→users(id) | who saved |
+| change_note | VARCHAR(280) NULL | optional summary |
+| created_at | DATETIME DEFAULT CURRENT_TIMESTAMP | |
+
+A revision is written **inside the same transaction** as each page create/update.
+
+### 3.6 Seed changes
+
+Rework [seed.js](server/db/seed.js): the current 8 hardcoded pages become **categories**
+(title + the blurb currently living in the frontend), each seeded idempotently via a new
+`seedDefaultCategory`. Existing seeded pages are migrated/attached where applicable.
+`seedDefault` for pages stays `INSERT IGNORE` so reseeding is safe.
+
+---
+
+## 4. Backend changes
+
+Keep the `model` (entity) / `db` (SQL) split and the route grouping by access level.
+
+### 4.1 Models (`server/src/model/wiki/`)
+
+- `wiki.db.js` — add SQL for: category CRUD; page list with `category`, `published`,
+  `q` (FULLTEXT) filters and ordering; tag upsert + attach/detach; `wiki_links` rebuild;
+  revision insert/list/get; backlink query.
+- `wiki.model.js` — orchestration. On **create/update** (single transaction):
+  1. sanitize `body` with the allowlist (§6),
+  2. upsert the page,
+  3. insert a `wiki_revisions` snapshot,
+  4. parse body for internal links → rebuild `wiki_links` for the page,
+  5. sync tags.
+- A small `wiki.links.js` helper: parse internal links out of the saved HTML
+  (anchors written by the editor as `href="/wiki/<slug>"` / a `data-wiki-slug` attr),
+  return the set of target slugs.
+
+### 4.2 Public API (`/api/v1/public`)
+
+| Method | Path | Notes |
+|---|---|---|
+| GET | `/wiki/categories` | ordered categories with page counts |
+| GET | `/wiki?category=&tag=&q=` | **published only**; list/filter/search summaries |
+| GET | `/wiki/:slug` | page + category + tags + backlinks (published only) |
+
+Still passes through the `siteMode` maintenance gate like other public content.
+
+### 4.3 Admin API (`/api/v1/admin`, behind `isLoggedIn` + `noindex`)
+
+| Method | Path | Purpose |
+|---|---|---|
+| GET | `/wiki` | all pages incl. drafts (filters: category, tag, q, status) |
+| GET | `/wiki/:slug` | one page incl. draft, tags, category |
+| POST | `/wiki` | create (slug, title, body, excerpt, category_id, tags, published) |
+| PUT | `/wiki/:slug` | update (allows slug rename — see §7) |
+| PATCH | `/wiki/:slug/publish` | `{published}` toggle, stamps `published_at` |
+| DELETE | `/wiki/:slug` | delete (cascades revisions/links/tags) |
+| GET | `/wiki/:slug/revisions` | list snapshots |
+| GET | `/wiki/:slug/revisions/:id` | one snapshot (for diff/preview) |
+| POST | `/wiki/:slug/revisions/:id/restore` | restore (writes a new revision) |
+| GET/POST/PUT/DELETE | `/wiki/categories[...]` | category CRUD + reorder |
+| GET/POST | `/wiki/tags` | list/create tags |
+| POST | `/uploads` | generalized image upload (see §4.4) → `{url}` |
+
+Validation via `express-validator` (slug regex `^[a-z0-9-]+$`, title required, etc.),
+centralized error handler unchanged. **Every write logs to `activity_log`**
+(`wiki.create`, `wiki.update`, `wiki.publish`, `wiki.delete`, `wiki.revision.restore`,
+`wiki.category.*`) following the existing convention.
+
+### 4.4 Image uploads
+
+Generalize the existing screenshot upload (multer config in [admin.routes.js:17](server/src/router/v1/admin/admin.routes.js))
+into a shared `POST /admin/uploads` returning `{ url: "/uploads/<file>" }`, reused by both
+the post editor and the wiki editor. Same size/mime limits. No new storage —
+served from the existing `uploads/` volume.
+
+---
+
+## 5. Frontend changes
+
+### 5.1 Admin
+
+- **`WikiEditor.jsx`** — replace the raw-HTML `<textarea>` with a **TipTap** editor:
+  bold/italic/headings (H2 for TOC)/lists/quote/code, link tool, **image insert**
+  (uploads via `/admin/uploads`), and an **internal-link picker** (`[[`-triggered
+  autocomplete over existing slugs; flags red links). Adds: category dropdown, tag
+  input (create-on-type), excerpt field, **Save draft / Publish** actions, and a
+  **History** tab (revision list → preview → diff → restore).
+- **`WikiAdmin.jsx`** — list gains status (draft/published), category column, and
+  filters; plus a **Categories** manager (CRUD + drag-to-reorder).
+
+### 5.2 Public
+
+- **`Wiki.jsx`** — fully data-driven: categories + real excerpts from the API
+  (delete the hardcoded `BLURBS`/`ROMAN` constants), a **search box**, optional
+  tag filter.
+- **`WikiArticle.jsx`** — keep auto-TOC; add category breadcrumb, tag chips, a
+  **"Linked from"** backlinks section, "last updated by", and **render via DOMPurify**
+  (`dangerouslySetInnerHTML` only after sanitize).
+
+### 5.3 API client & routes
+
+- Extend [client/src/api/client.js](client/src/api/client.js) with the new public/admin
+  wiki calls (categories, search params, revisions, tags, uploads).
+- Add a public search/category route if needed; admin categories view registered in
+  [App.jsx](client/src/App.jsx) under `/admin/wiki` (sub-tab, no new top-level route required).
+
+### 5.4 Dependencies (new)
+
+- **client**: `@tiptap/react`, `@tiptap/starter-kit`, `@tiptap/extension-link`,
+  `@tiptap/extension-image` (+ a small diff lib for history, e.g. `diff`); `dompurify`.
+- **server**: `sanitize-html`.
+
+(The client currently ships only React + react-router, so this is the first feature
+dependency addition — keep the bundle lean, import only the extensions used.)
+
+---
+
+## 6. Security
+
+- **Two-layer sanitization.** Server sanitizes on save with a strict `sanitize-html`
+  allowlist (headings, p, lists, blockquote, code/pre, a[href], img[src,alt],
+  strong/em, hr, table basics); strips scripts, event handlers, `javascript:` URLs,
+  styles. Client re-sanitizes with DOMPurify before render. The stored value is already
+  clean, so even direct DB edits or future API clients can't inject script.
+- **Upload safety** unchanged from posts: mime allowlist (png/jpe/gif/webp/avif),
+  8 MB cap, random filenames, served as static files (no execution).
+- **Authorization**: all mutating wiki/category/tag/upload routes stay behind
+  `isLoggedIn` (admin or editor). Public routes are read-only and published-only.
+- **No secrets/logging changes**; reuse existing rate-limit, helmet/CSP, noindex.
+  CSP `img-src` already covers `/uploads`.
+
+---
+
+## 7. Migration & backward compatibility
+
+- Schema migration is additive; run by `ensureSchema()` on boot and shipped in
+  `schema.sql` for fresh containers. Use `ALTER TABLE ... ADD COLUMN IF NOT EXISTS`
+  / `ADD INDEX` guarded for idempotency (MariaDB 11 supports `IF NOT EXISTS`).
+- Existing pages: `published` backfills to `1`, `published_at` to `updated_at`,
+  `category_id` left NULL (surface as "Uncategorized" until assigned).
+- **Slug rename** (new capability): on `PUT` slug change, update the page slug and
+  best-effort rewrite known internal links pointing at the old slug; old slug is not
+  auto-redirected (acceptable for a staff-curated wiki) — note in release notes.
+- Public API response shape is **extended, not broken**: existing fields
+  (`slug`, `title`, `body`, `updated_at`) remain; new fields are additive, so the
+  current frontend keeps working between phases.
+
+---
+
+## 8. Implementation process (phased)
+
+Each phase is a self-contained, shippable unit: build → run locally → verify in the
+browser preview → commit on `wiki-upgrade`. Open a PR into `main` at the end (or per
+phase if preferred). Do not merge a phase that hasn't been verified.
+
+### Phase 0 — Branch & scaffolding ✅ (this doc)
+- `wiki-upgrade` branch created; this spec committed.
+
+### Phase 1 — Foundation & safety (highest value) ✅
+- Schema: add `wiki_categories`, alter `wiki_pages` (category_id, excerpt, published,
+  published_at, sort_order, FULLTEXT), update `seed.js`.
+- Server: server-side sanitization on save; drafts/publish endpoints; categories CRUD;
+  public list filtered to published + categories endpoint.
+- Client: data-driven `Wiki.jsx` (remove hardcoded blurbs); DOMPurify render in
+  `WikiArticle.jsx`; draft/publish + category in the (still-textarea) admin editor.
+- **Exit check**: existing pages still render; XSS payload in body is neutralized;
+  draft pages hidden from the public list/article.
+- **Verified** (2026-06-27): schema migration ran clean on MariaDB 11; XSS payload
+  (`<script>`, `onerror=`, `javascript:`) stripped server-side; drafts return 404 on
+  the public API and are absent from the public list while visible in admin; public
+  index is data-driven (categories + sections); article shows category breadcrumb;
+  client builds and server boots with no errors.
+
+### Phase 2 — Authoring UX ✅
+- TipTap editor replaces the textarea; generalized `/admin/uploads`; inline images.
+- **Exit check**: create/edit a page with headings, a list, a link, and an inline
+  image; verify it renders sanitized on the public page.
+- **Verified** (2026-06-27): `/admin/uploads` returns `{url}` and the file serves as
+  an image; a page authored with H2/H3, lists, a link, and an uploaded inline image
+  round-trips through the WYSIWYG and renders sanitized publicly (link `rel` forced,
+  `<script>` stripped); a toolbar edit (insert divider) saved and persisted. TipTap
+  is code-split into its own chunk (lazy-loaded), keeping it off the public bundle.
+
+### Phase 3 — Connectivity ✅
+- Internal `[[slug]]` links + red-link detection; `wiki_links` rebuild on save;
+  backlinks on the article; tags + tag/category filtering.
+- **Exit check**: link page A→B, confirm B shows A under "Linked from"; tag filter works.
+- **Verified** (2026-06-27): internal links authored via an in-editor page picker
+  (links to `/wiki/<slug>`); A→B made B list A under "Linked from"; a link to a
+  non-existent page renders as a red link; removing the link on save cleared the
+  backlink (link index rebuilt). Tags upsert on save, filter via `?tag=` (chips +
+  flat index view), list with published counts, and orphan tags are auto-pruned.
+- Implementation note: links are plain anchors to `/wiki/<slug>` (the WYSIWYG fits
+  this better than `[[ ]]` syntax); the sanitizer also allows `data-wiki-slug`.
+
+### Phase 4 — Discovery & trust ✅
+- FULLTEXT search (public search box + admin filter); revision history list /
+  diff / restore.
+- **Exit check**: search returns expected pages; edit a page twice, diff the
+  revisions, restore an older one, confirm a new revision is recorded.
+- **Verified** (2026-06-27): `?q=` natural-language search matches on both body
+  (`recipes`→crafting) and title (`monsters`); the public search box and admin
+  filter both work. A page edited twice produced 3 revisions; the History modal
+  shows a word-level diff (added vs removed) of an old revision against current;
+  restoring reverted the page and appended a "Restored from revision #N" entry.
+
+### Verification (every phase)
+Use the preview workflow, not manual hand-off: start the dev server, exercise the
+public wiki and the admin editor, check console/network for errors, and capture a
+screenshot of the changed surface. Confirm `npm run` lint/build passes for the client
+and the server boots cleanly with `ensureSchema()` applying the migration.
+
+---
+
+## 9. File-change map (reference)
+
+| Area | Files |
+|---|---|
+| Schema/seed | `server/db/schema.sql`, `server/db/seed.js`, `server/src/utils/db.js` (ensureSchema) |
+| Models | `server/src/model/wiki/wiki.db.js`, `wiki.model.js`, **new** `wiki.links.js` |
+| API | `server/src/router/v1/public/public.{routes,controller}.js`, `server/src/router/v1/admin/admin.{routes,controller}.js` |
+| Sanitize | **new** `server/src/utils/sanitizeHtml.js` |
+| Client API | `client/src/api/client.js` |
+| Public UI | `client/src/routes/wiki/Wiki.jsx`, `WikiArticle.jsx` |
+| Admin UI | `client/src/routes/admin/views/WikiAdmin.jsx`, `WikiEditor.jsx`, **new** category manager + revisions view |
+| Deps | `client/package.json`, `server/package.json` |
+
+---
+
+## 10. Open questions / assumptions
+
+1. **Slug redirects**: assumed not needed on rename (staff wiki). Revisit if pages get
+   external inbound links.
+2. **Search ranking**: FULLTEXT natural-language mode assumed; can switch to BOOLEAN
+   mode if operators are wanted later.
+3. **Diff granularity**: line/word diff of the HTML source is assumed sufficient for
+   revision compare; a rendered visual diff is a later nice-to-have.
+4. **Editor scope**: tables and embeds beyond images are deferred unless requested.

website/website-README.md

@@ -0,0 +1,496 @@
+# Runic Gateway Website
+
+Public site, wiki, and protected admin panel for a private Ultima Online shard — a
+full-stack app in one repo. Branding is instance-configurable via `BRAND_*` (see
+[Branding](#branding)); **UOMysticmoon** is the first instance.
+
+A full-stack app in one repo:
+
+- **Backend** — Node.js + Express REST API (layered `router → controller → model → db`), MariaDB, a provider-agnostic session layer (JWT cookie for web, bearer tokens for mobile, pluggable SSO).
+- **Frontend** — React + Vite single-page app (public site, wiki, and the admin panel), dark "gothic" theme (Cinzel + Georgia).
+- **Deploy** — Docker Compose (app + MariaDB) behind a Pangolin reverse proxy. Express serves the built SPA in production.
+- **Shard link** — a live bridge to the in-game ServUO shard through the **uo-link** sidecar ([RunicGateway/link](https://gitea.whitlocktech.com/RunicGateway/link)): the site ingests a live event feed and makes server-side REST calls to show shard status, economy, staff presence, IDOCs, live activity, and per-character sheets. See [Shard integration (uo-link)](#shard-integration-uo-link).
+
+The design reference is [BACKEND_DESIGN.md](BACKEND_DESIGN.md) (API contract, schema, security).
+
+---
+
+## Contents
+
+- [Tech stack](#tech-stack)
+- [Project structure](#project-structure)
+- [Prerequisites](#prerequisites)
+- [Setup & run](#setup--run)
+  - [Option A — Docker Compose (full stack)](#option-a--docker-compose-full-stack)
+  - [Option B — Local development (hot reload)](#option-b--local-development-hot-reload)
+  - [Option C — Production build without Docker](#option-c--production-build-without-docker)
+- [First admin & site mode](#first-admin--site-mode)
+- [Pages & routes](#pages--routes)
+- [API endpoints](#api-endpoints)
+- [API documentation (Swagger)](#api-documentation-swagger)
+- [Shard integration (uo-link)](#shard-integration-uo-link)
+- [Environment variables](#environment-variables)
+- [Security](#security)
+- [Logging](#logging)
+- [Deployment behind Pangolin](#deployment-behind-pangolin)
+
+---
+
+## Tech stack
+
+| Layer | Tech |
+|---|---|
+| Backend | Node.js 20+, Express 4, `mariadb` driver (parameterized SQL, no ORM) |
+| Auth | Session service over JWT: httpOnly cookie (web) + bearer access/refresh tokens (mobile), bcrypt hashing, optional TOTP 2FA (`speakeasy` + `qrcode`), pluggable OAuth2/OIDC SSO (built-in Google & Discord + generic) |
+| Database | MariaDB 11 (own container) |
+| Frontend | React 18, Vite 5, React Router 6 |
+| Email | Nodemailer via Gmail OAuth2 (configured in admin), with a `mailto:` fallback |
+| API docs | OpenAPI 3.0 via `swagger-autogen`, served with `swagger-ui-express` at `/api/docs` |
+| Deploy | Docker Compose, Pangolin reverse proxy |
+
+---
+
+## Project structure
+
+```
+UOMSITE/
+├─ server/                     Express API
+│  ├─ src/
+│  │  ├─ server.js             bootstrap: ensure schema → seed → listen (0.0.0.0)
+│  │  ├─ app.js                middleware + static SPA + routes
+│  │  ├─ auth/                 session layer: session.service · token (JWT/cookies) · session.middleware · ssoState (PKCE/CSRF) · providers/ (base · oauth2 · google · discord · genericOidc · registry)
+│  │  ├─ router/v1/            auth (web · mobile · sso) / public / admin route groups
+│  │  ├─ model/                users · posts · wiki · settings · activity · mobileSessions · authProviders · userIdentities (.model + .db)
+│  │  ├─ middleware/           siteMode · noindex · rateLimit · loginProtection · botScore · validate
+│  │  └─ utils/                auth (compat facade) · totp (2FA) · secretBox (AES-GCM secrets) · db (pool) · mailer · logger
+│  ├─ db/                      schema.sql + seed.js
+│  ├─ swagger/                 swagger.js (OpenAPI generator config) + swagger-output.json (generated spec)
+│  └─ .env.example
+├─ client/                     React + Vite SPA
+│  ├─ src/
+│  │  ├─ routes/public/        Portal, Website, News, Screenshots, FiveOnFriday, Newsletter(+Issue), Status, About, Maintenance
+│  │  ├─ routes/wiki/          Wiki landing + WikiArticle
+│  │  ├─ routes/admin/         AdminLogin (password + TOTP + SSO buttons), AdminLayout, views/ (Dashboard, Posts, Wiki, Settings, Activity, Bot Activity, Authentication, Users, Account) + editors
+│  │  ├─ components/           SiteHeader, SiteFooter, layout, guards, Modal, ProviderIcon (inline SSO SVGs), …
+│  │  ├─ contexts/             AuthContext, SiteContext
+│  │  ├─ api/client.js         fetch wrapper (sends cookies)
+│  │  └─ styles/theme.css      design tokens
+│  └─ public/assets/img/       hero image
+├─ Dockerfile                  builds client → serves via Express
+├─ docker-compose.yml          app + MariaDB
+├─ .env.example                root env (used by Compose)
+└─ package.json                workspace scripts
+```
+
+---
+
+## Prerequisites
+
+- **Node.js 20+** and npm (Node 22/24 are fine).
+- **Docker Desktop** (for MariaDB, and for the full Compose deploy).
+
+---
+
+## Setup & run
+
+### Option A — Docker Compose (full stack)
+
+`docker-compose.yml` is **production-shaped**: it *pulls* the prebuilt `app` and `bot` images from
+the Gitea container registry (published by `.gitea/workflows/build-images.yml` on every merge to
+`main`) — it never builds. Each image already bundles the server deps and the built React client,
+which Express serves. MariaDB runs in its own container; tables + defaults + the first admin are
+created automatically on first boot.
+
+```bash
+cp .env.example .env
+# Edit .env and set at least:
+#   DB_PASSWORD, DB_ROOT_PASSWORD   (any strong values)
+#   JWT_SECRET                      (a long random string)
+#   ADMIN_USERNAME, ADMIN_PASSWORD  (your first admin login)
+
+docker compose pull && docker compose up -d          # IMAGE_TAG defaults to `latest`
+# pin a specific build (reproducible deploy / rollback):
+IMAGE_TAG=sha-042a151 docker compose pull && docker compose up -d
+```
+
+- App: **http://localhost:3000** (binds `0.0.0.0`)
+- Health check: `GET http://localhost:3000/api/health` → `{ "status": "ok" }`
+- Logs: `docker compose logs -f app` (and `./logs/app.log` on the host)
+- Stop: `docker compose down` (add `-v` to also wipe the database + uploads volumes)
+
+**Build the images locally instead of pulling** (offline, or to test an unmerged change) — overlay
+the dev file, which adds `build:` back:
+
+```bash
+docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build
+```
+
+Keeping `build:` out of the base file means a production host can only ever pull — it can never
+accidentally build.
+
+### Option B — Local development (hot reload)
+
+Run the API and the Vite dev server separately. The Vite server proxies `/api` and `/uploads`
+to the backend, so the SPA stays same-origin (cookies work).
+
+**1. Start a MariaDB the backend can reach** (published on `localhost:3306`):
+
+```bash
+docker run -d --name rg-db -p 3306:3306 -e MARIADB_DATABASE=runic_gateway -e MARIADB_USER=runic -e MARIADB_PASSWORD=devpass -e MARIADB_ROOT_PASSWORD=rootpass mariadb:11
+```
+
+**2. Configure + start the backend** (terminal 1):
+
+```bash
+cp server/.env.example server/.env
+# Set DB_HOST=127.0.0.1, DB_PORT=3306, DB_USER=runic, DB_PASSWORD=devpass,
+#     JWT_SECRET=<anything>, ADMIN_USERNAME=admin, ADMIN_PASSWORD=<your password>
+npm run install-server
+npm run server          # nodemon → http://localhost:3000
+```
+
+**3. Start the frontend** (terminal 2):
+
+```bash
+npm run install-client
+npm run client          # Vite → http://localhost:5173
+```
+
+Develop at **http://localhost:5173** (hot reload). On Windows, the Vite proxy targets
+`127.0.0.1:3000` to avoid the IPv6-`localhost` pitfall.
+
+> Tip: `npm run install-all` installs both server and client deps in one go.
+
+### Option C — Production build without Docker
+
+Build the SPA and let Express serve it on a single port (still needs a MariaDB + `server/.env`):
+
+```bash
+npm run install-all
+npm run build           # → client/dist
+npm start               # node server → serves API + SPA at http://localhost:3000
+```
+
+---
+
+## First admin & site mode
+
+- On first boot, if the `users` table is empty and `ADMIN_USERNAME` / `ADMIN_PASSWORD` are set,
+  the first admin is created automatically. You can also run `npm run seed`. After it exists you
+  may blank those env vars.
+- The site **starts in `maintenance` mode**: public visitors see the polished "coming soon" page;
+  the admin login and panel are always reachable.
+- Sign in at **`/admin/login`**, then flip **Maintenance → Live** from the Dashboard. A logged-in
+  admin can preview the live site even while it's in maintenance.
+
+---
+
+## Pages & routes
+
+**Public** (gated by site mode):
+
+| Route | Page |
+|---|---|
+| `/` | Portal landing (hero + destinations) |
+| `/site` | Website index (section cards) |
+| `/site/news` | News feed |
+| `/site/screenshots` | Screenshot gallery |
+| `/site/five-on-friday` | Five on Friday |
+| `/site/newsletter` · `/site/newsletter/:id` | Newsletter list + issue |
+| `/site/about` · `/site/status` | About · Shard status |
+| `/wiki` · `/wiki/:slug` | Wiki landing + article (auto table-of-contents) |
+
+**Admin** (cookie auth, `noindex`):
+
+| Route | View |
+|---|---|
+| `/admin/login` | Sign in |
+| `/admin` | Dashboard (mode toggle, stats, recent activity) |
+| `/admin/posts` | Posts CRUD + publish + image upload |
+| `/admin/wiki` | Wiki pages CRUD |
+| `/admin/settings` | Site settings |
+| `/admin/activity` | Activity log |
+| `/admin/bot-activity` | Bot activity — banned IPs + recent scoring events, emergency unban (admin only) |
+| `/admin/auth-providers` | Authentication — enable/configure SSO providers: built-in Google & Discord + custom OIDC/OAuth2 (admin only) |
+| `/admin/users` | User management |
+| `/admin/account` | Account security (self-service TOTP two-factor + linked SSO accounts) |
+
+---
+
+## API endpoints
+
+| Group | Base | Auth |
+|---|---|---|
+| Auth (web) | `/api/v1/auth` (`login`, `login/totp`, `logout`, `me`) | cookie |
+| Auth (mobile) | `/api/v1/auth/mobile` (`login`, `refresh`, `logout`) | bearer (access + refresh tokens) |
+| SSO | `/api/v1/auth` (`providers` — public discovery; `sso/:provider/start`, `sso/:provider/link`, `sso/:provider/callback`) | redirect flow |
+| Public | `/api/v1/public` (`settings`, `status`, `posts/:category`, `posts/:category/:idOrSlug`, `wiki`, `wiki/:slug`, `contact`) | none |
+| Admin | `/api/v1/admin` (`dashboard`, `site-mode`, `posts`, `posts/upload`, `wiki`, `settings`, `activity`, `bot-activity`, `bot-activity/unban`, `auth/providers` (CRUD), `users`, `account`, `account/totp/*`, `account/identities`) | cookie (admin) |
+| Public · Shard | `/api/v1/public/shard` (`status`, `feed`, `economy`, `online`, `idoc`, `stream`) | none |
+| Player · Shard | `/api/v1/player/shard` (`link`, `accounts`, `roster/:account`, `vendors/:account`, `char/:serial`, `sales`) | cookie/bearer (player) |
+| Admin · Shard | `/api/v1/admin/shard` (self linking, same as player) · `/api/v1/admin/uo-link` (`config`, `towncrier`, `stream`) | cookie (staff / admin) |
+
+Post categories (URL form): `news`, `five-on-friday`, `newsletter`, `screenshots`.
+`authMethod` on a session ∈ `local · totp · mobile · google · discord · oidc`.
+See [BACKEND_DESIGN.md](BACKEND_DESIGN.md) §4 for the full contract, or the interactive Swagger
+docs below for a per-endpoint reference (parameters, request bodies, response codes).
+
+---
+
+## API documentation (Swagger)
+
+The full API is documented as an **OpenAPI 3.0** spec and served with **Swagger UI**:
+
+| URL | What |
+|---|---|
+| `http://localhost:3000/api/docs` | Interactive Swagger UI (try-it-out, auth) |
+| `http://localhost:3000/api/docs.json` | Raw OpenAPI 3.0 spec (JSON) |
+
+Every endpoint is tagged and grouped (Auth, Auth · Mobile, Auth · SSO, Public, and the Admin
+groups) with its summary, parameters, request body, security requirement, and the response codes it
+actually returns (`400` validation, `401`/`403` auth, `404`, `409` conflicts, `429` rate limits, …).
+
+**Authentication in the UI** — click **Authorize** and provide either:
+
+- `cookieAuth` — the session cookie (name `rg_token`, configurable via `COOKIE_NAME`; set automatically in the browser after
+  `POST /api/v1/auth/login`), or
+- `bearerAuth` — a mobile access token from `POST /api/v1/auth/mobile/login` (sent as
+  `Authorization: Bearer <token>`).
+
+**Regenerating the spec** — the spec is generated from `#swagger.*` annotations next to each route
+(`server/src/router/**`) plus the shared definitions in `server/swagger/swagger.js`
+([swagger-autogen](https://github.com/davibaltar/swagger-autogen)). The output
+`server/swagger/swagger-output.json` is committed so the docs work with no build step. After adding
+or changing a route, regenerate it:
+
+```bash
+cd server
+npm run swagger        # → server/swagger/swagger-output.json
+```
+
+If the generated spec is missing, the server logs a warning and simply disables `/api/docs` (it does
+not crash).
+
+---
+
+## Shard integration (uo-link)
+
+The site is wired to the live in-game world through **uo-link**, a standalone sidecar service that
+runs next to the ServUO shard. Its source lives in a separate repo:
+**[RunicGateway/link](https://gitea.whitlocktech.com/RunicGateway/link)**. uo-link speaks the shard's internals and
+exposes a small, authenticated HTTP + WebSocket API; this website is a *client* of it. The shard
+itself is never exposed to the internet — only the sidecar is, and only the website's backend talks
+to it.
+
+### How it works
+
+```
+ServUO shard  ──▶  uo-link sidecar (RunicGateway/link)  ──▶  website backend  ──▶  browser
+                   REST + WebSocket, bearer-auth      ingest + REST         same-origin JSON/SSE
+```
+
+- **Connection is admin-managed, not env.** The sidecar's base URL, WebSocket URL, shared-secret
+  token, and protocol version are stored in the database (`uoLinkConfig`), edited from the
+  **Admin → Shard** panel. The token is **encrypted at rest** (AES-256-GCM) and is **write-only** in
+  the API — it is never returned to any client and never sent to the browser. Every call the backend
+  makes carries `Authorization: Bearer <token>` and an `X-UOLink-Version` header (a protocol
+  mismatch fails fast with `409` instead of being mis-parsed).
+- **Live ingest (WebSocket).** When enabled, the backend opens an outbound WebSocket to the sidecar
+  and receives a stream of game events — `mob.login`/`logout`, `char.vitals`, `economy.supply`,
+  `vendor.sale`, `player.death`/`murdered`, `house.decay` (IDOC), staff `audit.*`/`cheat.*`,
+  `link.request`, and `server.hello`/`shutdown`. A single dispatcher (`utils/shardIngest.js`) routes
+  each event: state-changing kinds update `shard_online` / `shard_economy` / `shard_houses`; notable
+  kinds are appended to an append-only `shard_events` log; high-frequency kinds (vitals, supply
+  ticks) only update state and are not logged. A changed boot id on `server.hello` is detected as a
+  restart and stale "online" rows are cleared. On reconnect the backend backfills missed events via
+  the sidecar's `/history`.
+- **Live round-trips (REST).** For point-in-time reads the backend calls the sidecar directly —
+  `/char/serial/:serial`, `/roster/:account`, `/vendors/:account`, `/economy`, `/history` — plus
+  commands `/link/confirm` and `/towncrier`. The REST client (`utils/uoLinkClient.js`) **never
+  throws**: every call returns `{ ok, data, status }`, so a shard that is down or mid-restart
+  degrades to a `503`/retry banner instead of a 500.
+- **Fan-out to the browser.** Ingested events are pushed to browsers over **Server-Sent Events**.
+  Two channels exist: a **public** stream carrying only a safe allowlist of kinds, and an
+  **admin-only** stream that also includes sensitive kinds (staff audit, cheat detection, login
+  attempts, IPs). Sensitive kinds can never leak onto the public channel.
+
+### Account linking
+
+A player (or staff member) proves ownership of a game account without sharing any game credentials:
+
+1. In game, the player runs **`[link`** and receives a one-time code.
+2. On the website (Player portal, or Admin → Account for staff) they enter the code.
+3. The backend confirms the code with the sidecar (`POST /link/confirm`), which permanently tags the
+   game account with the website user id, and mirrors the link locally in `shard_account_links`.
+
+That mirror is the authorization basis for character reads: roster/vendor/character-sheet endpoints
+are **ownership-checked** so a user only sees accounts they linked. **Admins may view any
+character**; players and editor/moderator staff are limited to their own linked accounts.
+
+### What each audience sees
+
+| Surface | Endpoints | Who | Data |
+|---|---|---|---|
+| **Public** | `/api/v1/public/shard/*` (`status`, `feed`, `economy`, `online`, `idoc`, `stream`) | anyone | Shard up/down, gold-supply series, IDOC houses, a curated live feed, and **"Staff online"** — only players whose account is linked to a **staff** user (admin/editor/moderator), shown with name + map location. Linked *players* are never listed publicly; no vitals or account are exposed. |
+| **Player** | `/api/v1/player/shard/*` (`link`, `accounts`, `roster/:account`, `vendors/:account`, `char/:serial`, `sales`) | logged-in player | Their own linked accounts: character rosters, character sheets, player-vendor snapshots, and recent vendor sales. |
+| **Admin** | `/api/v1/admin/shard/*` (self-linking, same as player) · `/api/v1/admin/uo-link/*` (`config`, `towncrier`, `stream`) | staff / admin | Staff link their own accounts like players; **admins** additionally read *any* character's data, edit the sidecar connection config, publish/remove **town-crier** messages, and subscribe to the full event stream (incl. audit/cheat). |
+
+The sidecar URL and token are set once in **Admin → Shard**; if uo-link is not configured (or the
+shard is offline), every shard surface degrades gracefully — the public page still renders, showing
+the shard as offline.
+
+---
+
+## Environment variables
+
+Copy `.env.example` (Compose) or `server/.env.example` (local) and fill in. **`.env` is git-ignored.**
+
+| Var | Default | Notes |
+|---|---|---|
+| `NODE_ENV` | `production` | |
+| `PORT` | `3000` | server listens on `0.0.0.0:PORT` |
+| `UPLOAD_DIR` | `<server>/uploads` | where post images are written (`/app/uploads`, volume-mounted, in Compose) |
+| `DB_HOST` / `DB_PORT` | `db` / `3306` | `db` in Compose; `127.0.0.1` for local dev |
+| `DB_NAME` / `DB_USER` / `DB_PASSWORD` | `runic_gateway` / `runic` / — | app database credentials |
+| `DB_ROOT_PASSWORD` | — | MariaDB root (Compose only) |
+| `JWT_SECRET` | — | **required** — long random string; signs session, mobile, and SSO-flow tokens |
+| `JWT_EXPIRES_IN` | `1d` | web session token + cookie lifetime |
+| `COOKIE_SECURE` | `auto` | `auto` = Secure only over HTTPS (works on LAN HTTP + Pangolin HTTPS) |
+| `COOKIE_NAME` | `rg_token` | changing it on a live instance invalidates existing sessions |
+| `BRAND_*` | Runic Gateway | instance branding (name, tagline, colors, logo/hero/favicon) — see [Branding](#branding) |
+| `SECRET_ENC_KEY` | — | **required in prod** — key for AES-256-GCM encryption of stored OAuth client secrets. Dev falls back to a key derived from `JWT_SECRET` (with a warning) |
+| `APP_BASE_URL` | — | public base URL, used to build the SSO OAuth `redirect_uri` (`${APP_BASE_URL}/api/v1/auth/sso/:provider/callback`). Set in prod to match what you register with Google/Discord; if unset it is derived from the request (fine for local dev) |
+| `MOBILE_ACCESS_TTL` | `15m` | mobile bearer **access** token lifetime (short-lived) |
+| `MOBILE_REFRESH_TTL_DAYS` | `30` | mobile **refresh** token lifetime (long-lived, rotated on use) |
+| `TRUST_PROXY` | `1` | reverse-proxy trust for correct `req.ip` / `req.secure` (rate limiting, backoff, bot-ban). Pin to the proxy hop's LAN IP in prod. A blanket `true` is rejected (coerced to `1`) to block `X-Forwarded-For` spoofing |
+| `DEBUG_TRUST_PROXY` | `0` | `1` logs raw peer address + `X-Forwarded-For` + resolved `req.ip` per request (to verify/refresh the proxy IP). Noisy — leave off |
+| `TOTP_ISSUER` | `BRAND_NAME` | label shown in authenticator apps for optional per-user 2FA |
+| `TOTP_CHALLENGE_TTL` | `5m` | lifetime of the short-lived post-password "awaiting code" step |
+| `ADMIN_USERNAME` / `ADMIN_PASSWORD` | — | first-admin bootstrap (first boot only) |
+| _Email_ | — | configured in Admin → Settings → Email (Gmail OAuth2), not via env; recipient = `contact_email` setting |
+| `CLIENT_ORIGIN` | `http://localhost:5173` | enables CORS in dev only |
+| `LOG_LEVEL` / `FILE_LOG_LEVEL` | `info` / `debug` | console / file verbosity |
+| `LOG_TO_FILE` / `LOG_DIR` / `LOG_FILE` | `true` / `<server>/logs` / `app.log` | log file (bind-mounted to `./logs` in Docker) |
+| `ANNOUNCE_POLL_MS` | `15000` | how often the news-announcement dispatcher sweeps `announce_jobs` for due/retry legs (town crier + Discord) |
+| `TOWNCRIER_DURATION_SEC` | `3600` | how long a news post's in-game town-crier message stays up (≤ `86400`) |
+
+---
+
+## Branding
+
+Instance identity is data, not code — set via `BRAND_*` env vars, so one prebuilt
+image can run as any shard. With none set, everything renders as **Runic Gateway**.
+
+| Var | What |
+|---|---|
+| `BRAND_NAME` / `BRAND_SHORT_NAME` | display name (full / short-in-prose) |
+| `BRAND_TAGLINE` / `BRAND_DESCRIPTION` | tagline + meta/OG description |
+| `BRAND_CONTACT_EMAIL` / `BRAND_URL` | contact + canonical URL (for OG/absolute links) |
+| `BRAND_ACCENT_COLOR` | theme `--accent` (web) + Discord embed color |
+| `BRAND_LOGO` / `BRAND_HERO` / `BRAND_FAVICON` | image paths under the `/brand` mount, or absolute URLs |
+
+**How it flows:** text/colors reach the SPA at runtime through the public settings
+API (`SiteContext`), so no rebuild is needed; the server templates `index.html`
+`<title>`/meta/OG/favicon at boot; emails, TOTP issuer, and the Discord bot read
+`BRAND_*` directly. The admin-editable **site title** and **contact email**
+settings override `BRAND_NAME` / `BRAND_CONTACT_EMAIL` when set. Image assets are
+delivered from the `./brand` bind-mount (see `brand/README.md`).
+
+**UOMysticmoon** is the first instance — [`.env.uomysticmoon.example`](https://gitea.whitlocktech.com/RunicGateway/website/src/branch/main/.env.uomysticmoon.example)
+holds the exact `BRAND_*` + infra (`DB_NAME`/`DB_USER`/`COOKIE_NAME`) pinning to
+run this repo as UOMysticmoon.
+
+---
+
+## Security
+
+**Session & authorization**
+
+- All auth flows go through one **session service** (`server/src/auth/`): controllers call
+  `sessionService.createSession(user, authMethod)` and middleware calls `validateSession()`, so web
+  cookies, mobile bearer tokens, and SSO all produce the *same* authenticated session model.
+  `utils/auth.js` remains a thin backward-compat facade.
+- JWT in an httpOnly, `SameSite=Lax` cookie (`Secure` auto-detected), bcrypt password hashing.
+- Admin routes are **re-validated against the database on every request**, so a demoted or deleted
+  user loses access immediately instead of keeping their old role until the token expires.
+- **Role-based authorization** — admin-only endpoints (users, site mode, settings, auth providers)
+  are gated by a `requireRole` check, so a lower-privilege editor can't reach them.
+
+**Mobile bearer auth**
+
+- Native clients use `/api/v1/auth/mobile/*`: a short-lived **access token** (bearer JWT, validated
+  by the same middleware as the cookie) plus a long-lived, **server-stored, revocable refresh
+  token** that is **rotated on every refresh** (a replayed refresh token is single-use). Refresh
+  tokens are stored **hashed** (never in the clear); logout revokes one or all. Mobile login reuses
+  the same bot-scoring + backoff defenses as web, with single-request TOTP.
+
+**Single sign-on (OAuth2 / OIDC)**
+
+- Pluggable providers — built-in **Google** and **Discord** (endpoints fixed in code; admins supply
+  only client id/secret) plus fully-configurable **custom OIDC/OAuth2** providers, managed from the
+  **Authentication** admin panel. Only `enabled` + fully-configured providers are shown to users.
+- **Link-only** by policy: an SSO login succeeds *only* if the external identity is already linked to
+  an existing account (linked by the user from **Account**). External identities are **never
+  auto-provisioned** — no one gains access without an account you created.
+- The redirect flow is CSRF-protected with a signed, httpOnly, short-lived transaction cookie plus
+  **PKCE**; OAuth client secrets are **encrypted at rest** (AES-256-GCM) and never returned to any
+  client. SSO logins go through the same `sessionService`, so login/activity logging, RBAC, and bot
+  protection are identical to a local login.
+
+**Login hardening**
+
+- **Optional per-user TOTP two-factor** (opt-in, self-service on `/admin/account`). When enabled,
+  the password step issues only a short-lived, non-session `stage:'totp'` challenge; a session
+  cookie is granted only after the second factor verifies.
+- **Login throttling** — `express-slow-down` + a hard rate cap + a separate per-IP exponential
+  backoff, with generic error messages that don't reveal whether the username exists.
+- **Honeypot** field on the login form; submissions that fill it are treated as bots.
+- **Bot-scoring + automatic IP ban** — weighted scoring of CMS-scanner paths and junk 404s (with a
+  periodic sweep of stale entries) bans hostile scanners; failed logins and honeypot hits feed the
+  score. Admins get visibility into this on the **Bot Activity** panel: currently banned IPs and a
+  recent-events feed (in-memory, most-recent-first), plus a logged emergency **unban** for false
+  positives — read + unban only, not a scoring-config surface.
+
+**Uploads & input**
+
+- Uploaded file extensions are derived from the **validated mimetype**, not the client-supplied
+  filename (prevents a disguised-extension upload).
+- `express-validator` on all writes; usernames are validated **and** uniqueness-checked on update.
+
+**Platform**
+
+- `helmet`, admin routes `noindex` + `robots.txt` disallow, `trust proxy` for correct client IPs
+  behind Pangolin (see `TRUST_PROXY`), first admin seeded from env (no hardcoded credentials),
+  `.env` git-ignored. Passwords and request bodies are never logged. Email sends through Gmail
+  OAuth2 configured in the admin (refresh token stored AES-GCM-encrypted, never in env); the
+  contact form falls back to a `mailto:` link when unconfigured.
+
+---
+
+## Logging
+
+Every log line goes to **both the console and a log file**, timestamped and leveled
+(`error` / `warn` / `info` / `debug`):
+
+```
+2026-06-26T18:55:01.123Z INFO  [server] listening on http://0.0.0.0:3000 ...
+2026-06-26T18:55:09.880Z INFO  [http] 192.168.1.40 admin POST /api/v1/auth/login 200 12 ms - 48 bytes
+2026-06-26T18:55:14.402Z WARN  [auth] login failed {"username":"root","ip":"192.168.1.40"}
+2026-06-26T18:55:20.110Z ERROR [error] GET /api/v1/public/wiki -> 500 ... {"stack":"..."}
+```
+
+Captured: startup config banner, schema/seed steps, **HTTP access logs** (real client IP via
+`trust proxy`, the authenticated admin, method/URL/status/time/size), login success/failure,
+rate-limit hits, site-mode changes, all errors with stack traces, and graceful shutdown. Console
+verbosity is `LOG_LEVEL`; the file keeps the fuller `FILE_LOG_LEVEL` record. In Docker the file is
+bind-mounted to `./logs/app.log` and `docker compose logs -f app` shows the console stream.
+
+---
+
+## Deployment behind Pangolin
+
+`docker compose up -d --build` exposes the `app` container on `0.0.0.0:3000` (no `127.0.0.1`
+binding) so Pangolin can reach it. Point a Pangolin resource at `app:3000`. Because `COOKIE_SECURE`
+defaults to `auto`, the admin login works both directly via the LAN IP over HTTP **and** through
+Pangolin over HTTPS — no config change needed. MariaDB stays on the private Compose network
+(no published port by default); data persists in the `dbdata` volume, uploads in `uploads`.