Caller-retained declarative guild blueprints

Guild blueprints provide a high-level outcome workflow without adding a name-based broad apply engine or bypassing domain safety. Include guild-blueprints in tools.toolsets when selecting toolsets. Local compilation and preview need no credential, capability, scope, or Discord permission and grant none. Live capture has no independent capability or scope: it composes the ordinary exact guild boundary with capabilities.guildProfileAudit, capabilities.guildSettingsAudit, capabilities.guildCommunityAudit, capabilities.welcomeScreenAudit, capabilities.onboardingAudit, and capabilities.automodAudit plus all corresponding exact feature scopes. There is no blueprint change capability toggle or blueprint allowlist: every structure frontier still requires capabilities.guildScaffolds: true and an exact scopes.guildScaffoldGuildIds match, every exact role-configuration frontier still requires capabilities.roleConfiguration: true and an exact scopes.roleConfigurationIds match, every role-ordering frontier still requires both capabilities.roleOrderingAudit: true and capabilities.roleOrderingChanges: true, an exact scopes.roleOrderingGuildIds match, and complete Manage Roles and hierarchy evidence, every exact channel-metadata frontier still requires capabilities.channelMetadataChanges: true and an exact scopes.channelMetadataIds match, every channel-ordering frontier still requires both capabilities.channelOrderingAudit: true and capabilities.channelOrderingChanges: true, an exact scopes.channelOrderingGuildIds match, nonprivileged GUILDS layout evidence, and complete View Channel and Manage Channels evidence for its affected topology, every permission-overwrite frontier still requires capabilities.permissionOverwrites: true, an exact direct-channel match in scopes.permissionOverwriteChannelIds, and complete View Channel and Manage Roles evidence, every profile frontier still requires capabilities.guildProfileChanges: true and an exact scopes.guildProfileGuildIds match, every settings frontier still requires capabilities.guildSettingsChanges: true and an exact scopes.guildSettingsGuildIds match, every Community frontier still requires capabilities.guildCommunityChanges: true and an exact scopes.guildCommunityGuildIds match, every Welcome Screen frontier still requires capabilities.welcomeScreenChanges: true and an exact scopes.welcomeScreenGuildIds match, every onboarding frontier still requires capabilities.onboardingChanges: true and an exact scopes.onboardingGuildIds match, every AutoMod frontier still requires capabilities.automodChanges: true, an exact scopes.automodGuildIds match, Manage Guild, conditional Moderate Members for timeout actions, and an exact scopes.automodAlertChannelIds match for every alert action, and every publication frontier still requires capabilities.interactions: true, an exact scopes.interactionChannelIds match, every link destination's exact canonical HTTPS origin in scopes.componentLinkOrigins, configured notification-user scope where used, confirmed Message Content intent, and the component domain's complete channel, thread, and permission evidence. The underlying domain toolsets do not need to be exposed for the coordinator to enforce those policies.

Deterministic public starters

compile_guild_blueprint_starter is a versioned local compiler for four compact common layouts. It accepts one exact guild ID, bounded audit reason, stable master operation key, optional strict guild name, and starter name. It rejects unknown fields, runs the assembled candidate through the same production normalizer as plan_guild_blueprint, and returns the strict caller-retained request plus a review. discord://connector/guild-blueprint-starters publishes the data-free catalog, design principles, omissions, and lifecycle for resource-aware clients.

For example, compile the project layout locally:

{
  "auditReason": "Create the reviewed public project layout",
  "guildId": "123456789012345678",
  "operationKey": "project-layout-v1",
  "starter": "project"
}

Starter	Categories	Text channels	Forums	Intended use
community	3	4	1	Entry guidance, announcements, conversation, introductions, and structured ideas
creator	3	5	1	Releases, schedule, community discussion, fan work, clips, and content requests
project	3	5	2	Project reference, releases, collaboration, help, showcase, issues, and proposals
support	3	3	3	Entry guidance, FAQ, forum-first help and bug reports, conversation, and feedback

Every starter requests only categories, ordinary public text channels, forum channels, symbolic top-to-bottom category and per-parent child ordering, conservative guild settings, and an optional guild name. The settings use only-mentions default notifications, apply explicit content filtering to all members, point the system channel at the requested general channel, and preserve the live verification level. A supplied guild name is a complete replacement, not a label or prefix. The starter creates no role, assigns no member, requests no ADMINISTRATOR, imports no remote data, evaluates no arbitrary variables, contacts no Discord endpoint, inspects no policy, persists nothing, and grants no authority. Later scaffold planning may bind one unambiguous logical-name candidate only when complete current state exactly matches the additive request; duplicate, mismatched, visibility-limited, or drifting evidence blocks. Each compiled channelOrders chain remains within one known parent and omits reparenting acknowledgement; it converges only after every referenced scaffold ID is proven. Information channels are not read-only until their exact channel IDs are proven and reviewed permission-overwrite intent is added to the retained manifest or run through the standalone workflow. The returned review names channelPermissionOverwrites plus plan_channel_permission_overwrite as integrated and standalone permission-hardening paths and reports every omitted domain rather than implying a private area, read-only policy, Community setup, onboarding, AutoMod, or publication.

Call the compiler and inspect its counts, warnings, policy requirements, and omission list. Retain request, make only intended presentation changes, pass that exact result through preview_guild_blueprint, then pass it unchanged to plan_guild_blueprint. For a read-only policy, recipe plan guild-starter FILE --guild-id ID prepares the narrower structure, ordering, and settings policy and reports its exact changes before application. It preserves the live guild name; supplying guildName additionally requires the guild-profile capabilities and exact scope listed by the compiler. The plan still enforces every capability, exact scope, Discord permission, identity, approval, receipt, readback, and uncertainty boundary described below. Use author_guild_blueprint for a custom layout or capture_guild_blueprint for a bounded same-guild live draft; neither path is silently mixed with a starter.

Complete local manifest preview

preview_guild_blueprint accepts the exact same strict manifest as plan_guild_blueprint, runs the production normalizer, removes the raw master operation key from the result, and returns the complete normalized caller input plus one deterministic entry for structure, each role-configuration target, each bottom-up role-order adjacency, each channel-metadata target, each bottom-up channel-order adjacency, each permission-overwrite target, every selected singleton phase, each AutoMod rule, and each publication. Entries carry stable IDs, manifest paths, direct predecessor dependencies, exact and scaffold references, and bounded possible write-stage names. A channel-order entry identifies a possible same-parent order stage and, only when its chain explicitly acknowledges reparenting, a possible cross-parent no-permission-sync stage. Scaffold resources are declarations until live planning proves exact bindings. Possible stages are an upper-bound vocabulary derived from intent, not a diff or a claim that a write is required.

Preview is credential-free and performs no Discord, policy, receipt, reservation, activity, persistence, approval, or execution operation. Its keyed request digest can compare the retained normalized input but is explicitly not an executable plan digest, confirmation, or authority grant. It never invents a future Discord ID, resolves a scaffold reference, evaluates permissions, hierarchy or capacity, or simulates state after a write.

Every live plan_guild_blueprint response contains a manifestPreview overlay built from the same deterministic sequence. Each authored entry is marked freshlyAssessed or deferred, its live phase state and nested digest are shown, and only the matching write-required current frontier can be executable. A prerequisite discovered by the live planner but absent from caller intent, such as Community required before enabling onboarding, appears separately under livePrerequisites instead of being rewritten into the manifest. This provides whole-manifest review without pretending that later phases were assessed against state that does not yet exist.

capture_guild_blueprint accepts one exact guild ID, audit reason, and stable operation key. It reads the guild profile, named settings, returned role inventory, configured-policy- and Discord-visibility-bounded channel inventory, trusted Community routing evidence, onboarding, Welcome Screen, and complete AutoMod rule inventory twice, then compares canonical projections. A change between passes, including Community routing or AutoMod policy change, returns changed-during-capture with no draft or recovery binding. Capture reads no messages, member profiles, webhooks, invites, attachments, embeds, components, expressions, AutoMod execution events or match content, or audit history. The Community audit reads only the connector member needed for complete permission evidence and returns no profile fields. Capture creates no activity entry, receipt, operation reservation, coordinator claim, local snapshot, attestation record, or server-side blueprint journal.

A stable capture converts supported standard roles, categories, text channels, forum channels, profile text, named settings, enabled Community routing, Welcome Screen, onboarding, and complete exact-ID AutoMod policy into one strict plan_guild_blueprint input. It does not automatically add roleConfigurations, roleOrder, channelMetadata, channelOrders, or channelPermissionOverwrites: those phases express same-guild mutation authority and must be authored with exact IDs or proven scaffold references, explicit desired state, and separate policy review. Enabled Community is captured only when feature state, exact routing IDs, trusted direct channel evidence, and @everyone rules-channel visibility are complete. Otherwise capture emits COMMUNITY_EVIDENCE_OMITTED and never invents a target. Captured routing reuses scaffold text-channel keys where representable and retains exact IDs for other trusted text or announcement channels. Captured AutoMod rules retain their exact ruleId, use deterministic ID-derived keys, and reuse captured scaffold channel and role keys where representable; other known references remain exact same-guild IDs. Managed roles, ADMINISTRATOR, unknown permission bits, enums, or response fields, unsupported channel types, permission overwrites, role and channel ordering, role cosmetics, forum extras, unresolved references, ambiguous logical names, unknown Community or AutoMod evidence, and resources beyond blueprint bounds are omitted or block capture under fixed codes rather than being approximated. Returned text and AutoMod policy are transient untrusted Discord content. The response includes privacy evidence, per-domain coverage, fixed non-backup limitations, and an unkeyed sha256: content fingerprint; the fingerprint is not approval or authentication.

Every planner-ready capture also returns one signed recoveryBindings entry for each represented role and channel. Each opaque attestation binds the verified application, bot, and guild; exact resource type and ID; deterministic blueprint key; complete capture fingerprint; completion and expiry times; a digest of the exact captured target projection; and every applicable omission code. Channel projection evidence includes represented metadata plus counts and presence markers for omitted settings, not the omitted overwrite or forum-tag values themselves; those boundaries remain explicit in the binding's omission codes. Attestations expire after 30 minutes, are valid only in the running connector process that created them, and are absent from blocked and changed-during-capture results. Restarting the connector invalidates every outstanding attestation. prepare_guild_recovery is the capture-only prompt: it calls only this tool, isolates an optional exact role or channel binding, requires the complete caller-retained artifact and limitation review, and stops before every planner or executor.

Channel- and role-retirement planning requires exactly one recovery choice. The preferred form supplies the matching target binding and acknowledges that the caller retained the complete blueprint and reviewed every limitation and omission:

{
  "mode": "verified-blueprint-capture",
  "attestation": "guild-recovery.v1.<opaque-payload>.<signature>",
  "acknowledgeCallerRetentionAndLimitations": true
}

The explicit alternative records the operator's decision to proceed without a recovery artifact:

{
  "mode": "none",
  "acknowledgeNoRecoveryArtifact": true
}

Planning fetches fresh exact target state, recomputes the captured projection digest, and verifies the signature, 30-minute lifetime, application, bot, guild, resource kind, resource ID, and projection match. A forged, expired, cross-process, wrong-target, wrong-kind, identity-mismatched, or stale attestation fails before a plan is returned. The keyed plan binds the raw attestation only through its SHA-256 digest plus the verified credential-free recovery projection; signed confirmation state also carries only that digest. Deletion plans, confirmations, execution results, activity, operation receipts, logs, and telemetry never return or persist the raw attestation. Execution requires the identical recovery choice and a fresh matching plan. The explicit no-artifact branch adds a visible warning that the connector cannot restore the Discord content or original resource identity. Neither branch weakens any deletion scope, dependency, permission, freshness, approval, journaling, non-retry, or readback gate, and a verified attestation is not proof that the caller actually retained its companion blueprint.

ready means the selected representable state has no known omission and may be retained for a fresh plan. review-required returns a valid partial draft and target bindings that disclose its omissions, but the partial desired state and exact-bound references must be explicitly accepted or edited before blueprint planning. blocked returns no draft or binding until its blockers are resolved, and changed-during-capture must be retried. Capture is an authoring and same-guild recovery aid, not an atomic or complete backup. It does not prove caller retention or provide lossless restore, automatic rollback, original-ID restoration, message recovery, or cross-guild portability, and neither its draft nor an attestation supersedes fresh deletion or blueprint planner evidence.

The strict manifest always contains one bounded additive scaffold plus at least one role-configuration, role-order, channel-metadata, channel-order, channel-permission-overwrite, profile, settings, Community, Welcome Screen, onboarding, AutoMod, or publication phase. The coordinator uses the fixed order structure, exact role-configuration targets, bottom-up role-ordering adjacencies, exact channel-metadata targets, bottom-up channel-ordering adjacencies, exact-channel channel-permission-overwrite targets, profile, settings, community, welcome-screen, onboarding, ordered auto-moderation rules, then ordered publication steps, skipping an omitted phase. Role-configuration, channel-metadata, and overwrite arrays share a bounded convergence limit, reject duplicate target identities, and normalize by numeric snowflake and target identity, so caller array ordering does not change execution identity. roleOrder and channelOrders are different by design: their unique role or channel references preserve the caller's semantic top-to-bottom chains. Channel references must also remain globally unique across every channel-order chain before and after exact scaffold resolution. Profile accepts only a complete desired guild name and/or nullable description. Settings accepts the existing named sparse settings. afkChannel can be null or an exact { "kind": "exact", "channelId": "..." } reference to an existing voice channel because scaffolds do not create voice channels. systemChannel can additionally be a { "kind": "scaffold", "key": "..." } reference to a requested text channel.

roleConfigurations manages sparse fields on existing standard roles by exact roleId. Each entry reuses the standalone role-configuration schema without its guild, audit reason, or operation key. It can set name, colors, hoist, mentionability, one tagged icon intent, and either exact permissions or grantPermissions and revokePermissions. Exact permissions are the complete desired set of known permission names: they preserve every unknown future Discord bit, can be empty, cannot be combined with deltas, and cannot include ADMINISTRATOR. Every target still requires the standalone exact role allowlist, complete inventory and holder-count evidence, strict hierarchy, grantability, connector-continuity proof, one-shot receipt, and exact response plus readback verification. Names are transient desired fields, never target selectors.

roleOrder is a unique top-to-bottom chain of at least two role references. Each reference is either an exact existing standard-role ID or a scaffold role key whose exact ID is proven by the completed scaffold receipt. Planning resolves one adjacent pair at a time from the bottom upward and delegates an immediate above placement to the standalone role-ordering domain. Bottom-up convergence establishes the lower anchor before moving the next higher role, so every new frontier is assessed against fresh live hierarchy rather than a predicted bulk result. The target and anchor become adjacent; unrelated roles crossed by the move keep their mutual order but may change rank. Every adjacency still requires the exact role-order guild scope, complete role inventory and holder counts, strict connector hierarchy, MANAGE_ROLES, signed approval, durable guild-collection and exact-role coordination, one non-retried write, complete response validation, and full hierarchy readback. Names, numeric positions, managed roles, @everyone, duplicate references, and caller-supplied create results never select a target.

channelMetadata manages sparse type-applicable fields on existing non-thread guild channels by exact channelId. Each entry reuses the standalone channel-metadata schema without its guild, audit reason, or operation key. Omitted fields are unmanaged; explicit null or an empty topic clears the topic. Every target still requires the standalone exact channel allowlist, complete role and overwrite evidence, VIEW_CHANNEL and MANAGE_CHANNELS, conditional CONNECT for voice and Stage channels, one-shot receipt, and exact response plus readback verification. This phase does not move, reorder, create, delete, convert, or synchronize a channel, replace permission overwrites or forum tags, or mutate a thread.

channelOrders is a bounded set of top-to-bottom chains containing at least two exact existing or receipt-bound scaffold channel references. Each adjacency moves the higher channel immediately above the next lower anchor, and planning walks each chain from the bottom upward so every frontier uses fresh live topology instead of a predicted bulk result. Categories form one sortable family; text, announcement, forum, and media channels form another family within a parent. Voice and Stage channels remain available through the standalone exact workflow but cannot be scaffold references because scaffolds do not create them. A reference may appear in only one chain, and resolved exact aliases are rejected before any convergence-domain read.

Same-parent ordering needs no extra acknowledgement. A live cross-parent adjacency returns the content-free reparenting-acknowledgement-required blocker unless that chain contains literal "acknowledgeReparenting": true; known scaffold parents that differ are rejected during local normalization without it. Acknowledgement permits only the exact target to move to the anchor's category or guild root. It does not authorize a family change, arbitrary parent ID, permission synchronization, metadata edit, or overwrite replacement. The standalone planner must still prove complete coherent source and destination groups, category capacity, source-group, destination-group and target authority, and exact permission-overwrite preservation. Execution uses signed approval, durable guild-channel coordination, one non-retried complete normalized position PATCH, and a strictly newer complete matching Gateway layout plus coherent HTTP readback. Names, raw numeric positions, duplicate references, caller-supplied create results, retry, rollback, and best-effort continuation never select or settle an adjacency.

channelPermissionOverwrites is a bounded set of unique exact channel and target pairs. Every entry names one existing direct guild channelId, then selects either one exact member ID or one role reference that is exact or proven by a scaffold receipt. update accepts only named allow, deny, or inherit deltas and preserves every unspecified known permission bit; delete removes only that exact target's overwrite. Entries normalize by channel and target identity and execute one target per frontier. The phase cannot target a future scaffold channel because the standalone permission-overwrite allowlist must already contain the exact direct channel ID. It preserves member and unrelated-role overwrites, never replaces the complete channel set, and retains the standalone channel scope, complete role and overwrite evidence, connector-continuity proof, VIEW_CHANNEL, MANAGE_ROLES, signed approval, exact channel-and-target coordination, one non-retried PUT or DELETE, and complete readback.

The optional Community phase is a complete monotonic desired routing object with literal "acknowledgeCommunityEnablement": true, distinct rulesChannel and publicUpdatesChannel references, and nullable safetyAlertsChannel. Exact references may target existing text or announcement channels; symbolic references may target requested scaffold text channels only. Planning delegates to the standalone Community workflow, preserves every existing feature, can add only COMMUNITY, requires @everyone visibility for the rules channel, and never edits permissions, removes a feature, or disables Community. Routing-only changes require guild ownership or complete Manage Guild evidence. First-time enablement requires guild ownership or complete Administrator evidence; treat that authority as temporary and remove it after the Community frontier. When an enabled Welcome Screen or onboarding phase is requested without a Community phase, the coordinator performs a privacy-safe Community audit first. If Community is disabled, it returns the fixed community-phase-required blocker and plans no downstream domain; it never silently enables Community.

A Welcome Screen phase is the existing complete ordered replacement shape, except each entry uses a channel reference instead of channelId; it can target an exact existing channel or a requested scaffold text or forum channel.

An onboarding phase is the existing complete replacement shape with symbolic reference support. defaultChannels and each option's channels accept exact channel IDs or requested scaffold text or forum keys. Each option's roles accepts exact role IDs or requested scaffold role keys. Optional promptId and optionId fields remain exact Discord IDs: include them only to retain those exact existing items, and omit them to request new items. Prompt and option titles are never used for matching. Symbolic references resolve only after the scaffold planner proves every exact requested resource binding. Duplicate raw references and duplicate resolved Discord IDs are rejected. The onboarding planner still proves direct @everyone-visible channels, zero-authority self-assignable roles below the connector, complete guild features and permissions, safe emoji evidence, full-replacement deletions, and the conservative enabled-state default-channel constraints.

autoModerationRules contains a bounded ordered set of strict desired rules. Every entry has a stable key, optional exact ruleId, complete name, trigger, actions, exemptions, and final enabled state. Channel and role fields accept exact IDs or requested scaffold references; alert actions may use only exact eligible text or announcement channels or requested scaffold text channels. Omitting ruleId is an explicit create intent and never authorizes name, creator, singleton, trigger, or inventory-position adoption. A colliding live name blocks with exact rule IDs for review. Existing exact rules block if missing or if their immutable trigger type differs. Omission from the manifest never deletes a rule.

New rules are created disabled. A matching schema-v2 AutoMod receipt with a keyed request digest is the only way an unbound rule recovers its exact Discord ID after execution or restart. After the blueprint facade verifies pinned identity, the AutoMod verifier checks the receipt before guild, permission, inventory, or exact-rule access and never returns policy content. An enabled existing rule whose policy differs first receives a reviewed disable frontier, then a complete reviewed configure frontier, then a separately reviewed enable frontier only if the manifest requests it. Every selected stage checks its own request-bound receipt before planning, so a matching completed final stage can resume without reusing a spent key. One blueprint execution advances at most one stage for one rule. Request mismatch, pending, failed, uncertain, missing exact-rule, or drifting receipt evidence blocks later phases without scanning or fuzzy matching.

publications contains a bounded ordered set of Components V2 create or exact-ID edit requests. Every entry has a unique stable lowercase key, an exact channel or active-thread reference or a requested scaffold text-channel reference, a strict bounded components layout, and optional notifyUserIds. Layouts may use the component domain's callback-free link rows and authenticated request rows but gain neither link-origin nor native Interaction authority from the blueprint. A request row remains blocked until its resolved exact channel is independently present in native Interaction scope and the paired broker and managed command are ready. Create omits messageId; edit requires it. Replies and reply-author notification are deliberately excluded. The component domain suppresses notifications by default and permits an exact user notification only when that ID is separately allowlisted and visibly mentioned in the component text. Exact channel references retain the component domain's supported-channel and active-thread checks, while scaffold references are text-channel only.

{
  "auditReason": "Build the reviewed community layout",
  "guildId": "200000000000000001",
  "operationKey": "replace-with-one-high-entropy-stable-key",
  "scaffold": {
    "roles": [
      {
        "key": "moderators",
        "name": "Moderators",
        "permissions": ["VIEW_CHANNEL", "MANAGE_MESSAGES"]
      },
      {
        "key": "members",
        "name": "Members"
      }
    ],
    "channels": [
      {
        "key": "information",
        "kind": "category",
        "name": "Information"
      },
      {
        "key": "announcements",
        "kind": "text",
        "name": "announcements",
        "parentKey": "information"
      },
      {
        "key": "rules",
        "kind": "text",
        "name": "rules",
        "parentKey": "information"
      }
    ],
    "stepLimit": 2
  },
  "roleConfigurations": [
    {
      "roleId": "210000000000000001",
      "permissions": ["VIEW_CHANNEL", "SEND_MESSAGES"],
      "mentionable": false
    }
  ],
  "roleOrder": [
    {
      "kind": "scaffold",
      "key": "moderators"
    },
    {
      "kind": "scaffold",
      "key": "members"
    }
  ],
  "channelMetadata": [
    {
      "channelId": "220000000000000001",
      "name": "general",
      "rateLimitPerUser": 5
    }
  ],
  "channelOrders": [
    {
      "channels": [
        {
          "kind": "scaffold",
          "key": "announcements"
        },
        {
          "kind": "scaffold",
          "key": "rules"
        }
      ]
    }
  ],
  "channelPermissionOverwrites": [
    {
      "channelId": "220000000000000001",
      "mode": "update",
      "target": {
        "kind": "role",
        "role": {
          "kind": "scaffold",
          "key": "members"
        }
      },
      "changes": [
        {
          "permission": "VIEW_CHANNEL",
          "state": "allow"
        },
        {
          "permission": "SEND_MESSAGES",
          "state": "deny"
        }
      ]
    }
  ],
  "profile": {
    "name": "Reviewed Community"
  },
  "settings": {
    "defaultMessageNotifications": "only-mentions",
    "systemChannel": {
      "kind": "scaffold",
      "key": "announcements"
    },
    "verificationLevel": "medium"
  },
  "community": {
    "acknowledgeCommunityEnablement": true,
    "publicUpdatesChannel": {
      "kind": "scaffold",
      "key": "announcements"
    },
    "rulesChannel": {
      "kind": "scaffold",
      "key": "rules"
    },
    "safetyAlertsChannel": null
  },
  "welcomeScreen": {
    "enabled": true,
    "description": "Welcome to the reviewed community",
    "channels": [
      {
        "channel": {
          "kind": "scaffold",
          "key": "announcements"
        },
        "description": "Read the latest community news",
        "emoji": {
          "kind": "unicode",
          "unicode": "\uD83D\uDC4B"
        }
      }
    ]
  },
  "onboarding": {
    "enabled": false,
    "mode": "advanced",
    "defaultChannels": [
      {
        "kind": "scaffold",
        "key": "announcements"
      }
    ],
    "prompts": [
      {
        "type": "multiple-choice",
        "title": "Choose your community path",
        "singleSelect": true,
        "required": false,
        "inOnboarding": true,
        "options": [
          {
            "title": "Community member",
            "description": "Follow community announcements",
            "roles": [
              {
                "kind": "scaffold",
                "key": "members"
              }
            ],
            "channels": [
              {
                "kind": "scaffold",
                "key": "announcements"
              }
            ],
            "emoji": {
              "kind": "unicode",
              "unicode": "\uD83D\uDC4B"
            }
          }
        ]
      }
    ]
  },
  "autoModerationRules": [
    {
      "key": "community-safety",
      "name": "Community safety",
      "trigger": {
        "type": "keyword",
        "keywordFilter": ["blocked phrase"]
      },
      "actions": [
        {
          "type": "block-message",
          "customMessage": "Please keep the community welcoming."
        },
        {
          "type": "send-alert-message",
          "channel": {
            "kind": "scaffold",
            "key": "announcements"
          }
        }
      ],
      "exemptChannels": [],
      "exemptRoles": [
        {
          "kind": "scaffold",
          "key": "moderators"
        }
      ],
      "enabled": true
    }
  ],
  "publications": [
    {
      "action": "create",
      "key": "launch-message",
      "channel": {
        "kind": "scaffold",
        "key": "announcements"
      },
      "components": [
        {
          "kind": "container",
          "accentColor": 5793266,
          "components": [
            {
              "kind": "text",
              "content": "# Welcome\nStart with the community news above."
            },
            {
              "kind": "separator",
              "spacing": "small",
              "divider": true
            },
            {
              "kind": "text",
              "content": "Use the onboarding choices to personalize your experience."
            }
          ]
        }
      ],
      "notifyUserIds": []
    }
  ]
}

1. Compile a fixed public starter, author a custom manifest, or capture a same-guild live draft, then retain the exact manifest and master operation key in the client or operator workflow. For a starter, inspect the normalized request, make only intended presentation changes, and retain that exact result. For capture, retain ready, or explicitly accept or edit every review-required omission before continuing. The connector does not store any form.
2. Call preview_guild_blueprint with the retained manifest. Review the complete normalized intent, dependency sequence, references, possible stages, and explicit authority boundary. Keep the raw master key only in the caller-retained input.
3. Call plan_guild_blueprint with the unchanged manifest and review the aggregate identity, whole-manifest assessment overlay, planner-discovered prerequisites, caller-retained request digest, warnings, and complete nested plan for the first frontier that needs action.
4. Call execute_guild_blueprint with the identical manifest plus the aggregate plan digest. Approve only the displayed frontier.
5. Review the nested result, retain the manifest unchanged, and call plan_guild_blueprint again. One execution call never advances into a second phase.
6. Repeat the plan, review, and execute loop until planning returns already-current with no frontier. If planning returns blocked, explicitly acknowledge the exact channel-order chain only when its disclosed cross-parent move is intended, add an acknowledged Community phase when the fixed dependency blocker requires it, or inspect the content-free AutoMod or publication verifier status and exact IDs before choosing a new reviewed intent and key. Execution performs no write for any blocker.
7. Call verify_guild_blueprint with the same manifest. Treat only verified as fresh completion evidence; blocked means a channel-order reparenting acknowledgement or Community prerequisite is absent, or an AutoMod or publication receipt conflicts, remains unsettled, or no longer matches exact live state.

The master operation key is never forwarded to a domain. The coordinator derives a deterministic HMAC-separated key for each singleton phase, exact role-configuration target, role-order adjacency identity, exact channel-metadata target, channel-order adjacency identity, exact channel-and-overwrite-target pair, stable AutoMod rule and stage, and stable publication key, so structure, convergence, profile, settings, Community, Welcome Screen, onboarding, AutoMod, and individual publication operations cannot collide while intentional replanning addresses the same nested operation. Canonically sorted exact targets retain identity across array reordering. Each role or channel adjacency retains identity from its ordered target and anchor references rather than its array index. Reordering AutoMod rules or publications changes the manifest digest but preserves each item's operation identity. Changing any settled nested request under the same derived key produces a request-mismatch conflict rather than repurposing a spent key. The keyed request digest binds the complete normalized manifest without revealing it; the aggregate process-bound plan digest additionally binds the exact nested frontier, verifier codes, blocker, and verified resource bindings. Signed MCP request state contains only those two digests. A changed manifest, key, phase, Discord snapshot, nested digest, or connector process requires a new review.

Planning evaluates satisfied phases until it reaches the first required write, then marks later phases waiting. Its manifest overlay still shows every later intent entry, but labels it deferred and non-executable rather than projecting a live diff from stale or hypothetical state. For every reached role-configuration target, role-order adjacency, channel-metadata target, channel-order adjacency, or channel-permission-overwrite target, the coordinator invokes a narrow receipt-aware domain planner. With no prior receipt it behaves like ordinary standalone planning. A prior receipt can satisfy the target only when it is completed, verified as a match, bound to the same guild and exact resolved resources, and a fresh complete plan proves the requested state needs no write. Any pending, failed, uncertain, drifted, wrong-target, or later-divergent evidence preserves the spent-key conflict. Ordinary standalone planning never gains receipt reuse. A channel-order plan that discovers a live parent change stops as a content-free blocker before approval unless its exact chain acknowledged reparenting. Newly created onboarding prompts and options follow the same boundary: a verified completed receipt may recognize Discord-assigned IDs only while every ordered field and reference still matches; normal planning never adopts an existing ID-less item. A reached Community phase resolves only exact or proven scaffold text-channel bindings and delegates its complete request to the standalone Community planner. Without that phase, enabled Welcome Screen or onboarding intent triggers the read-only Community prerequisite audit described above. For each reached unbound AutoMod rule the coordinator first invokes the restart-safe AutoMod verifier. A matching completed receipt binds the exact created rule ID; a missing receipt checks only for an exact live name collision before delegating disabled creation to the AutoMod planner. Exact rule IDs are read directly. Policy changes are staged only while disabled, and enabling is always a separate frontier. After selecting a configure, disable, or enable stage, the coordinator verifies that stage's request-bound receipt before calling its planner. A matching completed final stage proves satisfaction without reusing a spent key; unsettled or drifting evidence blocks, and an intermediate stage that changes during reconciliation requires a fresh plan. For each reached publication the coordinator similarly invokes the component verifier; a matching completed receipt triggers one exact receipt-bound message GET, while a missing receipt falls through to the component planner. Any request mismatch, pending, failed, uncertain, malformed target, missing exact resource, or live-state mismatch becomes a content-free blocker and stops later phases. The coordinator never trusts a caller-supplied create result, scans rule or message history for recovery, embeds a managed marker, or persists a content-bearing checkpoint.

Execution recomputes the whole aggregate frontier and delegates exactly one nested request to the existing scaffold, role-configuration, role-ordering, channel-metadata, channel-ordering, channel-permission-overwrite, profile, settings, Community, Welcome Screen, onboarding, AutoMod, or component-message executor. The nested workflow retains its own durable coordination, shared interaction limiter where applicable, one-shot reservation, pending content-free activity, non-retried mutation, exact readback, drift reporting, and uncertainty quarantine. The coordinator creates no blueprint receipt or checkpoint of its own. Verification projects only identities, hashes, phase states, exact resources, hierarchy and channel-order target and anchor IDs, overwrite channel and target IDs, AutoMod rule IDs, and publication message IDs without symbolic keys, fixed verifier and receipt status codes, and existing content-free domain evidence. Guild, role, channel, and rule names, role permission intent, role colors and icons, channel metadata, overwrite values, AutoMod triggers and actions, topics, profile and Welcome Screen descriptions, onboarding prompt and option titles and descriptions, component trees, text, link destinations and origins, notification user IDs, Unicode emoji, audit reasons, symbolic keys, and the master operation key remain transient and are never included in verification.

The coordinator deliberately covers additive structure, bounded exact-ID standard-role configuration, bounded exact or receipt-bound role-order chains, bounded exact-ID sparse channel metadata, bounded exact or receipt-bound channel-order chains, bounded exact-channel one-target permission-overwrite convergence, sparse profile, named settings, monotonic Community enablement and routing, complete ordered Welcome Screen replacement, complete onboarding replacement, bounded exact-target AutoMod composition, and bounded Components V2 publications only. Parent-category overwrite synchronization, feature removal, deletion of omitted resources or AutoMod rules, arbitrary callback-bearing components, attachments, replies, and other administration remain separate reviewed workflows. The connector does not translate arbitrary prose into a fixed theme, infer a community type, import remote templates, fuzzy-adopt resources, search for managed markers, or persist a portable content-bearing plan token. The fixed local starter compiler covers only its published public layouts and returns a strict request without planning or authority. The optional author_guild_blueprint prompt lets a compatible client model draft a transient custom candidate from literal objective data, but it calls no tool, invents no exact ID, chooses no starter, and performs no validation. The caller must retain and inspect the candidate, pass it through the separate local preview, then pass its exact JSON to review_guild_blueprint; the strict manifest remains the reviewed source of truth.

Canonical source: docs/reference.md