Defensive data design

Safe defaults for code that can lose someone's work or leave them stuck. Apply them as checks, not intentions.

Errors the user sees

• Say the cause, not just the symptom. Where the failure carries a usable message, show it (and its code if that helps); fall back to your own copy when it does not. A catch that receives an error and shows a fixed string is a defect.
• Rejection shapes from apiFetch vary — see the pitfall in the root AGENTS.md before reading a cause from one.
• REST validation failures carry per-field reasons in error.data.params. The top-level message only names the field.
• Strip tags with __unstableStripHTML from @wordpress/dom rather than discarding a message that contains HTML.
• Never swallow. An empty catch is acceptable only when the failure is expected and the fallback is correct — say which failure, in a comment.
• Show enough of a failure to act on, and make it copyable where there is room. Keep the user's content out of the payload, and the current URL too: it can carry a nonce.
• Read the copy guide's Error Messaging section before writing the string. Plain words, name the cause, offer a next step.

Mutations and destructive actions

Prefer reversible changes, and make both the change and the way back visible. An irreversible one should be harder to trigger.