Guild blueprints

Treat live blueprint capture as a bounded read and authoring aid, never as backup authority. Require the ordinary exact guild boundary plus the profile, settings, Community, Welcome Screen, onboarding, and AutoMod audit gates before identity or capture reads. Read two bounded passes through only those domains, the returned role inventory, and the configured-policy- and Discord-visibility-bounded channel inventory. Include complete trusted Community routing and exact-ID AutoMod policy in the stability comparison and return no blueprint or recovery binding if any canonical projection differs. Never read messages, a member directory, non-connector member profiles, webhooks, invites, attachments, components, AutoMod execution events or match content, or audit history for capture. The Community sub-audit may read only the verified connector bot membership needed for complete permission evidence and must return no profile fields. Never write a snapshot, attestation, policy content, activity entry, operation receipt, or coordinator state.

Return only one strict planner-compatible representable subset with fixed omission and blocker codes, deterministic symbolic keys, explicit exact-bound references, enabled Community routing, exact-ID AutoMod rules, an unkeyed content fingerprint, privacy evidence, non-backup limitations, and a fixed next action. Capture must not automatically add exact-role-configuration or exact-channel-metadata convergence intent; the operator must author and review those same-guild exact-ID phases explicitly. For a planner-ready stable result only, mint one process-local HMAC attestation per represented role and channel. Bind the verified application, bot, guild, resource kind and exact ID, deterministic blueprint key, complete capture fingerprint, completion and fixed 30-minute expiry times, exact captured target-projection digest, and applicable omission codes. Never mint a binding for a blocked, torn, omitted, or unrepresented resource. Capture enabled Community only when its feature state, exact routing IDs, trusted direct text or announcement channels, and @everyone rules-channel visibility are complete. Otherwise omit it under a fixed finding and never invent a target. Managed or Administrator roles, unknown permission bits, enums, or response fields, unsupported channel types, permission overwrites, ordering, cosmetics, forum extras, unknown Community or AutoMod evidence, unresolved references, ambiguity, and capacity loss must never be silently approximated. A review-required result must not proceed to blueprint planning until its partial desired state is explicitly accepted or edited. Every retained draft still requires a fresh authoritative plan. Do not claim caller retention, atomicity, lossless restore, automatic rollback, original-ID restoration, message recovery, completeness, or cross-guild portability.

Treat compile_guild_blueprint_starter as an authority-free local authoring utility. It may compile only the fixed community, creator, project, or support public layout from one exact guild ID, stable operation key, audit reason, and optional guild name, then normalize the result through the production blueprint request contract. It must not inspect policy, contact Discord or another service, read a remote template, accept arbitrary variables, persist content, create roles, assign members, request ADMINISTRATOR, lower or otherwise replace the guild verification level, or claim private or read-only access. Its information channels remain ordinary public text channels, and its symbolic key order is only a deterministic creation hint rather than a final live order. The later scaffold planner retains its ordinary collision boundary: it may bind one unambiguous logical-name candidate only when complete current state exactly matches, while duplicates, mismatches, hidden-state limits, or drift block. Return exact policy requirements, omission codes, warnings, and separate exact-ID permission-overwrite and ordering handoffs. Compilation must never replace a fresh plan_guild_blueprint call or any nested domain gate.

Treat preview_guild_blueprint as an authority-free local projection, never a dry-run approval or simulated live plan. It must use the same strict production normalizer as live planning, remove the raw master operation key before returning data, expose the complete deterministic manifest sequence and direct dependencies, and classify exact and scaffold references without resolving them. Possible write stages may describe only bounded intent-derived vocabulary and must never claim that a stage or write is required. Preview must not read a credential or policy, contact Discord, mint an executable plan digest, reserve an operation, write activity, persist content, grant authority, invent an ID, or predict permission, hierarchy, capacity, receipt, or post-write state.

Build every live plan's manifest overlay from that same deterministic sequence. Mark only reached steps freshly assessed, mark later steps deferred, and mark at most the matching write-required current frontier executable. Keep planner-discovered safety prerequisites that were absent from caller intent in a separate collection rather than rewriting the normalized manifest. A complete sequence must never become permission to execute multiple phases under one snapshot or approval.

Treat the blueprint coordinator as sequencing only, never as new authority. Every structure, exact role-configuration, exact channel-metadata, profile, settings, Community, Welcome Screen, onboarding, AutoMod, and Components V2 publication frontier must pass the corresponding domain capability, exact scope, identity, intent, notification, complete-evidence, permission, planning, approval, reservation, pending-audit, non-retry, readback, conflict, and uncertainty gates. Exact role and channel targets must remain inside the standalone role-configuration and channel-metadata allowlists even when those standalone tools are hidden. A publication link must additionally pass the component domain's exact canonical HTTPS origin policy before Discord access. A publication request row must additionally pass exact native Interaction guild, resolved channel, and user scope plus paired broker and managed-command readiness; a blueprint must grant none of that authority. First-time Community enablement retains the exact-owner or complete ADMINISTRATOR requirement; routing-only changes retain exact-owner or complete MANAGE_GUILD authority. AutoMod timeout actions retain conditional MODERATE_MEMBERS, and alert actions retain their separate exact channel allowlist. Hiding a domain's standalone toolset must not bypass its policy, and enabling the blueprint toolset must grant no Discord access by itself.

Keep the manifest strict, exact, caller-retained, and bounded. The only supported order is structure, exact role configuration in ascending role-ID order, exact channel metadata in ascending channel-ID order, profile, settings, Community, Welcome Screen, onboarding, ordered AutoMod rules, then ordered publications, with omitted phases skipped and exactly one fresh frontier executable per call. Reject duplicate exact targets and derive target identity only from the exact snowflake, never a name, logical match, symbolic key, or inventory position. Exact role intent may use either one complete known permission-name set or grant and revoke deltas, never both. A complete known set must preserve unknown future bits and must not contain ADMINISTRATOR. Sparse channel metadata must preserve every omitted field and must not expand into ordering, type conversion, overwrite replacement, forum-tag replacement, deletion, or thread mutation. Community must carry literal enablement acknowledgement, distinct rules and public-updates references, and a nullable safety-alerts reference. Its exact references may target only trusted direct text or announcement channels; symbolic references may target requested scaffold text channels only. Preserve every existing guild feature and add only COMMUNITY. If enabled Welcome Screen or onboarding intent omits Community while the feature is disabled, return a fixed content-free dependency blocker and perform no downstream plan or write. Welcome Screen, onboarding, and AutoMod entries may use only their explicitly supported exact IDs or requested scaffold references. Existing onboarding prompts, onboarding options, and AutoMod rules may be retained only by exact Discord ID. An AutoMod rule without ruleId is create-only and must never adopt live state by name, trigger, creator, singleton status, or inventory position. Omission never deletes a rule. Publications require a unique stable key and either one exact channel or active thread or one requested scaffold text channel. Create publications must omit a message ID, edit publications must require one exact message ID, and replies, reply-author notification, arbitrary callback-bearing components, and attachments remain excluded. Resolve symbolic references only from complete exact scaffold bindings, reject duplicate raw references and duplicate resolved IDs, and require the existing hardened domain plan for every frontier.

Derive a separate deterministic HMAC operation key for every singleton phase, exact role target, exact channel target, stable AutoMod rule and stage, and stable publication key. Exact-target identities must remain stable when their arrays are reordered. Other reordering may change the manifest digest but must not change an individual item or stage identity. Bind the complete normalized manifest, verified identities, exact bindings, phase states, receipt-verification codes, blocker, nested plan digest, and current frontier into keyed request and aggregate plan digests. Signed request state may contain only those digests. AutoMod receipts must use strict schema 2 and bind a token-derived keyed request digest without persisting policy content; schema-1 AutoMod receipts are invalid and have no compatibility parser or migration. A changed manifest, master key, phase, item, identity, binding, Discord snapshot, receipt state, nested digest, or connector process must require a new review.

Standalone domain planning must continue rejecting every spent one-shot key. Blueprint reconciliation may inspect a prior nested receipt only through the domain's narrow reconciliation entry point. It may treat the phase as satisfied only when the receipt is completed, verification is match, the guild and resource IDs match exactly, and a fresh complete domain plan proves the requested state needs no write. A pending, failed, uncertain, drifted, wrong-target, malformed, or later-divergent receipt must remain a conflict. For newly created onboarding prompts or options, a matching receipt may bind Discord-assigned IDs only while every ordered field and reference matches fresh state; ordinary planning must continue refusing implicit ID adoption.

For each reached unbound AutoMod rule, verify its existing receipt before inventory access. A matching completed receipt may bind and read only its exact receipt-bound rule. A missing receipt may check exact name collisions and proceed to disabled creation; every other receipt or live mismatch blocks. Exact existing rules must use direct ID lookup, and immutable trigger-type changes must block. Stage enabled policy changes through disable, configure, and optional enable, one fresh review per stage. Verify the selected stage receipt before asking its domain planner to reuse the derived operation key; a matching terminal stage may satisfy only the exact final state it proves, while mismatch, uncertainty, drift, or an intermediate-stage race blocks or requires a fresh plan. For each reached publication, likewise verify its component-message receipt before planning. Any mismatched, pending, failed, uncertain, malformed-target, missing-resource, or live-state-mismatch evidence must produce a content-free blocker and stop every later phase without elicitation or a write. Never scan inventories for recovery, trust a caller-supplied create result, or infer a managed resource from content.

Never persist the manifest, master operation key, symbolic keys, guild, role, channel, or AutoMod rule names, role permission intent, colors, role icons, channel metadata, AutoMod triggers, actions, exemptions, custom responses, prompt or option titles, descriptions, Unicode emoji, topics, component layouts or text, link destinations or origins, notification user IDs, audit reason, nested confirmation text, or a coordinator checkpoint. The coordinator must create no write, receipt, or recovery semantics of its own. Verification must rebuild fresh domain plans and return only content-free identities, hashes, phase states, exact resource, receipt-bound AutoMod rule, and receipt-bound message IDs without symbolic keys, fixed receipt and verifier codes, blockers, and existing content-free domain evidence.

Canonical source: SECURITY.md