Guild incident actions

Keep guild incident-action inspection behind its own audit toggle and exact guild allowlist. The allowlist must remain a subset of configured read-guild scope. Require pinned application and bot identities, an exact guild and owner, exact connector membership, complete bounded roles, and complete effective guild permissions before returning an audit or plan. Audit may report absent source state or unknown-field counts, but a change must fail closed unless the Incidents Data object is available, every known timestamp is valid, no unknown incident field exists, no unknown permission bit exists, and the connector is the exact owner or has effective MANAGE_GUILD.

Project incident evidence at the REST boundary. Return only the exact guild and owner IDs needed for verification, nullable invite and direct-message disable deadlines, boolean presence for raid and direct-message-spam detection timestamps, source availability, and unknown-field counts. Never return or persist raw detection timestamps, guild or role names, raw objects, or unknown values. Treat absence as unavailable evidence, not as proof that every action is clear.

Treat every change request as one exact sparse two-field intent. Require at least one supported action, preserve omitted actions, interpret null as deliberate early clearing, and require every non-null deadline to remain strictly in the future and no more than 24 hours ahead at every planning pass. Require a bounded review reason but keep it local and digest-bound because the endpoint does not document X-Audit-Log-Reason. Do not add an immediate-call, raw-object, duration shorthand, server-local-time, fuzzy-guild, retry, rollback, or compensating shortcut.

Preserve every reviewed-write gate: verified identities, exact policy, complete known evidence, exact-owner or MANAGE_GUILD authority, strict timestamp and sparse-intent normalization, process-keyed plan binding, signed interactive confirmation, write-aware client approval, final fresh-plan match, durable exact-guild coordination, atomic one-shot operation-key reservation, pending content-free activity, one non-retried sparse PUT containing only changed action fields, strict Incidents Data response validation, and a fresh exact guild, member, role, permission, and incident-state readback. A client without MCP elicitation must not execute a guild incident-action change.

The plan digest must bind the normalized sparse request and local reason, operation-key hash, verified identities, exact owner, connector membership and roles, complete permissions, full current and desired action state, detection-presence booleans, requested and changed fields, effects, local limits, privacy projection, risks, warnings, and verification boundary. Any evidence or intent change must invalidate review. An already-current request must return without confirmation, coordination, reservation, activity, or mutation.

Validate the complete Incidents Data mutation response before readback. Compare both controlled action fields with the reviewed desired state in both the response and the fresh readback, including the action the caller omitted, so concurrent external administration is reported rather than silently accepted. Report valid divergence only as controlled field names. Never return or persist raw responses, raw detection times, changed deadline values, local reasons, or permission evidence.

A definite Discord client refusal may be classified as failed. Treat rate limiting, transport failure, Discord server failure, malformed success, unknown response fields, failed response validation, failed full readback, failed receipt finalization, or any otherwise indeterminate post-reservation state as uncertain and potentially completed. Spend every reserved key after every outcome, retain a permanent same-guild uncertainty barrier inside the service instance, and never retry, roll back, or compensate automatically. Keep same-guild serialization inside each process as defense in depth. The production facade must also acquire a durable exact guild incident-actions collection claim and retain it after uncertainty.

Guild incident-action activity and operation records may contain only the exact guild ID, plan digest, operation-key hash, record timestamps, fixed verification and outcome values, activity ID, sanitized error category, and sorted requested field names where applicable. Never persist action deadlines, detection timestamps, guild or role names, permissions, local review reasons, raw operation keys, raw Discord responses, or transport causes. Non-null actions expire automatically at Discord; do not schedule a second connector write.

Canonical source: SECURITY.md