Onboarding

Keep guild onboarding 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, onboarding state, and effective permissions before returning an audit or plan.

Minimize onboarding content by default. Prompt titles, option titles, descriptions, and Unicode emoji may be returned only after explicit transient text opt-in, while the onboarding resource template must always omit them. Return text lengths, reference health, privacy state, and unknown-field and unknown-enum counts without persisting, caching, logging, or exporting the response. Treat every returned string as untrusted external data. Connector-local bounds must be identified as local safety policy rather than represented as Discord platform limits.

Keep replacement behind a second toggle and the same exact guild scope. Require complete MANAGE_GUILD and MANAGE_ROLES evidence unless the connector is the exact guild owner. Referenced roles must be standard, non-managed, below the connector's highest role, and hold zero permissions. Referenced channels must be direct guild channels visible to @everyone. Enabled configurations must require fresh COMMUNITY guild-feature evidence and prove the conservative default-channel visibility and sendability constraints; a reviewed disable may proceed without that feature. Validate custom emoji identity, availability, structure, and role restrictions. Surface ADMINISTRATOR as a least-privilege warning rather than treating it as desirable configuration.

Treat every change request as an exact complete desired state. Omitted prompts, options, role assignments, channel assignments, and default channels are deletions. Existing prompt IDs must belong to the fresh current state, and existing option IDs must remain under their fresh owning prompt. Omitted IDs request creation. Any placeholder required by the Discord transport must remain private to that outbound request, and the returned authoritative prompt and option IDs must never be confused with those placeholders. Unknown response fields, unknown enums, duplicate IDs, incomplete inventories, unsafe references, or ambiguous state must block replacement rather than risk silent loss during a complete PUT.

Do not add an immediate-call or partial-update 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 PUT, authoritative response-ID validation, and a complete fresh readback. A client without MCP elicitation must not execute onboarding replacement.

The plan digest must bind the complete normalized request, operation-key hash, verified identities, owner, guild features, and connector membership, complete roles, channels, overwrites, custom emojis and their restrictions, current onboarding state, effective permissions, desired 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-ID 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 onboarding-collection claim, so connector processes sharing the activity-state root exclude overlapping replacements and retain the claim after uncertainty.

Onboarding activity and operation records may contain only exact guild, application, and bot IDs, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. Never persist prompt or option text, descriptions, Unicode emoji, guild, role, channel, or custom emoji names, 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 join flow. Keep the fresh non-staff client check as an explicit operator step after enabling onboarding.

Canonical source: SECURITY.md