docs(link): record world.ruleset and mark Protocol 3.0 progress #66

wtclaude · 2026-07-28T19:42:20Z

wtclaude commented

2026-07-28 19:42:20 +00:00

Protocol 3.0 order 2 (v3.md §5) is built across all four repos; this is its documentation half, plus the running progress record the plan was missing.

`v3.md` — the progress record

A progress table at the top and a State column on §9's sequencing table, so "what has landed?" is answerable without reading four git logs. Part A (order 1) and world.ruleset (order 2) are marked done with their PR links; the spawn atlas is flagged next.

§5 also gains the implementation notes worth keeping:

Where a system's on/off state is derived, read the system's own static — don't invent a .cfg key. Shadowguard.cfg has no Enabled (it's the TOL expansion gate); Factions.cfg has none either, because stock ServUO sets Settings.Enabled = !ViceVsVirtueSystem.Enabled. Only read Config.Get where the .cfg key is the truth.
caps.skill / caps.totalSkill are in tenths (1000 = 100.0).
Config.Get re-parses when the cached type differs, so reading a key as int where ServUO reads it as double is correct — worth knowing before assuming a shared cache.
The plugin can be compile-verified, contrary to the "no standalone build" caveat: point the SDK's Roslyn csc.dll at the whole ServUO Scripts tree with the overlay substituted. 6,205 files, ~40 s, catches every signature error a boot would. Recorded because it should be run on every plugin PR.

`INTEGRATION.md`

The world.ruleset catalog entry and GET /ruleset, leading with the two things consumers get wrong: caps are in tenths, and connect exists only if the operator set Bridge.PublicConnectAddress — the shard's real listen address is never published.

§2 now states plainly that v3 has not been bumped yet and what that implies: sidecars on edge report 2 while already carrying some v3 kinds, so during this window you must not infer feature availability from the version number — probe the endpoint instead. There is deliberately no feature-negotiation array.

`PROTOCOL_2.md` §10.4

Two long-open threads closed:

The deferred question is answered — this shard runs VvV; Factions is off, and the two are mutually exclusive by construction in stock ServUO, not by coincidence.
world.systems is superseded by world.ruleset, which carries the systems block it asked for. It was never implemented under that name, so no orphan kind is left behind. The old sentence is struck through in place rather than deleted, so a reader arriving from an old link sees what happened.

`BACKEND_DESIGN.md`

The shard_ruleset table — why it is stored whole rather than normalized, and why no row means null rather than {} — and the public route, including the tenths caveat.

`PLAN.md`

A "beyond 1.0" pointer (2.0 phasing → PROTOCOL_2.md §13, 3.0 → v3.md §9), and a note that the Bridge.cfg sample in that section is the 1.0 set, not the current one — overlay/Config/Bridge.cfg is authoritative.

Not touched

PROJECT_TREE.md — sync-project-tree regenerates it on push to main, so it updates itself at the v3 cutover. Hand-editing it now would just fight the generator.

Sibling PRs

servuo-plugins #3
link #17
website #111

AI-assisted: written with Claude Code (Claude Opus 5), reviewed before opening.

🤖 Generated with Claude Code

https://claude.ai/code/session_01U7CBg11prhLimL9iHSX1bP

Protocol 3.0 order 2 ([`v3.md` §5](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/edge/link/v3.md)) is built across all four repos; this is its documentation half, plus the running progress record the plan was missing. ## `v3.md` — the progress record A progress table at the top and a **State** column on §9's sequencing table, so *"what has landed?"* is answerable without reading four git logs. Part A (order 1) and `world.ruleset` (order 2) are marked done with their PR links; the spawn atlas is flagged next. §5 also gains the implementation notes worth keeping: - **Where a system's on/off state is *derived*, read the system's own static — don't invent a `.cfg` key.** `Shadowguard.cfg` has no `Enabled` (it's the TOL expansion gate); `Factions.cfg` has none either, because stock ServUO sets `Settings.Enabled = !ViceVsVirtueSystem.Enabled`. Only read `Config.Get` where the `.cfg` key *is* the truth. - **`caps.skill` / `caps.totalSkill` are in tenths** (1000 = 100.0). - `Config.Get` re-parses when the cached type differs, so reading a key as `int` where ServUO reads it as `double` is correct — worth knowing before assuming a shared cache. - **The plugin *can* be compile-verified**, contrary to the "no standalone build" caveat: point the SDK's Roslyn `csc.dll` at the whole ServUO `Scripts` tree with the overlay substituted. 6,205 files, ~40 s, catches every signature error a boot would. Recorded because it should be run on every plugin PR. ## `INTEGRATION.md` The `world.ruleset` catalog entry and `GET /ruleset`, leading with **the two things consumers get wrong**: caps are in tenths, and `connect` exists only if the operator set `Bridge.PublicConnectAddress` — the shard's real listen address is never published. §2 now states plainly that **v3 has not been bumped yet** and what that implies: sidecars on `edge` report `2` while already carrying some v3 kinds, so during this window you must not infer feature availability from the version number — probe the endpoint instead. There is deliberately no feature-negotiation array. ## `PROTOCOL_2.md` §10.4 Two long-open threads closed: - **The deferred question is answered** — this shard runs VvV; Factions is off, and the two are mutually exclusive *by construction* in stock ServUO, not by coincidence. - **`world.systems` is superseded by `world.ruleset`**, which carries the `systems` block it asked for. It was never implemented under that name, so no orphan kind is left behind. The old sentence is struck through in place rather than deleted, so a reader arriving from an old link sees what happened. ## `BACKEND_DESIGN.md` The `shard_ruleset` table — why it is stored whole rather than normalized, and why no row means `null` rather than `{}` — and the public route, including the tenths caveat. ## `PLAN.md` A "beyond 1.0" pointer (2.0 phasing → `PROTOCOL_2.md` §13, 3.0 → `v3.md` §9), and a note that the `Bridge.cfg` sample in that section is the 1.0 set, not the current one — `overlay/Config/Bridge.cfg` is authoritative. ## Not touched `PROJECT_TREE.md` — `sync-project-tree` regenerates it on push to `main`, so it updates itself at the v3 cutover. Hand-editing it now would just fight the generator. ## Sibling PRs - servuo-plugins [#3](https://gitea.whitlocktech.com/RunicGateway/servuo-plugins/pulls/3) - link [#17](https://gitea.whitlocktech.com/RunicGateway/link/pulls/17) - website [#111](https://gitea.whitlocktech.com/RunicGateway/website/pulls/111) --- - [x] AI-assisted: written with **Claude Code** (Claude Opus 5), reviewed before opening. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01U7CBg11prhLimL9iHSX1bP

wtclaude added 2 commits 2026-07-28 19:42:21 +00:00

docs(link): record world.ruleset and mark Protocol 3.0 progress b0a2207c6a

Protocol 3.0 order 2 (v3.md §5) is built across all four repos; this is its
documentation half, plus the running progress record the plan was missing.

v3.md
  - A progress table at the top and a State column on §9's sequencing table, so
    "what has landed" is answerable without reading four git logs. Part A (order
    1) and world.ruleset (order 2) are marked done; the spawn atlas is next.
  - §5 gains the implementation notes worth keeping, chiefly: where a system's
    on/off state is DERIVED rather than configured, read the system's own static
    instead of inventing a .cfg key (Shadowguard has no Enabled key — it's the
    TOL expansion gate; Factions is `!ViceVsVirtueSystem.Enabled` by
    construction in stock ServUO). Also that the plugin CAN be compile-verified
    despite the "no standalone build" caveat, and how.

INTEGRATION.md
  - The world.ruleset catalog entry and GET /ruleset, with the two things
    consumers get wrong: caps are in TENTHS (1000 = 100.0), and `connect` exists
    only if the operator set Bridge.PublicConnectAddress — the shard's real
    listen address is never published.
  - §2 now says plainly that v3 has NOT been bumped yet and what that means:
    sidecars on `edge` report 2 while already carrying some v3 kinds, so do not
    infer feature availability from the version during this window.

PROTOCOL_2.md §10.4
  - The deferred "which PvP system does this shard run?" is answered (VvV on,
    Factions off — and mutually exclusive by construction), and world.systems is
    marked superseded by world.ruleset, which carries the systems block it asked
    for. No orphan kind is left behind.

BACKEND_DESIGN.md — the shard_ruleset table (why it is stored whole rather than
normalized, and why no row means null rather than {}) and the public route.

PROJECT_TREE.md is deliberately untouched: sync-project-tree regenerates it on
push to main, so it updates itself at the v3 cutover.

Co-Authored-By: Claude <noreply@anthropic.com>

docs(link): link the world.ruleset PRs from the v3 progress table 09467c67b0

Co-Authored-By: Claude <noreply@anthropic.com>

whitlocktech approved these changes 2026-07-28 20:34:33 +00:00

whitlocktech merged commit e9ecdc0ecb into edge

2026-07-28 20:34:40 +00:00

whitlocktech deleted branch docs/world-ruleset

2026-07-28 20:34:41 +00:00

whitlocktech referenced this issue from a commit

2026-07-28 20:34:42 +00:00

Merge pull request 'docs(link): record world.ruleset and mark Protocol 3.0 progress' (#66) from docs/world-ruleset into edge

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/docs#66

docs(link): record world.ruleset and mark Protocol 3.0 progress #66

v3.md — the progress record

INTEGRATION.md

PROTOCOL_2.md §10.4

BACKEND_DESIGN.md

PLAN.md