docs(link): roster members carry guild rank #155

wtclaude · 2026-08-17T22:45:17Z

wtclaude commented

2026-08-17 22:45:17 +00:00

Amends Protocol 4 in place — no bump. The protocol has not reached main, and a bump is owed only once one has been released.

Pairs with servuo-plugins #13 (the emitter) and Module-uo #10 (the ingest and the provider).

Why

The roster shipped as the standard actor object, which carries no rank. Teams phase 2 found the consequence: the website could learn leadership only from the board's single leader field, so it could name exactly one leader — while a UO guild routinely has several, and TEAMS.md §2.5 treats multiple leaders as the normal case.

`v4.md` §2.3

The three new fields (rank, rankCliloc, rankName), why rank is on roster members only, and why only the raw rank travels — ServUO ships no text for those clilocs, so resolving one is the consumer's job.

Both files carry the trap

PlayerMobile.GuildRank returns Leader for anyone at GameMaster or above, whatever their real rank. A gameplay convenience so staff can operate a guild stone; the true value has no accessor. The bridge therefore omits the rank entirely for a staff account rather than publishing a leadership claim it knows is false.

So an absent rank means "not known", and a consumer must read it as neither 0 (which silently demotes them) nor leadership (which republishes the lie). Written into both the spec and the integrator guide because it is precisely the kind of thing that is got wrong silently and discovered on a public page.

INTEGRATION.md also states the other half plainly for an outside integrator: guild.update's single leader is the founder-leader, not the set of leaders, so "who leads this guild" is a read of the roster's ranks.

Recorded for next time

The sidecar needs no change and no store migration — it treats roster members as opaque values and never reads a field inside one. Worth having written down before someone assumes a new member field implies sidecar work.

AI-assisted: written with Claude Code. Commits carry Co-Authored-By: Claude <noreply@anthropic.com>.

Amends **Protocol 4 in place — no bump.** The protocol has not reached `main`, and a bump is owed only once one has been released. Pairs with servuo-plugins #13 (the emitter) and Module-uo #10 (the ingest and the provider). ## Why The roster shipped as the standard actor object, which carries no rank. Teams phase 2 found the consequence: the website could learn leadership only from the board's single `leader` field, so it could name exactly one leader — while a UO guild routinely has several, and `TEAMS.md` §2.5 treats multiple leaders as the normal case. ## `v4.md` §2.3 The three new fields (`rank`, `rankCliloc`, `rankName`), why rank is on roster members only, and why only the raw rank travels — ServUO ships no text for those clilocs, so resolving one is the consumer's job. ## Both files carry the trap **`PlayerMobile.GuildRank` returns Leader for anyone at GameMaster or above, whatever their real rank.** A gameplay convenience so staff can operate a guild stone; the true value has no accessor. The bridge therefore omits the rank entirely for a staff account rather than publishing a leadership claim it knows is false. So an **absent rank means "not known"**, and a consumer must read it as neither 0 (which silently demotes them) nor leadership (which republishes the lie). Written into both the spec and the integrator guide because it is precisely the kind of thing that is got wrong silently and discovered on a public page. `INTEGRATION.md` also states the other half plainly for an outside integrator: `guild.update`'s single `leader` is the **founder-leader, not the set of leaders**, so "who leads this guild" is a read of the roster's ranks. ## Recorded for next time The sidecar needs no change and no store migration — it treats roster members as opaque values and never reads a field inside one. Worth having written down before someone assumes a new member field implies sidecar work. --- AI-assisted: written with Claude Code. Commits carry `Co-Authored-By: Claude <noreply@anthropic.com>`.

wtclaude added 1 commit 2026-08-17 22:45:19 +00:00

docs(link): roster members carry guild rank 0622ed00e0

Amends Protocol 4 in place rather than bumping it: the protocol has not reached
`main`, and a bump is owed only once a protocol has been released.

The roster shipped as the standard actor object, which carries no rank. Teams
phase 2 found the consequence -- the website could learn leadership only from the
board's single `leader` field, so it could name exactly one leader while a UO
guild routinely has several, and TEAMS.md §2.5 treats multiple leaders as the
normal case.

Roster members now carry `rank` (0-4, 4 being Leader) plus `rankCliloc`, or
`rankName` where a shard's custom rank definitions use literal names. Rank is on
roster members only -- it is a property of a mobile's membership of THIS guild,
not of the mobile, and every other actor the bridge writes is a bystander, a
killer or a governor.

Both files carry the trap this found, because it is the kind of thing a consumer
gets wrong silently: **`PlayerMobile.GuildRank` returns Leader for anyone at
GameMaster or above, whatever their real rank.** It is a gameplay convenience so
staff can operate a guild stone, and the true value has no accessor -- so the
bridge omits the rank entirely for a staff account rather than publish a
leadership claim it knows is false. An absent rank therefore means "not known",
and a consumer must read it as neither 0 (which silently demotes them) nor
leadership (which republishes the lie).

INTEGRATION.md also states the other half plainly for an outside integrator:
`guild.update`'s single `leader` is the founder-leader, not the set of leaders,
so "who leads this guild" is a read of the roster's ranks.

Recorded too: the sidecar needs no change and no store migration, because it
treats roster members as opaque values and never reads a field inside one. That
is the forwarder design paying off, and it is worth having written down the next
time someone adds a member field.

Pairs with servuo-plugins (the emitter) and Module-uo (the ingest and the
provider).

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

wtclaude referenced this pull request

2026-08-17 22:45:46 +00:00

docs(teams): Team core, MODULE_API 1.6.0, and what phase 2 disproved #154

whitlocktech merged commit cbc492ea52 into edge

2026-08-17 22:48:33 +00:00

whitlocktech deleted branch docs/protocol4-guild-rank

2026-08-17 22:48:34 +00:00

whitlocktech referenced this issue from a commit

2026-08-17 22:48:34 +00:00

Merge pull request 'docs(link): roster members carry guild rank' (#155) from docs/protocol4-guild-rank into edge

Sign in to join this conversation.