Skip to content

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.

Canonical source: SECURITY.md

Documentation generated for guildcontrol@0.0.0. Canonical source and edit history remain in the public repository. GuildControl is an independent project and is not affiliated with or endorsed by Discord Inc. Discord is used only to identify the platform that GuildControl connects to.