Compare commits

...

4 Commits

Author SHA1 Message Date
5deaf74049 Merge pull request 'docs(readme): the event system, protocol 7, and module-uo v1.2.2' (#6) from docs/events-system into main
Reviewed-on: #6
2026-09-10 04:28:33 +00:00
0a7d138daa docs(readme): the event system, protocol 7, and module-uo v1.2.2
Phase 16c of the events plan. The landing page is updated when the shape of the
project changes, and a subsystem that lets staff schedule an unattended change to
a live game world is one.

* **A new bullet in "How they fit together"**, beside the engagement one it sits
  next to: an event is written once as phases and steps, published as an
  immutable version and executed unattended. What matters on a front page is the
  posture rather than the feature list — everything arrives switched off, caps are
  enforced in the database rather than in a role check, cleanup is generated from
  a ledger rather than authored, and an event does not edit the world but holds a
  **lease** the game restores on its own deadline even if the site never speaks to
  it again. The game keeps its own switch, separate from the staff write plane.
* **Protocol 5 → 7** in the four values the installer prints. That block is what a
  reader copies into Admin → Shard, so a stale number there is the one that costs
  somebody an afternoon.
* **module-uo v1.1.0 → v1.2.2** in the manifest URL and the `MODULES=` line.
* `docs/website/EVENTS.md` added to "Where to go next".

Verified against the platform rather than assumed: the protocol number is
`link/sidecar/src/main.rs` and `servuo-plugins/overlay.toml` on `main`, and
v1.2.2 is the current Module-uo release, whose own notes name
`module-uo-1.2.2.json` as the manifest to paste.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4
2026-09-09 22:04:39 -05:00
159eb53e73 Merge pull request 'docs(readme): the engagement system, protocol 5, and module-uo v1.1.0' (#5) from docs/engagement-and-protocol-5 into main
Reviewed-on: #5
2026-09-01 18:55:28 +00:00
029ba2893e docs(readme): the engagement system, protocol 5, and module-uo v1.1.0
The engagement cutover landed on 2026-09-01 and three things on this page stopped
being true with it.

The capability itself is the reason for the change: the site now talks to its
players, and an operator decides when. It is a headline capability by the org
lead's call, which is the condition ENGAGEMENT.md Phase 13 step 8 attaches to
touching this file at all -- a landing page that lists every feature is a landing
page nobody reads.

The bullet leads with the operator rather than the mechanism, and names the one
property that is a security boundary rather than a feature: a trigger declares
the widest audience a rule may ever be given, so a sensitive game event cannot be
mailed to everyone by a misconfiguration.

The other two are cutover outputs and would mislead an operator directly:

  * the installer's sample output prints "Protocol version 4"; the paired bundle
    is 2026.09.01 and the wire is 5.
  * the quick start pins module-uo v1.0.1 in both the manifest URL and the
    MODULES= line; v1.1.0 is the release that carries the shard triggers.

Co-Authored-By: Claude <noreply@anthropic.com>
2026-09-01 13:15:13 -05:00

View File

@@ -71,6 +71,24 @@ Three layers, and the shape is the same for any game:
- Players **link** a game account to a website account with a one-time in-game code, which
is what authorizes character reads. Staff can push town-crier messages and control
commands back into the game.
- **The site talks to its players, and an operator decides when.** Anything notable — in the
platform or in the game — can be declared as a **trigger**; an operator writes rules against
triggers in the admin panel and picks who is told and on which channel: **email** through any SMTP
provider, an **on-site inbox**, or a **push** to the Android app. Bodies are editable templates
with a live preview, every rule a module ships arrives **switched off**, and each trigger declares
the widest audience a rule may ever be given — so a sensitive game event cannot be mailed to
everyone by a misconfiguration. A module brings its own triggers: for Ultima Online that is
a house about to collapse, a vendor running out of gold, a champion spawn, a new governor.
- **Staff can put an event on the calendar and let it run itself.** An event is written once
as phases and steps, published as an immutable version, and executed unattended — announcing
itself, spawning what it needs, borrowing values the world already had, counting who took
part and publishing the results. Everything it may do arrives **switched off**, every run
spends against per-run caps enforced in the database rather than in a role check, and every
world write is ledgered so the undo is **generated rather than authored** and runs on
completion, cancellation and abort alike. An event does not edit the world; it holds a
**lease** the game restores on its own deadline — even if the site never speaks to it again.
The game keeps its own switch: scheduled events are off in `Bridge.cfg` until an operator
turns them on, separately from the staff write plane.
- **Accounts are hardened out of the box** — TOTP two-factor with trusted devices, optional
SSO (Google / Discord / any OIDC provider, link-only: an external identity must already
belong to an account), bot scoring with automatic IP bans, and rate limiting.
@@ -134,11 +152,11 @@ Ultima Online that manifest is `module-uo-<version>.json` from the
[Module-uo releases](https://gitea.whitlocktech.com/RunicGateway/Module-uo/releases):
```
https://gitea.whitlocktech.com/RunicGateway/Module-uo/releases/download/v1.0.1/module-uo-1.0.1.json
https://gitea.whitlocktech.com/RunicGateway/Module-uo/releases/download/v1.2.2/module-uo-1.2.2.json
```
A compose-managed host can declare the set instead of clicking, with
`MODULES=uo@1.0.1=<that URL>` — resolution at container start is idempotent and offline-safe,
`MODULES=uo@1.2.2=<that URL>` — resolution at container start is idempotent and offline-safe,
so a restart with the network down brings the site up exactly as it was.
> **The module system shipped on 2026-08-12** and this is now simply how the site works — a
@@ -176,7 +194,7 @@ unprivileged account, and finishes by printing the four values to paste into **A
```
Base URL http://<shard-host>:8080
WebSocket URL ws://<shard-host>:8080/ws
Protocol version 4
Protocol version 7
Auth token 4f9c…
```
@@ -217,6 +235,7 @@ and the design contract in [`docs/android/PLAN.md`](https://gitea.whitlocktech.c
- **Setting up a shard** → [`docs/installer/INSTALL.md`](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/installer/INSTALL.md) — the operator guide: what the run asks, where it writes, the patch tier, `doctor` / `update` / `uninstall`, troubleshooting, and the by-hand path.
- **Running / customizing the site** → [website README](https://gitea.whitlocktech.com/RunicGateway/website) (tech stack, API endpoints, env vars, security, branding, Swagger at `/api/docs`).
- **The Android client** → [Android-app README](https://gitea.whitlocktech.com/RunicGateway/Android-app) and [`docs/android/PLAN.md`](https://gitea.whitlocktech.com/RunicGateway/docs) — the authoritative design contract, milestones, and the push-notification architecture.
- **The event system** → [`docs/website/EVENTS.md`](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/website/EVENTS.md) — the design of record: leases, the resource ledger, the caps, and the module seam an event's world verbs arrive through.
- **The bridge internals** → [docs](https://gitea.whitlocktech.com/RunicGateway/docs) — design docs, the canonical wire-protocol spec, and the integration guide.
- **Working on the sidecar or plugin** → [link README](https://gitea.whitlocktech.com/RunicGateway/link) and [servuo-plugins](https://gitea.whitlocktech.com/RunicGateway/servuo-plugins) — building from source, the loopback protocol, and the compatibility rules.