Channel metadata

Keep exact metadata reads under ordinary guild and channel scope. Project every Discord response immediately to the supported metadata fields, applicable-field list, overwrite count, and unknown-field count. Never cache, journal, persist, or return the raw channel object or complete overwrite set through this surface. Treat returned names, topics, and RTC region IDs as untrusted transient Discord text. Global and exact-guild voice-region reads must remain complete, locally bounded, deterministic, identity-pinned, strictly projected, raw-payload-free, and non-persistent; enforce exact guild scope before a guild-region API call.

Do not add a metadata-change shortcut that bypasses the independent configuration gate, exact direct-channel allowlist, verified application and bot identities, exact guild and owner, exact bot membership, complete roles and overwrites, effective VIEW_CHANNEL plus MANAGE_CHANNELS authority, type-required CONNECT authority for voice and Stage targets, process-keyed planning, signed interactive confirmation, write-aware host approval, final fresh-plan match, atomic one-shot operation-key reservation, pending content-free activity, same-channel serialization, one non-retried PATCH, exact response validation, or complete fresh projected GET. If a client cannot support MCP elicitation, keep execution unavailable in that client.

Keep mutation partial and type-aware. Permit only name, topic, NSFW, slowmode, default thread slowmode, default auto-archive duration, bitrate, user limit, RTC region, and semantic video-quality mode where Discord defines those fields for the exact non-thread channel type. Preserve omitted fields from fresh state. Reject unknown keys, undefined values, malformed text, unsupported durations or modes, type-inapplicable fields, thread targets, and mismatched IDs before planning. Explicit null or empty topic input may clear a supported topic, and explicit null RTC region restores Discord's automatic selection; no implicit clearing is allowed.

For voice bitrate, bind the fresh guild premium tier and VIP_REGIONS feature to the applicable documented ceiling. Keep the Stage bitrate ceiling independent of guild boost state and enforce distinct voice and Stage user limits. An explicit non-null RTC region must appear exactly once and must not be deprecated in a fresh complete exact-guild inventory. Bind that whole canonical inventory through a keyed digest so any addition, removal, rename, flag change, or selected-region change invalidates review. Do not fetch the inventory when RTC region is omitted or explicitly automatic.

Do not silently add channel deletion, type conversion, parent or position changes, permission-overwrite replacement, forum-tag replacement, flags, thread edits, bulk changes, retry, rollback, or reconciliation. Those operations differ in blast radius, reversibility, permissions, and concurrency behavior and require separate policy and evidence.

Bind the normalized partial request, verified identities, exact guild ownership, bot membership, complete role and overwrite evidence, effective permission decision, complete supported current and desired metadata projections, requested and changed fields, local limits, applicable voice-setting and region evidence, audit reason, and domain-separated operation-key hash into the plan. Exclude the raw key from plan material, signed request state, records, results, and errors. Guild ownership grants permission according to Discord's permission contract, but must be bound explicitly and must not relax exact bot-member or state validation.

A no-op must reserve nothing, journal nothing, request no approval or confirmation, and issue no write. A real change must reserve the key before creating a pending activity record and writing. A reserved key remains spent after every outcome. A known pre-response Discord client error may settle as failed. Transport errors, server errors, malformed responses, post-response failures, and readback failures are uncertain and potentially completed. Never retry, compensate, or roll back automatically.

Serialize metadata changes to one channel inside the process as defense in depth. The production facade also acquires durable exact channel and guild channel-collection claims, so connector processes sharing the activity-state root exclude overlapping channel-topology changes and retain the claims after uncertainty. Never persist names, topics, region names, voice-region inventories, role names, permission evidence, current or desired metadata, audit reasons, raw operation keys, or raw Discord responses. Activity and operation records may contain only exact guild and channel IDs, requested field names, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category.

Canonical source: SECURITY.md