feat(guilds): a third place on the guild page, and where that page lives #13

Merged
whitlocktech merged 1 commits from feature/teams-phase6-notifications into edge 2026-08-18 23:10:04 +00:00
Member

The module's half of Teams phase 6. Into edge. Companion PRs: website#156 and docs#159.

Two things only core cannot supply for itself.

uo.guild.header — a third declared slot

At the top of the guild page, for core's per-Team notification control. A third rather than a corner of the activity feed, because a slot holds one component and the first fill wins: the control is an action on this page and the other two are content in it. Separate slots are what let this module say so — and it does, putting the control above the roster and the feed and forum below it.

pageUrlTemplate — where a guild page actually is

Teams are a contract primitive with no core surface: core owns the tables, the sync and the access rules; this module owns the word "guild" and therefore the page. That left core unable to write a link to one, which phase 6 ran straight into — a notification email that cannot take you to the thread it is about is most of the way to useless.

pageUrlTemplate: '/uo/guilds/{externalId}'

Core substitutes and does nothing else with it. It is data rather than a callback deliberately: a function would put a module hook on the mail path — one more thing that can hang or throw between a forum reply and the mail about it — to produce a string that never varies. A template naming its own host is refused at registration, protocol-relative with it.

The member is optional. A module that omits it costs its deployment clickable links in Team notification email and nothing else.

Verification

npm test428 server, 42 client, both green; npm run build and npm run check:externals clean. The registration test now asserts three declared slots, and the existing "every declared slot is rendered by the page that owns it" check covers the new one.

Walked as far as the rig allowed: the module installs into a phase-6 core, boots, and serves its chunk with the new slot in it. The rendered toggle itself is not visually confirmed — the browser tooling failed in this environment — see the note on website#156.


AI-assisted: written with Claude Code.

🤖 Generated with Claude Code

The module's half of Teams phase 6. Into `edge`. Companion PRs: **website#156** and **docs#159**. Two things only core cannot supply for itself. ## `uo.guild.header` — a third declared slot At the top of the guild page, for core's per-Team notification control. A third rather than a corner of the activity feed, because a slot holds one component and the first fill wins: the control is an action **on** this page and the other two are content **in** it. Separate slots are what let this module say so — and it does, putting the control above the roster and the feed and forum below it. ## `pageUrlTemplate` — where a guild page actually is Teams are a contract primitive with **no core surface**: core owns the tables, the sync and the access rules; this module owns the word "guild" and therefore the page. That left core unable to write a link to one, which phase 6 ran straight into — a notification email that cannot take you to the thread it is about is most of the way to useless. ```js pageUrlTemplate: '/uo/guilds/{externalId}' ``` Core substitutes and does nothing else with it. It is **data rather than a callback** deliberately: a function would put a module hook on the mail path — one more thing that can hang or throw between a forum reply and the mail about it — to produce a string that never varies. A template naming its own host is refused at registration, protocol-relative with it. The member is optional. A module that omits it costs its deployment clickable links in Team notification email and nothing else. ## Verification `npm test` — **428 server**, **42 client**, both green; `npm run build` and `npm run check:externals` clean. The registration test now asserts three declared slots, and the existing "every declared slot is rendered by the page that owns it" check covers the new one. Walked as far as the rig allowed: the module installs into a phase-6 core, boots, and serves its chunk with the new slot in it. The rendered toggle itself is **not** visually confirmed — the browser tooling failed in this environment — see the note on website#156. --- AI-assisted: written with Claude Code. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
wtclaude added 1 commit 2026-08-18 23:03:14 +00:00
feat(guilds): a third place on the guild page, and where that page lives
All checks were successful
PR Checks / server-tests (pull_request) Successful in 23s
PR Checks / client-build (pull_request) Successful in 17s
PR Checks / frozen-manifest (pull_request) Successful in 34s
c57310c505
Two lines only core cannot supply for itself.

`uo.guild.header` is a third declared slot, at the top of the page, for core's
per-Team notification control. A third rather than a corner of the feed because a
slot holds one component and the first fill wins: the control is an action ON this
page and the other two are content IN it, and separate slots are what let this
module say so.

`pageUrlTemplate` tells core where a guild page actually is. Teams are a contract
primitive with no core surface — core owns the tables and the access rules, this
module owns the word "guild" and therefore the page — which leaves core unable to
write a link to one. A notification email that cannot take you to the thread it is
about is most of the way to useless. Core substitutes `{externalId}` and does
nothing else with it; a template naming its own host is refused at registration.

Co-Authored-By: Claude <noreply@anthropic.com>
whitlocktech merged commit 990a50b491 into edge 2026-08-18 23:10:04 +00:00
whitlocktech deleted branch feature/teams-phase6-notifications 2026-08-18 23:10:05 +00:00
Sign in to join this conversation.
No Reviewers
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: RunicGateway/Module-uo#13
No description provided.