Exact thread-state audit and reviewed governance

Thread governance is independent of ordinary thread listing, inherited parent reads, thread creation, forum posts, message pins, and permission-overwrite management. Set capabilities.threadAudit: true, configure non-empty exact scopes.threadGuildIds and scopes.threadIds, and keep those allowlists inside the corresponding read allowlists. get_thread_state accepts one exact guild and thread ID. get_thread_membership additionally requires one exact user in scopes.threadMemberUserIds. Neither tool lists members, searches by name, returns messages, or relies on a cached Gateway view.

Every audit verifies the pinned application and bot identity, exact guild and owner, exact connector membership, strict thread state, supported exact parent relationship, complete bounded roles and parent overwrites, and effective inherited permissions. Results contain only bounded guild, parent, thread, and optional member names; explicit lifecycle fields; exact IDs; membership booleans and nullable join times; complete permission evidence; discarded unknown-field counts; and a privacy projection. Member counts, message counts, last-message IDs, tags, flags, timestamps, raw permission summaries, embedded guild members, raw payloads, and unknown-field values are omitted. An exact thread-member 404 proves absence only after the exact thread, parent, guild, connector identity, and inherited access evidence have succeeded; any other lookup failure remains an error, and a thread GET 404 is never a no-op. The exact discord://guilds/{guildId}/threads/{threadId} and discord://guilds/{guildId}/threads/{threadId}/members/{userId} resources apply the same gates and minimization.

Set capabilities.threadChanges: true only after audit scope is working. The strict action union supports rename, archive, unarchive, lock, unlock, set-auto-archive-duration, set-slowmode, set-invitable, join, leave, add-member, and remove-member. Join and leave always target the verified connector bot and accept no user ID. Each other request accepts only its one action-specific field. Invitation policy is private-thread only. Listing, bulk membership, thread deletion, applied-tag changes, pins, message edits, retries, rollback, and multi-field PATCH requests remain outside this surface.

1. Call plan_thread_change with the exact action-specific request, guild and thread IDs, optional exact allowlisted user ID, Discord audit-log reason, and unique one-shot operation key.
2. Review the verified identities, exact guild, parent, thread and optional member, minimized current and desired state, connector and target membership, complete inherited permission evidence, action-specific authorization basis, privacy projection, risks, warnings, operation-key hash, and keyed digest.
3. Call execute_thread_change with identical intent plus the digest.
4. Approve the signed MCP confirmation only if every exact identity, state, permission, authority result, risk, warning, reason, hash, and digest remains intended.
5. Review the exact state or membership readback, fixed drift fields, activity ID, verification state, and outcome before any related operation.

All real changes require complete known lifecycle metadata and VIEW_CHANNEL. Rename, archive, auto-archive, lock, unlock, slowmode, and invitation-policy changes require MANAGE_THREADS. Unarchive requires exact connector membership and SEND_MESSAGES_IN_THREADS; a locked thread additionally requires MANAGE_THREADS. Connector join and leave follow Discord's documented active-thread requirement and do not invent a send or unlocked-state requirement. A private-thread connector join or leave additionally requires MANAGE_THREADS so complete pre-write access and exact post-write readback remain possible. Member addition requires SEND_MESSAGES_IN_THREADS plus connector membership or MANAGE_THREADS, exact target parent visibility, and MANAGE_THREADS for a non-invitable private thread. Member removal requires MANAGE_THREADS or exact connector ownership of a private thread, and rejects configured protected users, the guild owner, and administrators. Active and unlocked state is required where Discord's lifecycle makes the requested action unsafe.

The process-keyed digest binds the normalized request, verified application and bot, exact guild, parent and thread, connector and optional target membership, complete roles and overwrites, current lifecycle state, permission and authority evidence, privacy projection, audit reason, and domain-separated operation-key hash. Relevant drift invalidates approval. An already-current request returns a record-free no-op without confirmation, reservation, activity, or mutation.

A real execution atomically reserves the operation-key hash, appends pending content-free activity, sends one non-retried single-field PATCH, exact connector @me membership PUT or DELETE, or exact member PUT or DELETE, validates any returned thread state, and performs an exact state or membership readback. Safe unrelated lifecycle divergence is reported as completed-with-drift. A known pre-write Discord 4xx refusal may settle as failed. Rate limits, transport or server failures, malformed success, mismatched response, readback failure, or any indeterminate post-reservation state are uncertain and potentially completed. Every reserved key remains spent. The production facade acquires a durable exact thread claim plus an exact member claim for targeted membership actions, so connector processes sharing the activity-state root exclude overlapping changes and uncertainty retains the claims for operator review. Direct service instances retain same-thread serialization as defense in depth.

Thread-member endpoints do not document an audit-log reason header, so their reviewed reason remains transient and is not claimed as a Discord audit-log entry. Durable records contain only the action, exact guild and thread IDs, optional target user ID, plan digest, domain-separated operation-key hash, timestamps, fixed status and verification values, activity ID, and sanitized error category. They never contain thread, parent, guild, or member names; lifecycle values; membership timestamps; permission evidence; audit reasons; raw keys; response bodies; or transport causes. See Discord's thread metadata, thread modification, and thread member endpoints references.

Canonical source: docs/reference.md