Welcome Screens

Keep Welcome Screen inspection behind its own audit toggle and exact guild allowlist. The allowlist must remain a subset of any configured read-guild scope. Require verified application and bot identities, an exact guild, owner, and bounded feature set, exact connector membership, complete bounded roles, channels, permission overwrites, custom emojis, Welcome Screen state, and effective permissions before returning an audit or plan.

Minimize member-facing content by default. Descriptions and Unicode emoji may be returned only after explicit transient text opt-in, while the Welcome Screen resource template must always omit them. Return exact structural references, text lengths, reference health, privacy state, and unknown-field counts without persisting, caching, logging, or exporting the response. A disabled Welcome Screen without complete MANAGE_GUILD authority is unavailable evidence and must never be reconstructed or guessed.

Keep complete replacement behind a second toggle and the same exact guild scope. Require the COMMUNITY guild feature and complete MANAGE_GUILD authority unless the connector is the exact guild owner. Referenced targets must be direct text, announcement, forum, or media channels visible to @everyone. Custom emoji must match an exact available guild emoji with no role restriction; Unicode emoji must be one normalized emoji grapheme. Unknown response fields, duplicate channel IDs, incomplete inventories, unsafe references, or ambiguous state must block replacement rather than risk silent loss during a complete PATCH.

Treat every change request as one exact complete ordered desired state. Omitted channel entries are deletions, and moving an entry changes its order. Do not add an immediate-call, partial-update, public widget, widget-image, invite-creation, or member-presence shortcut. Preserve every gate: verified identities, exact policy, complete evidence, strict complete-state normalization, process-keyed plan binding, signed interactive confirmation, write-aware client approval, final fresh-plan match, atomic one-shot operation-key reservation, pending content-free activity, one non-retried PATCH with an encoded audit-log reason, authoritative response validation, and complete fresh readback. A client without MCP elicitation must not execute Welcome Screen replacement.

The plan digest must bind the complete normalized request, operation-key hash, verified identities, owner, guild features, connector membership and authority, complete roles, channels, overwrites, custom emojis and their restrictions, current Welcome Screen state, desired ordered state, diff, local limits, privacy projection, risks, warnings, and verification boundary. Any change to that evidence must invalidate the review. An already-current request must return without confirmation, reservation, activity, or mutation.

A definite Discord client refusal may be classified as failed. Treat transport failure, Discord server failure, malformed success, failed authoritative response validation, failed full readback, or any otherwise indeterminate post-reservation state as uncertain and potentially completed. Spend every reserved key after every outcome, retain a permanent same-guild uncertainty barrier inside the service instance, and never retry, roll back, or compensate automatically. Keep same-guild serialization inside each process as defense in depth. The production facade also acquires a durable exact guild Welcome Screen collection claim, so connector processes sharing the activity-state root exclude overlapping replacements and retain the claim after uncertainty.

Welcome Screen activity and operation records may contain only the exact guild ID, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. Never persist descriptions, Unicode emoji, guild, role, channel, or custom emoji names, channel IDs, permission evidence, audit reasons, raw operation keys, raw Discord responses, or transport causes. API response and fresh readback can verify only the controlled server state, not the member client experience. Keep a fresh non-staff client check as an explicit operator step after enabling the Welcome Screen.

Canonical source: SECURITY.md