Reviewed exact channel retirement

Channel deletion is an independently scoped retirement workflow rather than an extension of ordinary channel reads, metadata edits, message deletion, or broad administration. Set capabilities.channelDeletionAudit: true, list each eligible target in scopes.channelDeletionIds, include channel-deletion in a selected toolset surface, enable gateway.enabled, and include both the exact target and its guild in readScope.channelIds and readScope.guildIds. Add guild-blueprints only when using the optional prepare_guild_recovery prompt and satisfy the blueprint capture audit prerequisites documented below. Set capabilities.channelDeletions: true only when execution is intended. Audit requires pinned application and bot identities, an exact read-guild boundary, and the nonprivileged GUILDS Gateway intent; it never requires Message Content.

discord://guilds/{guildId}/channels/{channelId}/deletion-readiness and plan_channel_deletion support one exact allowlisted direct text, voice, category, Stage, forum, or media channel. Direct messages, threads, announcement channels, directory channels, and unknown future types are rejected. Every request uses the exact guild and channel IDs. A plan additionally requires one bounded Discord audit-log reason, one unique operation key, literal acknowledgeIrreversibleContentLoss: true, and the exact recovery choice; names, fuzzy matching, bulk targets, dependent-resource cleanup, retries, recreation, rollback, and absent-target success are unavailable.

Readiness combines a continuity-stable complete Gateway layout with exact HTTP guild, channel, connector-member, and complete role evidence. It requires guild-level MANAGE_GUILD, target-effective VIEW_CHANNEL and MANAGE_CHANNELS, MANAGE_WEBHOOKS for webhook-capable targets, and READ_MESSAGE_HISTORY plus MANAGE_THREADS for text, forum, and media targets. The target must be visible and must match the Gateway type, parent, and position exactly. Unknown roles, permission bits, overwrites, identity fields, channel evidence, or topology fail closed.

The dependency pass blocks retirement when the exact target is a guild AFK, system, rules, public-updates, safety-alerts, or widget reference; appears in authenticated widget settings, onboarding, a Welcome Screen, or an AutoMod rule; hosts a scheduled event or active Stage instance; owns an invite or webhook; contains any active, public archived, or private archived thread; or is a non-empty category. Discord normally uncategorizes children when a category is deleted, but this workflow refuses that implicit topology mutation. Dependency results expose only kinds, counts, and a keyed digest. Invite codes, webhook credentials, thread identities, policy content, member identities, and other dependency identifiers never leave transient private evidence. Discord supplies no bounded REST inventory of voice occupants, so voice and Stage plans explicitly warn that occupancy is unavailable and require the operator to verify the target is empty before approval; an active Stage instance remains an automatic blocker.

Message content is never fetched, enumerated, counted, hashed, or persisted. A last-message reference, when Discord supplies one, is surfaced only as a boolean; its absence is explicitly not treated as proof that the channel is empty. The plan therefore describes the content loss as unbounded and irreversible even after every enumerated structural dependency is clear.

1. Optionally invoke prepare_guild_recovery with the exact guild and channel IDs, then retain the complete returned blueprint and matching unexpired channel attestation. This prompt performs no plan or write and never selects the no-artifact alternative.
2. Read the deletion-readiness resource or call plan_channel_deletion with the exact guild and channel IDs, literal irreversible-loss acknowledgement, audit reason, one-shot operation key, and either the exact matching attestation plus caller-retention acknowledgement or the explicit no-artifact acknowledgement.
3. Review the verified identities, transient untrusted target name, target type and parent, complete topology revision, HTTP evidence mode, exact required and effective permissions, dependency kinds and counts, credential-free recovery mode, capture fingerprint, target projection digest, timestamps, omissions and limitations, privacy boundary, risks, warnings, operation-key hash, and keyed digest. The plan never echoes the attestation.
4. If the plan is blocked, clear dependencies through their own reviewed workflows and create a fresh plan; execution performs no approval, reservation, activity write, or Discord mutation for that result.
5. Call execute_channel_deletion with identical inputs plus the digest, then approve the signed MCP confirmation only if the exact target, irreversible and recovery acknowledgements, credential-free recovery evidence and limitations, reason, dependency and permission evidence, risks, warnings, operation-key hash, and digest remain intended.
6. Review the newer Gateway revision, remaining channel count, added-channel drift count, activity ID, verification, and outcome before any follow-up.

The process-keyed plan digest binds the normalized request without the raw operation key or attestation, its domain-separated operation-key hash and attestation hash where present, verified credential-free recovery projection, verified application, bot, guild, membership, roles, guild and target permissions, exact target projection, complete Gateway topology and revision, coherent HTTP evidence mode, dependency inventory, audit reason, irreversible and recovery acknowledgements, privacy boundary, risks, and warnings. A connector restart invalidates both the plan and every recovery attestation. The MCP adapter rebuilds the plan before signed confirmation, and the service rebuilds it immediately before durable coordination and reservation. Every plan must match exactly.

A real retirement durably claims the exact target and whole guild channel collection, atomically reserves the one-shot key, appends pending content-free activity, subscribes to Gateway layout updates, and synchronously verifies the baseline before sending one non-retried DELETE with the encoded audit reason. It strictly validates that Discord returned the reviewed channel, then requires a newer complete Gateway layout in which the target is absent and every baseline survivor retains the same type, parent, and obfuscation state. Newly added unrelated channels produce completed-with-drift; a removed or structurally changed survivor never counts as success.

A known non-rate-limited Discord client refusal before acceptance can settle as failed. Transport ambiguity, rate limiting, server errors, response mismatch, continuity loss, timeout, contradictory topology, or any failure after the mutation may have begun is uncertain. Direct service instances quarantine later same-guild channel deletion after uncertainty. The production facade's durable guild-channel collection claim also excludes overlapping topology workflows across connector processes sharing the activity-state root. There is no automatic retry, cleanup, rollback, recreation, or inference from a later 404.

Activity and operation records contain only exact guild and target IDs, target kind, baseline and observed layout revisions and channel counts, dependency count, plan and operation-key digests, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. They never contain channel names, topics, message facts, dependency identifiers, permission or overwrite evidence, recovery attestations or blueprint content, audit reasons, raw operation keys, or Discord payloads. Discord's Delete/Close Channel contract defines the irreversible remote operation and returned Channel object; this connector adds the stricter reviewed dependency, state-binding, recovery-choice, and Gateway absence requirements.

Canonical source: docs/reference.md