Exact Discord references
Treat exact-reference parsing as local syntax conversion, never as name resolution, Discord access verification, or authorization. Accept only one complete canonical discord.com channel or message jump link or one official typed user, channel, role, application-command, or custom-emoji mention. Never scan surrounding prose, choose among multiple references, accept an alternate host or scheme, follow a URL, contact Discord, open the Gateway, or persist the input.
Reject malformed or zero snowflakes, values outside the unsigned 64-bit range, padding, controls, malformed Unicode, queries, fragments, unsupported Discord routes and mentions, invite capabilities, webhook execution credentials, OAuth links, and Discord CDN, attachment, or media URLs. Error messages and results must not echo the input. Omit application-command and custom-emoji names rather than turning transient display text into output or a later target.
Project only the exact configured guild and channel read boundary that can be decided from the supplied IDs. Mark missing guild or private-recipient context as incomplete, and state explicitly that Discord access remains unverified. A parsed ID and an eligible local read projection must never bypass a downstream tool's strict schema, exact feature scope, Discord permission evidence, protected-target rules, reviewed plan, host approval, signed confirmation, freshness check, one-shot reservation, journaling, or readback.
Keep initial setup presets read-only. Add a write workflow only through a locally defined additive recipe whose descriptor declares every capability, exact feature scope, canonical toolset, Discord permission, privileged intent, Gateway evidence requirement, risk, and warning it introduces. Recipe inspection, planning, and application must not resolve a secret, construct a Discord client, contact Discord, open the Gateway, start telemetry, or create activity state. A recipe must preserve the configured event-feed policy. If the resulting runtime derives a nonprivileged evidence-only Gateway connection from newly enabled feature scopes, the descriptor and review report must identify its exact intent and purpose. Scope inputs must be exact bounded snowflakes inside the existing outer read boundary; an empty outer channel list retains its documented all-visible-channels-inside-guild meaning and must produce an offline ownership warning.
Bind each recipe plan to the normalized absolute file path, canonical current and proposed documents, exact normalized request, descriptor contract, changes, and warnings with SHA-256. Application must recompute the plan, require its exact digest and exact recipe-name confirmation, then compare the reviewed source again inside the exclusive config-file lock. Refuse a stale, changed, removed, identity-drifted, or scope-escaping source. A real application may add only declared policy fields, must use atomic publication and retain a recoverable backup, and must verify the exact resulting document. An already-current application is a no-write, no-backup operation. A recipe changes local policy only; every Discord operation still requires all of its independent permission, plan, approval, freshness, evidence, readback, and uncertainty gates.
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.