Guild Community lifecycle

Keep Community inspection behind its own audit toggle and exact guild allowlist. The allowlist must remain a subset of the ordinary read-guild boundary. Require verified application and bot identities, an exact guild and owner, exact connector membership, complete bounded roles with no unknown permission bits, and continuity-safe direct-channel evidence before returning an audit or plan. Validate every existing routing reference as an exact trusted text or announcement channel and evaluate the rules channel against complete @everyone overwrite evidence. Return guild feature values only as a count and digest, never as a list.

Keep Community changes behind a second toggle and the same exact guild scope. Accept one complete desired routing object with literal enablement acknowledgement, distinct exact rules and public-updates channel IDs, and one nullable exact safety-alerts channel ID. Require the rules channel to be visible to @everyone; warn when it is sendable. Do not add fuzzy channel lookup, permission edits, feature removal, Community disablement, partial routing, immediate mutation, retry, rollback, compensation, or best-effort continuation. Preserve every existing guild feature and add only COMMUNITY when absent.

Routing-only changes require exact guild ownership or complete MANAGE_GUILD evidence. First-time enablement requires exact ownership or complete ADMINISTRATOR evidence because Discord's enablement mutation has broader authority than later routing changes. Treat Administrator as temporary operator-managed authority, surface its removal in every enablement plan, and never have setup or a recipe grant it automatically. Require a fresh plan after an additive scaffold creates a referenced text channel so exact trusted channel and permission evidence can be rebound.

Preserve every reviewed-write gate: strict exact normalization, verified identity and policy, complete role and continuity-safe channel evidence, process-keyed plan binding, explicit risks, signed interactive confirmation, write-aware client approval, final fresh-plan match, durable exact-guild coordination, atomic one-shot operation-key reservation, pending content-free activity, one non-retried PATCH with an encoded audit-log reason, strict full Guild response validation, and a fresh exact readback. The plan must bind all preserved feature evidence, current and desired routing, layout revision, connector roles and effective permissions, rules-channel overwrite evidence, acknowledgement, operation-key hash, local constraints, risks, warnings, privacy projection, and verification boundary. An already-current request must return without confirmation, coordination, reservation, activity, or mutation.

Require both the authoritative mutation response and fresh readback to contain COMMUNITY, retain every reviewed preexisting feature, and match all three exact routing fields. A definite Discord client refusal before accepted mutation may be classified as failed. Treat rate limiting, transport ambiguity, Discord server failure, malformed success, feature loss, routing mismatch, unreadable readback, receipt finalization failure, or any otherwise indeterminate post-reservation result as uncertain and potentially completed. Spend every reserved key, retain a permanent same-guild ambiguity barrier and durable coordination claim after uncertainty, and never retry, roll back, compensate, remove a feature, or guess whether the write landed.

Community activity and operation records may contain only exact guild, application, bot, and routing channel IDs, sorted changed-field names, preserved feature count and digest, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. Never persist feature names, guild, role, or channel names or topics, member profiles, role or permission evidence, permission overwrites, audit reasons, raw operation keys, raw Discord responses, or transport causes.

Canonical source: SECURITY.md