Durable reviewed-write coordination
The production connector facade must acquire a durable exact-target claim before invoking any reviewed workflow backed by OperationStore. Resource target namespaces are shared across operation kinds so channel, message, member, role, webhook, and integration mutations cannot bypass one another. Guild-level create and complete-state workflows must claim the applicable bounded collection namespace. Application-emoji changes must claim the verified application's complete emoji collection. A resumable guild scaffold must claim both the guild role and channel collections using its persistent request digest. Channel placement must claim the whole guild channel collection plus the exact target, anchor, and any source or destination parent categories. Integration deletion must additionally claim the guild integration and webhook collections plus the associated bot member when present. Multi-target claims must publish in deterministic order, release every partial acquisition before waiting, let a known same-process predecessor finish and replan, and fail fast against a different live process.
Never expire or steal a claim because time elapsed. A later process may reclaim a dead owner's claim automatically only when the matching operation receipt is absent, belongs to a different reviewed plan, or is terminal with completed or failed status. Read receipt evidence through a stable private-file handle with no symlink traversal and reject identity or metadata changes across the read. A matching pending or uncertain receipt, unreadable receipt, malformed state, indeterminate owner, or inconsistent multi-target record is quarantined. PID liveness may prove only that an owner still exists; it cannot prove whether Discord applied a request.
Keep coordination state beside the activity and operation state in owner-private directories. Publish only complete records atomically, sync files and directory entries before advancing, reject symlinks, extra hard links, public modes, foreign ownership where inspectable, unknown fields, invalid target bindings, and oversized or malformed records, and remove only a freshly reread exact claim identity. Coordination records may contain only exact Discord target identifiers, bounded target and operation kinds, operation-key hashes, plan digests, PIDs, timestamps, schema versions, and random claim IDs. Never store names, content, reasons, payloads, URLs, local paths, raw operation keys, credentials, permission evidence, or transport details.
Operator resolution must remain a credential-free local CLI action, never an MCP tool. Require the claim ID as exact confirmation, refuse a live or indeterminate owner, and instruct the operator to stop the owner and inspect Discord before proceeding. Publish an immutable content-free acknowledgement before releasing target claims. A partial resolution may finish only from the exact acknowledgement and claim identity. Never delete or reopen the immutable operation receipt or make the old operation key reusable.
Advertise coordination only when connector processes share one canonical local activity-state root on a local filesystem. Local file-creation and rename atomics are not a network-filesystem coordination guarantee. Direct construction of an individual workflow service retains only its documented process-local defense. A scaffold callback that returns normally with its exact matching top receipt still pending may release its collection claims so an intentional pause can resume elsewhere. An exception, process loss, mismatched receipt, uncertain state, or unreadable evidence must retain quarantine. Message deletion claims each exact message target through its durable one-shot identity. Member moderation remains excluded until it gains the same model, and ordinary interactions retain Discord-nonce and throughput semantics.
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.