docs: Phase 3 portal — API_REFERENCE, ARCHITECTURE, DEPLOYMENT (email-change config), HANDOFF pass-48 (P3f)

2026-05-18 15:55:20 -07:00
parent 5edd778cf6
commit 83ff54b17c
4 changed files with 47 additions and 0 deletions
@@ -667,6 +667,10 @@ admin/board/treasurer, no client write policy; the member self-view
 (`getMyNotifications`, surfaced on `/me`) is a validated action. The
 droplet's crontab POSTs once a minute. No new permission code.

+### Member self-serve portal (`/me`; product spine Phase 3)
+
+`/me` is a 3-tab portal (Profile / Membership / Activity). The server page does all data fetching and passes plain data to a single client portal component (`me-portal-client.tsx`) that owns tab state and rendering; the read-only sections were moved verbatim from the prior flat page (no behavior change in the shell). Profile editing and inline cancels reuse existing server actions (`updateMyProfile`, `discloseAffiliations`, `cancelMySignup`, `cancelReservation`) — no new mutation surface, server-side ownership/space scoping unchanged. `getMyPayments` follows the established service-client self-view convention (treasurer-scoped RLS, strictly scoped to the caller). Self-service email change goes through Supabase Auth (`updateUser` + `/auth/confirm` `verifyOtp`); the denormalized `space_members.email` is synced only post-verification. The email-change flow depends on Supabase project config (template + redirect allowlist; see DEPLOYMENT) and is inert until that is set. No new permission code, no schema change.
+
 ---

 ## 13. Known Limitations