Design a Consistent Error-Handling Strategy for Your App

You are a senior engineer designing error handling for a small application — the boring discipline that separates "flaky" from "trustworthy".

<context>
[THE APP — what it does and the stack — e.g. "Node/Express API plus React front end for booking jobs"]
[FAILURE REALITY — what actually goes wrong today: paste example errors or logs if you have them]
[WHO SEES FAILURES — e.g. "customers booking online, staff on the admin side"]
[EXTERNAL DEPENDENCIES — payment gateway, email service, third-party APIs, database]
[CURRENT STATE — e.g. "try/catch scattered randomly, console.log everywhere, no alerting"]
</context>

Before designing, classify the failure space for THIS app into: expected-and-recoverable (bad user input, double submits), expected-and-degradable (email service down — the booking still saves), and unexpected (bugs, broken invariants). The whole design hangs off treating these three differently.

<task>
1. Define the policy per class: where it's caught (boundary vs call site), what the user sees (exact tone and detail per audience), what gets logged, and whether the operation retries, degrades or aborts.
2. Specify the error shape: one structured error type for the app (code, human message, safe-to-show flag, correlation id, cause chain) with the actual type or class definition in my stack.
3. Show the pattern code: the boundary handler (e.g. Express error middleware plus a React error boundary, or my stack's equivalents), one example of wrapping an external dependency from my list with timeout/retry/degrade rules, and one example of validating input at the edge so deeper code can assume sanity.
4. Set the logging contract: what every logged error must include, what must NEVER be logged (passwords, tokens, card numbers, personal details beyond an id), and the one place logs go.
5. Define the alert line: which errors page a human (the unexpected class, or an expected class breaching a rate you set) versus which just sit in the log.
6. Give the migration path from my current state: the first three places to fix, and the rule all new code follows from today.
</task>

<output_format>
Policy table (class — catch where — user sees — log — action), the error-shape code, the pattern code blocks, the logging contract, the alert rules, then the migration steps.
</output_format>

Rules:
- All code idiomatic for my named stack and complete enough to paste; unknown stack details become [NEEDED: ...] rather than pseudo-code.
- User-facing messages never expose internals (stack traces, SQL, vendor names) — show one good and one bad example.
- Size everything for a small team: no error-tracking SaaS required, but name where one would slot in later.

Copy the block above straight into Claude — anything in [BRACKETS] is yours to fill in.