Add specificity to error handling messages on registration - Check registration error logs

[rcraw]

In the registration process, formatting or other requirements may prevent successful registration. Yet the error messages are generic...
"Registration Failed. Please try again or contact retreat@agentics.org"

We need to pass the specific error generated to the user so they can self-correct the registration form.

Also, review format rules to ensure the least possible friction.

Check logs for Kunal Dalal's registration attempts.

[nicholas-ruest]

Update — ADR-027 (docs/ADR-027-registration-error-messages.md) drafted to address all three asks; client-side implementation is done locally and ready to commit/PR.

Client-side (this repo, forward-compatible — ships before the backend, no flag day):

• src/lib/api.ts — ApiError now carries { status, code, message, field }. The HTTP client parses the structured envelope ({ error: { code, message, field } }) when the backend sends it, falls back to the current { error: "string" } / plain-text shapes otherwise. No regression against today's backend.
• src/pages/Register.tsx, src/pages/Home.tsx, src/pages/FAQ.tsx — every form catch block now routes field-attributable failures inline via setError and surfaces the backend's message verbatim in the toast for global failures. The single generic line is now a fallback, not the default.
• Zod schemas tightened to reduce surprise rejections (the issue's second ask — "review format rules to ensure the least possible friction"):
  • Phones: permissive E.164-ish regex /^\+?[\d\s()-]{7,20}$/, trimmed; emergencyPhone required, attendee phone optional.
  • Emails: .trim().toLowerCase().max(254).email() everywhere — matches what Stripe Checkout will accept.
  • Names: .trim().min(2).max(100).
  • partner validated as .email() (was a free string); only required when tier=buddy.
  • dietaryReqs and contact message capped to prevent absurd inputs.

Verified: npm run typecheck clean, npm run build succeeds, Vite dev server transforms all four files HTTP 200.

Backend (separate repo — agenticsorg/agentics, crm/dashboard/functions/src/api/retreat.ts):

Per ADR §2.1 the four retreat* Cloud Functions need to emit the structured envelope with a stable code set: VALIDATION_FAILED, INVENTORY_SOLD_OUT, DUPLICATE_REGISTRATION, STRIPE_REJECTED, RATE_LIMITED, INTERNAL_ERROR. Plus structured logs ({ code, field, email_hash, tier, ip }) so "check the logs for X" becomes a real query (ADR §2.4). That PR is the follow-up.

On the third ask (Kunal Dalal's registration attempts):

That log lookup is gated on GCP auth + a Cloud Functions log query and needs to happen separately from the code change. The structured logging in ADR §2.4 is specifically designed so this kind of "check the logs for so-and-so" question becomes trivially answerable next time, rather than an ad-hoc manual scan.

ADR doc: https://github.com/agenticsorg/retreat-agentics-org/blob/main/docs/ADR-027-registration-error-messages.md (committing shortly)