docs(link,installer): protocol 4 is live — correct every stale 3 #172

wtclaude · 2026-08-19T22:58:50Z

wtclaude commented

2026-08-19 22:58:50 +00:00

Phase 0 of the runicgateway.com plan, conflicts 1, 2, 3 and 5. These are wrong independently of that site — a marketing page just happened to be the thing that read them closely.

Protocol 4 shipped 2026-08-19 as sidecar v2.0.0 and overlay v1.0.0, paired in bundle 2026.08.19. Three documents still said 3.

`link/INTEGRATION.md` — the contract a third party implements against

It contradicted itself. The event catalog fully documents the protocol-4 kinds — guild.roster, guild.leave, a subsection headed "On Protocol 4" — while normative §2 still declared X-UOLink-Version: 3, "protocol": 3 in /health and ws.hello, and a worked JS client sending "3".

§2 now states the current version and what shipped it, and gains a v4 paragraph alongside v2 and v3. The "Upgrading a v2 integration" note is generalised, since the advice was never v2-specific.

The (Protocol 3.0) markers on individual features are deliberately left alone — those record which version introduced a kind, and they are correct.

Two stale examples the original audit had not spotted:

the --print-config sample reported "version": "0.1.0";
the minimal browser client told readers to check ev.protocol === 1 — a leftover from protocol 1.

`installer/INSTALL.md` — the one that actively misconfigured installs

Line 413 is the Protocol version value an operator pastes into Admin → Shard. The document's own troubleshooting table says a stale number comes back as a 409 that "looks exactly like your shard going offline", so this was a live footgun.

Corrected along with the stale component versions throughout — bundle 2026.08.04, overlay v0.1.1, sidecar 1.1.0 — including Appendix A's copy-pasteable curl commands, which pointed at release assets for the wrong versions. The doctor and --version sample outputs move too, so nothing an operator compares against is stale.

I verified the bundle URL the document publishes (raw/branch/bundles/current.json) still resolves — it does, 200.

`link/v4.md` — it said the cutover had not happened

It has. Status line updated with the releases and the bundle that pair them.

One thing worth your attention rather than just review. Its outstanding-work note said the five-rung shard visibility walk was "outstanding for the cutover" — now self-contradictory, since the cutover shipped. Rather than quietly deleting the line or implying the walk passed, it now says plainly that the cutover shipped without it and no result is recorded here or in website/SHARD_VISIBILITY.md. I searched for one and found nothing.

guild.roster carries actor objects for every member of every guild, which makes it the widest surface any protocol version has added to that check. Worth walking against the released pair even though v4 is already live — your call whether that becomes an issue.

Verification

No code or contract changes; every edit moves documentation to match what the code already does. Values read from the Gitea API on 2026-08-19:

Value	Authority
protocol `4`	`link` `main:sidecar/src/main.rs:55`
overlay `protocol = 4`	`servuo-plugins` `main:overlay.toml`
sidecar v2.0.0, overlay v1.0.0, bundle 2026.08.19	`installer` branch `bundles` → `current.json`

AI-assisted contribution

Drafted by Claude (Claude Code), per the org's AI-usage disclosure policy. Commit carries the Co-Authored-By trailer.

Phase 0 of the [runicgateway.com plan](https://gitea.whitlocktech.com/RunicGateway/runicgateway.com/pulls/2), conflicts 1, 2, 3 and 5. These are wrong independently of that site — a marketing page just happened to be the thing that read them closely. Protocol 4 shipped **2026-08-19** as sidecar **v2.0.0** and overlay **v1.0.0**, paired in bundle **2026.08.19**. Three documents still said 3. ## `link/INTEGRATION.md` — the contract a third party implements against It contradicted itself. The event catalog fully documents the protocol-4 kinds — `guild.roster`, `guild.leave`, a subsection headed "On Protocol 4" — while normative §2 still declared `X-UOLink-Version: 3`, `"protocol": 3` in `/health` and `ws.hello`, and a worked JS client sending `"3"`. §2 now states the current version and what shipped it, and gains a **v4** paragraph alongside v2 and v3. The "Upgrading a v2 integration" note is generalised, since the advice was never v2-specific. **The `(Protocol 3.0)` markers on individual features are deliberately left alone** — those record which version introduced a kind, and they are correct. Two stale examples the original audit had not spotted: - the `--print-config` sample reported `"version": "0.1.0"`; - the minimal browser client told readers to `check ev.protocol === 1` — a leftover from **protocol 1**. ## `installer/INSTALL.md` — the one that actively misconfigured installs Line 413 is the **Protocol version** value an operator pastes into Admin → Shard. The document's own troubleshooting table says a stale number comes back as a `409` that "looks exactly like your shard going offline", so this was a live footgun. Corrected along with the stale component versions throughout — bundle `2026.08.04`, overlay `v0.1.1`, sidecar `1.1.0` — **including Appendix A's copy-pasteable `curl` commands**, which pointed at release assets for the wrong versions. The `doctor` and `--version` sample outputs move too, so nothing an operator compares against is stale. I verified the bundle URL the document publishes (`raw/branch/bundles/current.json`) still resolves — it does, 200. ## `link/v4.md` — it said the cutover had not happened It has. Status line updated with the releases and the bundle that pair them. **One thing worth your attention rather than just review.** Its outstanding-work note said the five-rung shard visibility walk was "outstanding for the cutover" — now self-contradictory, since the cutover shipped. Rather than quietly deleting the line or implying the walk passed, it now says plainly that **the cutover shipped without it and no result is recorded** here or in `website/SHARD_VISIBILITY.md`. I searched for one and found nothing. `guild.roster` carries actor objects for **every member of every guild**, which makes it the widest surface any protocol version has added to that check. Worth walking against the released pair even though v4 is already live — your call whether that becomes an issue. ## Verification No code or contract changes; every edit moves documentation to match what the code already does. Values read from the Gitea API on 2026-08-19: | Value | Authority | |---|---| | protocol `4` | `link` `main:sidecar/src/main.rs:55` | | overlay `protocol = 4` | `servuo-plugins` `main:overlay.toml` | | sidecar v2.0.0, overlay v1.0.0, bundle 2026.08.19 | `installer` branch `bundles` → `current.json` | ## AI-assisted contribution Drafted by Claude (Claude Code), per the org's AI-usage disclosure policy. Commit carries the `Co-Authored-By` trailer.

wtclaude added 1 commit 2026-08-19 22:58:52 +00:00

docs(link,installer): protocol 4 is live - correct every stale 3 7579d6baa2

Protocol 4 shipped on 2026-08-19 as sidecar v2.0.0 and overlay v1.0.0,
paired in bundle 2026.08.19. Three documents still said 3.

INTEGRATION.md contradicted itself: its event catalog fully documents the
protocol-4 kinds, including a subsection headed "On Protocol 4", while
its normative section 2 still declared X-UOLink-Version: 3, "protocol": 3
in /health and ws.hello, and a worked JS client sending "3". That is the
contract a third-party integrator implements against, so it mattered
most. Section 2 now states the current version and what shipped it, and
gains a v4 paragraph alongside v2 and v3. The "(Protocol 3.0)" markers on
individual features are left alone - those record which version
introduced a kind and are correct.

Two stale examples the audit had not spotted: the --print-config sample
reported version 0.1.0, and the minimal browser client told readers to
check ev.protocol === 1, a leftover from protocol 1.

INSTALL.md is the one that actively misconfigured a real install. Line
413 is the "Protocol version" value an operator pastes into Admin ->
Shard, and the document's own troubleshooting table says a stale number
comes back as a 409 that "looks exactly like your shard going offline".
Corrected along with the stale bundle, overlay and sidecar versions
throughout, including Appendix A's copy-pasteable curl commands, which
pointed at overlay v0.1.1 and sidecar v1.1.0.

v4.md still said the cutover had not happened. It has. Its outstanding-
work note said the five-rung shard visibility walk was "outstanding for
the cutover", which is now self-contradictory - so it says plainly that
the cutover shipped without it and no result is recorded anywhere.
guild.roster carries actor objects for every member of every guild, the
widest surface any protocol version has added to that check, so it is
worth walking against the released pair.

No code or contract changes. Every value verified against the Gitea API:
link main sidecar/src/main.rs PROTOCOL_VERSION, servuo-plugins
overlay.toml, and current.json on the installer bundles branch.

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

wtclaude referenced this pull request from RunicGateway/.profile

2026-08-19 22:59:47 +00:00

docs(readme): protocol 4, and module-uo v1.0.1 in the quick start #4

wtclaude referenced this pull request

2026-08-19 23:05:05 +00:00

docs: hygiene sweep — the four places the docs describe a site that no longer exists #173

whitlocktech merged commit afb2fea50a into main

2026-08-19 23:25:51 +00:00

whitlocktech referenced this issue from a commit

2026-08-19 23:25:52 +00:00

Merge pull request 'docs(link,installer): protocol 4 is live — correct every stale 3' (#172) from docs/protocol-4-accuracy into main

whitlocktech deleted branch docs/protocol-4-accuracy