Reviewed application privileged-intent enablement

This workflow replaces a narrow manual Developer Portal step without creating a generic application editor. Enable it with capabilities.applicationIntentChanges: true and include application-security in tools.toolsets. The gate grants no action by itself: plan_application_intent_enablement and execute_application_intent_enablement accept only the pinned current application and only an intent already justified by the rest of the strict schema-v2 policy.

Guild Members is eligible only when capabilities.memberDirectory is enabled and scopes.memberDirectoryGuildIds contains at least one exact guild. Message Content is required when configured announcement crossposts, component messages, static rich-embed messages, or message forwarding need content, and is recommended when the messages toolset is selected. A target with no such policy requirement is rejected before planning. Presence, arbitrary flags, full-authorization flags, disabling, Public Bot, code-grant settings, installation configuration, application text, and all other current-application fields are outside the contract.

Every request has exactly four fields:

{
  "acknowledgePrivilegeExpansion": true,
  "intent": "guild-members",
  "operationKey": "application-intent-change-0001",
  "reviewReason": "Enable the exact member directory configured in policy"
}

The intent is guild-members or message-content. The acknowledgement must be literal true; the operation key is one-shot; and the bounded control-free review reason is part of the keyed plan and signed confirmation state but is neither sent to Discord nor persisted. Caller-selected application IDs, bot IDs, numeric flags, audit reasons, and extra fields are rejected.

Planning verifies the bot token's pinned application and bot identities, requires authoritative current-application flag evidence, derives a named current state, and proves the policy requirement. Its keyed digest binds the complete observed flag value, exact desired full value, outgoing limited-flag mask, named target, requirement, ephemeral rationale, one-shot key hash, risks, and warnings. MCP output deliberately includes only named state and omission evidence, never the raw flag values or raw operation key. A target already enabled through either its full or limited Discord flag is an operation-record-free no-op.

Execution rebuilds that plan from fresh evidence and stops before confirmation if anything changed. A real change requires host write approval and signed interactive confirmation, then acquires a durable exact application privileged-intents collection claim, reserves the one-shot key, writes pending content-free activity, and issues exactly one non-retried PATCH /applications/@me containing only the preserved editable limited-intent mask plus the reviewed target. The response must identify the same application and bot and expose the exact expected complete flag value. An independent fresh GET /applications/@me must then return that same complete value with the reviewed limited bit enabled. The facade discards its cached application identity after every execution attempt so later operations cannot rely on pre-change flag evidence.

A known Discord client rejection, including a rate-limit response, is failed because Discord returned a definitive non-success response before mutation evidence. Transport ambiguity, server failure, malformed or mismatched mutation evidence, readback failure, and failed durable receipt finalization are uncertain and may have completed. Every reserved key stays spent; uncertain outcomes additionally retain the application-wide claim and block same-application changes until an operator inspects Discord and resolves the durable evidence. The connector never retries, disables another intent, compensates, rolls back, or requests a full authorization automatically.

Application-intent activity and operation records contain only the application and bot IDs, named intent, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. Review rationale, application text, raw flags, raw operation keys, credentials, raw Discord objects, and transport causes remain absent. review_application_intent_enablement renders the exact strict request into a plan-only workflow under the same application-security toolset and explicitly forbids execution.

Canonical source: docs/reference.md