Define Errors

Core Rules

1. All variants for a domain live in one defineErrors call — never spread them across multiple calls
2. The factory function returns { message, ...fields } — that is the entire API; no .withMessage(), .withContext(), or .withCause() chains
3. cause: unknown is just a field like any other — accept it in the input and forward it in the return object
4. Call extractErrorMessage(cause) inside the factory, never at the call site
5. Each call like MyError.Variant({ ... }) returns Err(...) automatically — no separate FooErr pair
6. Shadow the const with a same-name type using InferErrors — const FooError / type FooError
7. Use InferError<typeof FooError.Variant> to extract a single variant's type when needed
8. Variant names describe the specific failure mode — never use generic names like Service, Error, or Failed
9. Aim for 2–5 variants per domain, each named by failure mode
10. Write .message for end-user readability — toastOnError shows .message as the muted toast description below the bold title. Write messages that make sense to users, not just developers. Avoid raw paths, status codes, or stack traces as the primary message. Include them after a human-readable prefix:

// ✅ GOOD — human-readable prefix, technical detail after