Reviewed exact guild departure

Guild departure removes the authenticated connector bot from one exact guild and immediately ends its access there. It has no immediate-call path and no name-based target. Enable it only with the dedicated guild-departure toolset, capabilities.guildDepartures: true, and a nonempty scopes.guildDepartureGuildIds allowlist. That allowlist must remain inside readScope.guildIds when an outer guild allowlist is configured. No Discord permission, audit-log reason, generic administration toggle, or other write toolset grants departure authority.

The relevant policy fragment is:

{
  "capabilities": {
    "guildDepartures": true
  },
  "scopes": {
    "guildDepartureGuildIds": ["YOUR_GUILD_ID"]
  },
  "tools": {
    "toolsets": ["guild-departure"]
  }
}

Merge that fragment into a complete schema-v2 policy rather than using it as a standalone file. config explain $.capabilities.guildDepartures and config explain $.scopes.guildDepartureGuildIds return the same schema-backed descriptions used by the workbench, while doctor reports whether the capability, exact scope, and dedicated toolset agree.

1. Stop every connector and external operation against the target guild.
2. Call plan_guild_departure with the exact guild ID, a unique one-shot operation key, a transient local review reason, and literal true acknowledgments for immediate access loss, separate re-entry, and stopped concurrent work.
3. Review the pinned application and bot IDs, transient untrusted target name, exact non-owner and bot-membership evidence, complete current-guild inventory counts, privacy projection, warnings, operation-key hash, creation time, and keyed digest.
4. Call execute_guild_departure with identical inputs plus the digest, then approve the signed MCP confirmation only if every exact identity, acknowledgment, omission, warning, reason, hash, and digest remains intended.
5. Treat only completed with verifiedAbsent: true as success. A later installation or invitation is a separate Discord-side action.

Planning verifies the pinned application and bot before fetching the exact guild, the exact bot member, and every bounded page of the current bot's guild inventory. The target must appear exactly once, its transient name must agree across independent routes, ownership evidence must agree, the authenticated bot must be the exact member, and the bot must not own the guild. Other guild IDs, names, profiles, permissions, and raw payloads are projected out before the plan is formed; only aggregate page and membership counts remain. Malformed, duplicate, cursor-violating, incomplete, absent, inconsistent, or over-bound evidence blocks planning.

The process-keyed digest binds the exact normalized request, hashed operation key, pinned identities, bot roles, target identity and non-ownership, complete inventory shape and target evidence, consequence acknowledgments, privacy contract, transient reason, and warnings. The adapter rebuilds the plan before signed approval, the production facade rebuilds it before durable coordination, and the service rebuilds it again inside the acquired claims. Any reviewed state drift invalidates the digest before mutation.

Execution claims every modeled guild collection for the exact guild, so reviewed collection-wide workflows sharing the same canonical local activity-state root cannot overlap the departure. Collection claims cannot identify every resource-only operation or any external Discord actor. The explicit quiescence acknowledgment therefore remains a real operator obligation: keep those operations stopped from planning until the departure reaches a terminal result. The connector then reserves the one-shot key, writes pending content-free activity, sends one non-retried DELETE /users/@me/guilds/{guild.id}, and rereads the complete current-guild inventory. Completion requires the exact target to be absent.

A known pre-mutation Discord client refusal other than request timeout or rate limiting may settle as failed. Rate limiting, transport failure, server failure, malformed success evidence, target presence in readback, failed complete readback, failed receipt finalization, or any otherwise indeterminate post-reservation state is uncertain and may represent a completed departure. The key remains spent, the durable claims remain quarantined when receipt evidence is not safely terminal, and a process-local same-guild uncertainty barrier blocks another departure. Never retry, reinstall, invite, compensate, or claim rollback automatically.

Departure activity and operation records 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. Guild names, other guild identities, member profiles, role names, permissions, the local review reason, raw operation key, raw responses, and transport causes never enter persistent records, diagnostics, or telemetry. Discord documents no audit-log reason for this route, so the local reason is neither sent to Discord nor persisted. See Discord's current-user guild endpoints and Leave Guild route.

Canonical source: docs/reference.md