Reviewed forum-tag lifecycle

Forum-tag audit and changes have no broad or immediate-call path. Set capabilities.forumTagAudit: true and list every eligible stable forum by its own exact ID in scopes.forumTagChannelIds. Set capabilities.forumTagChanges: true only when reviewed mutation is needed. The forum allowlist must be a subset of readScope.channelIds when the read allowlist is present. Guild scope, parent scope, channel-metadata scope, and forum-post scope never grant tag authority to another channel.

audit_forum_tags and discord://channels/{channelId}/forum-tags require effective View Channel and return the complete bounded ordered available_tags inventory for one stable GUILD_FORUM channel. The projection contains exact tag IDs, transient names, moderation state, privacy-safe Unicode or custom emoji identity, positions, channel flags, and count-only unknown channel and tag fields. Unknown permission-overwrite fields block the permission claim entirely. The workflow never accepts a media channel, enumerates posts or threads, estimates tag usage, or persists tag text. Changes additionally require effective Manage Channels from complete guild, connector-member, role, and forum-overwrite evidence.

The narrow mutation surface accepts one exact action:

• create appends one name from zero through 20 Unicode characters, optional moderation state, and optional single NFC Unicode emoji grapheme. One exact semantic match is a record-free no-op, multiple matches are ambiguous, and a full 20-tag inventory blocks creation.
• update-metadata targets one exact tag ID and changes at least one explicit name, moderation state, or Unicode emoji field. Omitted fields are preserved, unicodeEmoji: null clears the emoji, and omitting unicodeEmoji preserves an existing custom emoji ID.
• delete targets one exact tag ID and surfaces that bounded tag-use counts are unavailable. It never scans active or archived posts to invent impact evidence.

Custom emoji introduction, fuzzy name selection, raw array replacement, reordering, bulk actions, and media channels are deliberately absent. Unknown future tag fields remain visible as counts during audit but block changes because a full replacement could otherwise destroy data the connector cannot preserve.

1. Call plan_forum_tag_change with the exact action, guild, stable forum, action-specific tag fields, audit reason, and one-shot operation key.
2. Review the exact identity, forum type and flags, target ID, current and desired ordered inventories, permission evidence, deletion-impact limitation, warnings, hashed operation key, and keyed digest.
3. If writeRequired is false, the requested semantic state already exists and no approval or write is needed.
4. Call execute_forum_tag_change with identical inputs plus the digest.
5. Approve the signed MCP confirmation only if every exact ID, ordered tag field, permission, impact limitation, warning, reason, operation-key hash, and digest remains intended.
6. Review the returned tag ID, exact response and readback verification, activity ID, and outcome before any follow-up.

The process-keyed digest binds the normalized action-specific request with only its operation-key hash, application and bot identity, exact guild and forum state, channel flags, complete roles and overwrites, permission evidence, and every current and desired ordered tag field. The raw operation key never enters plan material. A connector restart invalidates the digest. The MCP adapter rebuilds the plan before approval, and the service rebuilds it again before reserving the key.

Discord exposes forum-tag mutation as a full channel available_tags replacement without a conditional update or idempotency token. The connector therefore acquires durable exact forum-channel and guild channel-collection claims, atomically reserves the one-shot key, records pending content-free activity, sends one non-retried PATCH containing only the complete desired tag array, strictly validates the returned channel, and performs one fresh complete GET. A known non-rate-limited Discord 4xx before acknowledgement is recorded as failed. Transport ambiguity, rate limiting, server failure, malformed success evidence, response drift, readback failure, or local completion-record failure is uncertain and retains the same-channel quarantine for operator review. No path retries or rolls back the replacement.

Activity and operation records contain only the action, guild, forum and applicable tag IDs, operation-key hash, plan digest, timestamp, fixed error category, outcome, and verification. Names, emoji, audit reasons, raw keys, replacement arrays, and raw payloads are never persisted. Use review_forum_tag_change for a locally validated plan-only prompt that preserves the security-relevant difference between an omitted emoji field and explicit null. See Discord's modify channel reference.

Canonical source: docs/reference.md