Guild scaffolds

Do not add a scaffold shortcut that bypasses the dedicated capability gate, exact scaffold-guild allowlist, verified application and bot identities, exact bounded symbolic graph, complete role and visible channel inventories, effective permission and strict hierarchy evidence, collision and capacity checks, durable request binding, checkpoint validation, process-keyed frontier planning, signed interactive confirmation, write-aware client approval, final fresh-plan match, bounded step limit, per-step one-shot reservation, pending activity journaling, non-retried single-resource writes, exact readbacks, or fresh review after dependencies change. If a client cannot support MCP elicitation, keep scaffold execution unavailable in that client.

Keep the surface additive-only and limited to roles, categories, text channels, and forum channels. Every child may reference only a category declared in the same request. Do not add existing-parent IDs, permission overwrites, edits, moves, positions, role assignments, deletion, rollback, skip-on-error, best-effort continuation, or blueprint reconciliation. Those operations change existing state or authority and need independent policy, evidence, plans, confirmation, recovery, and tests.

Normalize and globally de-duplicate safe symbolic keys before planning. Canonicalize role steps before categories and category children so derived operation identities never depend on caller array order. Reuse the standalone role and channel validators for exact properties and logical names. Treat an exact matching existing resource as a no-op; fail closed on ambiguity, managed roles, property mismatch, invalid parent linkage, incomplete evidence, unsupported channel types, or visibility-bounded capacity exhaustion.

Require complete guild-role evidence and exact connector-member identity. For requested roles, require MANAGE_ROLES, strict hierarchy above @everyone, forbid ADMINISTRATOR, and require every requested named permission to be a subset of the connector's effective guild permissions. For requested channels, require guild-level MANAGE_CHANNELS and VIEW_CHANNEL. Before creating a child under an existing category, require complete overwrite evidence and both permissions at that exact parent. Never claim that visible channel absence proves global uniqueness.

Bind the persistent scaffold operation to the verified application ID, bot ID, exact guild, audit reason, and canonical resource intent with a domain-separated HMAC keyed by the raw operation key. Persist only the resulting request digest and top operation-key hash. Bind the bounded execution limit, complete live evidence, ordered execution-frontier step indexes, checkpoint projection, and persistent request digest into the process-keyed reviewed plan. The execution limit may change only through a fresh plan and signed confirmation; it must not change the durable resource intent.

Derive a distinct domain-separated one-shot operation key for each canonical step. Preserve every standalone role or channel creation invariant, including a private pending receipt, pending activity record, one non-retried POST, and exact readback. Keep the top scaffold receipt pending across intentional frontier pauses. Mark it completed only after a fresh plan proves that every step is already current or has an exact matching completed checkpoint and no step remains ready or waiting for a parent.

A newly created category must end the dependency frontier for every child that references it. Require a fresh plan to discover the exact category ID, re-evaluate its permissions and capacity, and bind that evidence before child execution. Never resolve a new parent from the create response and continue under the earlier approval.

Treat any pending per-step receipt as active or interrupted work and block it without takeover. Treat failed, uncertain, drifted, missing, mismatched, or divergent checkpoints as permanent blockers for that scaffold operation key. A restart may rebuild a fresh process-keyed plan from the same raw operation key, persistent request digest, live Discord state, and immutable completed checkpoints, but it must never infer completion from a receipt alone. Require the exact receipt resource ID and current exact state to match.

Keep the top operation pending when a step fails before any per-step reservation exists because the write invariant proves that no Discord mutation began. Require exact operator review and claim release followed by a fresh reviewed plan before continuing. Serialize logical role and channel targets across different operation keys inside one connector process. The production facade must also claim both guild collections for every active scaffold, using the persistent request digest that exactly matches the top receipt rather than a process-keyed frontier digest. Release those claims after a normal verified pause, but retain quarantine after any thrown, interrupted, or uncertain pending execution. This must exclude overlapping scaffolds and standalone role or channel creation across connector processes sharing the activity-state root without implying logical-name uniqueness.

Never persist the raw operation key, symbolic keys, names, topics, named permission lists, colors, audit reasons, role names, overwrites, plan confirmation text, or raw Discord responses. Scaffold and per-step receipts may contain only domain-separated hashes, exact Discord IDs, timestamps, fixed operation, outcome, and verification states, activity IDs, and sanitized error categories. Completion verification must require the caller-retained exact request and operation key, re-run the same strict live plan checks, and return only identities, hashes, counts, step indexes, kinds, states, resource IDs, receipt status, and a fresh process-keyed digest. It must not reserve, append activity, mutate Discord, or reconstruct omitted intent from receipts. An all-current unreserved request must remain a content-free no-op without reserving the top key and verification must label it unrecorded, not verified.

Canonical source: SECURITY.md