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.

Canonical source: SECURITY.md