Forum tags

Keep forum-tag audit behind its own toggle and non-empty exact stable-forum allowlist. The allowlist must remain a subset of any configured read-channel scope. Require the exact GUILD_FORUM type, verified application and bot identities, exact guild ownership, exact connector membership, complete bounded roles and forum overwrites, complete bounded ordered available_tags, and effective VIEW_CHANNEL before returning an audit or plan. Reject media channels even if Discord exposes a similar shape. Do not derive tag authority from guild scope, channel-metadata scope, forum-post scope, a readable parent, or Gateway events.

Project the channel and tag response immediately. Return only exact guild, forum and tag IDs, numeric type and flags, bounded transient names, moderation state, privacy-safe Unicode or custom emoji identity, order, count-only unknown fields, fixed limits, and complete permission evidence. Never enumerate posts or threads to estimate tag usage. Never cache, journal, persist, log, or export tag names, emoji, raw arrays, role or overwrite evidence, or raw Discord payloads.

Keep changes behind a second toggle and require complete MANAGE_CHANNELS evidence. Permit only one exact create, exact-ID metadata update, or exact-ID deletion. Creation may append one tag and become a record-free no-op only for one exact semantic match; duplicate semantic matches are ambiguous. Metadata update must preserve every omitted field and every untouched custom emoji ID, while explicit unicodeEmoji: null clears an emoji. Deletion must state that bounded usage impact is unavailable and must not scan active or archived posts. Do not add custom emoji introduction, fuzzy name resolution, raw-array input, reordering, bulk actions, media channels, retries, rollback, or reconciliation.

Validate the complete ordered inventory and fail closed above the documented tag bound, at capacity for creation, on duplicate or missing IDs, malformed Unicode, unsupported emoji pairs, unknown permission-overwrite fields, or unknown tag fields that a full replacement could destroy. Audit may report unknown channel and tag fields only as counts, but unknown overwrite fields block permission claims and no change plan may proceed while an existing tag has unknown fields. Preserve IDs, ordering, moderation, names, emoji IDs, emoji names, and untouched fields exactly in the desired replacement.

Bind the normalized action-specific request, verified identities, exact guild and forum, channel flags, complete roles and overwrites, effective permissions, complete current and desired ordered inventories, deletion-impact limitation, audit reason, and domain-separated operation-key hash into the process-keyed plan. Preserve omitted versus explicit null metadata in signed request state. Exclude the raw operation key from plan material, signed state, records, results, and errors. A no-op must reserve nothing, journal nothing, request no confirmation, and issue no write.

Do not add a forum-tag shortcut that bypasses exact scope, pinned identity, complete evidence, process-keyed planning, signed interactive confirmation, write-aware host approval, final fresh-plan equality, durable exact channel and guild channel-collection coordination, atomic one-shot operation-key reservation, pending content-free activity, one non-retried PATCH containing only the full available_tags array, strict returned-channel validation, or one fresh complete GET readback. A client without MCP elicitation must not execute a forum-tag change.

Discord supplies no conditional update or idempotency token for the full-array replacement. A known non-rate-limited Discord 4xx refusal before acknowledgement may settle as failed. Treat rate limiting, transport failure, Discord server failure, malformed success, response mismatch, readback failure, local completion-record failure, or every other indeterminate post-reservation result as uncertain and potentially completed. Permanently spend the key, retain same-channel quarantine inside the service and durable coordination layer, and never retry, compensate, or roll back automatically.

Forum-tag activity and operation records may contain only exact guild, forum and applicable tag IDs, action, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. A completed create must record the returned exact tag ID; a pending or failed create must not invent one. Never persist names, emoji, audit reasons, raw keys, complete replacement arrays, permission evidence, raw responses, or transport causes.

Canonical source: SECURITY.md