Client error observability contracts

Global capture handlers and framework error hooks catch different, non-overlapping error surfaces; the observability contract is wiring all of them, keeping stacks readable in production without shipping original source, grouping errors so one bug is one issue, and scrubbing PII before the payload leaves the browser. The goal is not a monitoring-vendor tutorial — it is to make sure no class of error silently disappears and no sensitive data silently ships.

Boundary with sibling skills

• Use client-error-observability-contracts for the capture wiring itself: window.onerror/error + unhandledrejection listeners, crossorigin/CORS for readable cross-origin stacks, source-map upload-vs-ship, grouping/fingerprint config, and beforeSend/scrubber PII redaction.
• Use frontend-security-baseline for the policy around a public source map as an info leak and for do-not-ship-secrets — this skill owns the capture side, not the security ruling.
• Use ssr-hydration-mismatch when the reported error is a recoverable React hydration mismatch (minified #418/#425, no server-vs-client diff).
• Use payment-page-client-security for the rule that PAN/CVV must never be logged or serialized into an error payload.

Core rule