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.

Canonical source: SECURITY.md