Guild settings

Keep guild-settings inspection behind its own audit toggle and exact guild allowlist. The allowlist must remain a subset of any configured read-guild scope. Require pinned application and bot identities, an exact guild and owner, exact connector membership, complete bounded roles, complete effective guild permissions, and continuity-safe direct-channel evidence before returning an audit or plan.

Expose only the finite named settings surface: verification level, default message notifications, explicit-content filtering, nullable AFK channel, AFK timeout, nullable system channel, named system-notification suppressions, and premium progress-bar enablement. Never expose or accept raw numeric enums or a raw system-channel bitfield. Omit guild, role, and channel names, member data, raw payloads, and unknown values. Reduce unknown system-channel bits to presence and block suppression-list changes while any unknown bits exist.

Collect channel evidence by bracketing one bounded HTTP inventory with identical complete Gateway layouts. Accept only a complete HTTP inventory or its exact non-obfuscated subset. Treat omitted or obfuscated metadata as unsafe, not absent. Require exact trusted ordinary voice metadata for requested non-null AFK channels and exact trusted text or announcement metadata for requested non-null system channels. Permit explicit clearing of an unsafe current reference, and do not block unrelated scalar changes solely because an unmodified current reference is unsafe.

Treat every change request as one exact sparse named-field intent. Require at least one supported field, preserve every omitted field, and interpret an explicit nullable channel as a deliberate clear. Do not add immediate-call, raw-bitfield, raw-enum, fuzzy-channel, complete-object replacement, retry, rollback, or compensating shortcuts. Preserve every gate: verified identities, exact policy, complete evidence, MANAGE_GUILD or exact-owner authority, strict 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 sparse PATCH with an encoded audit-log reason, strict authoritative-response validation, and a complete fresh readback. A client without MCP elicitation must not execute a guild-settings change.

The plan digest must bind the normalized sparse request, operation-key hash, verified identities, exact owner, connector membership and roles, complete permissions, continuity-safe channels, authoritative current and desired named settings, requested and changed fields, effects, privacy projection, verification boundary, risks, and warnings. Any evidence or intent change must invalidate review. An already-current request must return without confirmation, reservation, activity, or mutation.

Validate the complete Guild mutation response before readback. Require every supported controlled field in the response, compare each requested field with the reviewed value, preserve unrelated response fields outside the write contract, and perform a fresh full evidence read. Report valid divergence only as controlled field names. Never return or persist a raw response, raw bitfield, changed value, channel name, or audit reason.

A definite Discord client refusal may be classified as failed. Treat transport failure, Discord server failure, malformed success, failed response validation, failed full readback, failed receipt finalization, 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 must also acquire a durable exact guild-settings collection claim and retain it after uncertainty.

Guild-settings 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; activity records may additionally contain sorted requested field names. Never persist setting values, channel IDs, guild, role, or channel names, permission or inventory evidence, audit reasons, raw operation keys, raw Discord responses, or transport causes.

Canonical source: SECURITY.md