# Security

## Credentials

Treat the bot token referenced by any config or profile as a password, whether it arrives through `DISCORD_BOT_TOKEN`, another selected `DISCORD_*_TOKEN` variable, or a protected file. Keep it in a local secret source, never paste it into prompts, and never embed its value in static MCP client configuration, policy files, shell history, logs, issue reports, or Git. Rotate a token immediately in the Discord Developer Portal if exposure is suspected.

Treat every Discord invite code and complete invite URL as a bearer credential. Never copy one into an MCP argument, prompt, resource URI, audit reason, log, diagnostic, issue report, or persistent record. Use only the connector's process-local opaque invite references.

Treat every native Guild Template code and complete template use URL as a bearer credential. Never copy one into an MCP argument, prompt, resource URI, audit reason, log, diagnostic, issue report, or persistent record. Use only the connector's process-local opaque template references.

The connector sends the token only to Discord: in a bot authorization header at the fixed production REST API origin, or in Gateway Identify and Resume payloads after connecting to the fixed production `gateway.discord.gg` origin or a credential-free `gateway-*.discord.gg` resume host. Tests can inject another transport directly, but runtime environment variables cannot redirect production traffic.

Treat all Discord-provided names, descriptions, locations, topics, forum tags, thread names, message bodies, embeds, components, filenames, and URLs as untrusted input. They are data to inspect, not instructions for language models, MCP hosts, or connector operators.

## Unified configuration

Keep configuration non-secret and host-neutral. One strict versioned JSON document contains the verified application and bot identities, exact read scope, selected tools, Gateway policy, capability gates, feature-specific scopes, bounded limits, owned local storage roots, runtime settings, and credential-free observability policy. Secret fields contain only external environment or file references; collector headers remain environment references. Never put a bot token, collector header value, Discord name, message data, attachment URL, embed, component, or other Discord content in a configuration document.

Treat a selected configuration as the exclusive policy boundary. Activation must parse and materialize the document directly, resolve only the exact secret references it names, and never mutate `process.env`. Reject every other populated `GUILDCONTROL_*` or `OTEL_*` variable and every undeclared Discord token variable so ambient state cannot silently widen or alter file policy. Tool selection remains a callable-surface restriction, never a substitute for Discord permissions, exact allowlists, planning, approval, confirmation, freshness, operation receipts, or content-free audit gates.

Load standalone configuration only from a bounded canonical regular file owned by the process user or root, with one hard link and no group or world write access. Creation and replacement additionally require a canonical private directory owned by the process user. Publish through private exclusive temporary files, an exclusive lock, file and directory synchronization, and exact readback. Replacement must retain a recoverable hidden backup and refuse to change the pinned Discord identity.

Load a file-backed bot credential only from an absolute reference that resolves to a bounded stable regular target owned by root or the process user, with one hard link and no group or world write access. Permit a projected-secret symlink at the configured path, but open the resolved final target without following another link and verify path and metadata stability around one bounded UTF-8 read. Reject an ambient canonical token alongside a file reference instead of selecting a fallback. Never include bot credential bytes in errors, reports, logs, telemetry, configuration, or connector-managed persistent state.

Managed profiles use the same complete policy contract in a private per-user directory. Unsupported schema versions fail closed and no environment-policy compatibility shape is accepted. Profile removal must require exact confirmation and move a validated profile into private recoverable trash; it must never claim to revoke or modify the external Discord credential. Restore only the newest valid generation and only when no active profile has that name.

## Host configuration inspection

Keep static host inspection explicit, adapter-bound, release-exact, and permanently read-only. Accept one caller-selected file only when an adapter is also selected. Never search a home directory, infer a host, query a package registry, resolve a connector credential, contact Discord, start a child, edit a host or policy file, create an activity record, or expose an apply path from inspection.

Read the destination only as one bounded canonical regular single-link stable JSON file. Reject symbolic path components, unsafe size, unstable identity or metadata, duplicate object keys, malformed JSON, foreign ownership, or group and world access where portable ownership and mode metadata exist. On a platform without those portable checks, report them as unverified rather than claiming a private file. Convert every filesystem and parse failure into fixed path- and content-free diagnostics.

Derive the expected projection only from the selected strict policy and current installed-release activation plan. For a shared host file, compare only the exact connector-owned server entry and generated sensitive-input identities while ignoring unrelated host state. Compare a dedicated extension manifest completely. Emit only closed drift categories, expected adapter and activation identities, safe counts, fixed file-review and privacy evidence, limitations, and a domain-separated digest of that safe report. Never return or persist the selected host path, raw bytes, observed values, unrelated entries, credential material, or a digest computed from private host content.

Treat a match as evidence for one stable static snapshot only. It does not prove that the host loaded or retained the file, supplied a credential, honored approval or elicitation, started the process, negotiated MCP, or reached Discord. Require regeneration and a second inspection after drift repair, then direct runtime verification through `smoke` and the host's read-only path.

## Reviewed host configuration installation

Keep host installation explicit, adapter-bound, release-exact, and separate from read-only inspection. Require `host plan` or `host apply`, one caller-selected path, one exact adapter, and the same selected strict policy and launcher that produced the adapter. Never search for a host, create a parent directory, resolve a connector credential, contact Discord or another network endpoint, start a process, create activity state, or change connector policy. Do not add a generic config importer, opaque host-database writer, TOML writer, comment-preserving guess, or host auto-detection path.

Require the parent to be an existing canonical directory owned by the process user and not writable by group or world where portable metadata exists. Permit an absent target, but require every existing target to pass the inspection boundary for canonical path, regular type, single link, bounded stable duplicate-free JSON, trusted owner, and private mode. Bound JSON structure and reject non-finite, unsafe-integer, or negative-zero values that native rewriting cannot preserve. Reject incompatible shared-document roots, non-object existing server collections, non-array existing extension inputs, and duplicate generated input IDs rather than deleting or coercing ambiguous state. Preserve every unrelated top-level value, server entry, and extension input semantically. Treat a generated dedicated extension manifest as one complete-document projection, never as a shared merge.

Emit only fixed change categories and safe counts from planning. Never return the selected path, observed value, raw host JSON, unrelated entry, credential material, or a stable digest of private host bytes. Bind the plan digest to the exact activation and adapter identities, generated server name, normalized target internally, fixed change summary, and stable target and parent identity metadata. State that metadata freshness detects ordinary changes but is not a cryptographic content commitment against a privileged filesystem adversary. Require the exact generated server name as confirmation and the exact recomputed fresh plan digest before apply.

Serialize changed output as bounded canonical UTF-8 JSON. Apply only under an exclusive owner-mode sibling lock, through an exclusive synced temporary file, after an exact source byte and metadata recheck. Retain an exact owner-mode sibling backup before replacing an existing target, use no-clobber creation for an absent target, sync directory metadata where supported, reread exact published bytes, and require ordinary adapter inspection to match. On failed verification, restore and reread the original or remove and verify absence for a newly created target only while the published binding and bytes remain exact. Preserve a destination changed during verification and return uncertainty rather than overwriting it. Never claim the sibling lock excludes an external writer that ignores it. Never declare an interrupted operation's sibling lock stale automatically.

Return a backup path only when recovery requires locating the retained original and disclose that it may contain any credential already present in the host file. Never return destination content or include host content in activity, logs, telemetry, diagnostics, or another persistent record. Clear temporary byte buffers where practical and disclose that parsed JavaScript strings cannot be reliably erased. Treat successful publication as one static-file fact only; require host reload, static inspection, `smoke`, and a read-only host request for progressively stronger evidence.

## Migration planning

Keep migration planning release-exact, offline, non-mutating, and separate from runtime policy. Accept only a canonical versioned source identity from the shipped manifest catalog. Never accept or read a source checkout, source configuration, MCP host configuration, active connector policy, environment value, credential file, token, Discord content, activity state, coordination record, arbitrary URL, or nearest-version alias. Do not start a process, contact a network or Discord endpoint, open a Gateway, export telemetry, create an activity record, or change the source, target, policy, host, or Discord installation while producing a plan.

Account for every public tool in the audited source inventory exactly once. Preserve whether the evidence came from a public version tag or only version-matching public source, require one commit-pinned GitHub tree URL plus the exact versioned Registry identity, and bind the canonical inventory to its audited SHA-256 digest. Each outcome must state a closed supported, review-required, or intentionally excluded disposition, exact target tools, applicable additive recipes, a fixed operator instruction, and a fixed trust-model change. Intentionally excluded outcomes must claim no target route. Never claim argument compatibility, configuration compatibility, permission readiness, or semantic equivalence merely because names resemble one another.

Validate every mapped target tool against the credential-free production catalog and every preset and recipe against its canonical local catalog. Bind the normalized source manifest, migration catalog, negotiated target contract, mappings, staged commands, limitations, and non-execution disclosures into deterministic digests. Reject a stale target route rather than emitting partial guidance. Migration output may contain only public release identities, public HTTPS evidence links, public tool and route names, fixed placeholders, digests, counts, dispositions, and durable explanatory text. It must contain no real Discord ID, local source path, secret value, display name, message content, profile, or host-specific state.

Write optional migration HTML only through exclusive mode-0600 creation without replacement. Require a fresh valid plan digest before rendering, escape every embedded value, allow no automatic network request or external asset, persist no browser state, and remove a partial file after failure. Evidence links may navigate only after explicit user activation and must use HTTPS with no referrer. The page has no import, approval, configuration-write, host-write, process-launch, or Discord authority. A migration plan never restores legacy environment-policy compatibility or becomes an alternate runtime policy source.

## MCP result boundaries

Apply `limits.mcpReadResponseMaxBytes` to the compact UTF-8 JSON encoding of every complete redacted application read result. Enforce the strict 64 KiB through 8 MiB range with a 1 MiB default. Measure only after recursive secret redaction, and refuse an oversized read as one whole result. For a native binary attachment result, derive a conservative raw-byte ceiling from the same limit before fetch, reserving both the fixed MCP envelope and base64 expansion, then apply the ordinary whole-result measurement to the encoded tool or resource response. Never truncate structured or binary data, return a preview, report the actual size, emit a digest of withheld data, compress around the policy, spill to a file, create a snapshot or result cache, or issue a follow-up token that bypasses the same boundary.

Tool refusals must be schema-valid fixed content-free errors containing only a fixed code, fixed recovery guidance, the configured limit, and an above-limit marker. Resource and prompt refusals must be bounded `InvalidParams` protocol errors with no URI-specific evidence, identifiers, arguments, values, or measured byte count. Apply the same boundary to `input_required` results because no mutation has occurred yet.

Never replace, truncate, or reject the final result or error of a mutation-capable tool based on this read budget. Discord may already have changed, so preserving its complete final outcome takes priority over the configured read boundary. Protocol initialization, discovery and list responses, list-change events, and notifications are separate control surfaces; bound them through toolset selection, progressive discovery, and existing catalog rules rather than treating them as application read results.

Keep community activity analysis transient and metadata-only. Resolve only exact permitted channels, ignore every message-content field, and return only aggregate participant, reply, timing, sample-composition, and pagination evidence. Exact author and reply-target IDs may exist only inside one calculation and must not enter the result, activity state, operation receipts, cache, telemetry, database, error detail, or local file. Omit usernames, channel names, profiles, roles, content, attachments, URLs, per-message evidence, and per-user rankings. Treat a bounded sample and a short or empty Discord page as limited observations, never as complete history, whole-community behavior, sentiment, intent, or causal evidence.

## Exact Discord references

Treat exact-reference parsing as local syntax conversion, never as name resolution, Discord access verification, or authorization. Accept only one complete canonical `discord.com` channel or message jump link or one official typed user, channel, role, application-command, or custom-emoji mention. Never scan surrounding prose, choose among multiple references, accept an alternate host or scheme, follow a URL, contact Discord, open the Gateway, or persist the input.

Reject malformed or zero snowflakes, values outside the unsigned 64-bit range, padding, controls, malformed Unicode, queries, fragments, unsupported Discord routes and mentions, invite capabilities, webhook execution credentials, OAuth links, and Discord CDN, attachment, or media URLs. Error messages and results must not echo the input. Omit application-command and custom-emoji names rather than turning transient display text into output or a later target.

Project only the exact configured guild and channel read boundary that can be decided from the supplied IDs. Mark missing guild or private-recipient context as incomplete, and state explicitly that Discord access remains unverified. A parsed ID and an eligible local read projection must never bypass a downstream tool's strict schema, exact feature scope, Discord permission evidence, protected-target rules, reviewed plan, host approval, signed confirmation, freshness check, one-shot reservation, journaling, or readback.

Keep initial setup presets read-only. Add a write workflow only through a locally defined additive recipe whose descriptor declares every capability, exact feature scope, canonical toolset, Discord permission, privileged intent, Gateway evidence requirement, risk, and warning it introduces. Recipe inspection, planning, and application must not resolve a secret, construct a Discord client, contact Discord, open the Gateway, start telemetry, or create activity state. A recipe must preserve the configured event-feed policy. If the resulting runtime derives a nonprivileged evidence-only Gateway connection from newly enabled feature scopes, the descriptor and review report must identify its exact intent and purpose. Scope inputs must be exact bounded snowflakes inside the existing outer read boundary; an empty outer channel list retains its documented all-visible-channels-inside-guild meaning and must produce an offline ownership warning.

Bind each recipe plan to the normalized absolute file path, canonical current and proposed documents, exact normalized request, descriptor contract, changes, and warnings with SHA-256. Application must recompute the plan, require its exact digest and exact recipe-name confirmation, then compare the reviewed source again inside the exclusive config-file lock. Refuse a stale, changed, removed, identity-drifted, or scope-escaping source. A real application may add only declared policy fields, must use atomic publication and retain a recoverable backup, and must verify the exact resulting document. An already-current application is a no-write, no-backup operation. A recipe changes local policy only; every Discord operation still requires all of its independent permission, plan, approval, freshness, evidence, readback, and uncertainty gates.

## Application posture

Derive application posture only from the authenticated current-application response already required for pinned identity verification. Do not add a caller-selected application ID, application mutation, new policy gate, broader Discord scope, Gateway connection, cache, persistent file, activity record, or telemetry payload for this audit. Bind every conclusion to the freshly verified application and bot identities and to the selected connector capabilities that actually require privileged intents or Gateway Interaction delivery.

Project the response before returning it. Permit only verified IDs, booleans, fixed enums and findings, normalized known permission names, and bounded counts. Never return or persist application or bot profile text, media hashes, verification data, owner, team, guild identity, URL values, redirect targets, RPC origins, raw flags, raw permission bitfields, webhook event names, raw objects, or unknown values. Count unknown contexts, enums, scopes, permission bits, and fields without guessing their meaning. Treat malformed known evidence and unsupported bounds as errors, and treat absent or invalid authoritative flags as unknown rather than disabled.

Keep per-context installation defaults separate from legacy defaults. Report Administrator and unknown authority explicitly. Treat outgoing-webhook and Gateway Interaction delivery as mutually exclusive, require only the privileged intents selected connector capabilities need, and warn about unused Presence intent without enabling a presence workload. Findings and remediation text must come from a fixed local vocabulary, never from Discord-provided text.

## Bot installation drift

Audit installed guild membership only through an authenticated current application and bot already verified against the exact configured identities. Enumerate the Get Current User Guilds endpoint from an explicit zero cursor in fixed maximum-size pages with approximate member and presence counts disabled. Bound every response body, page, total installed-guild count, discarded-field count, and returned result before use.

Project each guild object to one unique canonical positive ID at the REST boundary. Never return, persist, log, trace, or retain guild names, icons, ownership, permissions, features, member or presence counts, unknown values, raw payloads, transport details, or partial pages. Fail the whole audit on malformed evidence, duplicates within or across pages, a non-advancing cursor, an unsafe bound, or any request failure. Require an empty terminator after an exact full local bound.

Compare the complete verified installed set with the configuration's exact guild read scope and return only sorted configured, installed, installed-in-scope, missing, and unexpected IDs plus fixed completeness and privacy evidence. Treat unexpected installation visibility as diagnostic evidence, never as authority. Do not expand local scope, rewrite policy, resolve display metadata, leave a guild, perform another mutation, create an activity or operation record, open the Gateway, or persist the result. Missing configured installations must fail online setup and verification; unexpected installations must remain an explicit warning for deliberate operator remediation. Describe multi-page evidence as a bounded completed enumeration, not an atomic Discord snapshot or proof of channel access, effective permission, consent, future membership, or write authority.

## Application Activity instances

Inspect Activity instances only for the configured and verified current application and bot. Accept one bounded opaque instance ID plus one exact expected guild and channel already inside ordinary read scope, and optionally one exact user ID for a boolean membership answer. Accept no caller-selected application, participant enumeration, private-channel target, display name, profile, token, URL, Gateway dependency, cache, write, activity record, operation receipt, telemetry payload, or persistent file.

Require the Discord response to match the pinned application, requested instance, and exact expected public guild-channel location before returning any active evidence. Fail closed on private-channel locations, guild or channel drift, malformed or duplicate participant IDs, malformed known fields, excess bounds, unknown location kinds, or identity mismatch. Treat only Discord's exact not-found response as inactive or unavailable; do not convert transport, rate-limit, server, or malformed-response failures into absence.

Return only verified application and bot IDs, active state, exact expected location, launch ID, participant count, optional membership evidence for the one caller-supplied user, fixed warnings, and count-only unknown fields. Never return or persist the participant list, display names, profiles, opaque location ID, raw response, error evidence, or transport cause. Describe the result as a transient snapshot, never as durable membership, authorization, an Activity launch or join, or voice-session evidence.

## Authenticated bot profile

Keep current-bot profile reads behind their own audit gate and the `bot-profile` toolset. Resolve the target only from the configured and freshly verified current application and bot identities. Accept no caller-selected application or bot ID, guild or channel scope, guild permission, privileged intent, Gateway requirement, generic User object, or raw response. Return only exact IDs, transient untrusted username, avatar and banner presence plus animation state, and bounded unknown-field counts. Never return media hashes, email, locale, flags, decorations, collectibles, or unknown values, and never persist profile text or media state.

Keep changes behind the independent bot-profile change gate, application-wide acknowledgement, process-keyed fresh planning, signed interactive confirmation, host write approval, final fresh remote-and-file match, durable application-wide coordination, atomic one-shot reservation, pending content-free activity, one non-retried sparse current-user PATCH, strict response validation, and independent exact editable-state readback. Accept only the bounded safe username contract and explicit avatar or banner set and clear variants. Never add a generic user or application editor, caller-supplied JSON body, audit reason, immediate mutation path, arbitrary field, or automatic retry, compensation, restore, or rollback.

Image replacement must accept only one bounded canonical process-owned regular single-link JPEG, PNG, or GIF file contained by a dedicated configured root. Reject URLs, CDN references, data URIs, base64 input, arbitrary bytes, relative paths, symlinks, hardlinks, foreign ownership, unstable reads, malformed structures, unsupported formats, and oversized files before reservation. Bind canonical file identity, stable bytes, decoded metadata, and a domain-separated keyed content digest into the plan, then encode the reviewed snapshot internally for Discord. A missing root must leave username changes and image clearance usable while blocking replacement. Never claim remote byte equality because Discord exposes only transformed media hashes after upload.

Require exact requested username and clearance state plus unchanged unrequested fields in both mutation response and fresh readback. For replacement images, require reviewed presence and animation state and exact agreement between the two returned editable profiles. A matching username and clearance of absent media are record-free no-ops; replacement remains a real write because byte equality is unobservable. A known pre-response Discord client refusal may fail. Transport ambiguity, server error, malformed or mismatched evidence, unreadable readback, or failed receipt finalization is uncertain, permanently spends the key, retains the application claim, and blocks same-application profile changes for operator review.

Activity and operation records may contain only exact application and bot IDs, three changed-field booleans, plan and operation-key digests, timestamps, fixed status and verification values, activity ID, and sanitized error category. Never persist username, review reason, local path, file metadata, image dimensions, media or content hash, image bytes, raw operation key, raw request or response, credential, or transport cause.

## Application linked-role metadata

Audit application role-connection metadata only for the freshly verified pinned application and bot. Accept no caller-selected application ID, bearer token, user role-connection values, guild role target, schema mutation, new configuration field, policy gate, Gateway connection, cache, persistent file, activity record, or telemetry payload. Validate verification-endpoint presence without returning or persisting its URL, then fetch the complete Discord inventory under the documented maximum of five records and a fixed response-byte ceiling.

Return only exact metadata keys, transient untrusted names and descriptions with character counts, normalized value families and comparisons for the eight documented types, localization counts, bounded unknown-field and future-type counts, fixed findings, and verified application and bot IDs. Never return localization values, user metadata values, raw payloads, unknown field values, or the verification URL. Fail closed on malformed identities, known fields, duplicate keys, Unicode, controls, bounds, payload size, or endpoint evidence.

Do not infer which guild roles use a metadata record, whether any user satisfies it, or whether Discord will grant a linked role. Treat future fields and type codes as explicitly incomplete evidence, never as permission or eligibility. Keep the tool and fixed resource private and uncached, and make the guided prompt stop after one read-only audit.

Keep schema changes behind a separate capability gate and the `linked-roles` toolset. Use only the verified current application's bot token; require no guild permission or privileged intent. Accept only `replace` with one complete non-empty canonical schema and exact application-wide replacement acknowledgement, or `clear` with exact clearance acknowledgement. Reject partial updates, raw Discord objects, caller-selected application IDs, empty replacement arrays, unsupported metadata types, duplicate keys, unordered localizations, unknown fields, and every guild-role or user-value operation.

Bind the freshly verified application and bot identities, verification-endpoint presence, complete transient current and desired schemas, exact ordering, complete count-only diff, schema digests, acknowledgements, risks, warnings, and domain-separated operation-key hash into the keyed plan. Require a fresh exact plan before signed interactive confirmation and again before mutation. Signed request state may contain only the action, application ID, desired-schema digest, operation-key hash, and plan digest; never place metadata keys, labels, descriptions, localization values, the verification URL, or raw keys in it.

Acquire one durable application-wide role-connection-metadata collection claim before reservation so separate connector processes cannot overlap schema replacements. Append pending content-free activity before exactly one non-retried complete-schema PUT, validate the exact complete response, and require an independent fresh exact readback. An already-current replacement or already-empty clearance is a record-free no-op. A definite pre-response Discord client refusal may fail; rate limiting, transport ambiguity, server failure, malformed or mismatched evidence, unreadable readback, or failed receipt finalization is uncertain, spends the key, retains the claim, and blocks same-application changes for operator review. Never retry, compensate, merge, restore, or roll back automatically.

Activity and operation records may retain only the exact application and bot IDs, action, record counts, reorder flag, plan and operation-key digests, timestamps, fixed status and verification values, activity ID, and sanitized error category. Never persist metadata keys, labels, descriptions, localization values, verification URLs, user role-connection values, guild-role configuration, raw requests or responses, raw operation keys, credentials, or transport causes.

## Application SKU catalogs

Audit application SKU catalogs only for the freshly verified pinned application and bot. Accept no caller-selected application ID, entitlement or subscription target, bearer token, monetization mutation, new configuration field, policy gate, Gateway connection, cache, persistent file, activity record, or telemetry payload. Fetch only the complete current-application List SKUs response under a fixed byte ceiling and a defensive record ceiling that leaves headroom above Discord's documented owner-created SKU limit and generated subscription-group records.

Treat the entire catalog as untrusted evidence. Require each SKU to carry a unique exact ID and the pinned application ID, bound its object shape and transient name and slug, reject malformed Unicode and known numeric fields, sort by snowflake ID, normalize only documented type and flag meanings, and count unknown fields and flag bits without returning their values. Preserve an unknown positive type code only as explicit future evidence rather than guessing its meaning.

Never return or persist benefits, prices, media, store URLs, entitlement or subscription objects, purchaser IDs, beneficiary guild IDs, payment data, raw payloads, or unknown values. Availability is catalog evidence, not entitlement, subscription, payment, revenue, or access evidence, and an unavailable reason must not be inferred. Keep entitlement, subscription, test-grant, consumption, deletion, and every SKU mutation outside this audit surface.

## Application monetization audit

Keep entitlement and subscription reads disabled unless the independent audit capability, dedicated `application-monetization` toolset, non-empty exact current-application SKU allowlist, and at least one endpoint-specific entitlement-guild, entitlement-user, or subscription-user scope are configured. A guild entitlement beneficiary must also remain inside the outer guild read policy. An entitlement user scope must never authorize subscription lifecycle evidence, and a subscription user scope must never authorize entitlement evidence. Enforce every policy check before identity or commerce reads, freshly verify the pinned application and bot for each request, and fetch the complete current SKU catalog before accepting any requested SKU. Never accept a caller-selected application, unconfigured subject, unconfigured SKU, stale catalog, or non-subscription SKU for a subscription audit.

Query entitlements for exactly one configured guild or user beneficiary and one bounded configured SKU set. Always request exclusion of ended and deleted entitlements. Require every response record to match the pinned application, requested SKU set, and exact beneficiary. A user-beneficiary record must have the exact user ID and no guild ID; a record with both identifies a guild benefit purchased by that user and must fail closed rather than grant user access. A guild-beneficiary record must have the exact guild ID, and any purchaser user ID must be validated and omitted.

Query subscriptions only for one exact configured user and one exact configured current subscription SKU. Require every record to match that user and include the requested SKU. Treat subscription status and period as lifecycle and reporting evidence only. Entitlements remain the only access authority; never infer access from an active subscription or denial from an inactive, ending, absent, incomplete, or unknown subscription record.

Return only exact record and configured SKU IDs, normalized documented state, canonical timestamps, bounded page evidence, configured related-SKU relationships, count-only omitted relationships and future evidence, fixed warnings, and exact requested subject identity. Never return or persist subject profiles, guild-entitlement purchaser IDs, country, payment source, payment or revenue data, product names, benefits, prices, media, entitlement links, raw payloads, unknown values, or unconfigured SKU IDs. Create no activity record, cache, Gateway state, persistent file, entitlement consumption, test grant, deletion, subscription change, SKU change, or other monetization write path.

Reject malformed known fields, timestamps, snowflakes, identities, duplicates, oversized objects or pages, cursor contradictions, invalid SKU relationships, unknown application ownership, and records outside the exact filters without echoing raw evidence. Keep every result subject to the connector's complete lossless MCP read-result byte boundary, and expose no historical or complete-inventory claim for a bounded entitlement or subscription page.

## Discord permissions

Grant only `View Channels` and `Read Message History` for ordinary read access. Native message search, reviewed announcement crossposts, native message forwarding, and Components V2 planning also require the application's Message Content privileged intent. Components V2 messages additionally require the applicable direct-channel or thread send permission only at exact selected targets. Add `View Audit Log` only to exact guilds where privacy-minimized server history is needed. Add `Pin Messages` only to exact channels or threads selected for reviewed pin management; do not grant legacy `Manage Messages` as a substitute. For message deletion, add `Manage Messages` only where another author's message, an AutoMod action message, or a bulk batch may be deleted; a bot-owned ordinary message remains an individual least-authority deletion. For announcement crossposts, add `Send Messages` only on exact selected direct announcement channels and add `Manage Messages` only when another author owns a message that may be published. For message forwarding, grant `View Channel` plus `Read Message History` only on exact selected direct sources, and grant `View Channel`, `Read Message History`, plus `Send Messages` only on exact selected direct targets. For announcement subscriptions, grant `View Channel` only on exact selected announcement sources and grant `View Channel` plus `Manage Webhooks` only on exact selected text targets. For application-owned emojis, use only the verified current application's bot token; do not add a guild permission or privileged intent. Add `Manage Webhooks` only to exact direct guild channels selected for credential-redacted generic webhook audit or reviewed Incoming-webhook creation, rename, move, or deletion. Add `Manage Guild` only to exact guilds selected for privacy-safe integration audit or deletion, capability-safe invite or privacy-bounded vanity URL audit, invite revocation, capability-safe native Guild Template audit or changes, authenticated widget-settings audit or replacement, Community routing audit or changes, or disabled Welcome Screen inspection or reviewed complete replacement. Keep a selected widget channel visible to `@everyone`, and enable the connector's independent public-exposure policy only where reviewed enabling or retargeting is intentional. Add both `Manage Guild` and `Manage Roles` only to exact guilds selected for reviewed complete onboarding replacement or exact role retirement. Add `Create Guild Expressions` only to exact guilds selected for emoji or sticker creation and management of bot-owned expressions, and add `Manage Guild Expressions` only when cross-owner changes are intended. Add `Create Events` only to exact guilds selected for scheduled-event administration, add `Manage Events` only when cross-owner changes are intended, and grant the documented voice or stage channel permissions only at exact hosting targets. Scheduled-event subscriber audit reuses those read permissions, forces member expansion off, and must not introduce a Guild Members privileged-intent dependency. For Stage lifecycle changes, grant `View Channel`, `Connect`, `Manage Channels`, `Mute Members`, and `Move Members` only on exact selected Stage channels; add `Mention Everyone` only when reviewed Stage starts must issue Discord's guild-wide notification. Add `Attach Files` and the applicable send permission only to exact channels or threads selected for reviewed attachment messages. Add `Send Messages` only to exact forums selected for reviewed forum-post creation, and add `Manage Threads` only when the workflow must apply moderated tags. Add `View Channel` only to exact stable forums selected for forum-tag audit, and add `Manage Channels` only when reviewed forum-tag changes are intended. Add `Create Public Threads` only to exact text or announcement parents selected for reviewed anchored or standalone-public creation, add `Create Private Threads` only to exact text parents for standalone-private creation, and retain `Read Message History` for message-anchored creation. Add `Manage Channels` and retain `View Channel` only on exact direct guild channels selected for reviewed metadata changes. Add `Manage Channels` only to exact guilds and parent categories selected for reviewed additive channel creation or guild scaffolds. Add `Manage Roles` only to exact guilds selected for reviewed additive role creation, guild scaffolds, exact member-role changes, exact standard-role configuration, exact role retirement, or exact relative role ordering, and keep the connector bot's highest role above every selected target and anchor. Add `Manage Messages` only to exact channels selected for reaction moderation. Add `Kick Members`, `Ban Members`, or `Moderate Members` only to exact guilds where the corresponding reviewed action is required. Do not make `Administrator` a standing connector grant. First-time Community enablement may use exact guild ownership or a temporary operator-managed `Administrator` grant; remove that grant immediately after the reviewed enablement frontier and retain only the narrower permissions required by later workflows.

The `Manage Roles` guidance covers both single-member and independently scoped bulk member-role changes. A Discord permission never substitutes for either workflow's exact local guild and role allowlists, protected-user exclusions, hierarchy proof, permission-impact review, or signed approval.

One-to-one direct messages require no guild permission or privileged intent. Keep them behind their own exact ordinary-user allowlist and independent audit, delivery, owned-file attachment, editing, and deletion gates. Private attachments additionally require ordinary delivery authority and a canonical owned local root, but no guild `Attach Files` permission. Never infer private-message authority from a guild installation, shared guild, member scope, channel scope, username, guild attachment authority, or another messaging capability.

Private webhook message actions require only `View Channel` for the connector's exact target evidence plus the privately held Incoming-webhook credential for message access. They must not infer broader Discord or local authority from possession of that credential, and they must never cross the dedicated exact webhook-message channel allowlist. Grant `Manage Webhooks` only when the separately gated administration workflow needs it.

Restart-safe Components V2 verification retains the Message Content intent requirement but needs only `View Channel` and `Read Message History` at the exact target. It binds the caller-retained request to a token-keyed content-free receipt, fetches only the receipt-bound exact message, and authenticates every managed request Button without requiring a live broker. It does not require send permission, scan history, reserve an operation, append activity, consume a write limit, or mutate Discord. Rotating the bot token intentionally invalidates prior request bindings and published request-button routes.

Restart-safe static rich-embed verification retains the independent exact embed-message scope and Message Content intent requirement but likewise needs only `View Channel` and `Read Message History` at the exact target. It binds the caller-retained request to a separate token-keyed content-free receipt and fetches only the receipt-bound exact message. It does not require `Embed Links` or send permission, scan history, reserve an operation, append activity, consume a write limit, or mutate Discord. Rotating the bot token intentionally invalidates prior request bindings.

Privacy-minimized guild-settings audit, guild incident-action audit, and their reviewed sparse changes require only `Manage Guild` at each exact separately allowlisted guild, unless the verified bot is the exact guild owner. Do not add `Administrator`, channel-management, moderation, or member permissions for these surfaces.

For the bot's own reaction additions, grant `Add Reactions` only in exact interaction channels; removing an existing own reaction does not require it. Reaction-user identity pages require no write permission but must remain behind their independent local gate and exact channel allowlist. Reviewed reaction moderation requires `View Channel`, `Read Message History`, and `Manage Messages` on every exact selected target, plus `Connect` for voice or Stage channels. Do not grant reaction authority through a parent, category, another write scope, or `Administrator`.

For exact member voice-state audit, grant only `View Channel` and `Connect` on each separately selected voice or Stage channel. For reviewed member voice changes, add only the action-specific permission on exact ordinary voice channels: `Move Members` for move or disconnect, `Mute Members` for server mute or unmute, and `Deafen Members` for server deafen or undeafen. The target must also have effective `View Channel` and `Connect` at a move destination. Do not grant one voice capability as a substitute for another or enable Stage participant mutation.

For exact thread-state audit, retain `View Channel` on each separately selected thread's parent. For reviewed governance, add `Send Messages in Threads` only where an unarchive or member-add action requires it, and add `Manage Threads` only for exact selected lifecycle, metadata, invitation-policy, or membership actions that require moderator authority. A member-add target must independently have effective parent visibility. Do not grant thread-creation, pin-management, permission-overwrite, or deletion authority as a substitute.

For metadata changes on voice and stage channels, retain `Connect` on the exact target. Discord's implicit permission rules otherwise make channel-management authority ineffective there.

Use Discord channel permission overrides and the connector allowlists together. Removing either Discord access or the local allowlist entry should be sufficient to stop connector access.

An allowlisted channel grants local read scope to child threads, including forum posts, but does not grant interaction, static component-message, or static rich-embed scope, deletion, pin-management, reaction-user-audit, reaction-moderation, announcement-crosspost, message-forwarding, announcement-subscription, thread-governance, channel-metadata, or Stage-instance scope to those thread IDs, webhook scope to a thread, integration, invite, Guild Template, onboarding, Welcome Screen, or widget-settings scope to its guild, forum-post creation or forum-tag scope to another channel, or thread-creation scope to its parent. Static rich-embed creation and editing require the target channel or thread's own exact ID in `scopes.embedMessageChannelIds`; interaction scope grants no substitute authority. Thread audit and changes require the target thread's own exact ID plus its exact guild in dedicated allowlists, and member operations require the target user's exact dedicated allowlist entry. Reaction-user audit and moderation require the target channel or thread's own exact ID in the shared reaction allowlist. Metadata changes require the target direct channel's own exact ID in the metadata allowlist, forum-tag audit and changes require the stable forum's own exact ID in their dedicated allowlist, Stage audit and changes require each exact Stage channel in their dedicated allowlist, pin changes require the target thread's own exact ID in the pin allowlist, crossposts require the direct announcement channel's own exact ID in the announcement-crosspost allowlist, forwarding requires independent exact direct source and target entries in its dedicated allowlists, announcement-subscription audit and unsubscription require the direct text target's own exact ID while creation also requires the direct announcement source's own exact ID, generic webhook audit accepts only separately allowlisted direct channels, integration, invite, Guild Template, onboarding, Welcome Screen, and widget-settings audit each accept only separately allowlisted exact guilds, forum-post creation requires the parent forum's own exact ID in its separate allowlist, and general thread creation requires the text or announcement parent's own exact ID in its separate allowlist. When a channel allowlist is configured, guild search is constrained to exact allowed channel IDs before contacting Discord.

Guild-settings audit and changes require their own exact guild allowlist. Guild incident-action audit and changes require a different exact guild allowlist. A general guild, channel, category, onboarding, Welcome Screen, widget-settings, template, integration, administration, guild-settings, or guild-incident scope grants no authority to the other independently gated surface.

Member voice audit and changes require both an exact dedicated guild allowlist and the current exact voice channel's dedicated allowlist entry; a guild, category, thread parent, Stage lifecycle scope, member-directory scope, or general moderation scope grants neither. A move destination needs its own dedicated channel entry. Both dedicated allowlists must remain inside configured read scope, and the independent change toggle cannot operate unless audit is also enabled.

Search results are bounded and omit attachment URLs, raw embeds, raw components, reactions, and Discord member payloads. They are returned to the MCP caller but are not persisted by the connector.

Keep conversation recall inside native read scope and the existing Message Content intent boundary. Accept only one exact guild, bounded unique literal phrase variants, optional exact channel and author subsets, canonical explicit-offset timestamp bounds, and bounded result and context sizes. Apply local scope before each search, exclude age-restricted results, and return no match until every phrase completes. If any phrase reports indexing, discard earlier candidates and return only content-free progress. Rank deduplicated candidates deterministically by phrase coverage, reciprocal rank, recency, and exact ID without returning phrase text.

Before returning each context, freshly verify the exact channel, guild, local read scope, age restriction, unique message evidence, and indexed target snapshot through an exact bounded `around` read. Any missing, duplicate, malformed, moved, or changed target rejects the complete result. Return only minimized current context and one-based phrase indexes. Never persist search phrases, memory text, message content, context, names, profiles, links other than canonical message jumps, raw payloads, candidates, scores, or errors, and never add an archive, embedding index, background sync, automatic retry, or semantic-search claim to this path.

## Directed coordination routing

Keep directed coordination in its independent toolset. Address creation must remain a local credential-free randomness operation with no policy read, Discord access, registration, persistence, activity record, or authority. Accept later addresses only by one strict canonical syntax. Never claim that syntax, random issuance, Discord authorship, page observation, a sender field, a tag, a body, a notification mention, or a reaction authenticates a participant, binds a model or session, reserves a name, proves ownership or liveness, conveys approval, or authorizes another tool.

Read one exact policy-permitted channel or inherited thread page per call. Require pinned application and bot identity, exact route and successful channel-history evidence, bounded unique messages with deterministic ordering, and strict connector-bot authorship before parsing. Discord exempts content in messages an app sends from the Message Content privileged intent, so this bot-authored protocol must not require that intent. Never broaden the reader to foreign-authored content without introducing the appropriate privileged-intent gate. Admit only canonical plain ordinary notes or strict same-channel replies. Reject or count every unsupported webhook, foreign author, rich payload, attachment, component, embed, sticker, snapshot, poll, TTS, everyone or role mention, malformed notification, reference, or envelope without returning raw evidence. A malformed page-level identity, route, duplication, timestamp, or shape claim must fail the whole read closed. See Discord's [Message Content intent contract](https://docs.discord.com/developers/events/gateway#message-content-intent).

Address observation may return only page-local sender labels, exact last-message IDs, counts, and timestamps. It must omit bodies, tags, recipients, notification targets, profiles, reaction users, raw payloads, and differently addressed content and must never become a registry, directory completeness claim, listener, presence signal, or mailbox guarantee. Recipient reads may return only exact matches and selected broadcasts after strict filters. Fixed aggregate status emoji are optional untrusted conventions; user enumeration remains a separate disabled-by-default gate, and no aggregate can identify a claimant, prove work, or authorize execution.

Route every note write through the existing guarded message interaction with one stable idempotency key, exact interaction-channel scope, complete direct or thread send evidence, host write approval, shared anti-spam controls, pending content-free activity, strict response validation, and exact readback. Keep the optional exact notification user separate from the routing label and require both visible mention alignment and the existing mention allowlist. Return no body, address, tag, notification ID, idempotency key, or compiled envelope from a successful send.

Never add a connector-owned address registry, note database, retained listener, timer, polling loop, automatic second page, background worker, persona authority, name-based protected target, or autonomous executor. Never persist an address, note body, tag, recipient, notification target, cursor, observation, status signal, profile, or raw Discord response in activity, operation, durable coordination, diagnostics, errors, logs, metrics, traces, or caches. The MCP host and model provider remain external custodians of invoked inputs and matching transient results.

Keep principal permission diagnostics read-only and inside the same exact guild and derived channel scope as other reads. Fetch a requested member only through the exact guild-member endpoint and private-thread membership only through the exact thread-member endpoint; never replace either with member enumeration or a privileged Gateway member cache. Validate the complete bounded role inventory, exact response identities, overwrite uniqueness, arbitrary-width bitfields, timeout timestamps, thread parent, and hierarchy target before claiming a complete decision. Missing or contradictory evidence must produce an unknown decision or fail closed, never an optimistic allowance.

Treat channel-role audits as standalone role baselines. Member-specific overwrites, member timeouts, and private-thread membership cannot be attributed to a role; report their limitations explicitly and do not inspect or return member profiles to fill the gap. Permission diagnostics may return live role names and decision evidence to the MCP caller, but must not persist names, member data, permission results, or raw Discord responses.

## Command-processing signals

Keep transient processing feedback inside the existing interaction capability and exact channel or thread allowlist. Require the verified connector bot as the only target and one caller-known exact source message. Never expose a generic typing dispatcher, arbitrary presence control, repeating loop, duration control, model-selected target, name lookup, or authority inherited from a parent, guild, read scope, native Interaction, or Gateway event.

Before contact, freshly prove a supported active channel, an ordinary user-authored regular or reply source, both parsed and literal direct mention of the verified bot, consistent timestamp and snowflake creation evidence inside the fixed freshness window, exact thread parent, exact private-thread membership where applicable, complete role and overwrite evidence, and effective read plus send permission. Fail closed on a webhook, bot, system source, indirect mention, stale or future source, malformed evidence, unsupported or inactive target, incomplete permission inventory, missing scope, or identity drift.

Use one bounded process-local ledger to coalesce the exact channel-and-source pair while fresh. Keep transient and durable per-channel cooldowns separate so the hint does not postpone the response, but charge both against the shared rolling interaction budget. Append pending content-free activity before exactly one non-retried bodyless request, accept only the documented 204, and return only exact identifiers, fixed status, replay state, and expiry. Never return or persist source content, mention data, profile fields, permission evidence, response data, or transport cause. Since Discord exposes no typing-state readback and local coalescing ends on restart, advertise the tool as non-idempotent and never treat it as work, completion, liveness, or delivery evidence.

## Guild audit logs

Keep Discord guild audit history in the separate read-only `audit-logs` toolset and inside the existing exact guild allowlist. Do not add a broader guild scan, member enumeration, or Gateway cache. Every page must remain bounded, use an exact before-entry cursor, request only one lookahead entry, and validate unique IDs, descending order, cursor direction, and exact actor and action filters. Exact lookup must use the predecessor cursor and validate the returned entry ID so a neighboring audit entry can never stand in for a missing one.

Treat the entire Discord response as untrusted evidence. Validate its shape and bounds before returning any projection. Preserve unknown future numeric action types without guessing a name. Derive timestamps locally from audit-entry snowflakes rather than trusting content fields. Reject malformed reason Unicode and contradictory remote filter or ordering evidence.

Return structural summaries only. Never return change values, option values, embedded users, webhooks, integrations, threads, application commands, scheduled events, AutoMod rules, or other embedded objects. Audit target identifiers are polymorphic and can contain invite codes; return a target only when it is a valid snowflake and explicitly mark every other non-null target as redacted. Reflect only bounded conservative change and option keys, and disclose how many keys were omitted.

Reasons remain opt-in Discord content. Omit them by default and make the selected tier explicit in every result. Never persist, cache, journal, log, or export an audit response, reason, structural key, target, actor, filter, or result. Observability may record only the fixed MCP and REST operation names with aggregate outcomes and durations. Keep Discord's retained server history distinct from the connector's local content-free write activity.

## MCP tool surface

The `catalog` command is a separate credential-free trust boundary. It must build the full production registration surface from fixed internal configuration without consulting ambient credentials, policy, activity paths, attachment roots, Gateway settings, or telemetry settings. It must not construct a Discord client or operational service. Replace low-level tool dispatch before the transport connects so listed tools, invalid arguments, discovery, disabled capabilities, and unknown names all return the same fixed `CATALOG_ONLY` result without reaching a registered handler.

Keep catalog checks self-contained and content-free. They may negotiate the four MCP catalogs, inspect schemas and annotations, render validated prompts, and read static safety or fixed policy guidance. Live Discord, activity, Gateway-event, and operational observability reads must remain unavailable. The check report may contain only fixed safety claims, package identity, schema version, and catalog counts. Pack verification must exercise the installed check without providing a bot token.

Publish one deterministic machine-readable access contract for every canonical tool and the local discovery tool. Classify each as local, live read, reviewed plan, reviewed execution, receipt verification, or guarded write; identify every exact reviewed workflow companion; and bind the manifest into credential-free catalog evidence. Treat this metadata only as an explanation of the authorization lifecycle. It must never grant authority, claim target readiness, replace tool annotations, expose an excluded tool through progressive discovery, or bypass the operation's exact identity, policy, scope, permission, hierarchy, intent, approval, freshness, coordination, recovery, and verification checks.

Keep `tools.surface` set to `full` for clients that already defer tools natively. This retains each canonical tool's exact name, schema, annotations, and approval identity while the client controls context loading. The portable `progressive` mode may hide a canonical tool only by disabling its registration through the MCP SDK. `discover_discord_tools` must reveal and enable those same registrations through standard tool-list change notifications; do not replace exact tools with a generic read, write, or destructive dispatcher.

Tool discovery is local and bounded. It must never contact Discord, return its query, log tool arguments or results, or reveal a tool excluded by `tools.toolsets`. Exact-name results may return the canonical input contract. Broader results must remain bounded, and an already enabled result must not create another list-change notification.

Treat toolsets as a reduction in callable surface, never as authorization. Discord permissions, capability gates, exact allowlists, protected targets, reviewed plans, approvals, signed confirmation, freshness checks, operation-key reservation, and pending activity records remain authoritative even when a tool is selected. Keep guild audit logs, permission diagnostics, channel metadata changes, channel-order audit and changes, forum-tag audit and changes, message pins, reaction lifecycle, component messages, exact-recipient direct messages, announcement crossposts, message forwarding, announcement subscriptions, native polls, credential-safe webhook administration and its private message lifecycle, guild integration audit and deletion, invite and vanity URL audit and invite revocation, native Guild Templates, guild onboarding, Welcome Screens, authenticated widget settings, application-owned emojis, guild expressions, scheduled events, Stage instances, member voice moderation, thread governance, attachments, forum posts, guild scaffolds, channel creation, role creation, role configuration, role deletion, role ordering, message deletion, and moderation in their deliberately selected toolsets. Reveal every private-message read, plan, verification, and execution tool together, reveal the component preview, plan, and execution tools together, and reveal every other reviewed plan-plus-execute pair together, so clients cannot discover an incomplete reviewed workflow. Keep `audit_channel_order`, channel-deletion readiness, and `audit_role_deletion` independently discoverable because audit and mutation have separate policy gates.

Keep both single-member and bulk member-role planners and executors in `member-roles`, while preserving independent capability and scope checks inside each service.

Keep named guild-settings audit and changes in the dedicated `guild-settings` toolset, keep guild incident-action audit and changes in the dedicated `guild-incidents` toolset, and reveal each planning and execution pair together.

## Gateway events

Keep the Gateway disabled unless real-time invalidation, channel-order layout evidence, exact-scope soundboard playback corroboration, or exact-scope native Interaction ingress is required. Enabling it requires expected application and bot IDs plus the exact scope required by the selected mode. READY must match both identities and identify a bot user before the feed accepts dispatches. The event feed may request only `GUILDS`, `GUILD_MESSAGES`, `GUILD_MESSAGE_REACTIONS`, and `GUILD_MESSAGE_POLLS`; a layout-only channel-order connection requests only `GUILDS`; soundboard playback adds the standard `GUILD_VOICE_STATES` intent; and an Interaction-only connection requests zero intents. Do not add Message Content, presence, member, or other privileged intents.

Count every successful outbound Gateway event in one rolling budget private to its shard connection. Admit caller-triggered commands only below a conservative half-budget boundary so Heartbeat, Identify, and Resume retain priority capacity, but never let priority bypass the absolute Discord limit. Keep the command FIFO bounded by count and wait time, remove an aborted entry exactly, and cancel all retained commands on every connection boundary. Begin remote evidence freshness and response timing only after the command is written. A locally exhausted control budget must reconnect before another write and expose only a fixed error category. Never persist, log, export, or return a queued payload, its exact IDs, queue contents, or transport cause, and never add a configuration knob that can weaken the boundary.

Gateway dispatches must be reduced immediately to fixed event kinds, Discord identifiers, and receive times. Stage create, update, and delete dispatches may retain only exact guild, channel, and Stage-instance IDs; never retain their topics, speaker or audience state, scheduled-event objects, or unknown payload fields. A `guild-updated` event may hint that widget settings changed, but it must never carry settings fields, populate a widget cache, or replace a fresh authenticated REST read. Never retain raw payloads, message content, profile data, emoji, or URLs. Session IDs, Discord sequence numbers, and resume URLs may exist only as transient connection state needed for Resume; they must be cleared on stop or terminal failure and must never enter the event buffer, status, resources, logs, or persistent state. The bounded event buffer remains process-local and content-free, and resource notifications contain only an exact local resource URI.

A `guild-updated` event may also hint that named guild settings changed, but it must never populate a settings cache or substitute for the continuity-bracketed HTTP evidence used by audit and planning.

Complete direct-channel layout evidence may be retained only for the union of exact event-feed, channel-ordering, channel-cloning, Guild Template, guild-settings, onboarding, and member-role guild scopes. Any one of those evidence consumers may activate this projection without activating the public event feed. Never infer complete guild layout authority from channel-only read scope or from the visibility-bounded HTTP guild-channel endpoint. Retain only channel ID, documented direct-channel type, nonnegative raw position, nullable parent ID, and the explicit `CHANNEL_OBFUSCATED` flag. Never retain or trust an obfuscated channel's synthetic permission overwrite, name, topic, or any other metadata. Public status may expose aggregate layout counts and states, but not the retained guild or channel IDs.

Treat the independently enabled bulk member-role guild scope as another member-role layout-evidence consumer, without letting it widen the single-member scope or activate the public event feed.

Require one valid complete Guild Create channel array before marking a guild layout ready. Reject a partial array, duplicate or malformed ID, unknown or thread channel type, invalid position or flags value, category with a parent, missing category parent, or cross-guild channel. Apply direct Channel Create, Update, and Delete dispatches only to a ready or privately retained resuming snapshot and validate the complete topology after each change. A socket interruption must make the projection unreadable while replay proceeds; only successful Resume continuity may restore readiness. Clear affected evidence on guild unavailability or deletion, malformed relevant dispatches, and every connection gap or new Identify; never let transport READY alone imply layout readiness. Do not send Discord's temporary channel-obfuscation preview capability by default.

Gateway cursors are opaque and process-bound. Report malformed, foreign, expired, ahead-of-buffer, and connection-gap cursors as explicit continuity resets. Never expose a Discord sequence number as a cursor or imply uninterrupted delivery after overflow or a reconnect that cannot preserve Resume continuity.

## Native Discord Interactions

Keep native Interaction command management and ingress behind separate exact gates. Both require pinned application and bot identities. Command management requires an exact guild allowlist; ingress additionally requires exact direct text or announcement channel and exact user allowlists. Do not derive authority from ordinary read scope, a guild role, a channel category, thread inheritance, message-interaction scope, Gateway-event scope, or another administrative feature.

Keep the managed guild command contract fixed except for its validated name: guild-only chat input, administrator-only by default, no NSFW use, one required bounded string option, and no localization, autocomplete, subcommand, attachment, mention, component, modal, or arbitrary option surface. Do not use bulk replacement or name-only routing. Planning must bind the complete bounded command inventory, exact contract, application, bot, guild, current exact command ID and version, action, one-shot key hash, and full inventory digest. Same-name duplicates or drift are blockers. Installation and removal require signed interactive confirmation, final fresh planning, one-shot reservation, pending content-free activity, one non-retried POST or DELETE, exact response validation where applicable, and a complete readback proving the inventory changed by exactly the reviewed command.

Treat any command mutation after reservation as externally consequential. Only a known Discord client-error refusal other than a request timeout or rate limit may settle as failed. A transport error, request timeout, rate limit, server error, malformed success, unexpected full-inventory transition, or readback failure is uncertain and must quarantine the exact guild command target. Never automatically retry, bulk reconcile, compensate, reinstall, or remove a command after ambiguity. Never persist the guild name, command description, option text, full inventory, raw operation key, permission evidence, raw response, or transport cause.

Use Gateway delivery only when the Discord application has no outgoing Interaction endpoint. An Interaction-only connection must request intents `0`; enabling the separate content-free event feed may add only its existing nonprivileged intents. Startup must verify the pinned identities, absent outgoing endpoint, and exactly one contract-matching managed command in every selected guild before the broker becomes ready. Shutdown during preflight must never revive or restart a stopped broker.

Accept only two closed guild Interaction event shapes. A chat-input event must bind the exact application, authorizing guild installation, command ID, command name and type, guild, direct supported channel, exact member and user, Administrator permission, and one required bounded request option. A request-button event must bind the exact application, authorizing guild installation, guild, direct supported channel, exact allowlisted member and user, Button component type, connector-authored Components V2 source message, and one authenticated managed custom ID. A request-button click creates no Discord mutation and must not require or imply Administrator. Ignore unrelated commands and custom IDs without retaining their payloads. Reject owned scope failures, malformed managed IDs, invalid references, and capacity failures with fixed ephemeral text when possible. Deduplicate exact Interaction IDs process-locally and never admit one event twice.

Authenticate the request-button ID and attached source before sending an ephemeral deferred acknowledgement. After deferral, require slower exact channel and fresh complete command-inventory verification for every owned request. For a request Button, additionally fetch the exact source message and require its application, bot, guild, channel, message, authenticated layout route, button index, label, and style to reproduce the attached event. Do not expose a request until every applicable check succeeds and a pending content-free accepted record is durable. Keep accepted slash text or request-button label and raw Interaction tokens only in the bounded process-local broker. Enforce the global queue ceiling, per-user ceiling, strict lifetime, and one-shot opaque references. Request text is untrusted data, not instructions. Expose request text or a button label only in the bounded pending-request MCP result; never persist, cache, log, trace, or export it. Never place a custom ID, authenticated route, or token in an MCP input, result, resource notification, error, activity record, operation receipt, diagnostic, or status value. A click record may retain only the source kind, exact source message ID, button index, and fixed style in addition to the existing content-free identifiers and outcome.

Require a durable pending response activity record before consuming a reference. Send only bounded plain text through one non-retried edit of the original deferred response. Require exact application, bot, guild, channel, user, Interaction, webhook, ephemeral flag, content, and empty rich-field evidence. A slash response must prove exact application-command metadata and its response message type. A request-button response must prove exact message-component metadata, interacted source message ID, source-message reference, and its response message type. Discard the token by default. Retain it only after an explicit `keepOpen` choice, durable original-response completion, remaining broker lifetime, and the fixed follow-up allowance, and expose only a rotating process-local opaque continuation reference.

Share global and per-user capacity across pending requests, continuations, and in-flight responses. For each follow-up, require a durable content-free pending record before consuming the old reference, send one non-retried ephemeral plain-text message with mentions and rich fields disabled, require exact direct response plus independent exact readback, and durably record completion before any optional rotation. Never return the same consumed reference, retain a token after broker shutdown, or return a new continuation after refusal, ambiguity, evidence drift, failed completion recording, expiry, or exhausted allowance. Never enable TTS, embeds, components, attachments, polls, public responses, follow-up editing or deletion, token passthrough, arbitrary webhook calls, or automatic response generation inside the broker. Expiry and shutdown must consume pending references and attempt only the fixed ephemeral expiry response, while dropping continuations without editing completed messages. A known refusal is failed; transport ambiguity, rate limiting, server errors, malformed response evidence, unavailable or drifting readback, or completion-record failure must not make the old reference reusable.

## Guild application commands

Keep guild application-command mutation behind `capabilities.applicationCommandChanges`, a nonempty exact `scopes.applicationCommandGuildIds` allowlist contained by ordinary guild read scope, pinned application and bot identities, and the independent `application-commands` toolset. Never infer write authority from command exposure audit, native Interaction management, global command authority, guild membership, another administrative feature, a command name, or another application's command object. Do not add bulk-overwrite, raw REST, name-targeted, partial-update, type-change, or immediate-call paths.

Accept only strict complete canonical chat-input, user, or message definitions. Require explicit default member permissions or `null`, explicit NSFW state, complete localization arrays, and the exact type-specific option tree. Enforce every known Discord name, description, localization, aggregate text, choice, autocomplete, required-order, depth, numeric, string, channel-type, and attachment-file-type constraint before contact. Reject unknown fields, raw numeric type codes or permission bitfields, omitted complete-state fields, future evidence that cannot be understood, and any incompatible option combination.

Planning must re-verify the pinned identities and exact non-pending connector membership, fetch the complete full-localization guild command inventory and every guild command-permission entry, and bind their canonical digests plus every command ID, version, type, transient name and definition digest, separate type capacities, total capacity, exact target permission overwrites, collision and no-op decisions, privacy claims, risks, warnings, operation-key hash, and verification contract into the process-keyed plan. A same-name and same-type collision must block creation because Discord POST otherwise upserts. Require exact-ID targeting for update and deletion, immutable type for update, and explicit deletion acknowledgement. Surface Discord's permanent target permission reset before every rename or deletion. Do not add command-permission writes because that route requires a user-authorized Bearer credential outside the bot-token boundary.

Preserve every reviewed-write gate: fresh complete evidence, process-keyed plan binding, destructive MCP annotation, write-aware host approval, signed request state, interactive confirmation, a final fresh matching plan, durable guild application-command collection coordination, atomic one-shot key reservation, pending content-free activity, one non-retried mutation, strict route-specific response validation, and exact complete command and permission survivor readback. Creation must accept only `201` and one exact new command, never Discord's `200` upsert response. Update must send one exact-ID complete replacement. Delete must send one exact-ID request. A no-op must bypass confirmation, coordination, reservation, activity, and mutation.

Permit a deterministic Discord client refusal other than timeout or rate limiting to settle as failed. Treat rate limiting, transport ambiguity, server failure, malformed success, response mismatch, complete-readback failure, survivor drift, or completion-record failure as uncertain and potentially completed. Spend every reserved key, quarantine the affected guild command collection, and never retry, reconcile, compensate, restore permissions, or roll back automatically. Persist only exact application, bot, guild, and command IDs; command type; definition, inventory, permission, plan, and operation-key digests; timestamps; fixed status and verification values; activity ID; and sanitized error category. Never persist command, option, choice, or localization text, permission target IDs, Discord names, raw requests or responses, raw keys, transport causes, or audit reasons.

## Global application commands

Keep global application-command mutation behind `capabilities.globalApplicationCommandChanges`, pinned application and bot identities, and the independent `application-commands` toolset. Never infer this application-wide authority from guild command changes, command exposure audit, native Interaction management, guild scope, another administrative capability, a command name, or another application's command object. Do not accept a caller-selected application ID, application-default inheritance, bulk overwrite, raw REST, name-targeted mutation, partial definitions, type changes, command-permission writes, propagation polling, or immediate-call paths.

Accept only strict complete canonical chat-input, user, message, or Primary Entry Point definitions with explicit nonempty canonical contexts and installation types. Require explicit global-exposure acknowledgement, named default member permissions or `null`, explicit NSFW state, complete localization arrays, and the exact type-specific option or handler fields. Require User Install for private-channel context, fresh application support for every requested installation type, and fresh EMBEDDED evidence for every Primary Entry Point. Reject unknown fields, raw numeric codes or permission bitfields, omitted complete-state fields, unsupported application contexts, future evidence that cannot be understood, and incompatible option combinations.

Planning must re-verify the pinned identities and complete application installation configuration, fetch the complete full-localization global command inventory, and bind application support, EMBEDDED evidence, the canonical inventory digest, every command ID, version, type, transient name and definition digest, separate type capacities, total capacity, exact target, complete current and desired definitions, collision and no-op decisions, global exposure, cross-guild permission-reset effects, privacy claims, risks, warnings, operation-key hash, and verification contract into the process-keyed plan. A same-name and same-type collision must block creation because Discord POST otherwise upserts. Require exact-ID targeting and immutable type for update and deletion. Require explicit global deletion and cross-guild permission-reset acknowledgements where applicable. Never claim to enumerate affected guilds or permission targets because the bot-token trust boundary cannot do so.

Preserve every reviewed-write gate: fresh complete evidence, process-keyed plan binding, destructive MCP annotation, write-aware host approval, signed request state, interactive confirmation, a final fresh matching plan, durable application-wide global-command collection coordination, atomic one-shot key reservation, pending content-free activity, one non-retried mutation, strict route-specific response validation, and exact complete inventory and survivor readback. Creation must accept only one exact new command and reject Discord's same-name upsert response. Update must send one exact-ID complete replacement. Delete must send one exact-ID request. A no-op must bypass confirmation, coordination, reservation, activity, and mutation.

Permit a deterministic Discord client refusal other than timeout or rate limiting to settle as failed. Treat rate limiting, transport ambiguity, server failure, malformed success, response mismatch, complete-readback failure, survivor drift, or completion-record failure as uncertain and potentially completed. Spend every reserved key, quarantine the application-wide global-command collection for the process lifetime, and never retry, bulk reconcile, compensate, recreate, restore permissions, or roll back automatically. Persist only exact application, bot, and command IDs; command type; definition, inventory, plan, and operation-key digests; timestamps; fixed status and verification values; activity ID; and sanitized error category. Never persist command, option, choice, or localization text, permission target IDs, Discord names, raw requests or responses, raw keys, transport causes, or audit reasons.

## Observability

Keep OTLP export disabled unless an operator has selected a trusted collector. Enabling export must remain a separate exact feature gate. Remote collectors require HTTPS; plaintext HTTP is permitted only for loopback. Collector URLs must remain credential-free and must not contain query strings or fragments. Treat OTLP header variables as secrets and percent-encode values according to the OpenTelemetry format. Reject unsupported certificate-file variables before constructing an exporter so upstream fallback configuration cannot read ambient files.

Telemetry must use only fixed operation, risk, outcome, and error categories plus numeric status, retry, duration, aggregate, trace, and span data. Continue an upstream MCP trace only from a strict W3C version `00` `_meta.traceparent`; retain `_meta.tracestate` only when its complete bounded normalized form validates without rewriting or loss. Ignore malformed carriers and all `_meta.baggage` without rejection, logging, persistence, metrics, or export. The REST boundary may reduce Discord's rate-limit scope header to a fixed shared-or-not boolean before observability, but no raw header value may cross that boundary. Never add tool arguments or results, Discord identifiers, raw routes or URLs, bodies, headers, bot tokens, error messages or stacks, plan digests, Gateway records, activity data, Discord content, or raw trace carriers to spans, metrics, stderr records, or local aggregates. Do not add automatic HTTP, logging, or exception instrumentation. Keep trace and metric providers private so process-global OpenTelemetry state cannot redirect connector telemetry or add unrelated data. Unknown operation names must collapse to a fixed value.

Track connector-observed 401, 403, and non-shared 429 responses in bounded monotonic rolling buckets, including intermediate responses that are retried. Exclude a 429 only when the transport proves `X-RateLimit-Scope: shared`. Treat the result as a lower bound on Discord's IP-wide invalid-request pressure because other processes and applications can share the egress IP. Report the documented reference limit and window but never infer remaining capacity, persist events, block a request, or change retry and uncertainty behavior from telemetry.

Exporter failure must never alter a Discord request or MCP tool result. Keep final flush bounded and keep exporter startup and shutdown under the stdio runner so construction, `doctor`, and `setup` cannot open collector connections. `smoke` launches the normal stdio runner, so configured exporters may start and must receive the same bounded shutdown. Status surfaces may report only aggregate operation health, bounded invalid-request pressure and its fixed coverage semantics, fixed privacy claims, exporter state and counters, and booleans indicating whether endpoint or header configuration exists.

Treat spawned smoke verification as a secret boundary. Give the child only the MCP SDK's safe process baseline, the exact non-secret policy selector, and environment values referenced by the selected policy. Never forward unrelated ambient variables. Retain only a bounded stderr tail, remove controls, and redact the bot token plus every referenced secret value before returning diagnostics. Smoke must use the current CLI entrypoint, normal `serve` startup, stable protocol negotiation, and read-only discovery and status calls so it proves the same startup path an MCP host uses without adding Discord write authority.

## Durable reviewed-write coordination

The production connector facade must acquire a durable exact-target claim before invoking any reviewed workflow backed by `OperationStore`. Resource target namespaces are shared across operation kinds so channel, message, member, role, webhook, and integration mutations cannot bypass one another. Guild-level create and complete-state workflows must claim the applicable bounded collection namespace. Application-emoji changes must claim the verified application's complete emoji collection. A resumable guild scaffold must claim both the guild role and channel collections using its persistent request digest. Channel placement must claim the whole guild channel collection plus the exact target, anchor, and any source or destination parent categories. Integration deletion must additionally claim the guild integration and webhook collections plus the associated bot member when present. Multi-target claims must publish in deterministic order, release every partial acquisition before waiting, let a known same-process predecessor finish and replan, and fail fast against a different live process.

Never expire or steal a claim because time elapsed. A later process may reclaim a dead owner's claim automatically only when the matching operation receipt is absent, belongs to a different reviewed plan, or is terminal with `completed` or `failed` status. Read receipt evidence through a stable private-file handle with no symlink traversal and reject identity or metadata changes across the read. A matching pending or uncertain receipt, unreadable receipt, malformed state, indeterminate owner, or inconsistent multi-target record is quarantined. PID liveness may prove only that an owner still exists; it cannot prove whether Discord applied a request.

Keep coordination state beside the activity and operation state in owner-private directories. Publish only complete records atomically, sync files and directory entries before advancing, reject symlinks, extra hard links, public modes, foreign ownership where inspectable, unknown fields, invalid target bindings, and oversized or malformed records, and remove only a freshly reread exact claim identity. Coordination records may contain only exact Discord target identifiers, bounded target and operation kinds, operation-key hashes, plan digests, PIDs, timestamps, schema versions, and random claim IDs. Never store names, content, reasons, payloads, URLs, local paths, raw operation keys, credentials, permission evidence, or transport details.

Operator resolution must remain a credential-free local CLI action, never an MCP tool. Require the claim ID as exact confirmation, refuse a live or indeterminate owner, and instruct the operator to stop the owner and inspect Discord before proceeding. Publish an immutable content-free acknowledgement before releasing target claims. A partial resolution may finish only from the exact acknowledgement and claim identity. Never delete or reopen the immutable operation receipt or make the old operation key reusable.

Advertise coordination only when connector processes share one canonical local activity-state root on a local filesystem. Local file-creation and rename atomics are not a network-filesystem coordination guarantee. Direct construction of an individual workflow service retains only its documented process-local defense. A scaffold callback that returns normally with its exact matching top receipt still pending may release its collection claims so an intentional pause can resume elsewhere. An exception, process loss, mismatched receipt, uncertain state, or unreadable evidence must retain quarantine. Message deletion claims each exact message target through its durable one-shot identity. Member moderation remains excluded until it gains the same model, and ordinary interactions retain Discord-nonce and throughput semantics.

## Exact-recipient direct messages

Keep one-to-one private messaging behind the dedicated `direct-messages` toolset, independent audit, delivery, owned-file attachment, editing, and deletion gates, and a bounded exact ordinary-user allowlist. The exact allowlist expresses only local operator authority; it is not evidence of recipient consent, prior contact, or Discord-side eligibility. Private-file delivery must additionally require ordinary delivery authority and at least one configured canonical attachment root; guild attachment authority and private attachment authority never imply each other. Never add recipient discovery, username lookup, private-channel enumeration, group DMs, bulk recipients, shared-bot relay, ambient scope inheritance, or DM Gateway ingestion. The operator must supply and pin their own Discord application, bot identity, and secret token.

Reads must require a caller-known exact recipient and exact one-to-one channel, plus an exact message ID for lookup. Re-verify the pinned application and bot, channel type, sole recipient, participant boundary, exact response identity, supported message type, timestamps, content, reply identity, message flags, pinned state, and aggregate rich-state and mention counts before returning a strict transient projection. Return supported text directly, normalize supported static Components V2 into the bounded Text Display, Separator, callback-free Link Row, and one-level Container DSL, and project a supported single attachment only as exact ID, safe filename, nullable bounded description, and numeric size. Return a static link-button destination only inside the transient normalized layout and treat it as untrusted. Omit Discord-generated component IDs plus custom-ID actions, attachment URLs, proxy URLs, content types, dimensions, placeholders, CDN signatures, and raw attachment objects. Classify every other rich presentation as unsupported while returning only its ordinary content and bounded aggregate counts, never rich bodies. Reject system and bot recipients, group channels, malformed evidence, profile expansion, and messages authored outside the two verified participants. Never cache, search, index, journal, trace, export, download, or persist private content, component layouts, link destinations, profiles, avatars, attachment URLs, raw payloads, or unknown values.

Keep text, static Components V2, or single owned-file send and reply, same-format text or Components V2 connector-message edit, and irreversible supported-message deletion behind one plan-verify-execute workflow with strict action-specific inputs. Send and reply require an explicit expected-contact acknowledgement; deletion requires an explicit irreversible-deletion acknowledgement. Planning a send may fetch only the exact user and read the explicitly requested local file when present; it must not create or discover a channel. Accept bounded plain text, only the static Text Display, Separator, callback-free Link Row, and one-level Container DSL, or one exact absolute local file path with optional plain text, safe filename, and bounded description. Require every normalized link-button origin to match `scopes.componentLinkOrigins` before recipient, channel, or Discord access. Never accept raw Discord component JSON, caller-selected component IDs, interactive controls, callbacks, embeds, remote media or attachment URLs, data URLs, base64, MCP byte fields, caller-selected MIME type, multiple files, streams, polls, stickers, or reusable content-bearing templates. Apply the owned-file symlink, hard-link, ownership, canonical-root, size, stable-path, stable-metadata, and keyed-byte checks under a direct-message-specific digest domain. Treat creation with `IS_COMPONENTS_V2` as irreversible for that message and never convert an existing message between formats. Editing must reject attachment bodies and require an unpinned same-format supported text or Components V2 message. Deletion may accept a URL-free single-attachment projection but must reject any target not authored by the pinned bot or any target with parsed mentions, unsupported rich state, pinning, or reactions. Bind the complete transient body, normalized layout and preview, exact link URLs and origins or file identity and keyed bytes when applicable, local review reason, exact identities, acknowledgements, forced empty mentions, fixed anti-spam limits, exact presentation and current state, privacy omissions, operation-key hash, and warnings into the process-keyed plan. Never send the local review reason as a Discord audit-log header.

Require signed interactive confirmation, write-aware host approval, a final fresh matching plan, durable exact-target coordination, a request-bound schema-v2 one-shot receipt, and pending content-free activity before Discord contact. Keep the global ceiling at five changes per rolling minute and the per-recipient interval at five seconds without a configuration override. Force the exact minimal empty `allowed_mentions` shape, disable reply-author notification, derive a deterministic enforced nonce for sends and replies, and never automatically retry a Create DM, create-message, multipart upload, edit, or delete request. Upload one reviewed in-memory snapshot through one `payload_json` and one `files[0]` field, with no guild ID or remote source. A send may need both Create DM and message creation, so checkpoint its exact channel before dispatch and checkpoint the exact message identity before readback. Require a matching exact presentation and complete body or receipt-bound filename, description, and byte size in the response and fresh message readback, or exact 404 absence after deletion. Never fetch an attachment URL to claim remote byte equality; Discord exposes no attachment content digest.

Receipt transitions must be immutable and monotonic from reserved through optional channel-ready and message-dispatched checkpoints to terminal. Derive the request binding from the active bot secret independently of the process-bound plan key, so restart preserves exact caller-retained request verification while credential rotation deliberately invalidates it. Verification must compare that binding and all receipt targets before Discord or local-file access, read only the receipt-bound exact message or absence when safe, and never reopen the requested file, follow an attachment URL, scan history, reserve a key, append activity, consume a rate budget, or trust caller-selected recovery targets. Pending, malformed, mismatched, rate-limited, transport-failed, server-failed, or readback-indeterminate work must fail closed or remain quarantined; every reserved key stays spent.

Persist only the exact recipient, channel, reply-target, and message IDs needed for recovery, action, fixed message-format class, nullable attachment byte size in the operation receipt, request and plan digests, operation-key hash, immutable stage, timestamps, fixed status and verification values, activity ID, and a sanitized error category. Never persist private content, local paths, file bytes, filenames, descriptions, file metadata, byte digests, component layouts or previews, link destinations or origins, attachment URLs, embeds, components, usernames, profile names, avatars, review reasons, raw operation keys, nonces, response bodies, routes, transport causes, or raw Discord objects.

## Native attachment reads

Keep inbound native attachment consumption inside the existing `messages` toolset and exact guild-channel read policy. It must add no capability toggle, write permission, attachment root, output path, activity record, operation receipt, Gateway mode, alternate origin, environment-policy field, or direct-message scope. Require exact positive channel, message, and attachment IDs, freshly verify the pinned application and bot, resolve the exact channel through local policy, refetch the exact message, and bind one unique attachment object to all three identities before delivery. Never accept a caller-supplied URL, filename, MIME type, path, base64 value, byte field, proxy selection, or raw Discord object.

Accept only a Discord-supplied signed attachment URL on the fixed CDN origin whose path kind, channel ID, attachment ID, decoded filename, exact signature query keys, timestamp ordering, and signature shape match the freshly read attachment. The delivery request must contain no bot token, Authorization header, cookies, caller credentials, referrer, or cache reuse. Refuse redirects, alternate hosts, content encoding, status drift, media-type drift, declared-length drift, and any streamed byte count that differs from the current attachment's declared size. Bound streaming by both that exact size and the conservative MCP raw-byte ceiling, cancel on expansion, and never retry automatically.

Return native MCP image or audio content only for an explicitly supported media type whose conservative byte signature matches. Fail closed when a declared supported type and its bytes disagree. Treat absent and unsupported types as `application/octet-stream` embedded resources instead of trusting an extension, delivery header, or active document type. Every tool result may include a private stable resource link, and the equivalent binary resource must repeat the same fresh checks rather than reuse a cache or local file.

Scan the assembled raw bytes for every active secret known to the MCP result-redaction boundary before base64 encoding and withhold a match. Overwrite streamed chunks after assembly, the assembled raw buffer after encoding or withholding, and a buffer rejected by native-signature validation. Never persist, cache, index, journal, export, log, trace, or include in an error any attachment byte, signed or proxy URL, filename, description, local path, response body, raw object, or delivery cause. Structured metadata may return only the exact verified identity, bounded display metadata, fixed privacy and trust claims, count-only unknown fields, and delivery-verification classes. Treat every returned byte and string as untrusted external data, never as instructions.

## Attachment messages

Do not add an attachment shortcut that bypasses the capability gate, exact attachment-channel allowlist, canonical directory roots, pinned bot identity, complete permission evidence, bounded stable file read, process-keyed byte planning, signed interactive confirmation, write-aware client approval, final fresh-plan match, shared interaction limiter, atomic one-shot operation-key reservation, pending activity journaling, single multipart POST, or exact message readback. If a client cannot support MCP elicitation, keep attachment execution unavailable in that client.

Keep the surface local-file-only and single-file. Never accept remote URLs, data URLs, base64 payloads, arbitrary byte fields, directories, multiple files, or a runtime-configurable Discord origin. Reject path escapes, symlinks, hardlinks, foreign-owned files, non-regular files, empty files, files above the configured byte ceiling, any file identity, metadata, or path change across a read, and runtimes that cannot prove numeric process ownership. Read the bounded bytes into memory before reservation and upload only that reviewed snapshot.

Require an exact channel or thread entry even when its parent is allowlisted. Require complete `VIEW_CHANNEL`, `READ_MESSAGE_HISTORY`, `ATTACH_FILES`, and applicable send-permission evidence. Keep all mentions suppressed unless exact visible user mentions and reply-author notification have each passed the existing notification allowlist. Never enable role, `@everyone`, or `@here` notification through this workflow.

Exclude the raw operation key from plan material, signed request state, records, results, and errors while binding its domain-separated hash into the plan. Keep the MCP execute tool non-idempotent. A reserved key remains spent after every outcome, including known failure, uncertainty, or local recording failure. Neither the REST client nor any wrapper may automatically retry the multipart POST, and the connector must not delete a sent message as compensation.

Never persist the local path, filename, description, file metadata, file size, byte digest, message content, notification user IDs, attachment URL, multipart body, or raw Discord response. Attachment activity and operation records may contain only exact guild, channel, reply, and message IDs, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category.

## Reviewed Components V2 messages

Do not add an immediate component-message call or a path around the existing interaction toggle, exact interaction-channel allowlist, pinned identities, confirmed Message Content intent, complete channel and thread evidence, process-keyed planning, signed interactive confirmation, write-aware host approval, final fresh-plan match, shared interaction limiter, durable exact-target coordination, atomic one-shot reservation, pending content-free activity, one non-retried mutation, or exact response and fresh readback. Keep execution unavailable when the client cannot support MCP elicitation.

Accept only the bounded `text`, `separator`, callback-free `link-row`, authenticated `request-row`, and one-level `container` DSL. Either row may appear at the top level or directly inside a container, must contain one to five buttons, and must count its row and every button toward the recursive component ceiling. Require one bounded single-line label per button and one normalized absolute HTTPS URL per link button. A request Button may select only `primary`, `secondary`, `success`, or `danger`; treat style as presentation without write or administration meaning. Never accept raw Discord component JSON, caller-selected component or custom IDs, disabled states, emojis, selects, modals, arbitrary callbacks, sections, thumbnails, media galleries, files, attachments, remote-media URL fields, data fields, base64 fields, or reusable content-bearing templates. Text Display content may contain ordinary Discord markdown links; show them in the exact review and never fetch them. Require at least one Text Display and enforce the complete recursive component, aggregate Unicode text, and canonical-byte limits locally before any Discord call. Reject every request row in one-to-one private-message workflows because native Interaction ingress is exact-guild scoped.

Keep link buttons disabled unless `scopes.componentLinkOrigins` contains every exact canonical HTTPS origin. Reject credentials, wildcards, paths, queries, fragments, trailing slashes, duplicates, and noncanonical spellings in the configured origins; reject surrounding whitespace, control characters, credentials, non-HTTPS schemes, malformed URLs, and oversized normalized destinations in layouts. Enforce the origin policy before any Discord request during planning and verification. Expose exact normalized destinations and unique sorted origins in transient review and bind them into the keyed request and plan digests. Never fetch a destination, resolve DNS, follow a redirect, inspect remote content, or claim that the configured first-hop origin is the final destination opened by a Discord client.

Require every target channel or thread to have its own exact interaction-scope entry. Verify the application, bot, guild, connector member, complete bounded roles, channel and parent identity, overwrites, active thread state, private-thread membership where applicable, and complete `VIEW_CHANNEL`, `READ_MESSAGE_HISTORY`, plus applicable send permission evidence. Keep all mentions suppressed unless each exact user is both locally authorized and visibly mentioned in the normalized layout. Never enable role, `@everyone`, or `@here` notification. Treat reply-author notification as a separate create-only reviewed permission.

Before planning any layout with a request row, require the target guild and exact channel in native Interaction scope, a nonempty exact user allowlist, a paired broker in ready state, freshly verified pinned application and bot identities, an unset outgoing Interaction endpoint, and exactly one contract-matching managed command from a fresh complete inventory read. Bind verified Gateway delivery, the authorized user IDs, broker phase, guild, command ID, command version, and schema into the plan digest, then repeat every fresh check and require identical readiness before execution. Generate every custom ID inside the connector from a token-derived domain-separated HMAC. Bind its route to the pinned application and bot, exact guild and channel, complete normalized layout, and operation-key hash; bind each tag to that route plus the button index, exact label, and style. Never return or persist the custom ID or route, accept caller routing input, or create a callback registry or route database. A normal restart with the same token must preserve authentication, while token rotation must invalidate every old route.

Set the irreversible Components V2 flag only during reviewed creation. Edit only an exact default already-V2 non-webhook message owned by the verified bot. Never convert a legacy message, alter its identity or reply reference, or accept a target with content, embeds, attachments, stickers, a poll, TTS state, role or mass mentions, unsupported component fields, unauthenticated request Buttons, or duplicate or invalid component IDs. Require parsed user mentions to be unique, visible in the normalized layout, and transiently reviewed. Only an exact layout and authenticated route match with empty parsed user-mention state is a notification-free no-op; it must bypass confirmation, coordination, reservation, activity, limiter, and mutation.

Bind the normalized layout and link destinations, freshly verified Gateway, identity, request-button command, and exact authorized-user evidence, live message state, intent, exact channel, link-origin, and native Interaction scope, thread evidence, complete permissions, reply, notifications, privacy projection, warnings, and operation-key hash into the process-keyed plan. Create uses a deterministic enforced nonce. Create and edit each issue one non-retried mutation, validate the strict response, then require a semantically exact GET readback after stripping only Discord-assigned numeric component IDs and authenticating every request Button. A known pre-response Discord 4xx other than timeout or rate limiting may be failed; transport ambiguity, rate limiting, server error, malformed evidence, mismatch, readback failure, or local completion-record failure is uncertain. Permanently spend the key and retain the exact-channel or exact-message claim after uncertainty. Never retry, compensate, restore, or delete automatically.

Never persist component text, normalized or raw layouts, link destinations or origins, request-button custom IDs or authenticated routes, notification or parsed-mention IDs, mention profiles, generated numeric IDs, nonce, raw payloads, raw operation key, or transport cause. Component-publication activity and operation records may contain only exact guild, channel, optional reply, and resulting message IDs, action, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category.

## Static rich-embed messages

Do not add an immediate rich-embed call or a path around the independent capability, exact embed-message channel or thread allowlist, pinned identities, confirmed Message Content intent, complete channel and thread evidence, process-keyed planning, signed interactive confirmation, write-aware host approval, final fresh-plan match, shared interaction limiter, durable exact-target coordination, atomic request-bound one-shot reservation, pending content-free activity, one non-retried mutation, or exact response and fresh readback. Keep execution unavailable when the client cannot support MCP elicitation. Interaction scope and the Components V2 workflow grant no substitute authority.

Accept only optional bounded plain content without HTTP URLs plus 1 through 10 static embeds containing title, description, integer color, explicit-offset timestamp, author label, footer text, and ordered bounded fields. Enforce every per-field limit, the per-embed field limit, the 6,000-character aggregate embed limit, and the canonical presentation byte limit before Discord access. Reject HTTP URLs in plain content so the required `EMBED_LINKS` permission cannot add an unreviewed automatic link embed. Never accept raw Discord embed JSON, an embed URL field, author or footer icon URL, image, thumbnail, video, provider, attachment, caller-selected type, unknown field, remote asset, data URL, base64 payload, or reusable content-bearing template. Embed text may contain ordinary Discord markdown links; show them in the exact review, treat them as untrusted presentation, and never fetch them through the connector.

Require every target channel or active unlocked thread to have its own exact embed-message scope entry. Verify the application, bot, guild, connector member, complete bounded roles, channel and parent identity, overwrites, private-thread membership where applicable, and complete `VIEW_CHANNEL`, `READ_MESSAGE_HISTORY`, `EMBED_LINKS`, plus applicable send permission evidence. Keep all notifications suppressed unless each exact user is locally authorized and visibly mentioned in the optional plain content. An embed-text mention may remain visible but must never authorize notification. Never enable role, `@everyone`, or `@here` notification. Treat reply-author notification as a separate create-only reviewed permission.

Create only a default message or exact reply with a deterministic enforced nonce. Edit only an exact unpinned default non-reply message owned by the verified bot with default flags and no webhook owner, attachment, component, sticker, poll, unsupported embed field, role mention, or mass mention. Treat editing as complete replacement of plain content and the ordered embed array. Never convert Components V2, forwarded, poll, webhook, reply, mixed-media, system, or unknown message state, and never alter identity, flags, pin state, creation timestamp, or reply state. Only an exact presentation match with empty live parsed user-mention state and an empty requested notification list is a notification-free no-op; it must bypass confirmation, coordination, reservation, activity, limiter, and mutation.

Bind the complete normalized presentation, live target state, identities, intent, independent scope, thread evidence, complete permissions, reply, notifications, privacy projection, warnings, and operation-key hash into the process-keyed plan. Each create or edit issues one non-retried mutation, validates strict response evidence, then requires a semantically exact GET readback. A known pre-response Discord 4xx other than timeout or rate limiting may be failed; transport ambiguity, rate limiting, server error, malformed evidence, mismatch, readback failure, or local completion-record failure is uncertain. Permanently spend the key and retain the exact-channel or exact-message claim after uncertainty. Never retry, compensate, restore, or delete automatically.

Derive restart-safe request verification from the active bot secret independently of the process-bound plan key. Compare the request binding and receipt target before Discord access, then revalidate exact scope, identity, intent, thread and reply evidence, notification policy, and read permissions before fetching only the receipt-bound message. Never scan history, trust a caller-selected create message ID, inspect coordination, reserve a key, append activity, or consume the limiter during verification.

Never persist plain content, embed text or layouts, notification or parsed-mention IDs, mention profiles, URLs, nonce, raw payloads, raw operation key, or transport cause. Rich-embed activity and operation records may contain only exact guild, channel, optional reply, and resulting message IDs, action, request and plan digests, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category.

## Application-owned emojis

Keep application-owned emoji inventory behind its own audit toggle and the configuration's pinned application and bot identities. Resolve application scope only from the freshly verified token identity. Never accept a caller-supplied application ID, infer another application, reuse guild-expression scope, or require a guild allowlist, guild permission, or privileged intent.

Project every Discord response immediately to bounded stable emoji metadata and unknown-field counts. Require the application-specific empty role array and a valid uploader object, then discard roles and uploader identity before returning data. Never return or persist image bytes, CDN URLs, uploader IDs or profiles, raw objects, role IDs, or unknown values. Require a complete bounded inventory with unique exact IDs before planning. Unknown fields, managed or non-colon emoji state, absent rename targets, exact-name collisions, and exhausted capacity must fail closed.

Keep create, rename, and delete behind the independent change toggle, process-keyed planning, signed interactive confirmation, write-aware host approval, final fresh-plan match, atomic one-shot operation-key reservation, pending content-free activity, one non-retried mutation, and exact metadata or complete-inventory absence readback. Require explicit global-impact acknowledgement for delete because the emoji may be referenced through every application installation. Do not add an audit-reason field because Discord does not document one for these endpoints. An already-current rename or already-absent delete must remain an operation-record-free no-op with no confirmation, reservation, activity entry, or mutation.

Creation must accept only one bounded canonical owned JPEG, PNG, GIF, WebP, or AVIF file under a dedicated application-emoji root. Never accept a remote URL, Discord CDN reference, data URL, base64 payload, arbitrary byte field, stream, directory, multiple files, or runtime-configurable Discord origin. Reject path escapes, symlinks, hardlinks, foreign ownership, unstable reads, unsupported formats, and files above Discord's byte limit before reservation. Upload only the reviewed byte snapshot bound into the fresh plan. Never claim stored-byte verification because Discord exposes only emoji metadata after creation.

Serialize changes per application inside one process as defense in depth. The production facade must also acquire one durable exact application emoji-collection claim so connector processes sharing the activity-state root exclude every overlapping application-wide change, regardless of emoji ID or operation key. A known pre-response Discord client rejection may be failed. Transport ambiguity, rate limiting, server failure, malformed mutation evidence, failure after mutation, readback failure, or receipt-finalization failure is uncertain and potentially completed. Retain the application claim after uncertainty and block queued same-application work. Never retry, compensate, restore, or roll back automatically.

Never persist emoji names, local paths, file metadata, image bytes, content digests, uploader data, raw operation keys, raw payloads, or private evidence. Activity and operation records may contain only exact application and emoji IDs, action, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category.

## Guild expressions

Keep emoji and sticker inventory behind its own audit toggle and exact guild allowlist. Project Discord responses immediately to bounded stable metadata and exact creator IDs; never return CDN URLs, image bytes, uploader profiles, or unknown raw fields. Require complete guild, bot-member, role, permission, and inventory evidence before returning a read or plan, and treat missing creator evidence as a blocker whenever ownership is needed.

Keep every create, update, and delete behind the independent change toggle, process-keyed planning, signed interactive confirmation, write-aware host approval, final fresh-plan match, atomic one-shot operation-key reservation, pending content-free activity, one non-retried mutation, and exact metadata or absence readback. Discord requires `CREATE_GUILD_EXPRESSIONS` for creation. Updating or deleting an expression requires either `MANAGE_GUILD_EXPRESSIONS` or exact bot ownership together with `CREATE_GUILD_EXPRESSIONS`; managed emojis are never mutable through this workflow.

Creation must accept only one bounded canonical owned local file under a dedicated expression root. Never accept a remote URL, Discord CDN reference, data URL, base64 payload, arbitrary byte field, stream, directory, multiple files, or runtime-configurable Discord origin. Reject path escapes, symlinks, hardlinks, foreign ownership, unstable reads, unsupported formats, invalid sticker dimensions, excessive animation duration, and files above Discord's byte limits before reservation. Require fresh `VERIFIED` or `PARTNERED` guild-feature evidence before planning a Lottie upload. Upload only the reviewed byte snapshot bound into the fresh plan.

Fail closed on absent targets, normalized-name collisions, missing emoji role references, incomplete permissions, local capacity exhaustion, malformed Discord evidence, changed file state, and stale plans. Permanently spend every reserved key after any outcome. A known pre-write Discord 4xx may be failed; transport errors, malformed mutation responses, Discord 5xx responses, and readback failures are uncertain and potentially completed. Never retry, compensate, or roll back automatically.

Serialize guild-expression changes per guild inside one process as defense in depth. The production facade also acquires a durable exact guild expression-collection claim, so connector processes sharing the activity-state root exclude overlapping changes and retain the claim after uncertainty. Never persist names, descriptions, tags, role names, local paths, file metadata, image bytes, content digests, audit reasons, raw operation keys, permission evidence, or raw Discord responses. Activity and operation records may contain only exact guild and expression IDs, expression kind, action, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category.

## Soundboard

Keep default and guild soundboard inventory behind its own audit toggle, and keep guild reads behind an exact guild allowlist. Project Discord responses immediately to bounded stable metadata, tagged emoji state, exact creator IDs, unknown-field counts, and complete ownership-aware permission evidence. Never return audio bytes, CDN URLs, creator profiles, raw objects, or unknown values. Require complete guild, bot-member, role, permission, and inventory evidence before returning a guild read or plan.

Keep every create, metadata update, and delete behind the independent change toggle, process-keyed planning, signed interactive confirmation, write-aware host approval, final fresh-plan match, atomic one-shot operation-key reservation, pending content-free activity, one non-retried mutation, and exact metadata or absence readback. Discord requires `CREATE_GUILD_EXPRESSIONS` for creation. Updating or deleting a sound requires either `MANAGE_GUILD_EXPRESSIONS` or exact bot ownership together with `CREATE_GUILD_EXPRESSIONS`. Do not add an immediate change call, bulk mutation, fuzzy lookup, automatic retry, rollback, or reconciliation. The change workflow must never accept playback fields or play audio.

Keep playback behind its own independent capability, exact ordinary voice-channel allowlist, and exact custom-sound source-guild allowlist. A null source may select only one exact sound from Discord's default inventory. A custom source must remain inside both local guild read scope and the dedicated source scope. Never infer a source guild, accept a name as identity, widen target scope from a guild, parent, inventory, or other soundboard capability, or let sound creation and administration grant playback.

Both the readiness check and the write must freshly verify the pinned application and bot, exact target channel and guild, ordinary voice type, complete channel overwrites, connector membership and roles, exact available sound, and the bot's exact current connection to that voice channel. Require complete `VIEW_CHANNEL`, `CONNECT`, `SPEAK`, and `USE_SOUNDBOARD` evidence, plus `USE_EXTERNAL_SOUNDS` when the custom sound comes from another guild. Server mute, server deaf, self-deaf, suppression, disconnected state, unknown evidence, malformed fields, absent sounds, and unavailable sounds must fail closed. The connector does not join a voice channel; an independently managed bot voice session must already be connected to the exact target.

Playback is a guarded non-destructive write, not a reviewed destructive workflow. Require MCP host write approval, a request-bound one-shot operation key, durable exact-channel coordination across connector processes, the shared interaction limiter, an atomic pending receipt, and pending content-free activity before one non-retried exact-ID POST. Accept only Discord's strict empty success. An exact `VOICE_CHANNEL_EFFECT_SEND` event for the same guild, channel, bot, and sound may corroborate success, but every non-target event must be discarded without entering the general event feed and no Gateway event may override an ambiguous REST result. A deterministic client rejection may be failed; rate limiting, request timeout, transport ambiguity, server failure, malformed success, and record-finalization failure remain uncertain with the key spent and exact channel claim quarantined.

A completed matching operation-key replay must return only from the durable receipt without repeating Discord reads or playback. A mismatched, pending, failed, uncertain, or malformed receipt must conflict rather than replay. Never persist sound or channel names, voice profiles or state, roles, overwrites, permission evidence, Gateway payloads, raw operation keys, or transport causes. Playback activity and operation records may contain only exact guild, channel, sound, and optional source-guild IDs, request digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category.

Creation must accept only one bounded canonical owned local MP3 or Ogg file under a dedicated soundboard root. Never accept a remote URL, Discord CDN reference, data URL, base64 payload, arbitrary byte field, stream, directory, multiple files, or runtime-configurable Discord origin. Reject path escapes, symlinks, hardlinks, foreign ownership, unstable reads, unsupported codecs or containers, invalid MP3 frames, invalid Ogg checksums or sequences, chained or multiplexed Ogg streams, audio above 512 KiB, and duration outside the supported range before reservation. Upload only the reviewed byte snapshot bound into the fresh plan.

Normalize names, bounded volume, exact IDs, and a tagged custom, Unicode, or absent emoji choice. Resolve a requested custom emoji by exact ID in the target guild. Fail closed on absent update targets, normalized-name collisions, missing or unavailable custom emoji, incomplete permissions, local safety capacity, unknown target fields, malformed Discord evidence, changed file state, stale plans, and a prior uncertain same-guild outcome. A no-op update or already absent deletion must reserve nothing, journal nothing, request no confirmation, and issue no write.

Bind the normalized request, verified identities, exact guild and complete inventory, relevant roles, permission and ownership evidence, current and desired metadata, custom emoji evidence, privacy projection, local audio state, warnings, and domain-separated operation-key hash into the plan. Exclude the raw operation key from plan material, signed request state, records, results, and errors. Treat a known pre-write Discord client error as failed. Treat transport errors, malformed mutation responses, Discord server errors, failures after mutation, failed readback, and failed receipt finalization as uncertain and potentially completed. Never claim stored byte equality because Discord does not return sound audio for readback.

Serialize soundboard changes per guild inside one process as defense in depth. The production facade also acquires a durable exact guild soundboard-collection claim, so connector processes sharing the activity-state root exclude overlapping changes and retain the claim after uncertainty. Never persist names, emoji, role names, local paths, file metadata, audio bytes, content digests, creator profiles, audit reasons, raw operation keys, permission evidence, or raw Discord responses. Activity and operation records may contain only exact guild and optional sound IDs, action, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category.

## AutoMod

Keep AutoMod inventory and exact lookup behind a separate audit gate and exact guild allowlist. Project list results to structural counts and reference health, return complete policy strings only through deliberate exact lookup, and treat every name, keyword, regex, preset, custom response, and Discord string as transient untrusted data. Never ingest AutoMod execution events because their payloads can contain message content, matched content, and matched keywords.

Keep changes behind an additional gate. Require complete `MANAGE_GUILD` evidence, conditional `MODERATE_MEMBERS` for timeout actions, strict trigger and action compatibility, complete exact role and channel references, and a separate exact visible alert-channel allowlist. Always create rules disabled, require a separate reviewed enable action, and require a disabled rule before policy update or deletion. Every write must use a fresh keyed plan, signed approval, durable guild AutoMod-collection coordination, one-shot reservation, pending content-free activity, one non-retried mutation, and exact rule-state or absence readback.

Persist strict schema-2 AutoMod receipts only. Bind the normalized caller-retained request and pinned identities through a token-derived keyed request digest, and reject schema-1 receipts without a parser, fallback, or migration. After pinned facade identity verification, inspect the receipt before guild, permission, inventory, or exact-rule reads. Never recover a created rule from its name, trigger, creator, singleton status, or inventory position; only a matching completed receipt may supply its exact rule ID. Request mismatch, nonterminal or malformed evidence, drift, and uncertainty must remain content-free blockers, and uncertainty must retain durable quarantine.

## Scheduled events

Keep scheduled-event inventory behind its own audit toggle and exact guild allowlist. Project Discord responses immediately to bounded event metadata, exact identities, optional aggregate subscriber counts, and complete entity-specific permission evidence. Ordinary inventory and exact-event reads must never return subscriber identities, creator profiles, cover URLs or hashes, embedded objects, or unknown raw fields. Require complete guild, bot-member, role, channel, permission, and event evidence before returning a read or plan.

Keep scheduled-event subscriber identities behind an additional opt-in that inherits the exact event guild scope. Resolve the exact event and complete entity-specific read evidence before calling the user endpoint. Force `with_member=false`, accept only bounded forward pagination, and project each raw row inside the REST client to an exact user ID plus bot flag. Reject member expansion, mismatched event IDs, invalid or duplicate users, and non-ascending pages. Never return or persist usernames, display names, avatars, nicknames, roles, join dates, member objects, profile fields, or raw payloads.

Keep every create, metadata update, lifecycle transition, and deletion behind the independent change toggle, process-keyed planning, signed interactive confirmation, write-aware host approval, final fresh-plan match, atomic one-shot operation-key reservation, pending content-free activity, one non-retried mutation, and exact state or absence readback. Do not add an immediate-call path, bulk mutation, fuzzy event lookup, subscriber profile enumeration, subscriber mutation, retry, rollback, or reconciliation.

Enforce Discord's exact entity-specific permission rules. Creation requires `CREATE_EVENTS` plus the documented voice or stage channel permissions. Updating, transitioning, or deleting requires `MANAGE_EVENTS`, or exact connector-bot ownership together with `CREATE_EVENTS`, plus the current entity's channel permissions. A hosting move must also prove the complete creation permissions at the destination. Missing creator evidence cannot establish ownership, and `ADMINISTRATOR` must remain a warning rather than a recommended setup.

Normalize exact action-specific fields, canonical timestamps, future starts, end-after-start ordering, external hosting requirements, documented lifecycle transitions, and only Discord-supported recurrence shapes. Never synthesize server-controlled recurrence count, end, or year-day fields. A recurring start-time change must explicitly replace or remove recurrence. Keep active-event metadata changes limited to fields Discord safely permits, and reject metadata changes to terminal events.

Cover input must remain local-file-only and single-file. Never accept a remote URL, Discord CDN reference, data URL, base64 payload, arbitrary byte field, stream, directory, multiple files, or runtime-configurable Discord origin. Accept only bounded JPEG or non-animated PNG content under a dedicated root. Reject path escapes, symlinks, hardlinks, foreign ownership, unstable reads, unsupported or animated formats, invalid dimensions, and files above the fixed ceiling before reservation. Upload only the reviewed byte snapshot bound into the fresh plan.

Bind the normalized request, verified identities, exact guild and event state, current and destination authority, relevant role and channel evidence, visible creation inventory, privacy projection, local cover state, warnings, and domain-separated operation-key hash into the plan. Exclude the raw operation key from plan material, signed request state, records, results, and errors. A reserved key remains spent after every outcome, including known failure, local recording failure, or uncertainty.

Treat a known pre-write Discord client error as failed. Treat transport errors, malformed mutation responses, Discord server errors, and failures after a mutation or during exact readback as uncertain and potentially completed. Cover verification can prove reviewed bytes were sent and a cover is present afterward, but must not claim byte equality because Discord does not return stored image bytes. Never retry, compensate, or roll back automatically.

Serialize scheduled-event changes per guild inside one process as defense in depth. The production facade also acquires a durable exact guild scheduled-events collection claim, so connector processes sharing the activity-state root exclude overlapping changes and retain the claim after uncertainty. Never persist event names, descriptions, locations, recurrence fields, subscriber counts or user IDs, role names, local paths, file metadata, image bytes, content digests, audit reasons, raw operation keys, permission evidence, or raw Discord responses. Activity and operation records may contain only exact guild and event IDs, entity type, action and transition target, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category.

## Stage instances

Keep Stage-instance inventory behind its own audit toggle and exact Stage-channel allowlist. Do not derive Stage scope from a guild, parent, category, or thread. Verify the pinned identities, exact guild ownership, exact Stage channel type, connector membership, complete roles and overwrites, and effective `VIEW_CHANNEL` before returning one active or inactive privacy projection. Within one inventory call, guild, connector-member, and role evidence may be shared per guild, but each channel and Stage instance must be read exactly and no evidence cache may survive the call. Never enumerate speakers or listeners, inspect voice state, return scheduled-event objects, forward unknown raw fields, or cache or persist a Stage read.

Keep every start, topic update, and end behind the independent change toggle, process-keyed planning, signed interactive confirmation, write-aware host approval, final fresh-plan match, atomic one-shot operation-key reservation, pending content-free operation and activity records, one non-retried mutation, and exact active-state or absence readback. Require guild-only privacy, no scheduled-event association, zero unknown fields, and complete `VIEW_CHANNEL`, `CONNECT`, `MANAGE_CHANNELS`, `MUTE_MEMBERS`, and `MOVE_MEMBERS` evidence. Deprecated public and scheduled-event-linked instances are read-only. Do not add an immediate-call path, fuzzy channel lookup, bulk mutation, automatic retry, rollback, reconciliation, or scheduled-event association mutation.

Keep Discord's guild-wide Stage start notification behind a third independent toggle. Require fresh `MENTION_EVERYONE` evidence, bind the choice into the plan and signed state, and consume the shared interaction rate budget before mutation. Never permit notification on update or end. A no-op must reserve nothing, journal nothing, request no confirmation, and issue no write.

Bind the normalized action-specific request, verified identities, exact guild and Stage channel, complete role and overwrite evidence, effective permissions, active or inactive current state, desired state, guild-only privacy, scheduled-event isolation, schema-drift count, notification choice, warnings, and domain-separated operation-key hash into the plan. Exclude the raw operation key from plan material, signed request state, records, results, and errors. Any identity, state, topic, privacy, association, schema, or permission drift must invalidate the reviewed plan. Check the shared interaction rate guard immediately before any notification reservation or durable write state.

Treat a known pre-write Discord client error as failed. Treat transport errors, malformed mutation responses, Discord server errors, and failures after mutation or during exact readback as uncertain and potentially completed. Never retry, compensate, or roll back automatically. Permanently spend every reserved key after any outcome.

Serialize changes per exact Stage channel inside one process as defense in depth. The production facade also acquires a durable exact channel claim, so connector processes sharing the activity-state root exclude overlapping changes and retain the claim after uncertainty. Never persist topics, guild or channel names, speaker or audience identities, scheduled-event objects, role names, permission evidence, audit reasons, raw operation keys, or raw Discord responses. Activity and operation records may contain only exact guild, channel, and optional Stage-instance IDs, action, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category.

## Member voice state and moderation

Keep exact member voice-state audit behind its own toggle plus non-empty exact guild and voice-channel allowlists. Do not derive scope from the member directory, ordinary guild reads, a category, thread inheritance, Stage lifecycle, or member administration. Verify the pinned identities, exact guild and target membership, strict voice-state response identity, source-channel ownership and supported type, complete roles and overwrites, and effective connector `VIEW_CHANNEL` plus `CONNECT` before returning one state. Treat only Discord error code 10065 as a disconnected target; a generic 404 or malformed result is not absence evidence.

Return only verified application, bot, guild, owner, and target IDs, bounded untrusted guild, member, and channel names, connection state, exact allowlisted source channel, server mute and deafen booleans, complete read-permission evidence, discarded unknown-field count, and fixed privacy claims. Never enumerate occupants or return session IDs, embedded members, self mute or deafen state, stream or camera state, Stage suppression or request-to-speak state, unknown-field values, or raw Discord payloads. Do not cache, persist, journal, or export a voice-state read.

Keep move, disconnect, server-mute, server-unmute, server-deafen, and server-undeafen behind an independent change toggle and a strict action-specific schema. Mutate only ordinary voice channels; Stage participants are always read-only. Reject the connector bot, guild owner, pending members, administrators, protected user IDs, and targets not strictly below the connector's unique highest role. Require complete `VIEW_CHANNEL`, `CONNECT`, and `MOVE_MEMBERS` evidence on source and destination for move, source for disconnect, `VIEW_CHANNEL`, `CONNECT`, and `MUTE_MEMBERS` on source for server mute state, or `VIEW_CHANNEL`, `CONNECT`, and `DEAFEN_MEMBERS` on source for server deafen state. A move must separately prove target `VIEW_CHANNEL` and `CONNECT` on the exact destination. Fail closed on unknown permission bits, incomplete or ambiguous roles, duplicate or unresolved overwrites, unsupported channel types, mismatched IDs, or state outside exact local scope.

Do not add an immediate-call path, occupant list, bulk action, fuzzy member or channel lookup, generic member update, Stage participant control, retry, rollback, compensation, or reconciliation. Preserve every gate: exact scope, pinned identity, protected-target checks, complete permission and strict local hierarchy evidence, exact current state, process-keyed planning, signed interactive confirmation, write-aware host approval, final fresh-plan match, atomic one-shot operation-key reservation, pending content-free activity, one non-retried one-field PATCH, strict response validation, and exact voice-state readback. A client without MCP elicitation must not execute member voice changes.

Bind the action-specific request, verified identities, guild owner, exact bot and target memberships, complete roles, source and destination channels and overwrites, current state, action-specific connector permissions, target destination access, strict hierarchy, privacy projection, audit reason, and domain-separated operation-key hash into the plan. Any relevant identity, membership, role, channel, overwrite, state, permission, destination, enabled value, reason, or key change must invalidate review. A verified already-current request must reserve nothing, journal nothing, request no confirmation, and issue no write.

Reserve and journal before dispatching one PATCH whose body contains exactly one of `channel_id`, `mute`, or `deaf`. Validate the returned user identity, every response field that can prove controlled state, and unchanged uncontrolled state, then perform an exact fresh voice-state readback and recheck channel scope. Report controlled success with unrelated state divergence as completed with drift. Only a known Discord 4xx refusal other than 429 returned instead of a successful mutation response may settle as failed. Treat a rate limit, transport or server error, malformed success, response mismatch, readback failure, local finalization failure, or other indeterminate post-reservation result as uncertain and potentially completed. Spend every reserved key permanently, serialize exact guild and user targets inside one process as defense in depth, never retry, and never roll back automatically. The production facade acquires a durable exact member claim, so connector processes sharing the activity-state root exclude overlapping voice changes and retain the claim after uncertainty without persisting voice-channel IDs.

Member-voice activity and operation records may contain only the exact guild and user IDs, action, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. Never persist source or destination channel IDs, voice-state booleans, names, role or permission evidence, hierarchy, audit reasons, raw operation keys, Discord responses, or transport causes.

## Bulk member-role changes

Keep bulk member-role authority independent from single-member role authority. Require its own capability plus nonempty exact guild and role allowlists, the shared protected-user denylist, pinned application and bot identities, one exact role, and 2-25 unique exact member IDs. Canonicalize the complete target set numerically and bind its digest. Never infer batch authority from a single-member allowlist, a role name, member search, a shared guild, a toolset, or Discord's `MANAGE_ROLES` grant.

Reuse the complete single-member hierarchy and permission-impact planner for every target through an unforgeable internal batch path. Require all target plans to share one keyed common-evidence digest over the pinned identity, guild, complete roles, bot authority, layout, and trusted direct-channel snapshots. Reject protected and special members, unsafe roles, unsafe unknown or excessive permission impact, obfuscated channels, mixed evidence, and any incomplete or mismatched child checkpoint before approval.

Bind signed MCP request state to the exact action, guild, role, canonical member set, target-set digest, audit reason, parent operation-key hash, and aggregate plan digest. After approval, recheck the complete plan, durably claim the guild member collection, selected role, and every exact member, reserve a pending content-free parent receipt, then execute only the reviewed frontier sequentially by canonical user ID. Each child keeps every single-member pending-audit, one-shot key, non-retried exact PUT or DELETE, and readback gate. Stop at the first failed, uncertain, drifting, or incomplete child; never continue best-effort, retry automatically, replace a complete role array, or roll back a completed target.

Allow resumption only from the original exact request and parent key after a verified pause, a fresh aggregate plan, and a new signed approval. Keep the parent request binding restart-stable through a domain-separated HMAC keyed by the caller-retained raw parent key, while keeping every aggregate review digest process-bound. Accept a child checkpoint only when its content-free receipt is terminal and verified and fresh exact state still matches. Final checkpoint drift, terminal failure, or terminal uncertainty must make the parent terminal and retain coordination for operator review. An interrupted process with a pending claim must remain review-required until the operator checks exact Discord state and resolves that claim. Parent and child records may contain only exact Discord IDs, domain-separated digests, timestamps, fixed outcomes, activity IDs, and sanitized error categories; never persist member, guild, role, or channel names, role sets, permission evidence, audit reasons, raw keys, payloads, or transport causes.

## 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.

## Parent-category permission synchronization

Keep permission synchronization behind its own disabled-by-default capability, non-empty exact direct-child allowlist, and independent MCP toolset. Do not derive it from read scope, a readable parent, category scope, permission-overwrite mutation, channel metadata, ordering, creation, cloning, scaffolding, or any other structural authority. Require the child allowlist to remain inside exact channel read scope, and never inherit mutation authority from the parent category.

Accept only one exact text, announcement, forum, media, voice, or Stage child and its live same-guild parent category. Reject categories, directory channels, threads, direct messages, parentless channels, arbitrary source IDs, caller-supplied bitfields or overwrite arrays, batches, fuzzy targets, retries, rollback, and reconciliation. Require literal acknowledgments that the child's complete overwrite set will be replaced, later parent changes will propagate while it remains synchronized, and every concurrent permission editor under the operator's control has stopped.

Verify pinned application and bot identities, exact guild ownership, exact connector membership, complete bounded roles, both complete overwrite sets, and every referenced role target. Reject unknown permission bits, known non-channel bits, duplicate or contradictory targets, changed protected-member overwrites, and an excessive changed-target frontier. Do not fetch changed member profiles or claim exhaustive combined member-effective access analysis; expose the limitation and keep the review structural.

Require complete current-child and prospective-child `VIEW_CHANNEL`, `MANAGE_CHANNELS`, and `MANAGE_ROLES` evidence, complete parent `VIEW_CHANNEL` evidence, and proof that the connector holds every permission present in the outgoing parent bitfields at the parent. Bind the strict request, all acknowledgments, verified identities, complete child and parent overwrite sets, supporting evidence, bounded structural delta, current, parent, and prospective authority, privacy boundary, warnings, and domain-separated operation-key hash into the process-keyed plan. Any relevant drift must invalidate approval before reservation.

Do not add an immediate execution path. Require write-aware MCP host approval, signed interactive confirmation, repeated fresh matching plans, durable claims on the exact live child and parent, atomic one-shot reservation, pending content-free activity, and a final fresh service plan before one non-retried PATCH containing only the complete reviewed `permission_overwrites` field and encoded audit reason. Require exact child identity, unchanged guild and parent binding, exact response overwrites, and a fresh complete child, parent, guild, connector-member, role, authority, and synchronized-state readback. An already-synchronized child must reserve nothing, journal nothing, request no confirmation, and issue no write.

Classify only a known pre-response Discord client rejection other than timeout or rate limiting as failed. Treat rate limiting, timeout, transport ambiguity, server errors, malformed or mismatched response evidence, failed synchronization proof, or local finalization failure as uncertain and potentially completed. Permanently spend the reserved key, retain both durable channel claims, block overlapping same-channel permission work after uncertainty, and never automatically retry, guess, compensate, or roll back. Durable local claims cannot stop a Discord administrator, another bot, or a connector with a different state root, so the stopped-concurrency acknowledgment remains a real operator boundary.

Permission-sync activity and operation records may contain only exact application, bot, guild, child, and parent IDs, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. Never persist changed role or member target IDs, permission values, role, member, guild, or channel names, audit reasons, raw operation keys, raw Discord payloads, or transport causes.

## Channel ordering

Keep channel-order audit behind its own capability gate, pinned application and bot identities, and non-empty exact guild allowlist inside the read-guild boundary. Reviewed changes require a second independent toggle. Do not derive audit or mutation authority from ordinary channel reads, channel metadata, channel creation, guild scaffolds, forum tags, permission overwrites, event-feed scope, channel-only read scope, a target name, or another administrative feature. A client without MCP elicitation must not execute channel-order changes.

Build audit evidence from one coherent complete Gateway layout plus one bounded HTTP guild-channel snapshot taken between equal layout revisions. The Gateway projection may contain only exact channel ID, documented direct-channel type, nonnegative raw position, nullable parent ID, and explicit `CHANNEL_OBFUSCATED` state. Before Discord's November 16, 2026 HTTP transition, accept a strict complete HTTP inventory. After or during obfuscation testing, accept only the strict exact non-obfuscated Gateway subset. Select the evidence mode from the observed sets rather than the local clock. Discard HTTP metadata for every Gateway-obfuscated channel even when HTTP still returns it. Reject missing, extra, duplicate, malformed, cross-guild, topologically invalid, or revision-drifting evidence.

Canonicalize every sortable group by ascending raw position and ascending snowflake ID. Categories form one guild-level family. Text, announcement, forum, and media channels form one text-like family per parent. Voice and Stage channels form one voice-like family per parent. Directory and unknown future channel types are unsupported, and an unsupported sibling at either affected parent must block a real change. Permit only one exact target immediately above or below one distinct same-family anchor. When the parents differ, derive the destination only from the exact anchor, require a valid root category or guild root, enforce category capacity, preserve the target's exact permission overwrites with literal `lock_permissions: false`, and never accept an arbitrary parent. Never accept arbitrary numeric positions, fuzzy names, caller-provided bulk payloads, cross-family moves, permission synchronization, permission or overwrite changes, flag or metadata changes, creation, deletion, retry, rollback, compensation, or reconciliation.

Require complete guild-level `MANAGE_CHANNELS` evidence or complete visible parent-category overwrite evidence proving `MANAGE_CHANNELS` for every affected sortable group. Top-level and category groups require guild-level authority. A cross-parent move additionally requires visible exact target metadata plus complete target `VIEW_CHANNEL` and `MANAGE_CHANNELS` evidence, as Discord documents independently from destination authority. Validate the exact guild and owner, connector membership, complete bounded roles, arbitrary-width permission bits, unique overwrite targets, supported parents, category capacity, and every response identity before claiming authority. An obfuscated target or anchor remains addressable only by caller-supplied exact ID and privacy-safe topology for a same-parent reorder; an obfuscated target must block a cross-parent move, while an obfuscated anchor may select a destination only when its parent authority is otherwise complete. Never expose or infer hidden metadata.

Bind the normalized request without the raw operation key, its domain-separated hash, verified identities, exact guild and owner, connector membership and permissions, complete roles, complete HTTP evidence and selected mode, complete Gateway layout and baseline revision, every canonical group order, exact target, anchor, source and destination parents, family, capacity, desired source and destination orders, complete normalized payload, overwrite-preservation behavior, impact, risks, warnings, and audit reason into the plan. Any relevant identity, membership, role, overwrite, layout, revision, visibility subset, metadata, order, authority, capacity, reason, target, anchor, placement, or key drift must invalidate review. A verified already-current request must acquire no claim, reserve nothing, journal nothing, subscribe to nothing, request no confirmation, and issue no write.

For a real change, acquire durable claims on the exact target, anchor, applicable parent categories, and guild channel collection before reservation. Atomically reserve and journal, subscribe to layout updates, and synchronously prove that the baseline remains exact before marking mutation as started. Send one non-retried PATCH whose body contains every channel in the reviewed affected groups normalized to sequential positions from zero. A cross-parent payload may add only the exact destination `parent_id` and literal `lock_permissions: false` to the target entry; no other parent, permission-sync, flag, or metadata field is allowed. Treat Discord's empty 204 as acceptance only, never as verification. Require a strictly newer complete Gateway layout whose expected topology and every canonical group match, then require one coherent HTTP readback that retains the exact target type, visibility class, and permission overwrites. Do not substitute a timer, one partial Channel Update, only the moved channel, or HTTP evidence without the complete Gateway proof.

A failure proven to occur before mutation, including an arm-time baseline mismatch, or a known non-retriable Discord client rejection before acceptance may settle as failed. Treat transport ambiguity, rate limits, server errors, timeout, continuity loss or malformed dispatches after mutation begins, a newer contradictory layout, a missing complete match, durable receipt finalization failure, or any other indeterminate post-reservation result as uncertain and potentially completed. Permanently spend the key, serialize and quarantine the whole guild channel collection inside direct service instances, and retain the production facade's durable collection claim after uncertainty. Never retry or roll back automatically.

Persist only exact guild, target, anchor, source parent, and destination parent IDs, relative placement, baseline and observed layout revisions, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. Never persist channel names, topics, layout inventories, positions, types, obfuscation state, permission or overwrite evidence, audit reasons, raw operation keys, raw Discord responses, Gateway dispatches, or transport causes.

## Channel deletion

Keep channel retirement behind its independent audit and change capabilities, non-empty exact channel allowlist, exact read scope, pinned application and bot identities, complete continuity-stable Gateway and HTTP evidence, type-specific permission proof, and the separate channel-deletion toolset. Do not add an immediate, fuzzy, bulk, cleanup, retry, recreation, rollback, or absent-target-success path.

Require every plan and execution request to make exactly one recovery choice in addition to literal irreversible-content-loss acknowledgement. The preferred choice must contain a fresh signed binding from a stable planner-ready two-pass guild blueprint capture plus literal acknowledgement that the caller retained the complete blueprint and reviewed its limitations and omissions. Verify the process-local signature, fixed 30-minute lifetime, application, bot, guild, resource kind, exact channel ID, and fresh captured channel-projection digest before returning a plan. The explicit alternative must contain literal acknowledgement that no recovery artifact is retained and must add a visible warning that content and original identity cannot be restored. Never infer either choice, substitute a binding, or let one branch relax another deletion gate.

Bind only the attestation's SHA-256 digest and verified credential-free recovery projection into the keyed plan and signed confirmation state. Return the capture fingerprint, deterministic blueprint key, capture and expiry times, target projection digest, omission codes, fixed limitations, mode, and verification state for review without returning the raw attestation. Rebuild and verify the identical choice at every existing freshness boundary. A forged, expired, cross-process, identity-mismatched, target-mismatched, wrong-kind, or stale attestation must fail before confirmation or reservation.

Preserve every dependency, permission, irreversible-loss, freshness, host approval, signed confirmation, durable coordination, one-shot reservation, pending activity, non-retry, returned-channel validation, and newer complete Gateway absence gate. An attestation is evidence that one lossy structural projection was captured, not proof that the caller retained it, a backup, rollback authority, message recovery, original-ID restoration, or permission to delete. Never persist or emit the raw attestation in a deletion plan, confirmation, execution result, activity record, operation receipt, error, log, trace, metric, or telemetry attribute.

## Channel creation

Do not add a channel-creation shortcut that bypasses the capability gate, exact creation-guild allowlist, pinned bot identity, exact guild and optional parent IDs, complete permission evidence, visibility-bounded collision and capacity checks, process-keyed planning, signed interactive confirmation, write-aware client approval, final fresh-plan match, atomic one-shot operation-key reservation, pending activity journaling, single POST, or exact readback. If a client cannot support MCP elicitation, keep channel creation unavailable in that client.

Keep this surface additive-only. Do not silently expand it to edits, moves, positions, permission overwrites, deletion, rollback, or blueprint reconciliation. Those capabilities change existing authority and state and require separate policies, plans, confirmation language, and tests.

Discord's create-channel operation has no idempotency token. Persist only the domain-separated operation-key hash, IDs, plan digest, timestamps, fixed outcome and verification states, activity ID, and sanitized error category in private one-shot receipts. Never persist or return the raw operation key. A reserved key must remain spent after every outcome, including a local recording failure or uncertainty. Never automatically retry the POST, and never treat an uncertain result as a failed write.

Serialize the same guild, parent, and normalized logical name across operation keys and supported channel kinds within a connector process. Rebuild every queued plan after the preceding execution, and block a queued execution without reserving its key when the preceding target outcome is uncertain.

Operation receipt directories and files must remain owner-private. Reject symlinks, hardlinked or foreign-owned files, public modes, oversized or malformed records, terminal records without a reservation, identity changes, and divergent terminal outcomes. Sync each receipt and its directory entry before the workflow advances.

Guild channel listings are visibility-bounded. Require both guild-level and parent-category `MANAGE_CHANNELS` and `VIEW_CHANNEL`, label the evidence honestly, and fail closed on ambiguous logical-name matches, incomplete roles or overwrites, invalid response identities, and capacity reached in the visible inventory. Do not claim that the absence of a visible collision proves global absence.

Never persist channel names, topics, audit-log reasons, permission overwrites, role names, or raw Discord responses. Channel-creation activity and operation records may contain exact guild, parent, and created-channel IDs, the channel kind, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity IDs, and sanitized error classifications.

## Guild scaffolds

Do not add a scaffold shortcut that bypasses the dedicated capability gate, exact scaffold-guild allowlist, verified application and bot identities, exact bounded symbolic graph, complete role and visible channel inventories, effective permission and strict hierarchy evidence, collision and capacity checks, durable request binding, checkpoint validation, process-keyed frontier planning, signed interactive confirmation, write-aware client approval, final fresh-plan match, bounded step limit, per-step one-shot reservation, pending activity journaling, non-retried single-resource writes, exact readbacks, or fresh review after dependencies change. If a client cannot support MCP elicitation, keep scaffold execution unavailable in that client.

Keep the surface additive-only and limited to roles, categories, text channels, and forum channels. Every child may reference only a category declared in the same request. Do not add existing-parent IDs, permission overwrites, edits, moves, positions, role assignments, deletion, rollback, skip-on-error, best-effort continuation, or blueprint reconciliation. Those operations change existing state or authority and need independent policy, evidence, plans, confirmation, recovery, and tests.

Normalize and globally de-duplicate safe symbolic keys before planning. Canonicalize role steps before categories and category children so derived operation identities never depend on caller array order. Reuse the standalone role and channel validators for exact properties and logical names. Treat an exact matching existing resource as a no-op; fail closed on ambiguity, managed roles, property mismatch, invalid parent linkage, incomplete evidence, unsupported channel types, or visibility-bounded capacity exhaustion.

Require complete guild-role evidence and exact connector-member identity. For requested roles, require `MANAGE_ROLES`, strict hierarchy above `@everyone`, forbid `ADMINISTRATOR`, and require every requested named permission to be a subset of the connector's effective guild permissions. For requested channels, require guild-level `MANAGE_CHANNELS` and `VIEW_CHANNEL`. Before creating a child under an existing category, require complete overwrite evidence and both permissions at that exact parent. Never claim that visible channel absence proves global uniqueness.

Bind the persistent scaffold operation to the verified application ID, bot ID, exact guild, audit reason, and canonical resource intent with a domain-separated HMAC keyed by the raw operation key. Persist only the resulting request digest and top operation-key hash. Bind the bounded execution limit, complete live evidence, ordered execution-frontier step indexes, checkpoint projection, and persistent request digest into the process-keyed reviewed plan. The execution limit may change only through a fresh plan and signed confirmation; it must not change the durable resource intent.

Derive a distinct domain-separated one-shot operation key for each canonical step. Preserve every standalone role or channel creation invariant, including a private pending receipt, pending activity record, one non-retried POST, and exact readback. Keep the top scaffold receipt pending across intentional frontier pauses. Mark it completed only after a fresh plan proves that every step is already current or has an exact matching completed checkpoint and no step remains ready or waiting for a parent.

A newly created category must end the dependency frontier for every child that references it. Require a fresh plan to discover the exact category ID, re-evaluate its permissions and capacity, and bind that evidence before child execution. Never resolve a new parent from the create response and continue under the earlier approval.

Treat any pending per-step receipt as active or interrupted work and block it without takeover. Treat failed, uncertain, drifted, missing, mismatched, or divergent checkpoints as permanent blockers for that scaffold operation key. A restart may rebuild a fresh process-keyed plan from the same raw operation key, persistent request digest, live Discord state, and immutable completed checkpoints, but it must never infer completion from a receipt alone. Require the exact receipt resource ID and current exact state to match.

Keep the top operation pending when a step fails before any per-step reservation exists because the write invariant proves that no Discord mutation began. Require exact operator review and claim release followed by a fresh reviewed plan before continuing. Serialize logical role and channel targets across different operation keys inside one connector process. The production facade must also claim both guild collections for every active scaffold, using the persistent request digest that exactly matches the top receipt rather than a process-keyed frontier digest. Release those claims after a normal verified pause, but retain quarantine after any thrown, interrupted, or uncertain pending execution. This must exclude overlapping scaffolds and standalone role or channel creation across connector processes sharing the activity-state root without implying logical-name uniqueness.

Never persist the raw operation key, symbolic keys, names, topics, named permission lists, colors, audit reasons, role names, overwrites, plan confirmation text, or raw Discord responses. Scaffold and per-step receipts may contain only domain-separated hashes, exact Discord IDs, timestamps, fixed operation, outcome, and verification states, activity IDs, and sanitized error categories. Completion verification must require the caller-retained exact request and operation key, re-run the same strict live plan checks, and return only identities, hashes, counts, step indexes, kinds, states, resource IDs, receipt status, and a fresh process-keyed digest. It must not reserve, append activity, mutate Discord, or reconstruct omitted intent from receipts. An all-current unreserved request must remain a content-free no-op without reserving the top key and verification must label it `unrecorded`, not `verified`.

## Guild blueprints

Treat live blueprint capture as a bounded read and authoring aid, never as backup authority. Require the ordinary exact guild boundary plus the profile, settings, Community, Welcome Screen, onboarding, and AutoMod audit gates before identity or capture reads. Read two bounded passes through only those domains, the returned role inventory, and the configured-policy- and Discord-visibility-bounded channel inventory. Include complete trusted Community routing and exact-ID AutoMod policy in the stability comparison and return no blueprint or recovery binding if any canonical projection differs. Never read messages, a member directory, non-connector member profiles, webhooks, invites, attachments, components, AutoMod execution events or match content, or audit history for capture. The Community sub-audit may read only the verified connector bot membership needed for complete permission evidence and must return no profile fields. Never write a snapshot, attestation, policy content, activity entry, operation receipt, or coordinator state.

Return only one strict planner-compatible representable subset with fixed omission and blocker codes, deterministic symbolic keys, explicit exact-bound references, enabled Community routing, exact-ID AutoMod rules, an unkeyed content fingerprint, privacy evidence, non-backup limitations, and a fixed next action. Capture must not automatically add exact-role-configuration or exact-channel-metadata convergence intent; the operator must author and review those same-guild exact-ID phases explicitly. For a planner-ready stable result only, mint one process-local HMAC attestation per represented role and channel. Bind the verified application, bot, guild, resource kind and exact ID, deterministic blueprint key, complete capture fingerprint, completion and fixed 30-minute expiry times, exact captured target-projection digest, and applicable omission codes. Never mint a binding for a blocked, torn, omitted, or unrepresented resource. Capture enabled Community only when its feature state, exact routing IDs, trusted direct text or announcement channels, and `@everyone` rules-channel visibility are complete. Otherwise omit it under a fixed finding and never invent a target. Managed or Administrator roles, unknown permission bits, enums, or response fields, unsupported channel types, permission overwrites, ordering, cosmetics, forum extras, unknown Community or AutoMod evidence, unresolved references, ambiguity, and capacity loss must never be silently approximated. A `review-required` result must not proceed to blueprint planning until its partial desired state is explicitly accepted or edited. Every retained draft still requires a fresh authoritative plan. Do not claim caller retention, atomicity, lossless restore, automatic rollback, original-ID restoration, message recovery, completeness, or cross-guild portability.

Treat `compile_guild_blueprint_starter` as an authority-free local authoring utility. It may compile only the fixed `community`, `creator`, `project`, or `support` public layout from one exact guild ID, stable operation key, audit reason, and optional guild name, then normalize the result through the production blueprint request contract. It must not inspect policy, contact Discord or another service, read a remote template, accept arbitrary variables, persist content, create roles, assign members, request `ADMINISTRATOR`, lower or otherwise replace the guild verification level, or claim private or read-only access. Its information channels remain ordinary public text channels, and its symbolic key order is only a deterministic creation hint rather than a final live order. The later scaffold planner retains its ordinary collision boundary: it may bind one unambiguous logical-name candidate only when complete current state exactly matches, while duplicates, mismatches, hidden-state limits, or drift block. Return exact policy requirements, omission codes, warnings, and separate exact-ID permission-overwrite and ordering handoffs. Compilation must never replace a fresh `plan_guild_blueprint` call or any nested domain gate.

Treat `preview_guild_blueprint` as an authority-free local projection, never a dry-run approval or simulated live plan. It must use the same strict production normalizer as live planning, remove the raw master operation key before returning data, expose the complete deterministic manifest sequence and direct dependencies, and classify exact and scaffold references without resolving them. Possible write stages may describe only bounded intent-derived vocabulary and must never claim that a stage or write is required. Preview must not read a credential or policy, contact Discord, mint an executable plan digest, reserve an operation, write activity, persist content, grant authority, invent an ID, or predict permission, hierarchy, capacity, receipt, or post-write state.

Build every live plan's manifest overlay from that same deterministic sequence. Mark only reached steps freshly assessed, mark later steps deferred, and mark at most the matching write-required current frontier executable. Keep planner-discovered safety prerequisites that were absent from caller intent in a separate collection rather than rewriting the normalized manifest. A complete sequence must never become permission to execute multiple phases under one snapshot or approval.

Treat the blueprint coordinator as sequencing only, never as new authority. Every structure, exact role-configuration, exact channel-metadata, profile, settings, Community, Welcome Screen, onboarding, AutoMod, and Components V2 publication frontier must pass the corresponding domain capability, exact scope, identity, intent, notification, complete-evidence, permission, planning, approval, reservation, pending-audit, non-retry, readback, conflict, and uncertainty gates. Exact role and channel targets must remain inside the standalone role-configuration and channel-metadata allowlists even when those standalone tools are hidden. A publication link must additionally pass the component domain's exact canonical HTTPS origin policy before Discord access. A publication request row must additionally pass exact native Interaction guild, resolved channel, and user scope plus paired broker and managed-command readiness; a blueprint must grant none of that authority. First-time Community enablement retains the exact-owner or complete `ADMINISTRATOR` requirement; routing-only changes retain exact-owner or complete `MANAGE_GUILD` authority. AutoMod timeout actions retain conditional `MODERATE_MEMBERS`, and alert actions retain their separate exact channel allowlist. Hiding a domain's standalone toolset must not bypass its policy, and enabling the blueprint toolset must grant no Discord access by itself.

Keep the manifest strict, exact, caller-retained, and bounded. The only supported order is structure, exact role configuration in ascending role-ID order, exact channel metadata in ascending channel-ID order, profile, settings, Community, Welcome Screen, onboarding, ordered AutoMod rules, then ordered publications, with omitted phases skipped and exactly one fresh frontier executable per call. Reject duplicate exact targets and derive target identity only from the exact snowflake, never a name, logical match, symbolic key, or inventory position. Exact role intent may use either one complete known permission-name set or grant and revoke deltas, never both. A complete known set must preserve unknown future bits and must not contain `ADMINISTRATOR`. Sparse channel metadata must preserve every omitted field and must not expand into ordering, type conversion, overwrite replacement, forum-tag replacement, deletion, or thread mutation. Community must carry literal enablement acknowledgement, distinct rules and public-updates references, and a nullable safety-alerts reference. Its exact references may target only trusted direct text or announcement channels; symbolic references may target requested scaffold text channels only. Preserve every existing guild feature and add only `COMMUNITY`. If enabled Welcome Screen or onboarding intent omits Community while the feature is disabled, return a fixed content-free dependency blocker and perform no downstream plan or write. Welcome Screen, onboarding, and AutoMod entries may use only their explicitly supported exact IDs or requested scaffold references. Existing onboarding prompts, onboarding options, and AutoMod rules may be retained only by exact Discord ID. An AutoMod rule without `ruleId` is create-only and must never adopt live state by name, trigger, creator, singleton status, or inventory position. Omission never deletes a rule. Publications require a unique stable key and either one exact channel or active thread or one requested scaffold text channel. Create publications must omit a message ID, edit publications must require one exact message ID, and replies, reply-author notification, arbitrary callback-bearing components, and attachments remain excluded. Resolve symbolic references only from complete exact scaffold bindings, reject duplicate raw references and duplicate resolved IDs, and require the existing hardened domain plan for every frontier.

Derive a separate deterministic HMAC operation key for every singleton phase, exact role target, exact channel target, stable AutoMod rule and stage, and stable publication key. Exact-target identities must remain stable when their arrays are reordered. Other reordering may change the manifest digest but must not change an individual item or stage identity. Bind the complete normalized manifest, verified identities, exact bindings, phase states, receipt-verification codes, blocker, nested plan digest, and current frontier into keyed request and aggregate plan digests. Signed request state may contain only those digests. AutoMod receipts must use strict schema 2 and bind a token-derived keyed request digest without persisting policy content; schema-1 AutoMod receipts are invalid and have no compatibility parser or migration. A changed manifest, master key, phase, item, identity, binding, Discord snapshot, receipt state, nested digest, or connector process must require a new review.

Standalone domain planning must continue rejecting every spent one-shot key. Blueprint reconciliation may inspect a prior nested receipt only through the domain's narrow reconciliation entry point. It may treat the phase as satisfied only when the receipt is `completed`, verification is `match`, the guild and resource IDs match exactly, and a fresh complete domain plan proves the requested state needs no write. A pending, failed, uncertain, drifted, wrong-target, malformed, or later-divergent receipt must remain a conflict. For newly created onboarding prompts or options, a matching receipt may bind Discord-assigned IDs only while every ordered field and reference matches fresh state; ordinary planning must continue refusing implicit ID adoption.

For each reached unbound AutoMod rule, verify its existing receipt before inventory access. A matching completed receipt may bind and read only its exact receipt-bound rule. A missing receipt may check exact name collisions and proceed to disabled creation; every other receipt or live mismatch blocks. Exact existing rules must use direct ID lookup, and immutable trigger-type changes must block. Stage enabled policy changes through disable, configure, and optional enable, one fresh review per stage. Verify the selected stage receipt before asking its domain planner to reuse the derived operation key; a matching terminal stage may satisfy only the exact final state it proves, while mismatch, uncertainty, drift, or an intermediate-stage race blocks or requires a fresh plan. For each reached publication, likewise verify its component-message receipt before planning. Any mismatched, pending, failed, uncertain, malformed-target, missing-resource, or live-state-mismatch evidence must produce a content-free blocker and stop every later phase without elicitation or a write. Never scan inventories for recovery, trust a caller-supplied create result, or infer a managed resource from content.

Never persist the manifest, master operation key, symbolic keys, guild, role, channel, or AutoMod rule names, role permission intent, colors, role icons, channel metadata, AutoMod triggers, actions, exemptions, custom responses, prompt or option titles, descriptions, Unicode emoji, topics, component layouts or text, link destinations or origins, notification user IDs, audit reason, nested confirmation text, or a coordinator checkpoint. The coordinator must create no write, receipt, or recovery semantics of its own. Verification must rebuild fresh domain plans and return only content-free identities, hashes, phase states, exact resource, receipt-bound AutoMod rule, and receipt-bound message IDs without symbolic keys, fixed receipt and verifier codes, blockers, and existing content-free domain evidence.

## 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.

## Forum posts

Do not add a forum-post shortcut that bypasses the capability gate, exact forum-channel allowlist, pinned bot identity, exact stable forum type, complete guild-role and forum-overwrite evidence, exact available and selected tag IDs, required and moderated tag checks, notification policy, process-keyed planning, signed interactive confirmation, write-aware client approval, final fresh-plan match, shared interaction limiter, atomic one-shot operation-key reservation, pending activity journaling, single POST, or exact thread and starter-message readback. If a client cannot support MCP elicitation, keep forum-post execution unavailable in that client.

Keep the surface to one public thread and one plain-text starter message in a stable `GUILD_FORUM` channel. Do not silently add media channels, files, embeds, components, stickers, fuzzy tag lookup, private or standalone threads, edits, locks, archive actions, pins, tag administration, deletion, retry, rollback, or reconciliation. Each excluded capability needs its own evidence, policy, confirmation, and recovery design.

Require complete `VIEW_CHANNEL`, `READ_MESSAGE_HISTORY`, and `SEND_MESSAGES` evidence on the exact parent forum. Discord ignores `CREATE_PUBLIC_THREADS` for this operation. Require `MANAGE_THREADS` whenever any selected exact tag is moderated. Validate the forum's complete bounded overwrite and available-tag arrays, unique IDs, guild identity, `REQUIRE_TAG`, setting bounds, bot member identity, and complete guild-role inventory before returning a plan.

Suppress every notification by default. Allow only exact user IDs already present as visible mentions in the starter content and separately configured in the notification allowlist. Never enable role, `@everyone`, or `@here` notification through this workflow.

Exclude the raw operation key from plan material, signed request state, activity, receipts, results, and errors while binding its domain-separated hash into the plan. The title, starter content, tag IDs and names, notification user IDs, forum name, audit reason, roles, and overwrites may appear in the reviewed plan but must never enter persistent records. Forum-post activity and receipts may contain only exact guild, parent forum, created thread and starter-message IDs, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category.

Discord supplies no nonce or idempotency token for a forum starter message. Keep the MCP execute tool non-idempotent, disable automatic REST retry, and make the key permanently spent once reserved. A transport failure, Discord 5xx response, malformed success, or failure after any valid thread ID is observed is uncertain and must be treated as potentially completed. Never delete a thread as compensation. Require operator inspection of the exact forum and Discord audit log before a new reviewed intent uses a new key.

Serialize the same exact forum and normalized logical title across operation keys inside one process as defense in depth. The production facade also acquires a durable exact forum-channel claim, so connector processes sharing the activity-state root exclude overlapping forum-post creation and retain the claim after uncertainty. Do not imply title uniqueness; Discord permits duplicate titles.

Validate the nested starter message in Discord's create response, then fetch the exact thread and starter message using the shared ID. Require the expected guild, parent, public-thread type, bot owner and author, regular message type, active unlocked state, no webhook, attachment, or component payload, and valid bounded settings. Return only fixed drift-field names when safe readback differs, never observed content.

## Thread creation

Do not add a general thread-creation shortcut that bypasses the capability gate, exact parent-channel allowlist, pinned bot identity, strict mode-specific request, exact parent and optional source IDs, complete guild-role and parent-overwrite evidence, process-keyed planning, signed interactive confirmation, write-aware client approval, final fresh-plan match, shared interaction limiter, atomic one-shot operation-key reservation, pending activity journaling, single POST, or exact readback. If a client cannot support MCP elicitation, keep thread-creation execution unavailable in that client.

Keep the surface to message-anchored creation in text or announcement parents and explicit standalone public or private creation in text parents. Reject forum and media parents, starter messages, files, tags, notifications, lifecycle or membership changes, edits, deletion, retries, rollback, and reconciliation. Require `VIEW_CHANNEL` and the exact mode's `CREATE_PUBLIC_THREADS` or `CREATE_PRIVATE_THREADS`; anchored creation additionally requires `READ_MESSAGE_HISTORY` and an exact fresh source-message snapshot.

Bind the exact application and bot identity, guild, parent, source snapshot, existing anchored thread, member roles, complete role and overwrite inventories, effective permissions, resolved defaults, desired settings, audit reason, and domain-separated operation-key hash into the plan. Exclude the raw key from plan material and signed request state. The reviewed plan may transiently contain untrusted names, source content, profiles, and attachment metadata, but none may enter activity records or operation receipts.

Treat an existing valid thread at the deterministic source-message ID as a no-op without confirmation, key reservation, activity, or mutation. For a real write, reserve and journal before the one non-retried POST. Require an exact bot-owned, active, unlocked response and fresh readback. Report only fixed drift fields when Discord adjusts safe settings.

After an ambiguous anchored write, recover only through the deterministic source-message ID and only when every expected identity and setting matches. Never infer standalone success from a logical name or channel listing. Permanently block the same normalized standalone target inside the direct service instance after uncertainty. The production facade also acquires a durable exact parent-channel claim, so connector processes sharing the activity-state root exclude overlapping thread creation and retain the claim after uncertainty. Never compensate by editing or deleting a possibly created thread.

## Thread state and governance

Keep exact thread-state audit behind its own toggle plus non-empty exact guild and thread allowlists. Do not derive authority from ordinary thread listing, a readable parent, thread creation, forum-post creation, pin management, permission-overwrite management, or Gateway events. Require a separate exact user allowlist for membership reads and actions. Verify pinned identities, exact guild ownership, strict thread and supported parent identity, exact connector membership, complete bounded roles and parent overwrites, effective inherited permissions, and known lifecycle metadata before returning a state or plan.

Return only bounded untrusted names, exact IDs, supported lifecycle fields, membership booleans and nullable join times, complete permission evidence, discarded unknown-field counts, and fixed privacy claims. Never enumerate members or return messages, member counts, message counts, last-message IDs, applied tags, flags, thread timestamps, raw permission summaries, embedded guild members, unknown-field values, or raw Discord payloads. Request exact thread membership without embedded guild-member hydration, and fetch an optional target profile only through the exact guild-member endpoint. Treat an exact thread-member 404 as absence only after the exact thread, parent, guild, connector identity, and inherited access evidence have succeeded; every other member-lookup failure remains an error, and a thread GET 404 never proves a no-op. Do not cache, persist, journal, or export a thread-state or membership read.

Keep rename, archive, unarchive, lock, unlock, auto-archive, slowmode, invitation-policy, member-add, and member-remove changes behind an independent toggle and a strict action-specific schema. Each metadata PATCH must contain exactly one supported field. Permit invitation-policy changes only on private threads. Reject bulk operations, member listing, self join or leave, deletion, applied-tag changes, pin changes, message edits, multi-field PATCH requests, retry, rollback, compensation, and reconciliation.

Require complete `VIEW_CHANNEL` evidence for every real change. Require `MANAGE_THREADS` for rename, archive, auto-archive, lock, unlock, slowmode, and invitation-policy changes; and require exact connector membership plus `SEND_MESSAGES_IN_THREADS` for unarchive, with `MANAGE_THREADS` when the thread is locked. Member addition also requires `SEND_MESSAGES_IN_THREADS`, connector membership or `MANAGE_THREADS`, and complete target parent visibility, with `MANAGE_THREADS` required when a private thread is non-invitable. Member removal requires `MANAGE_THREADS` or exact connector ownership of a private thread. A real removal must reject protected users, the guild owner, and administrators. Fail closed on archived or locked state where the requested action is unsafe, unknown metadata fields, unknown permission bits, incomplete roles or overwrites, malformed memberships, unsupported relationships, mismatched IDs, or absent action-specific evidence.

Do not add an immediate-call path. Preserve every gate: exact policy, pinned identity, strict minimized evidence, action-specific authority, protected-target checks, process-keyed planning, signed interactive confirmation, write-aware host approval, final fresh-plan match, atomic one-shot operation-key reservation, pending content-free activity, one non-retried write, strict response validation where Discord returns state, and exact state or membership readback. A verified already-current request must reserve nothing, journal nothing, request no confirmation, and issue no write. A client without MCP elicitation must not execute thread changes.

Bind the normalized action-specific request, verified application and bot, exact guild, parent and thread, connector and optional target membership, complete roles and overwrites, supported current lifecycle state, complete permission and authority evidence, privacy projection, audit reason, and domain-separated operation-key hash into the plan. Any relevant identity, relationship, membership, role, overwrite, lifecycle, permission, desired value, reason, or key change must invalidate review. Keep the raw operation key out of plan material and signed request state.

Reserve and journal before dispatching one PATCH, PUT, or DELETE. Never retry a write. Validate a returned PATCH response and then perform exact fresh state or membership readback. Report a controlled success with safe unrelated lifecycle divergence as completed with drift. Only a known pre-write Discord 4xx refusal may settle as failed. Treat rate limits, transport or server errors, malformed or mismatched success, readback failure, local finalization failure, or any other indeterminate post-reservation result as uncertain and potentially completed. Spend every reserved key permanently and serialize exact guild and thread targets inside one process as defense in depth. The production facade acquires a durable exact thread claim plus an exact member claim for membership actions, so connector processes sharing the activity-state root exclude overlapping changes and retain the claims after uncertainty.

Thread-governance activity and operation records may contain only the action, exact guild and thread IDs, optional target user ID, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. Never persist parent IDs, thread or member names, lifecycle values, membership timestamps, role or permission evidence, audit reasons, raw operation keys, Discord responses, or transport causes. Discord does not document an audit-log reason header for thread-member endpoints, so never claim that a member PUT or DELETE wrote its transient reviewed reason to Discord's audit log.

## Role creation

Do not add a role-creation shortcut that bypasses the capability gate, exact creation-guild allowlist, pinned bot identity, exact guild ID, complete role inventory, effective permission and strict hierarchy evidence, requested-permission subset, capacity and logical-name checks, process-keyed planning, signed interactive confirmation, write-aware client approval, final fresh-plan match, atomic one-shot operation-key reservation, pending activity journaling, single POST, or exact role readback. If a client cannot support MCP elicitation, keep role creation unavailable in that client.

Keep this surface additive-only. Do not silently expand it to role edits, moves, assignments, deletion, rollback, icons, emoji, gradients, or permission reconciliation. Never permit `ADMINISTRATOR`, and require every named permission to be present in the bot's complete effective guild permission set. Treat mentionable and high-risk permissions as explicit review warnings.

Validate a complete role inventory with exactly one valid `@everyone` role, unique IDs, arbitrary-width permission bitfields, Discord's solid `colors` object, managed-role provenance, and the documented guild-role bound. Fail closed on malformed evidence, unknown member role IDs, missing `MANAGE_ROLES`, a bot role no higher than `@everyone`, ambiguous logical-name matches, managed-role collisions, conflicting existing roles, or exhausted capacity.

Exclude the raw one-shot operation key from the role plan material, signed request state, activity log, receipts, results, and errors. Bind its domain-separated hash into the plan and reserve that hash durably before the write. A reserved key remains spent after every outcome, including known failure, local record failure, or uncertainty. The MCP execute tool must remain non-idempotent, and neither the REST client nor any wrapper may automatically retry the create-role POST.

Serialize the same guild and normalized logical role name across operation keys inside one process as defense in depth. Rebuild each queued plan after the preceding execution and block the queued request without reserving its key if that write ends uncertain. The production facade also acquires a durable exact guild roles-collection claim, so connector processes sharing the activity-state root exclude overlapping role creation and retain the claim after uncertainty. Do not imply logical-name uniqueness; Discord permits duplicate role names.

Never persist role names, named permission lists, colors, audit-log reasons, raw keys, or raw Discord responses. Role-creation activity and operation records may contain only the exact guild and created-role IDs, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category.

## Role configuration

Do not add a role-configuration shortcut that bypasses the dedicated capability gate, exact role allowlist, existing guild read scope, pinned application and bot identities, exact guild and role IDs, complete role inventory, complete role-holder counts, effective and post-change permission evidence, strict hierarchy and logical-name checks, process-keyed planning, signed interactive confirmation, write-aware client approval, final fresh-plan match, atomic one-shot operation-key reservation, pending activity journaling, one partial PATCH, complete response validation, or exact role, full inventory, and holder-count readback. If a client cannot support MCP elicitation, keep role configuration unavailable in that client.

Keep the surface partial and exact. Permit only an explicit role name, modern colors, hoist, mentionability, and named permission grant or revoke deltas. Preserve omitted fields and unrelated permission bits. Never target `@everyone` or a managed role, and never add deletion, reordering, assignment, creation, icons, Unicode emoji, bulk reconciliation, or raw permission-bitfield input. Allow `ADMINISTRATOR` revocation but reject every attempted grant.

Validate exactly one `@everyone` role, unique role IDs, arbitrary-width permission bitfields, modern color structure, managed-role provenance, bounded role inventory, exact connector membership, and the complete role-holder-count map. Require the target to be a configured standard unmanaged role strictly below the connector's highest role. Fail closed on unknown target fields, invalid modern colors, missing `MANAGE_ROLES`, unknown permission bits during a permission change, a complete desired known-permission set outside the connector's effective permission set when the permission bitfield would change, or a change that would remove the connector's own `MANAGE_ROLES` authority. Metadata-only changes may preserve existing permissions outside the connector's grantable set, but the plan must report that fact and must not include the permission field in the PATCH. Surface every logical-name collision as an explicit warning while retaining exact-ID targeting. Return only an aggregate affected-member count and never enumerate member identities for impact review.

Exclude the raw operation key from plan material, signed request state, activity, receipts, results, and errors while binding its domain-separated hash into the plan. Bind the verified identities, exact guild, connector membership and authority, full normalized role inventory, full holder-count map, current and desired target, requested and effective permission deltas, name collisions, impact, risks, and warnings. Reserve the hash durably before the write and permanently spend it after every outcome, including known failure, local record failure, or uncertainty.

Send one non-retried PATCH containing changed fields only and validate the complete returned role. Then fetch the exact role, complete role inventory, and role-holder counts again. Return `completed-with-drift` for safe observed divergence. Treat a transport error, Discord 5xx response, malformed response, or any failure after a response may have been applied as uncertain and potentially completed. Never retry, compensate, or roll back automatically.

Serialize the same exact guild and role across operation keys inside one process as defense in depth. The production facade also acquires durable exact role and guild roles-collection claims, so connector processes sharing the activity-state root exclude overlapping role configuration and retain the claims after uncertainty. Persist only exact guild and role IDs, requested field names, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. Never persist role names, colors, permissions, member counts or identities, audit reasons, raw keys, or raw Discord responses.

## Role deletion

Keep role retirement behind `capabilities.roleDeletionAudit`, a non-empty exact `scopes.roleDeletionIds` allowlist, exact `readScope.guildIds`, pinned application and bot identities, `gateway.enabled`, and the separate `role-deletion` toolset. Require `capabilities.roleDeletions` in addition to the audit gate before execution. Only those selected-document fields grant role-deletion authority. A general guild, role-read, role-creation, role-configuration, role-assignment, role-ordering, scaffold, integration, invite, onboarding, AutoMod, command, or overwrite scope grants no role-deletion authority.

Do not add a shortcut that bypasses literal irreversible-role-loss acknowledgement, an exact signed recovery binding with caller-retention and limitation acknowledgement or explicit no-artifact acknowledgement, exact guild and role IDs, complete unobfuscated Gateway and HTTP channel evidence, exact guild and connector membership, complete normalized role inventory, aggregate holder counts, complete `MANAGE_ROLES` and `MANAGE_GUILD` evidence, strict hierarchy, complete discoverable dependency inventories, process-keyed planning, signed interactive confirmation, write-aware host approval, repeated fresh-plan matching, durable evidence-domain coordination, atomic one-shot reservation, pending content-free activity, one non-retried exact-ID DELETE, fresh target-absence proof, or surviving-role and dependency preservation. If a host cannot support MCP elicitation, keep execution unavailable through that host.

Permit only one configured standard unmanaged role with zero holders and a position strictly below the connector. Reject `@everyone`, managed roles of every provenance, absent targets, nonzero holder counts, insufficient or unknown permission evidence, incomplete or obfuscated channel topology, unknown relevant fields, and any target reference in channel permission overwrites, invite role grants, guild-emoji restrictions, onboarding options, AutoMod exemptions, integrations, or this application's guild-command permissions. Return only blocker kinds and counts while keeping dependency identifiers private inside the keyed evidence digest.

Do not claim complete semantic impact. Discord exposes no complete bounded search for historical role mentions, Guild Template snapshots cannot be inventoried at role-reference granularity, and command-permission evidence covers only the verified current application. Surface these blind spots in every readiness result, plan, confirmation, and static safety explanation. Never fetch message content or template snapshots to approximate them, and never clean a dependency automatically.

For a signed recovery binding, verify the process-local HMAC, fixed 30-minute lifetime, verified application, bot, guild, resource kind, exact role ID, and fresh complete normalized role-projection digest. Reject a forged, expired, cross-process, identity-mismatched, target-mismatched, wrong-kind, or stale attestation. Bind the exact request without the raw operation key or attestation, its domain-separated operation-key hash, attestation hash where present, verified credential-free recovery projection, verified identities, guild and owner, connector membership and authority, full role inventory and relative order, full holder-count map, target, complete normalized dependency inventory, coherent layout evidence, audit reason, irreversible and recovery acknowledgements, privacy boundary, risks, and warnings into the plan. Signed confirmation state must carry only the attestation hash, never the raw value. Rebuild before confirmation, before durable coordination, and before reservation. Any relevant drift must invalidate review without spending the key.

Reserve and journal before one DELETE with automatic retry disabled. Fresh complete evidence must show the target absent, every baseline surviving role semantically unchanged and in the same relative order, every survivor holder count unchanged, and every baseline dependency entry preserved. Report added-only roles or dependencies as completed with drift. Treat rate limits, transport or server errors, target survival, malformed evidence, changed or missing survivors, readback failure, receipt finalization failure, or any post-dispatch ambiguity as uncertain and potentially completed. Never retry, roll back, recreate the role, or infer success from a later 404.

Serialize same-guild role deletion inside one process and quarantine that guild after uncertainty. The production facade must acquire durable claims for the exact role and guild role, channel, invite, emoji, onboarding, AutoMod, integration, and application-command collections so connector processes sharing the activity-state root exclude overlapping evidence-changing workflows and retain those claims after ambiguity. Persist only exact guild and role IDs, aggregate baseline and observed role counts, target holder and blocker counts, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. Never persist role or guild names, permissions, dependency identifiers, channel layout, recovery attestations or blueprint content, audit reasons, raw keys, Discord responses, or transport causes.

## Role ordering

Keep hierarchy audit behind its own capability gate and non-empty exact guild allowlist. Require the guild scope to remain inside the read-guild boundary. Return a complete canonical low-to-high hierarchy with exact IDs, transient untrusted role names, raw positions, deterministic snowflake tie ordering, managed provenance, connector ownership, permission evidence, unknown-field counts, and aggregate holder counts. Never fetch member identities or cache, journal, export, or persist an audit result.

Do not add a role-ordering shortcut that bypasses the independent change toggle, audit gate, exact guild allowlist, pinned application and bot identities, exact distinct target and anchor IDs, complete role inventory, complete role-holder counts, connector membership, complete `MANAGE_ROLES` and strict hierarchy evidence, process-keyed planning, signed interactive confirmation, write-aware host approval, final fresh-plan match, durable whole-hierarchy coordination, atomic one-shot operation-key reservation, pending content-free activity, one non-retried PATCH, complete response validation, or full hierarchy and holder-count readback. If a host cannot support MCP elicitation, keep role-order execution unavailable through that host.

Keep the surface exact and relative. Permit only one standard unmanaged role immediately `above` or `below` one distinct standard unmanaged anchor. Never accept arbitrary numeric positions, fuzzy names, bulk moves, `@everyone`, managed roles, connector-held roles, metadata or permission edits, membership changes, creation, deletion, retry, rollback, compensation, or reconciliation. Require every role in the affected segment to remain standard, unmanaged, unheld by the connector, and strictly below the connector before and after the move. Fail closed on any unknown top-level field anywhere in the complete inventory for a real change. Preserve and expose unknown permission bits because the request never rewrites them.

Bind the normalized request without the raw operation key, its domain-separated hash, verified identities, exact guild and owner, connector membership and authority, complete normalized hierarchy, complete holder-count map, target, anchor, current and desired order, complete affected segment, hierarchy-sensitive permissions, impact, risks, and warnings into the plan. Any relevant identity, membership, role, order, metadata, count, permission, reason, target, anchor, placement, or key drift must invalidate review. A verified already-current request must acquire no coordination claim, reserve nothing, journal nothing, request no confirmation, and issue no write.

Reserve and journal before sending one PATCH containing only the target role ID and reviewed destination rank. Never retry. Validate the complete returned hierarchy, then fetch the complete hierarchy and holder counts again. Require the exact desired order and unchanged non-position role metadata. Report holder-count-only drift as completed with drift. Treat transport ambiguity, rate limits, server errors, malformed or incomplete success evidence, hierarchy or metadata mismatch, readback failure, durable operation-receipt finalization failure, or any other indeterminate post-reservation outcome as uncertain and potentially completed. Permanently spend the key and quarantine the whole guild hierarchy after uncertainty.

Serialize every role-order change for the same guild inside one process as defense in depth. The production facade must acquire durable exact guild roles-collection, target-role, and anchor-role claims so connector processes sharing the activity-state root exclude overlapping role ordering, configuration, creation, assignment, or scaffold operations and retain the claims after uncertainty. Persist only exact guild, target, and anchor IDs, relative placement, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. Never persist role names, ranks, permission evidence, holder counts or identities, audit reasons, raw operation keys, or raw Discord responses.

## Reactions

Keep aggregate reaction reads in ordinary readable-channel scope. Accept only one exact message ID and return strict canonical aggregates containing normal count, burst count, total count, structured emoji identity, and the verified connector's own normal and burst flags. Validate the complete known reaction shape, count relationships, emoji identity, duplicate absence, bounds, message identity, and supported channel type. Project out message content, authors, user identities, profiles, burst colors, unknown fields, and raw payloads before returning a result, and never cache or persist an aggregate snapshot.

Keep reaction-user pages behind their independent disabled-by-default gate and an exact channel or thread allowlist, and enforce both before any Discord request. Accept one strict Unicode grapheme containing an emoji code point or one exact `name:snowflake` custom emoji. Support normal and burst pages separately, require bounded responses, unique positive user IDs, strict ascending order after the exact cursor, and return only IDs and bot flags. Never expose or persist usernames, display names, avatars, profile fields, burst colors, queries, or raw user objects. An absent aggregate must return an empty page without calling the identity-bearing endpoint.

Keep the connector's own normal reaction changes in exact interaction scope. Read the exact message before changing state, return a journaled no-op without consuming the write limiter when the desired state already holds, write pending content-free activity before mutation, require Discord's exact no-content success status, and read the exact message again to prove the connector-owned flag. Never persist emoji text. Treat malformed or mismatched post-state as uncertain rather than success.

Do not add a reaction-moderation shortcut that bypasses the independent moderation toggle, exact reaction-channel allowlist, and protected-user check before any Discord request, pinned application and bot identities, connector-owned target exclusion before target access, exact message ID, complete role and overwrite evidence, private-thread membership, complete `VIEW_CHANNEL`, `READ_MESSAGE_HISTORY`, `MANAGE_MESSAGES`, and conditional `CONNECT` authority, strict scope-specific target, complete aggregate snapshot, process-keyed plan, signed interactive confirmation, write-aware host approval, final fresh-plan match, durable exact-message coordination, atomic one-shot operation-key reservation, pending content-free activity, one non-retried DELETE, target-absence proof, or exact aggregate readback. If a host cannot support MCP elicitation, keep reaction moderation unavailable through that host.

Limit moderation to three exact actions: remove one non-protected user's normal reaction to one emoji, clear all normal and burst reactions for one emoji, or clear every reaction from one message. Route connector-owned normal removal through the ordinary own-reaction tool. Treat emoji and all scopes as identity-blind: they can remove reactions from locally protected users, and protected-user IDs guard only exact user scope. Put this limitation in the keyed plan, warning list, and confirmation. Do not add fuzzy emoji or user resolution, names as write targets, batches across messages, reaction copying, automatic restore, retry, compensation, or rollback. An already-absent target must remain a record-free no-op.

Bind the strict request, complete aggregate snapshot, structured target, verified identities, guild ownership, message metadata, complete relevant permission evidence, transient local review reason, privacy projection, warnings, and domain-separated operation-key hash into the plan digest. The reason must never be sent as an audit-log header or persisted because Discord does not document reason support for reaction endpoints. Any relevant drift must invalidate approval before reservation.

Reserve and journal before one DELETE with automatic retries disabled. Prove the target absent afterward and report safe unrelated aggregate divergence as completed with drift. Only a known Discord 4xx rejection received without a success response, other than request timeout or rate limit, may settle as failed. Treat transport ambiguity, request timeout, rate limiting, server errors, malformed evidence, a surviving target, failed readback, or receipt finalization failure as uncertain and potentially completed. Permanently spend every reserved key and retain the exact-message claim after uncertainty until credential-free operator review resolves it.

Reaction-moderation activity may retain only exact guild, channel, message, target-user, and custom-emoji IDs, scope, a keyed emoji fingerprint, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. Operation receipts remain narrower. Never persist Unicode emoji text, custom emoji names, message content, authors, user profiles, burst colors, aggregate counts, permission evidence, local reasons, raw keys, raw Discord responses, or transport causes.

## Message pins

Keep pin listing read-only, bounded, exact-channel scoped, and on Discord's current timestamp-paginated message-pins endpoint. Do not fall back to the deprecated unpaginated pins route. Validate the page shape, item uniqueness, exact channel and guild identities, pinned booleans, and timestamps before returning normalized messages. Never cache or persist a pin page.

Do not add a pin or unpin shortcut that bypasses the capability gate, exact target-channel allowlist, verified application and bot identities, exact message ID, current pin state, complete role and overwrite evidence, exact private-thread membership, dedicated `PIN_MESSAGES` permission, process-keyed content-bound plan, signed interactive confirmation, write-aware client approval, final fresh-plan match, atomic one-shot key reservation, pending activity journaling, one non-retried mutation, or exact state and review-snapshot readback. Both desired states remain destructive because unpin removes shared state. If a client cannot support MCP elicitation, keep pin changes unavailable in that client.

Use the thread's validated parent only as its permission-overwrite source; never inherit mutation scope from that parent. Require all message-read prerequisites, including `CONNECT` for voice and stage channels. Fail closed on partial or malformed evidence and do not treat `MANAGE_MESSAGES` as an alternative to `PIN_MESSAGES`.

Bind the review-relevant message snapshot into the opaque process-keyed HMAC so message edits invalidate approval, but never persist message content, attachment metadata, author names, guild or channel names, audit reasons, raw keys, or raw Discord responses. Activity and operation records may contain only exact guild, channel, and message IDs, desired state, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category.

Serialize the same exact channel and message target across operation keys inside one process as defense in depth. The production facade also acquires durable exact channel-and-message claims, so connector processes sharing the activity-state root exclude overlapping changes and retain the claims after uncertainty. A known pre-write Discord 4xx may be classified as failed; every transport failure, Discord 5xx response, failed readback after mutation, or otherwise indeterminate outcome is uncertain. Permanently spend every reserved key and never retry or compensate automatically.

## Announcement crossposts

Do not add a crosspost shortcut that bypasses the dedicated capability gate, exact direct announcement-channel allowlist, confirmed Message Content intent, verified application and bot identities, exact message ID, complete content-bearing message evidence, known default message type, poll absence, non-forwarded reference, complete role and overwrite evidence, `VIEW_CHANNEL`, `READ_MESSAGE_HISTORY`, `SEND_MESSAGES`, authorship-sensitive `MANAGE_MESSAGES`, a process-keyed content-bound plan, signed interactive confirmation, write approval, final fresh-plan match, atomic one-shot key reservation, pending activity journaling, one non-retried POST, strict response validation, or exact fresh readback. If a client cannot support MCP elicitation, keep crossposting unavailable in that client.

Keep the target surface to direct `GUILD_ANNOUNCEMENT` channels. Do not accept threads, text channels, polls, forwarded messages, system message types, fuzzy message selection, batches, follower management, or destination selection. An already-crossposted message is a record-free no-op. Expose that Discord does not provide the follower count or destination channels to this operation, so review cannot enumerate or constrain fanout and the connector has no rollback endpoint.

Bind the exact application, bot, guild, connector membership, relevant roles, channel overwrites, effective permissions, authorship class, Message Content intent, full review-relevant message snapshot, flags, and operation-key hash into the opaque keyed digest. Never persist or export message content or unkeyed content hashes, attachment metadata or URLs, embeds, components, profiles, names, follower data, raw operation keys, raw responses, or transport causes. Activity and operation records may contain only exact guild, channel, and message IDs, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category.

Accept success only when the POST response and a fresh exact GET preserve the message identity, author, content, attachments, embeds, components, reference, timestamps, type, and unrelated flags, with the `CROSSPOSTED` bit as the only transition. Treat a known pre-response Discord 4xx as failed. Treat transport errors, Discord 5xx responses, malformed or mismatched responses, failed or drifting readback, and every other indeterminate outcome as uncertain. Never automatically retry, compensate, or claim fanout delivery.

Serialize the same exact channel and message across operation keys inside one process as defense in depth. The production facade also acquires durable exact channel-and-message claims across connector processes sharing the activity-state root. Retain those claims after uncertainty until credential-free exact operator review resolves the receipt; never use leases or elapsed time to infer safety.

## Message forwarding

Do not add an immediate message-forward shortcut or bypass the dedicated forwarding toggle, exact direct source and target channel allowlists, pinned application and bot identities, confirmed Message Content intent, exact source message ID, same-guild default boundary, separate cross-guild toggle, complete endpoint guild, member, role, channel, and overwrite evidence, source `VIEW_CHANNEL` plus `READ_MESSAGE_HISTORY`, target `VIEW_CHANNEL`, `READ_MESSAGE_HISTORY`, plus `SEND_MESSAGES`, process-keyed content-bound planning, signed interactive confirmation, write-aware MCP host approval, final fresh-plan match, durable exact-target coordination, atomic one-shot key reservation, pending content-free activity, one non-retried create request, or strict response and independent readback verification. If a client cannot support MCP elicitation, keep forwarding unavailable in that client.

Accept only two different exact direct `GUILD_TEXT` or `GUILD_ANNOUNCEMENT` channels and one exact default, reply, chat-input command result, or context-menu command result source. Reject threads, polls, calls, activities, unsupported system types, malformed or missing reply references, an existing immutable snapshot, the `HAS_SNAPSHOT` source flag, nested forward references, batches, fuzzy selection, name resolution, caller-supplied content, caller-supplied embeds or components, arbitrary payload fields, and automatic destination choice. An age-restricted source must have an age-restricted target, and the downgrade check must run before reading source content. Cross-guild forwarding must fail unless both guilds independently pass read scope and the separate boundary toggle is enabled.

Bind the strict request, operation-key hash, deterministic nonce, verified identities, Message Content intent, exact source reference, complete validated source-author object and source body, stable attachment metadata, embeds, components, mentions, stickers, both exact endpoint states including age restriction, relevant roles and overwrites, complete effective permissions and unknown bits, boundary decision, empty allowed-mentions policy, nonce enforcement, one-snapshot requirement, and notification suppression into the opaque process-keyed digest. Exclude only expiring attachment delivery URLs from the stable attachment projection. Recursively and aggregately bound every rich JSON projection, preserve hostile property names as ordinary digest-bound data, reject invalid Unicode or non-JSON values, require the exact documented snapshot wrapper, and fail closed on any malformed, oversized, or unexpected evidence.

Send only an exact type-`FORWARD` message reference with source guild, channel, and message IDs, `fail_if_not_exists`, the deterministic nonce with enforcement enabled, empty allowed mentions, and `SUPPRESS_NOTIFICATIONS`. Disable automatic rate-limit retries. Do not add outer content, attachments, embeds, components, stickers, mentions, reply behavior, caller-selected flags, or audit-log reasons. Accept the response only when it is an empty ordinary message authored by the verified bot in the exact target, contains the exact forward reference, exactly one snapshot equal to the reviewed stable source projection, and exactly the required `HAS_SNAPSHOT` plus `SUPPRESS_NOTIFICATIONS` flags. Require the same proof from an independent exact target-message read.

Classify only a known pre-response Discord 4xx refusal other than request timeout or rate limiting as failed. Treat request timeout, rate limiting, transport ambiguity, server errors, malformed or mismatched responses, snapshot drift, readback failure, receipt-finalization failure, or any otherwise indeterminate state as uncertain and potentially completed. Preserve a known target message ID in content-free uncertain evidence when available, permanently spend the key, retain the exact source-message and target-channel claims, and never automatically retry, delete the created message, compensate, or roll back. Notification suppression is not a confidentiality boundary and may still produce an unread badge.

Return only the bounded source preview, counts, minimized author and endpoint identity, delivery controls, permission decision, risks, and keyed digest needed for review. Never persist or send to observability source or snapshot content, attachment filenames or metadata, attachment URLs, embeds, components, stickers, mentions, profiles, guild or channel names, permission evidence, raw payloads, raw operation keys, response bodies, or transport causes. Activity may retain only exact source and target guild, channel, and message IDs, the deterministic nonce, plan digest, operation-key hash, timestamp, fixed outcome and verification values, activity ID, and sanitized error category. Keep generic message normalization snapshot-blind: return only a bounded snapshot count and explicit redaction marker, never a forwarded snapshot body.

## Announcement subscriptions

Keep announcement-subscription audit behind its own toggle and exact direct text-target allowlist, separate from generic webhook scope. Require verified application and bot identities, exact target guild ownership, complete bounded roles and overwrites, effective target `VIEW_CHANNEL` plus `MANAGE_WEBHOOKS`, and a complete bounded target webhook inventory. Never read a message for this workflow.

Project every target webhook internally to exact ID, normalized type, locally derived creation timestamp, and both Channel Follower source IDs only when Discord supplies both and local read scope permits both. Expose only aggregate capacity and the exact Channel Follower subset. Expose an unavailable source identity explicitly, redact an out-of-scope source identity explicitly, and reject a partial identity. Never return or persist unrelated webhook identifiers, webhook credentials, execution URLs, webhook names, avatars, creator or application metadata, webhook-embedded source names or icons, message data, unknown raw fields, or raw responses.

Keep changes behind a second toggle. Subscribe additionally requires an exact direct announcement-source allowlist, exact `GUILD_ANNOUNCEMENT` source and `GUILD_TEXT` target types, source `VIEW_CHANNEL`, complete source and target guild evidence, target capacity, and proof that no duplicate source subscription exists. Permit cross-guild following only when both guilds and channels independently pass scope and permission checks, and expose the boundary in review. If any existing Channel Follower webhook has unavailable or policy-redacted source identity, fail closed because duplicate absence cannot be proven. Return one exact existing source subscription as a no-op before confirmation, coordination, reservation, activity, or mutation.

Unsubscribe must accept only one exact Channel Follower webhook ID from the complete asserted target inventory. Do not delete by source identity, webhook name, ordinal, or fuzzy match. Permit exact-ID unsubscription when Discord no longer exposes source identity or when local read policy redacts it because exact target membership and type remain independently verifiable. Never accept an Incoming or application webhook through this workflow, and never remove already delivered messages.

Do not add an immediate mutation path. Bind the normalized action, one-shot key hash, verified identities, exact source and target evidence when applicable, complete minimized target inventory, permissions, privacy projection, risks, and warnings into the process-keyed digest. Require a signed interactive confirmation, write-aware host approval, final fresh-plan equality, durable target and guild-webhook-collection coordination plus source-channel or exact-webhook coordination as applicable, atomic key reservation, and pending content-free activity before one non-retried mutation.

For subscribe, send only the exact target channel ID and reviewed audit reason to Discord's follow endpoint, validate the returned source channel and new webhook ID, and require a complete readback containing that exact follower plus every prior entry. For unsubscribe, send one exact bot-authenticated webhook DELETE and require complete readback proving the target absent and every survivor unchanged. Report unrelated but valid inventory drift rather than hiding it. Treat transport failure, rate limiting, server failure, malformed response evidence, failed or conflicting readback, or any otherwise indeterminate post-reservation state as uncertain and potentially completed. Permanently spend the key, retain durable claims after uncertainty, and never retry, guess, compensate, or recreate automatically.

Activity, receipt, and coordination records may contain only exact source, target, guild, and webhook IDs where applicable, plan digest, operation-key hash, timestamps, fixed action, outcome, and verification values, activity ID, sanitized error category, operation kind, and coordination metadata. Never persist channel or guild names, audit reasons, raw operation keys, webhook metadata beyond these exact IDs, permission evidence, raw responses, or transport causes.

## Native polls

Keep poll audit behind a dedicated toggle and exact channel or thread allowlist. Parent-channel scope must never grant poll authority to a child thread. Require supported guild-channel types, verified identity, and exact guild ownership for reads. For reviewed writes, require complete bounded roles and overwrite evidence plus complete read permissions, including `CONNECT` for voice and stage channels. Creation additionally requires `SEND_POLLS`, the correct direct-channel or thread send permission, and an active unlocked thread when applicable. Keep voter audit behind a second toggle and return only bounded strict-ascending user-ID pages without profile fields.

Treat question text, answer text, emoji, and counts as untrusted transient data. Never cache, persist, journal, log, or export them or any voter identity. Preserve Discord answer IDs without assuming they are sequential. Distinguish missing results from zero votes, unfinished approximate counts from finalized counts, and an unknown lifecycle from an active poll. Fail closed on malformed identities, timestamps, layout, answers, counts, ordering, duplicates, limits, or result relationships. Count unknown response fields and prohibit poll ending until the connector understands every field that could affect destructive review.

Do not add a poll-creation shortcut that bypasses the audit and creation toggles, exact target allowlist, identity pins, complete permission evidence, bounded immutable request, process-keyed plan, signed interactive confirmation, write-aware host approval, final fresh-plan match, shared interaction limiter, atomic one-shot operation-key reservation, pending content-free activity, nonce enforcement, one non-retried POST, complete response validation, or exact message readback. Permit only plain poll media, optional Unicode answer emoji, bounded integer duration, and optional multiselect. Do not add custom emoji creation, message content, mentions, attachments, embeds, components, stickers, edits, app voting, automatic retry, compensation, or rollback without a separate threat model.

Keep poll ending behind its own toggle and limit it to an exact non-webhook poll message authored by the verified bot. Treat ending as destructive because Discord provides no reopen operation. Bind the complete poll structure, lifecycle, and live counts into the keyed digest so a vote change invalidates approval. Return an already-ended poll as a no-op before elicitation and reservation. Otherwise require signed confirmation, fresh-plan equality, one-shot reservation, pending activity, one non-retried expire request, exact response validation, and finalization-aware readback. Never report unfinished asynchronous tallying as final.

Exclude the raw operation key from plan material, signed request state, records, results, and errors while binding its domain-separated hash into each plan. Persist only exact guild, channel, message, application, and bot IDs, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. Serialize creation per exact channel and ending per exact message inside one process as defense in depth. The production facade also acquires a durable exact channel claim for creation and durable exact channel-and-message claims for ending, so connector processes sharing the activity-state root exclude overlapping poll writes. Permanently spend every reserved key after success, known failure, local recording failure, or uncertainty. Treat transport errors, Discord 5xx responses, malformed successes, or failed post-write verification as uncertain and potentially completed. Retain the claims after uncertainty and never retry or compensate automatically.

## Webhooks

Keep webhook inventory behind its own capability gate and exact direct-channel allowlist. The allowlist must remain a subset of any configured read-channel scope. Require a supported guild channel, verified application and bot identities, a complete bounded channel webhook listing, complete guild-role and channel-overwrite evidence, and effective `VIEW_CHANNEL` plus `MANAGE_WEBHOOKS` permission before returning an inventory or plan. Parent scope must never grant webhook access to a child thread.

Project Discord webhook responses immediately to exact IDs, type, bounded name, channel and guild IDs, application ID, creator ID, and a creation timestamp derived locally from the webhook snowflake. Reduce the accompanying channel to its exact ID, guild ID, bounded name, parent ID, numeric type, and fixed type name; omit topics, forum metadata, message state, and raw overwrite bodies from the result. Never return a webhook token, execution URL, private credential path, avatar, creator profile, source object, or unknown raw field. Creation must validate the credential-bearing Discord response and pass the token directly into private connector custody before any public service result can be formed. Never add an MCP argument that accepts a token, complete execution URL, credential path, identity override, or raw webhook payload.

Keep creation, change, and deletion behind independent capability gates in addition to webhook audit, and do not add an immediate-call path. Preserve every gate for an actual write: verified identities, exact scope, complete permissions, process-keyed plan binding, signed interactive confirmation, write-aware client approval, final fresh-plan match, durable affected-target coordination, atomic one-shot key reservation, pending activity journaling, one non-retried mutation, strict response validation when a response exists, and fresh complete-inventory readback. Application webhooks remain inventory-only. Channel Follower creation and deletion belong only to the dedicated announcement-subscription workflow with its separate source and target scope.

Creation may add only one strict bounded-name Incoming webhook to a non-full exact channel inventory. Require its plan to bind capacity, the desired name and type, the complete credential-redacted inventory, permission evidence, credential omissions, and durable bearer-capability risks. Require one configured existing canonical process-owned `0700` credential root. After reservation and pending activity, send one non-retried bot-authenticated POST, require a valid token-bearing response, reserve only `<webhookId>.token` without following links, require a single-link process-owned `0600` regular file, write one bounded newline-terminated UTF-8 token, synchronize the file and containing directory, and verify the created webhook plus every prior inventory member through a fresh complete readback. If Discord identifies the created webhook but private custody fails, return an uncertain content-free orphan result containing the webhook ID so the operator can remediate it; never expose the token or raw storage cause.

Changes may rename, move within one exact guild, or combine both only for one exact Incoming webhook discovered in its asserted current channel. Require both source and destination to be separately allowlisted, supported, non-full where capacity is consumed, and proven through complete inventories and channel-level permissions. Bind exact current and desired metadata, requested and changed fields, both inventories, capacity, credential omissions, and the fact that a move preserves the existing bearer credential while redirecting future external deliveries. Return an exact already-current no-op without confirmation, reservation, activity, or mutation. Otherwise send one non-retried bot-authenticated PATCH and require exact response, destination readback, source absence for a move, and complete non-target inventory evidence.

Deletion must remain limited to one exact Incoming webhook from its asserted complete source inventory. Send one non-retried bot-authenticated DELETE and require a fresh complete inventory proving exact absence. Only after verified Discord absence may the connector inspect and unlink that exact webhook ID's private credential file and synchronize the containing directory. A missing or unconfigured credential is safe; a cleanup failure is local drift and must not obscure the independently proven remote absence. Never remove a credential when the webhook survives or the remote outcome is uncertain. Discord's modify and delete routes are addressed by webhook ID rather than by channel and webhook together. Treat the final inventory-to-mutation interval as an unavoidable external race because Discord supplies no channel-qualified conditional write. Keep `MANAGE_WEBHOOKS` denied outside exact selected channels, surface the limitation and move consequences in every applicable plan, and require exclusive webhook administration for a high-risk integration.

Keep credential-authenticated webhook message actions behind independent lookup, delivery, edit, and deletion capability gates plus one exact direct text or announcement channel allowlist. Editing and deletion require lookup authority; delivery remains independently selectable. Resolve only an exact webhook ID to an exact private credential file, authenticate one live Incoming webhook, require its guild and channel to match exact bot-readable channel evidence, and reject threads, forum and media parents, voice and Stage channels, direct messages, unsupported webhook types, or parent-derived scope. Keep all credential paths and execution URLs inside the connector.

Exact lookup may return bounded transient untrusted message content and stable identity, time, flag, boolean, and rich-payload count evidence. Omit author profiles, attachment URLs, embed and component bodies, stickers, poll bodies, raw payloads, and unknown fields. Plain-text delivery and editing must accept no username or avatar override, TTS, thread target, forum parameter, embed, component, file, attachment, poll, sticker, raw flag, or raw mention object. Permit only separately allowlisted visible user notifications, disable role and everyone parsing, suppress embeds, use the shared per-channel anti-spam limiter, reserve a stable one-shot intent before one non-retried mutation, validate the exact response, and perform independent exact readback. Reject editing a rich target. Allow a record-free edit no-op only for exact plain-text state with no requested notification.

Webhook message deletion must have no immediate-call path. Bind the verified application and bot, exact guild, direct channel, Incoming webhook, complete projected message content and metadata, transient local review reason, privacy boundary, one-shot operation-key hash, warnings, and every displayed untrusted guild label into a process-keyed plan. Require signed interactive confirmation and rebuild the plan immediately before mutation. Recheck the final webhook target against the reviewed target, coordinate the exact webhook and message, reserve the key, write pending content-free activity, send one non-retried token-authenticated DELETE, and accept absence only from an exact message 404 followed by a still-valid webhook credential pinned to the reviewed guild and channel. Discord accepts no guild audit-log reason on this route, so never send or persist the local review reason. When rich bodies are omitted, bind their displayed counts or presence and explicitly warn that same-count internal rich-payload changes remain outside review evidence.

Persist webhook credentials only in the dedicated exact-ID private files described above. Never persist webhook names, execution URLs, private paths, avatars, creator profiles, source objects, audit-log or local review reasons, message content, notification-user IDs, standalone content hashes, raw operation keys, permission evidence, raw responses, or transport causes. Content-free activity, operation, and coordination records may contain only the exact Discord IDs needed for review, process-keyed plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, sanitized error category, operation kind, and coordination metadata.

A known pre-write Discord 4xx may be classified as failed. Treat rate limiting, transport failure, Discord 5xx, malformed or mismatched success, failed readback, or any otherwise indeterminate post-reservation state as uncertain and potentially completed. Spend every reserved key after every outcome and never retry, roll back, recreate, or compensate automatically. Serialize creation by exact channel and administration changes or deletion by exact webhook inside each process as defense in depth. Serialize private message sends by exact webhook and edits or deletion by exact webhook plus message. The production facade acquires the corresponding durable affected-channel, exact-webhook, exact-message, and guild-webhook-collection claims, so connector processes sharing the activity-state root exclude overlapping writes and retain those claims after uncertainty.

## Guild integrations

Keep guild integration inventory 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 role evidence, a strict bounded integration response, and effective guild-level `MANAGE_GUILD` before returning an inventory or plan.

Project each Discord integration immediately to exact integration, role, application, and associated bot IDs; normalized type; bounded lifecycle and synchronization properties; recognized OAuth scope names; count-only unknown scopes and fields; and an explicit privacy contract. Never return integration, external account, application, user, or bot names or profiles, external account IDs, descriptions, icon hashes, raw payloads, or unknown field values. Preserve a future integration type as `unknown` for audit and never infer its semantics.

Discord's integration endpoint has a hard maximum and no pagination. Mark a response at that boundary as incomplete and prohibit every deletion from an incomplete inventory. Reject responses above the bound, duplicate identities, malformed timestamps or fields, unsorted or duplicate normalized scopes, and any evidence that cannot support one canonical privacy-safe snapshot.

Keep deletion behind a second capability gate plus exact guild and integration allowlists. Do not add an immediate-call path. Keep `guild_subscription` integrations audit-only. Fail closed when any inventory entry has an unknown type, OAuth scope, or field because privacy-discarded evidence cannot be reviewed safely. Protect the connector's own application and bot identities and every configured protected associated bot.

Discord deletion removes associated webhooks and can kick an associated bot, while the API does not expose the exact affected webhook set. Require explicit acknowledgment of webhook removal for every request and a separate bot-kick acknowledgment whenever the target names an associated bot. Verify that bot's exact current membership without member enumeration. Acknowledgments record informed intent but must never weaken identity, scope, permission, freshness, approval, reservation, activity, coordination, or readback requirements.

Bind the exact normalized request, one-shot key hash, pinned identities, guild owner, connector member and roles, complete permission evidence, full projected integration inventory, target, associated-bot membership, privacy projection, acknowledgments, and warnings into the process-keyed plan. Rebuild the complete plan before signed interactive confirmation and immediately before mutation. A client without MCP elicitation must not execute integration deletion.

After durable coordination, atomically reserve the operation key and append pending content-free activity before one non-retried DELETE carrying the reviewed audit reason. Claim the exact integration, guild integration collection, guild webhook collection, and associated bot member when present. Fetch a complete fresh inventory after the write and report completion only when the target is absent and every non-target projection is unchanged. Discord supplies no conditional deletion primitive, so treat the final inventory-to-delete interval as an unavoidable external race and require an exclusive administration window for high-risk changes.

A known Discord client refusal other than request timeout or rate limiting may settle as failed. Treat transport failure, rate limiting, server failure, malformed evidence, incomplete or drifting readback, or any otherwise indeterminate post-reservation state as uncertain and potentially completed. Spend every reserved key, retain durable claims and the process-local same-guild quarantine after uncertainty, and never retry, reinstall a bot, recreate a webhook, or compensate automatically.

Integration-deletion activity and operation records may contain only exact guild, integration, target application, and associated bot IDs, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. Never persist names, external account identities, profiles, descriptions, icon hashes, audit reasons, raw operation keys, unknown OAuth values, raw responses, permission evidence, or transport causes. Mark integration list and deletion REST operations content-sensitive so response bodies and external error details cannot enter diagnostics.

## Guild departure

Keep connector departure behind its own capability, dedicated `guild-departure` toolset, exact guild allowlist, and outer read-guild scope. Do not add an immediate, name-targeted, permission-inferred, or generic administration path. Require the caller to acknowledge immediate access loss, separate Discord-side re-entry, and a stopped-work window for every connector and external operation against the target guild.

Verify the pinned application and bot before collecting an exact guild, exact bot member, and complete bounded current-user guild inventory. Require one unique target, strict agreement on its transient name and ownership evidence, exact bot-member identity, complete bounded bot roles, and proof that the bot is not the guild owner. Reject missing, duplicate, cursor-violating, incomplete, over-bound, malformed, or inconsistent evidence. Project every other guild identity and all raw payloads out immediately.

Bind the complete normalized request, hashed one-shot key, pinned identities, bot roles, exact target and non-ownership, complete inventory shape, acknowledgments, privacy contract, transient local reason, and warnings into a process-keyed plan. Rebuild it before signed interactive confirmation, before durable coordination, and again inside the acquired claims. Require write-aware host approval and exact matching request state. A client without MCP elicitation must not execute departure.

Claim every modeled guild collection for the exact guild before reserving the operation key. Those claims exclude overlapping collection-wide workflows only when connector processes share one canonical activity-state root on a local filesystem. They cannot infer every exact resource-only workflow or external Discord actor, so never present coordination as a substitute for the explicit stopped-work acknowledgment. Keep the target guild quiescent from planning until a terminal result.

Reserve the one-shot key and append pending content-free activity before one non-retried `DELETE /users/@me/guilds/{guild.id}`. Accept completion only after a complete fresh current-user guild inventory proves the exact target absent. Discord accepts no audit-log reason on this route, so never send or persist the local review reason.

A known pre-mutation Discord client refusal other than request timeout or rate limiting may settle as failed. Treat rate limiting, transport failure, server failure, malformed success evidence, target presence, incomplete readback, receipt-finalization failure, or any other indeterminate post-reservation result as uncertain and potentially completed. Spend every reserved key, retain unsafe durable claims, keep a process-local same-guild departure quarantine, and never retry, reinstall, invite, compensate, or roll back automatically.

Departure activity and operation records may contain only the exact application, bot, and guild IDs, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. Never persist guild names, other guild identities, member profiles, role names, permissions, local review reasons, raw operation keys, raw responses, or transport causes.

## Invites

Keep guild invite inventory behind its own audit toggle and exact guild allowlist. The allowlist must remain a subset of any configured read-guild scope. Require verified application and bot identities, an exact guild and owner, exact connector membership, complete bounded roles and channels, a complete bounded invite inventory, and effective guild-level `MANAGE_GUILD` before returning an inventory or plan. Do not add a reduced `VIEW_AUDIT_LOG` mode because Discord withholds complete invite metadata without `MANAGE_GUILD`.

Keep creation behind a separate capability gate, exact direct-channel allowlist, and private capability-root allowlist. Require finite positive lifetime and use limits, forced uniqueness, explicit temporary-membership intent, an audit reason, one-shot operation key, bearer-capability acknowledgment, exact `VIEW_CHANNEL` and `CREATE_INSTANT_INVITE` evidence, plus guild-level `MANAGE_GUILD` for exact-user acceptance, a fresh canonical absent output target, process-keyed planning, signed approval, write-aware host approval, durable exact-channel and guild invite-collection coordination, pending content-free activity, one non-retried POST, strict response evidence, exact readback, and exclusive process-owned `0600` file delivery. Never return the created code or URL through MCP.

Keep invite role assignment behind an additional capability, a nonempty exact role allowlist, and enabled nonprivileged Gateway layout evidence. Require a tagged exact role set, explicit persistent-grant acknowledgment, `MANAGE_ROLES`, one unambiguous connector highest role, strict hierarchy, standard unmanaged roles other than `@everyone`, no `ADMINISTRATOR`, no unknown role or selected-overwrite permission bit, and proof that every guild and channel permission conferred by the selected roles is already held by the connector. Reject temporary membership, incomplete or obfuscated channel metadata, topology or continuity drift, unresolved overwrites, and a permission impact too large for human review. Project the minimum new ordinary member before and after the role set across every direct channel, disclose every guild and changed-channel permission decision plus high-risk gain, and state that existing members can accept, granted roles persist after invite expiry or deletion, removal is a separate action, and later role or channel-overwrite edits can change authority before or after acceptance.

Require every creation request to select one exact acceptance mode. `bearer` permits anyone holding the finite capability to attempt acceptance. `exact-users` additionally requires one bounded nonempty set of unique positive user IDs. Canonicalize that set numerically and bind every exact ID into the transient plan, digest, and signed confirmation, but never place it in activity, operation, diagnostic, telemetry, or capability-file output. The private file may contain only the acceptance kind and target count so sharing it with one intended recipient cannot disclose the others.

Generate the exact-user CSV inside the connector and accept no caller-provided bytes, path, filename, form field, role payload, or raw multipart payload. Keep the file reservation empty while polling Discord's target-user job under a fixed bound. Require strict create-response and independent readback agreement on the exact assigned-role set before capability delivery, then require a strict completed target-user status with exact totals and an authenticated bounded CSV readback whose canonical user set exactly matches the review when applicable. Coordinate every selected role in addition to the exact channel and guild invite collection. A failed, incomplete, timed-out, malformed, or mismatched role or target-user verification is uncertain after dispatch, spends the operation key, keeps the channel quarantined, and never writes the capability file. Do not retry, update, revoke, replace, remove roles, or compensate automatically.

Discord exposes no conditional target-user snapshot that can bind verification atomically to local capability delivery. Coordinate connector-owned writes durably, require an exclusive external invite-administration window, and disclose the remaining race in every exact-user plan. A remote invite can remain after an uncertain target-user job even though its code was never disclosed. Require manual inventory review by an authorized operator rather than claiming cleanup.

For guild inventory and opaque-reference lookup, keep invite codes transient inside the REST and invite service layers. Project raw Discord responses before forming an MCP result. Return only a process-keyed opaque reference, bounded channel and invite metadata, exact inviter and target IDs without profiles, usage and lifetime properties, known and unknown flags, and granted-role IDs with permission evidence. Never return a code, URL, guild object, user profile, role name or visual, application metadata, scheduled-event or stage object, Discord-derived target-user acceptance set, approximate count, raw response, or unknown field. Do not add invite acceptance, arbitrary code lookup, URL input, a code-bearing MCP schema, or an immediate creation shortcut outside the separately gated private-file workflow.

Guild vanity URL audit is the narrow exception for a custom public invite code. Reuse only the invite-audit capability and exact guild allowlist, require complete owner or `MANAGE_GUILD` evidence, validate the `VANITY_URL` feature, and cross-check the guild object against Discord's documented vanity read. Omit the code by default and from every resource; disclose it transiently only when the strict tool input sets `includeCode: true`. Never return a full URL or persist, cache, summarize, log, trace, or export the code. Do not implement an undocumented vanity mutation route.

Authenticate every local page cursor and bind it to the exact guild, full inventory digest, and next offset. Fetch and validate another complete fresh inventory for every continuation page and exact-reference lookup. Reject cursor tampering, foreign process state, changed metadata or use counts, missing channels or roles, contradictory target semantics, duplicate capabilities, unsupported invite types, and any inventory above the local safety ceiling. A reference and cursor must expire on connector restart and must never be reversible to an invite code.

Keep revocation behind a second capability gate and require the same exact guild audit scope. Do not add an immediate-call path. Preserve every gate: verified identities, exact scope, complete evidence, process-keyed full-inventory 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 DELETE, exact returned-target validation, and a fresh complete inventory proving absence. Reject the target code and invite URLs in the audit reason before mutation.

Discord deletes an invite by code and supplies no conditional operation that atomically binds the preceding inventory. Treat the final inventory-to-delete interval as an unavoidable external race. Surface it in every deletion plan and require exclusive invite administration for high-risk revocation. Deletion prevents later use but does not remove members or roles granted by earlier uses, so surface prior use as a risk and never describe revocation as retroactive access removal. Freshness, a digest covering the complete inventory, least-privilege `MANAGE_GUILD`, returned-target validation, and full absence readback reduce but cannot eliminate the race.

Replace the code-bearing REST path with a fixed diagnostic route and suppress the underlying transport cause. Mark invite list and deletion operations content-sensitive so response text and external error details cannot enter diagnostics. Observability may receive only fixed operation names, risk classes, outcomes, numeric status, retry data, and durations. Never include the code, URL, raw route, response, audit reason, opaque cursor payload, or permission evidence in errors, logs, telemetry, activity, or operation receipts.

A known pre-write Discord 4xx may be classified as failed. Treat transport failure, Discord 5xx, malformed success, returned-target mismatch, failed absence readback, or any otherwise indeterminate post-reservation state as uncertain and potentially completed. Spend every reserved key after every outcome, retain a permanent same-reference uncertainty barrier inside the service instance, and never retry or compensate automatically. The production facade also acquires a durable exact guild invite-collection claim, so connector processes sharing the activity-state root exclude overlapping revocations and retain the claim after uncertainty.

Invite creation and deletion activity and operation records may contain only exact guild, channel, and selected role IDs, the opaque invite reference when available, plan digest, operation-key hash, timestamps, fixed acceptance, role-assignment, verification and outcome values, activity ID, and sanitized error category. Never persist invite codes, URLs, target-user IDs or CSV, profiles, names, role permissions or impact, local paths, audit reasons, raw operation keys, raw Discord responses, or transport causes.

## Guild Templates

Keep native Guild Template inventory behind its own audit toggle and exact guild allowlist. The allowlist must remain a subset of any configured read-guild scope. Require verified application and bot identities, an exact guild and owner, exact connector membership, complete bounded roles and direct guild channels, a complete bounded template inventory, and effective guild-level `MANAGE_GUILD` before returning an inventory or plan.

Keep template codes transient inside the REST and Guild Template service layers. Project raw Discord responses before forming an MCP result. Return only a process-keyed opaque reference, bounded timestamps and usage state, creator user ID without a profile, metadata character counts, count-only snapshot structure and permission risks, dirty state, count-only live guild structure, and explicit privacy and snapshot limitations. Never return a code, use URL, name, description, creator profile, guild name, role or channel name, channel topic, icon hash, serialized source guild, raw response, or unknown field value. Do not add template use, guild creation from a template, import, export, restore, arbitrary code lookup, or a code-bearing MCP schema.

Treat a Guild Template as a reusable snapshot for future guild creation, not as a backup. Surface that it does not preserve original IDs, members, messages, audit history, integrations, or application-owned resources and that Discord may omit unsupported channel types, managed roles, and guild features. Validate every serialized snapshot under strict depth, node, string, role, channel, and overwrite bounds. Count unknown fields without returning values. Bind the complete private snapshot into freshness while returning only count-based live and target structure. Keep managed roles out of advisory identity drift while retaining them in count-only structure and risk evidence. Treat structural drift as advisory because Discord's snapshot is partial, and use Discord's explicit clean dirty-state only for a no-op synchronization decision. Permit read-only inventory to count unknown top-level template fields, but fail closed before change planning because their privacy-discarded values cannot be freshness-bound. Retain and privately bind unknown serialized-snapshot values while exposing only their count.

Keep create, synchronize, metadata-update, and delete actions behind a second capability gate and the same exact guild audit scope. Do not add an immediate-call path. Every non-create action must accept only an opaque process-local reference. Reject template URLs in audit reasons before any Discord read and reject the freshly resolved target code before mutation. Preserve every gate: verified identities, exact scope, complete private inventory and live guild evidence, strict action-specific 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 mutation, strict returned-capability validation, and an exact complete-inventory transition readback. A client without MCP elicitation must not execute a Guild Template change.

Treat Guild Template creation and synchronization as non-atomic snapshots. Discord exposes no conditional mutation that binds the reviewed live guild to the resulting snapshot. Require an authoritative clean response plus exact full-inventory readback, but do not represent that evidence as proof of complete fidelity with the reviewed guild or a future guild created from the template. Prevent concurrent guild administration and use an exclusive administration window for high-risk snapshots. A non-clean response or readback is an uncertain outcome, spends the operation key, and retains the guild quarantine.

Discord does not document audit-log-reason support for Guild Template endpoints. Validate and bind the reason into the reviewed plan and signed confirmation, but do not send an undocumented audit-log header. Never suggest that the reason entered Discord's audit log.

A known Discord 4xx refusal before a mutation acknowledgement may be classified as failed. Treat rate limiting, transport failure, Discord server failure, malformed success, returned-capability or metadata mismatch, failed complete-inventory readback, or any otherwise indeterminate post-reservation state as uncertain and potentially completed. A mutation with exact successful readback whose local completion record fails is known completed but remains quarantined. Spend every reserved key after every outcome, retain a permanent same-guild ambiguity barrier inside the service instance, and never retry, compensate, restore, or infer a result from template names. The production facade also acquires a durable exact guild template-collection claim, so connector processes sharing the activity-state root exclude overlapping changes and retain the claim after uncertainty or failed completion recording.

Guild Template activity and operation records may contain only the exact guild ID, optional opaque template reference, action, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. Never persist template codes, URLs, names, descriptions, creator profiles, source snapshots, guild or resource names, permission evidence, audit reasons, raw operation keys, raw Discord responses, or transport causes.

## Guild Community lifecycle

Keep Community inspection behind its own audit toggle and exact guild allowlist. The allowlist must remain a subset of the ordinary read-guild boundary. Require verified application and bot identities, an exact guild and owner, exact connector membership, complete bounded roles with no unknown permission bits, and continuity-safe direct-channel evidence before returning an audit or plan. Validate every existing routing reference as an exact trusted text or announcement channel and evaluate the rules channel against complete `@everyone` overwrite evidence. Return guild feature values only as a count and digest, never as a list.

Keep Community changes behind a second toggle and the same exact guild scope. Accept one complete desired routing object with literal enablement acknowledgement, distinct exact rules and public-updates channel IDs, and one nullable exact safety-alerts channel ID. Require the rules channel to be visible to `@everyone`; warn when it is sendable. Do not add fuzzy channel lookup, permission edits, feature removal, Community disablement, partial routing, immediate mutation, retry, rollback, compensation, or best-effort continuation. Preserve every existing guild feature and add only `COMMUNITY` when absent.

Routing-only changes require exact guild ownership or complete `MANAGE_GUILD` evidence. First-time enablement requires exact ownership or complete `ADMINISTRATOR` evidence because Discord's enablement mutation has broader authority than later routing changes. Treat Administrator as temporary operator-managed authority, surface its removal in every enablement plan, and never have setup or a recipe grant it automatically. Require a fresh plan after an additive scaffold creates a referenced text channel so exact trusted channel and permission evidence can be rebound.

Preserve every reviewed-write gate: strict exact normalization, verified identity and policy, complete role and continuity-safe channel evidence, process-keyed plan binding, explicit risks, signed interactive confirmation, write-aware client approval, final fresh-plan match, durable exact-guild coordination, atomic one-shot operation-key reservation, pending content-free activity, one non-retried PATCH with an encoded audit-log reason, strict full Guild response validation, and a fresh exact readback. The plan must bind all preserved feature evidence, current and desired routing, layout revision, connector roles and effective permissions, rules-channel overwrite evidence, acknowledgement, operation-key hash, local constraints, risks, warnings, privacy projection, and verification boundary. An already-current request must return without confirmation, coordination, reservation, activity, or mutation.

Require both the authoritative mutation response and fresh readback to contain `COMMUNITY`, retain every reviewed preexisting feature, and match all three exact routing fields. A definite Discord client refusal before accepted mutation may be classified as failed. Treat rate limiting, transport ambiguity, Discord server failure, malformed success, feature loss, routing mismatch, unreadable readback, receipt finalization failure, or any otherwise indeterminate post-reservation result as uncertain and potentially completed. Spend every reserved key, retain a permanent same-guild ambiguity barrier and durable coordination claim after uncertainty, and never retry, roll back, compensate, remove a feature, or guess whether the write landed.

Community activity and operation records may contain only exact guild, application, bot, and routing channel IDs, sorted changed-field names, preserved feature count and digest, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. Never persist feature names, guild, role, or channel names or topics, member profiles, role or permission evidence, permission overwrites, audit reasons, raw operation keys, raw Discord responses, or transport causes.

## Onboarding

Keep guild onboarding inspection behind its own audit toggle and exact guild allowlist. The allowlist must remain a subset of any configured read-guild scope. Require verified application and bot identities, an exact guild, owner, and bounded feature set, exact connector membership, complete bounded roles, channels, permission overwrites, custom emojis, onboarding state, and effective permissions before returning an audit or plan.

Minimize onboarding content by default. Prompt titles, option titles, descriptions, and Unicode emoji may be returned only after explicit transient text opt-in, while the onboarding resource template must always omit them. Return text lengths, reference health, privacy state, and unknown-field and unknown-enum counts without persisting, caching, logging, or exporting the response. Treat every returned string as untrusted external data. Connector-local bounds must be identified as local safety policy rather than represented as Discord platform limits.

Keep replacement behind a second toggle and the same exact guild scope. Require complete `MANAGE_GUILD` and `MANAGE_ROLES` evidence unless the connector is the exact guild owner. Referenced roles must be standard, non-managed, below the connector's highest role, and hold zero permissions. Referenced channels must be direct guild channels visible to `@everyone`. Enabled configurations must require fresh `COMMUNITY` guild-feature evidence and prove the conservative default-channel visibility and sendability constraints; a reviewed disable may proceed without that feature. Validate custom emoji identity, availability, structure, and role restrictions. Surface `ADMINISTRATOR` as a least-privilege warning rather than treating it as desirable configuration.

Treat every change request as an exact complete desired state. Omitted prompts, options, role assignments, channel assignments, and default channels are deletions. Existing prompt IDs must belong to the fresh current state, and existing option IDs must remain under their fresh owning prompt. Omitted IDs request creation. Any placeholder required by the Discord transport must remain private to that outbound request, and the returned authoritative prompt and option IDs must never be confused with those placeholders. Unknown response fields, unknown enums, duplicate IDs, incomplete inventories, unsafe references, or ambiguous state must block replacement rather than risk silent loss during a complete PUT.

Do not add an immediate-call or partial-update shortcut. Preserve every gate: verified identities, exact policy, complete evidence, strict complete-state 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 PUT, authoritative response-ID validation, and a complete fresh readback. A client without MCP elicitation must not execute onboarding replacement.

The plan digest must bind the complete normalized request, operation-key hash, verified identities, owner, guild features, and connector membership, complete roles, channels, overwrites, custom emojis and their restrictions, current onboarding state, effective permissions, desired state, diff, local limits, privacy projection, risks, warnings, and verification boundary. Any change to that evidence must invalidate the review. An already-current request must return without confirmation, reservation, activity, or mutation.

A definite Discord client refusal may be classified as failed. Treat transport failure, Discord server failure, malformed success, failed authoritative-ID validation, failed full readback, 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 also acquires a durable exact guild onboarding-collection claim, so connector processes sharing the activity-state root exclude overlapping replacements and retain the claim after uncertainty.

Onboarding activity and operation records may contain only exact guild, application, and bot IDs, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. Never persist prompt or option text, descriptions, Unicode emoji, guild, role, channel, or custom emoji names, permission evidence, audit reasons, raw operation keys, raw Discord responses, or transport causes. API response and fresh readback can verify only the controlled server state, not the member client join flow. Keep the fresh non-staff client check as an explicit operator step after enabling onboarding.

## Welcome Screens

Keep Welcome Screen inspection behind its own audit toggle and exact guild allowlist. The allowlist must remain a subset of any configured read-guild scope. Require verified application and bot identities, an exact guild, owner, and bounded feature set, exact connector membership, complete bounded roles, channels, permission overwrites, custom emojis, Welcome Screen state, and effective permissions before returning an audit or plan.

Minimize member-facing content by default. Descriptions and Unicode emoji may be returned only after explicit transient text opt-in, while the Welcome Screen resource template must always omit them. Return exact structural references, text lengths, reference health, privacy state, and unknown-field counts without persisting, caching, logging, or exporting the response. A disabled Welcome Screen without complete `MANAGE_GUILD` authority is unavailable evidence and must never be reconstructed or guessed.

Keep complete replacement behind a second toggle and the same exact guild scope. Require the `COMMUNITY` guild feature and complete `MANAGE_GUILD` authority unless the connector is the exact guild owner. Referenced targets must be direct text, announcement, forum, or media channels visible to `@everyone`. Custom emoji must match an exact available guild emoji with no role restriction; Unicode emoji must be one normalized emoji grapheme. Unknown response fields, duplicate channel IDs, incomplete inventories, unsafe references, or ambiguous state must block replacement rather than risk silent loss during a complete PATCH.

Treat every change request as one exact complete ordered desired state. Omitted channel entries are deletions, and moving an entry changes its order. Do not add an immediate-call, partial-update, public widget, widget-image, invite-creation, or member-presence shortcut. Preserve every gate: verified identities, exact policy, complete evidence, strict complete-state 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 PATCH with an encoded audit-log reason, authoritative response validation, and complete fresh readback. A client without MCP elicitation must not execute Welcome Screen replacement.

The plan digest must bind the complete normalized request, operation-key hash, verified identities, owner, guild features, connector membership and authority, complete roles, channels, overwrites, custom emojis and their restrictions, current Welcome Screen state, desired ordered state, diff, local limits, privacy projection, risks, warnings, and verification boundary. Any change to that evidence must invalidate the review. An already-current request must return without confirmation, reservation, activity, or mutation.

A definite Discord client refusal may be classified as failed. Treat transport failure, Discord server failure, malformed success, failed authoritative response validation, failed full readback, 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 also acquires a durable exact guild Welcome Screen collection claim, so connector processes sharing the activity-state root exclude overlapping replacements and retain the claim after uncertainty.

Welcome Screen 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. Never persist descriptions, Unicode emoji, guild, role, channel, or custom emoji names, channel IDs, permission evidence, audit reasons, raw operation keys, raw Discord responses, or transport causes. API response and fresh readback can verify only the controlled server state, not the member client experience. Keep a fresh non-staff client check as an explicit operator step after enabling the Welcome Screen.

## 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.

## Guild incident actions

Keep guild incident-action inspection behind its own audit toggle and exact guild allowlist. The allowlist must remain a subset of configured read-guild scope. Require pinned application and bot identities, an exact guild and owner, exact connector membership, complete bounded roles, and complete effective guild permissions before returning an audit or plan. Audit may report absent source state or unknown-field counts, but a change must fail closed unless the Incidents Data object is available, every known timestamp is valid, no unknown incident field exists, no unknown permission bit exists, and the connector is the exact owner or has effective `MANAGE_GUILD`.

Project incident evidence at the REST boundary. Return only the exact guild and owner IDs needed for verification, nullable invite and direct-message disable deadlines, boolean presence for raid and direct-message-spam detection timestamps, source availability, and unknown-field counts. Never return or persist raw detection timestamps, guild or role names, raw objects, or unknown values. Treat absence as unavailable evidence, not as proof that every action is clear.

Treat every change request as one exact sparse two-field intent. Require at least one supported action, preserve omitted actions, interpret `null` as deliberate early clearing, and require every non-null deadline to remain strictly in the future and no more than 24 hours ahead at every planning pass. Require a bounded review reason but keep it local and digest-bound because the endpoint does not document `X-Audit-Log-Reason`. Do not add an immediate-call, raw-object, duration shorthand, server-local-time, fuzzy-guild, retry, rollback, or compensating shortcut.

Preserve every reviewed-write gate: verified identities, exact policy, complete known evidence, exact-owner or `MANAGE_GUILD` authority, strict timestamp and sparse-intent normalization, process-keyed plan binding, signed interactive confirmation, write-aware client approval, final fresh-plan match, durable exact-guild coordination, atomic one-shot operation-key reservation, pending content-free activity, one non-retried sparse PUT containing only changed action fields, strict Incidents Data response validation, and a fresh exact guild, member, role, permission, and incident-state readback. A client without MCP elicitation must not execute a guild incident-action change.

The plan digest must bind the normalized sparse request and local reason, operation-key hash, verified identities, exact owner, connector membership and roles, complete permissions, full current and desired action state, detection-presence booleans, requested and changed fields, effects, local limits, privacy projection, risks, warnings, and verification boundary. Any evidence or intent change must invalidate review. An already-current request must return without confirmation, coordination, reservation, activity, or mutation.

Validate the complete Incidents Data mutation response before readback. Compare both controlled action fields with the reviewed desired state in both the response and the fresh readback, including the action the caller omitted, so concurrent external administration is reported rather than silently accepted. Report valid divergence only as controlled field names. Never return or persist raw responses, raw detection times, changed deadline values, local reasons, or permission evidence.

A definite Discord client refusal may be classified as failed. Treat rate limiting, transport failure, Discord server failure, malformed success, unknown response fields, 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 `incident-actions` collection claim and retain it after uncertainty.

Guild incident-action activity and operation records may contain only the exact guild ID, plan digest, operation-key hash, record timestamps, fixed verification and outcome values, activity ID, sanitized error category, and sorted requested field names where applicable. Never persist action deadlines, detection timestamps, guild or role names, permissions, local review reasons, raw operation keys, raw Discord responses, or transport causes. Non-null actions expire automatically at Discord; do not schedule a second connector write.

## Authenticated widget settings

Keep widget-settings inspection behind its own audit toggle and exact guild allowlist. The allowlist must remain a subset of any configured read-guild scope. Use only Discord's authenticated guild widget-settings endpoint. Do not call, proxy, cache, or expose the anonymous widget JSON or widget-image routes because their public guild, channel, presence-oriented, and invite data is outside the administrative evidence boundary.

Require verified application and bot identities, an exact guild and owner, exact connector membership, complete bounded roles, direct guild channels and overwrites, effective permissions, and a strict authenticated settings object before returning an audit or plan. Use optional guild-object widget fields only as a contradiction-detecting cross-check. Omit channel names, member and presence data, invites, raw payloads, and unknown-field values. Treat unknown settings fields, unknown permission bits, malformed or incomplete inventories, missing references, cross-check contradictions, and unsupported or hidden selected channels as blockers for change.

Keep replacement behind a second toggle and the same exact guild scope. Require complete `MANAGE_GUILD` authority unless the connector is the exact guild owner. A selected channel must be one exact direct text, voice, announcement, Stage, forum, or media channel with complete permission evidence and effective `VIEW_CHANNEL` for `@everyone`. Report effective `CREATE_INSTANT_INVITE` for `@everyone` as public-exposure evidence without treating it as connector mutation authority. Do not infer eligibility from a parent allowlist, connector-only visibility, a name, or a partial channel object.

Keep public exposure behind an independent action-sensitive toggle. Require it for every real write whose desired state is enabled and for every real write that selects a different non-null channel, including a latent target while disabled. Do not require it for an exact no-op, a reviewed disable retaining the current channel, or clearing the channel while disabled. This exception must not become a general write bypass: audit scope, change scope, complete evidence, planning, confirmation, approval, freshness, reservation, journaling, and readback remain mandatory.

Treat every request as one exact complete desired state containing the enabled boolean and nullable channel ID. Do not add an immediate-call, partial-update, fuzzy-channel, public-widget read, widget-image, invite-creation, member-presence, retry, rollback, or compensating shortcut. Preserve every gate: verified identities, exact policy, complete evidence, strict full-state 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 PATCH with an encoded audit-log reason, strict authoritative-response validation, and a complete fresh authenticated readback. A client without MCP elicitation must not execute widget-settings replacement.

The plan digest must bind the normalized complete request, operation-key hash, verified identities, guild owner, connector membership and authority, complete roles, channels and overwrites, effective connector and `@everyone` permissions, authoritative current settings, optional guild cross-check, desired state, diff, action-sensitive exposure authorization, privacy projection, risks, warnings, and verification boundary. Any identity, permission, channel, overwrite, state, cross-check, desired value, audit reason, exposure policy, or operation-key change must invalidate the review. An already-current request must return without exposure authorization, confirmation, reservation, activity, or mutation.

A definite Discord client refusal may be classified as failed. Treat transport failure, Discord server failure, malformed success, unsafe or mismatched authoritative response, 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 also acquires a durable exact guild widget-settings collection claim, so connector processes sharing the activity-state root exclude overlapping changes and retain the claim after uncertainty.

Widget-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. Never persist enabled state, selected channel IDs, guild or channel names, permission evidence, exposure details, audit reasons, raw operation keys, raw Discord responses, or transport causes. Enabling the widget makes the Server Profile public outside the guild and can permit anonymous invite generation. Disabling it does not restore Private Profile. Keep a fresh non-member review after enabling and manual Private Profile inspection and restoration after disabling as explicit operator steps, and never claim that authenticated API readback verifies either external result.

## Deletion

Do not add a deletion shortcut that bypasses exact IDs, local policy, keyed planning, fresh reads, signed interactive confirmation, write-aware client approval, or pending activity journaling. If a new client cannot support MCP elicitation, keep deletion unavailable in that client.

The activity file intentionally excludes message bodies, attachment URLs, raw keys, audit-log reasons, and mutable Discord names. Preserve that property when adding fields or new write operations.

## Member administration

Do not add an administration shortcut that bypasses the capability gate, exact administration-guild allowlist, protected-user denylist, exact IDs, complete permission and hierarchy evidence, process-keyed planning, signed interactive confirmation, write-aware client approval, final fresh-plan match, or pending activity journaling. If a client cannot support MCP elicitation, keep member administration unavailable in that client.

Never persist Discord audit-log reasons, usernames, global names, nicknames, role names, avatars, ban reasons, or other profile data. Member-moderation activity records may contain exact guild and user IDs, action names, numeric action parameters, plan digests, timestamps, sanitized error classifications, and outcomes.

Treat `uncertain` outcomes as potentially completed writes. Inspect the exact member, ban, or timeout state before considering a retry.

## Reporting

Use a [private GitHub Security Advisory](https://github.com/j-256/guildcontrol/security/advisories/new) to report a vulnerability. Security reports should describe the behavior and affected version without including live bot tokens, private Discord content, expiring attachment URLs, npm credentials, or GitHub tokens.

If private advisory access is unavailable, open a minimal public issue asking for a private contact channel. Do not include exploit details, credentials, Discord identifiers, or Discord content in that issue.

## Release credentials

Release automation must not store or receive an npm token. The first npm publication uses an exact GitHub-attested candidate and an interactive maintainer session with passkey authentication because npm does not permit staging or trusted publishing before the package exists. Later npm staging and MCP Registry registration use GitHub OIDC, with npm restricted to stage-only trusted publishing and token-based publication disabled.

Release automation must attest the first-publication candidate, keep OIDC provenance enabled for later staged versions, verify the checksum-pinned MCP publisher, compare the reconstructed archive with npm's SHA-512 integrity before OCI or registry publication, and preserve full commit SHA pins for every GitHub Action.