Channel deletion

Keep channel retirement behind its independent audit and change capabilities, non-empty exact channel allowlist, exact read scope, pinned application and bot identities, complete continuity-stable Gateway and HTTP evidence, type-specific permission proof, and the separate channel-deletion toolset. Do not add an immediate, fuzzy, bulk, cleanup, retry, recreation, rollback, or absent-target-success path.

Require every plan and execution request to make exactly one recovery choice in addition to literal irreversible-content-loss acknowledgement. The preferred choice must contain a fresh signed binding from a stable planner-ready two-pass guild blueprint capture plus literal acknowledgement that the caller retained the complete blueprint and reviewed its limitations and omissions. Verify the process-local signature, fixed 30-minute lifetime, application, bot, guild, resource kind, exact channel ID, and fresh captured channel-projection digest before returning a plan. The explicit alternative must contain literal acknowledgement that no recovery artifact is retained and must add a visible warning that content and original identity cannot be restored. Never infer either choice, substitute a binding, or let one branch relax another deletion gate.

Bind only the attestation's SHA-256 digest and verified credential-free recovery projection into the keyed plan and signed confirmation state. Return the capture fingerprint, deterministic blueprint key, capture and expiry times, target projection digest, omission codes, fixed limitations, mode, and verification state for review without returning the raw attestation. Rebuild and verify the identical choice at every existing freshness boundary. A forged, expired, cross-process, identity-mismatched, target-mismatched, wrong-kind, or stale attestation must fail before confirmation or reservation.

Preserve every dependency, permission, irreversible-loss, freshness, host approval, signed confirmation, durable coordination, one-shot reservation, pending activity, non-retry, returned-channel validation, and newer complete Gateway absence gate. An attestation is evidence that one lossy structural projection was captured, not proof that the caller retained it, a backup, rollback authority, message recovery, original-ID restoration, or permission to delete. Never persist or emit the raw attestation in a deletion plan, confirmation, execution result, activity record, operation receipt, error, log, trace, metric, or telemetry attribute.

Canonical source: SECURITY.md