feat(discord): set up the Discord server with /openmu setup (M3)

[sven-n]

Milestone M3 of the Discord integration (#1101). Stacked on #1156 (M2), so review/merge that first.

What

• Layout file (src/Discord/Provisioning/DefaultLayout.json, embedded): roles GM and Linked Player; categories Info (#announcements, #events, #server-status), Community (#world-news, #world-chat, #general) and Staff (#staff-alerts, #gm-commands, only visible to GM). Each item has a stable key. Channels can be read-only, announcement channels, receive notification categories or show the status. A custom layout can be configured with Discord__Bot__LayoutFile; it's validated on load (unique keys, known roles).
• /openmu setup: a slash command with Administrator as its default member permission, usable in guilds only. The handler re-checks that the user is an admin. Behaviour:
  • Idempotent: existing roles, categories and channels are adopted by name (case-insensitive); only the missing ones are created.
  • Permissions: the permissions the layout defines are merged into the existing overwrites for @everyone, the roles and the bot; other overwrites stay as they are.
  • Nothing destructive: nothing is deleted or renamed.
  • Report: an ephemeral reply (en/de) lists what was created, what was adopted and what failed, plus a hint about the needed permissions.
• Key-based routing: the bot finds the layout's channels by name in the configured guild (or in the only guild it's in), refreshed every status tick and right after setup. Notifications and the status message go there. Explicitly configured Bot__Channels__* / Bot__StatusChannelId take precedence. Until the bot is connected, categories without an explicit channel fall back to their webhook.
• Storage decision: no DB entity or migration. The key→id mapping is resolved by name at runtime, just as the status message is found again after a restart. Renamed channels can be pinned by configuring their id.
• Testability: provisioning runs against a small IDiscordServer abstraction; SocketGuildServer adapts Discord.Net's guild to it.
• Docs: setup section, layout format, server template workflow (M3.4), extra bot permissions (Manage Channels, Manage Roles) and new settings.

Tests

New: provisioning of an empty server, idempotency, adoption by name across categories, failure reporting with continuation, permission overwrites, finding channels, layout validation, routing precedence, setup report, and webhook fallback in the notifier. Full suite: 1690 passed.

Not tested against a real Discord server/bot token.

🤖 Generated with Claude Code

https://claude.ai/code/session_01USFZ9xErMB1EwkpfdUHzoZ

---

Generated by Claude Code

[cloudflare-workers-and-pages]

Deploying openmudocs with    Cloudflare Pages

Latest commit:	1979383
Status:	✅  Deploy successful!
Preview URL:	https://3aecb009.openmudocs.pages.dev
Branch Preview URL:	https://claude-sweet-cray-w8crms-m3.openmudocs.pages.dev

View logs

[sven-n]

Part of a review pass over the whole Discord stack.

The idempotency story here is the part I was most sceptical of going in, and it holds up: adopt by name, create only what's missing, never delete or rename, and the IDiscordServer seam with FakeDiscordServer means the provisioner is actually testable without a live server. /openmu setup is gated twice — WithDefaultMemberPermissions(Administrator) on the command plus an explicit GuildPermissions.Administrator check at execution, because the default can be overridden in the Discord server's settings. That's the right instinct and the comment says so.

Three comments inline. The permission-overwrite one is the only one with a user-visible failure mode.

---

Generated by Claude Code