Close INV-11: remove hardcoded SMTP credential

.cursor/handoffs/README.md

@@ -0,0 +1,31 @@
+# Cross-Repo Handoffs
+
+Use this folder to hand work cleanly between frontend and backend.
+
+## Folders
+
+- `open/` -> active requests waiting for pickup
+- `done/` -> completed requests with outcome notes
+
+## Naming
+
+Use:
+
+- `YYYY-MM-DD-backend-<slug>.md` for frontend -> backend
+- `YYYY-MM-DD-frontend-<slug>.md` for backend -> frontend
+
+## Rule
+
+Every handoff must include:
+- clear direction
+- exact requested changes
+- acceptance criteria
+- verification steps
+
+## Backend Startup Requirement
+
+Before any new backend implementation task:
+- check `open/` for frontend-originated tasks
+- communicate either:
+  - `open_handoff_tasks_found` + file names, or
+  - `no_open_handoff_tasks`

.cursor/handoffs/closed/2026-03-02-backend-doula-profile-cloudsql-bio.md

@@ -0,0 +1,112 @@
+# Handoff: Cloud SQL doula profile parity for profile tab fields
+
+## Metadata
+- Direction: `frontend->backend`
+- Priority: `P0`
+- Requested By: `frontend`
+- Date: `2026-03-02`
+- Status: `closed`
+- Related Links:
+  - `frontend-crm/src/features/doula-dashboard/components/ProfileTab.tsx`
+  - `frontend-crm/src/api/doulas/doulaService.ts`
+  - `backend/src/controllers/doulaController.ts`
+  - `backend/src/services/cloudSqlTeamService.ts`
+  - `backend/src/db/migrations/add_bio_to_doulas.sql`
+
+## Why This Is Needed
+- Doula profile save can fail with `User not found` when legacy `users` row is missing.
+- Frontend profile form includes `bio` and address fields that should persist reliably.
+- Current source split between Supabase `users` and Cloud SQL `public.doulas` causes drift.
+
+## Current Behavior
+- `PUT /api/doulas/profile` may fail for Cloud SQL-only doula identities in some environments.
+- `public.doulas` supports `bio` in code, but migration rollout and parity checks are still required.
+- Field ownership is partially ambiguous across Cloud SQL, Supabase `users`, and Supabase storage.
+
+## Expected Behavior
+- Authenticated doula can always load and update profile through `/api/doulas/profile`.
+- `bio` persists in Cloud SQL.
+- Remaining profile fields have a defined source of truth and are returned consistently.
+
+## Requested Changes
+- [x] Apply migrations in local environment:
+  - `src/db/migrations/add_bio_to_doulas.sql`
+  - `src/db/migrations/add_profile_fields_to_doulas.sql`
+- [ ] Apply migrations in all target environments (staging/production rollout).
+- [x] Ensure `/api/doulas/profile` update path supports Cloud SQL-only doula records.
+- [x] Implement final field ownership:
+  - Cloud SQL `public.doulas`: `firstname/lastname` (or `full_name` mapping), `email`, `phone_number`, `bio`, `address`, `city`, `state`, `country`, `zip_code`, `account_status`
+  - Supabase storage: `profile_picture` file storage
+  - No `business` field support needed
+- [x] Keep response shape compatible with frontend: `{ success, profile }`.
+
+## API/Contract Notes
+- Endpoint(s):
+  - `GET /api/doulas/profile`
+  - `PUT /api/doulas/profile`
+- Request shape:
+  - Current frontend sends `UpdateProfileData` from `doulaService.ts`.
+- Response shape:
+  - `profile` object with user-facing doula fields:
+    - required: `firstname`, `lastname`, `email`, `bio`, `address`, `city`, `state`, `country`, `zip_code`, `account_status`
+    - optional passthrough: `profile_picture` (from Supabase-linked source)
+    - excluded: `business`
+- Backward compatibility:
+  - Do not break existing frontend parser expectations for `profile`.
+
+## Data/Migration Notes
+- Tables:
+  - `public.doulas`
+  - optional legacy: `public.users`
+- Required migration:
+  - `yes` ->
+    - `src/db/migrations/add_bio_to_doulas.sql`
+    - `src/db/migrations/add_profile_fields_to_doulas.sql`
+      - `address TEXT`
+      - `city TEXT`
+      - `state TEXT`
+      - `country TEXT`
+      - `zip_code TEXT`
+      - `account_status TEXT NOT NULL DEFAULT 'approved'`
+
+## Backend File Touchpoints
+- `src/services/cloudSqlTeamService.ts`
+  - map/select/update added profile fields from `public.doulas`
+- `src/controllers/doulaController.ts`
+  - ensure GET/PUT profile returns new field set with Cloud SQL-first behavior
+- `src/db/migrations/add_profile_fields_to_doulas.sql`
+  - add missing columns for profile tab parity
+
+## Acceptance Criteria
+- [x] Doula can update `bio` without `User not found` error path in Cloud SQL-first profile update flow.
+- [x] `GET /api/doulas/profile` returns `bio` in profile response.
+- [x] Profile update succeeds for users present only in Cloud SQL `public.doulas`.
+- [x] `address`, `city`, `state`, `country`, `zip_code`, `account_status` now exist in Cloud SQL and round-trip via updated GET/PUT profile flow.
+- [x] `business` is not required by backend contract and is ignored safely if sent.
+- [x] Contract remains compatible with existing frontend `ProfileTab` expectations (`{ success, profile }`).
+
+## Verification Steps
+- Backend:
+  - Run both migrations in Cloud SQL.
+  - Call `PUT /api/doulas/profile` with `bio`, `address`, `city`, `state`, `country`, `zip_code`, `account_status` and confirm 200.
+  - Call `GET /api/doulas/profile` and confirm persisted fields.
+- Frontend:
+  - Update bio in profile tab and refresh page.
+  - Confirm persisted values display and no error toast appears.
+
+## Implementation Notes
+- Current frontend relies on `ProfileTab` + `updateDoulaProfile` and expects stable profile payload.
+- Profile picture remains in Supabase storage; do not move binary/media storage into Cloud SQL.
+
+## Completion Summary (2026-03-02)
+
+- Added and applied local Cloud SQL migrations:
+  - `src/db/migrations/add_bio_to_doulas.sql`
+  - `src/db/migrations/add_profile_fields_to_doulas.sql`
+- Updated Cloud SQL profile mapping and update behavior in:
+  - `backend/src/services/cloudSqlTeamService.ts`
+  - `backend/src/controllers/doulaController.ts`
+- Verified local Cloud SQL `public.doulas` now includes:
+  - `bio`, `address`, `city`, `state`, `country`, `zip_code`, `account_status`.
+- Remaining non-code rollout item:
+  - apply migrations in all target environments.

.cursor/handoffs/closed/2026-03-11-backend-doula-documents-id-mismatch.md

@@ -0,0 +1,38 @@
+# Backend handoff: Doula documents ID mismatch
+
+## Status: closed
+
+## Summary
+
+There's an **ID mismatch**: documents are stored with the **Supabase auth user id**, but the admin view loads them using the **Cloud SQL doula id**. For some doulas (e.g. info@techluminateacademy.com), those IDs can differ, so the admin sees no documents.
+
+## Proposed fix
+
+When the admin document endpoint finds no documents by Cloud SQL doula id, it should:
+
+1. Look up the doula's email in Cloud SQL
+2. Find the Supabase auth user id for that email
+3. Fetch documents by that auth user id and return them
+
+## Implementation (completed)
+
+- [x] Added `DoulaDocumentIdResolver` service to resolve Cloud SQL doula id → Supabase auth user id via email
+- [x] Updated `getDoulaDocumentsAdmin`: try Cloud SQL id first; if no docs, fallback to auth user id by email
+- [x] Updated `reviewDocument` and `getDocumentUrl`: use `isDocumentOwnedByDoula` for ownership check (handles ID mismatch)
+- [x] Frontend: No changes required
+
+## Optional quick check
+
+In Supabase, run:
+
+```sql
+SELECT doula_id, file_name, document_type FROM doula_documents;
+```
+
+In Cloud SQL, run:
+
+```sql
+SELECT id, email FROM public.doulas WHERE email = 'info@techluminateacademy.com';
+```
+
+If the `doula_id` in `doula_documents` is different from `id` in `doulas`, that confirms the mismatch.

.cursor/handoffs/closed/2026-05-11-backend-request-intake-referral-source-other.md

@@ -0,0 +1,64 @@
+# Backend handoff: request intake & client referral fields (`referral_source_other`)
+
+## Status: closed
+
+## Completion summary (2026-05-11)
+
+- **Intake** (`POST /requestService/requestSubmission` → `RequestFormService.newForm`): `referral_source` is required and must be one of the CRM enum values; `referral_source_other` is required (trimmed non-empty) when source is `Other`; otherwise stored as null. `referral_email` validated when non-empty. Shared rules in `src/constants/referralSource.ts` (`parseIntakeReferral`).
+- **Persistence**: `phi_clients` INSERT extended with `referral_source`, `referral_name`, `referral_email`, `referral_source_other`. Migration `src/db/migrations/add_phi_clients_referral_intake_fields.sql` adds columns if missing.
+- **Staff PATCH** (`updateClient`): `normalizeStaffReferralOperationalPatch` runs when any referral field is present; if `referral_source` is set to a non-`Other` value, **`referral_source_other` is cleared server-side** (`null`).
+- **GET /clients/:id** (PHI merge): returns `referral_source_other` with other referral fields.
+- **Types / entities**: `RequestFormData`, `RequestFormResponse`, `User`, `ClientDetailDTO`, `RequestForm` entity; `cloudSqlClientRepository` map + `updateClient` + `updateClientOperational` allowlists; `phiFields` `OPERATIONAL_UPDATE_COLUMNS` + `referralSourceOther` alias; `supabaseClientRepository` parity for shadow/legacy.
+- **Tests**: `src/__tests__/requestEndpoint.test.ts` updated and expanded.
+- **Docs**: `docs/CLOUD_SQL_SOKANA_PRIVATE_SCHEMA.md` updated.
+
+---
+
+## Direction (original)
+
+`frontend` → `backend` (Sokana CRM frontend contract)
+
+## Summary (original)
+
+The public **request form** and **admin lead/client profile** were updated in the frontend. Align the API and persistence layer so the same fields validate, save, and return consistently.
+
+---
+
+## 1. `referral_source_other` (new)
+
+### Behavior (match frontend)
+
+- `referral_source` remains a **required** categorical value on intake (one of the known options, including **`Other`**).
+- When `referral_source === "Other"`, **`referral_source_other`** is **required**: non-empty string after trim (free-text explanation of how the client heard about Sokana).
+- When `referral_source !== "Other"`, **`referral_source_other`** should be **optional**; treat empty/null as “not provided” and **prefer clearing** any stored value if the client changes from `Other` to another option.
+
+### Allowed `referral_source` values (must include `Other`)
+
+`Google`, `Doula Match`, `Former client`, `Sokana Member`, `Social Media`, `Email Blast`, `Other`
+
+### Endpoints to update
+
+1. **Request submission** — `POST /requestService/requestSubmission` (`src/routes/requestRoute.ts`, `RequestFormService`, `RequestFormController`, `RequestFormRepository`).
+2. **Client / lead read + update** — staff CRM (`GET`/`PATCH` client flows in `clientController`, `cloudSqlClientRepository`, `ClientDetailDTO`, `User` entity / serializers).
+
+### Database
+
+- Nullable columns on `public.phi_clients`: `referral_source`, `referral_name`, `referral_email`, `referral_source_other` (migration adds if missing).
+
+---
+
+## 4. Acceptance criteria (backend)
+
+- [x] Request submission accepts and stores **`referral_source_other`** when `referral_source` is **`Other`**; rejects missing/blank **`referral_source_other`** in that case with a clear validation error.
+- [x] Request submission accepts **`referral_source`** = **`Other`** as a valid enum/value.
+- [x] Client/lead detail APIs return **`referral_source_other`** when set.
+- [x] Staff updates can set or clear **`referral_source_other`**; changing **`referral_source`** away from **`Other`** clears **`referral_source_other`** server-side.
+- [x] Migration + ORM/model/DTO updates completed; no silent drops of the new key in serializers.
+
+---
+
+## Completion checklist
+
+- [x] Implementation merged
+- [x] Tests green (`npm test -- --testPathPattern=requestEndpoint`)
+- [x] Handoff moved to `closed/` with summary and status updated

.cursor/handoffs/closed/2026-08-20-hipaa-13a-restrict-client-csv-export.md

@@ -0,0 +1,42 @@
+# Handoff: HIPAA-13A Restrict bulk client CSV exports
+
+## Metadata
+
+- Direction: `compliance->backend`
+- Priority: `P0`
+- Requested By: HIPAA remediation (INV-02)
+- Date: `2026-08-20`
+- Status: `ready_for_verification`
+- Related Links:
+  - `docs/HIPAA_13A_CLIENT_CSV_EXPORT_STATUS.md`
+  - `docs/HIPAA_TECHNICAL_PHI_INVENTORY.md` (INV-02)
+  - `docs/HIPAA_BOARD_TECHNICAL_STATUS.md`
+
+## Why This Is Needed
+
+`GET /clients/fetchCSV` allowed the `client` role and exported all families’
+names, income, and address. Highest-clarity P0 authorization issue.
+
+## Requested Changes
+
+- [x] Remove `client` (and non-admin) role access — interim **admin-only**
+- [x] Enforce server-side (route + use case)
+- [x] Negative tests: client, doula, billing, unauthenticated
+- [x] Log denied attempts without PHI
+- [x] Stakeholder status of access + exported fields
+- [ ] Production deploy confirmation
+- [ ] Formal closure approval / reviewer sign-off
+
+## Acceptance Criteria
+
+- Non-admin roles receive 403; unauthenticated receives 401
+- Admin still receives CSV
+- Deny logs include role/userId/event only
+- Stakeholder doc lists current export columns
+
+## Completion Summary (2026-08-20)
+
+Contained in code. Automated tests: `src/__tests__/clientCsvExportAuth.test.ts`
+— **10/10 passed**. Stakeholder brief:
+`docs/HIPAA_13A_CLIENT_CSV_EXPORT_STATUS.md`. Remaining: deploy + formal
+closure.

.cursor/handoffs/closed/2026-08-24-hipaa-13f-intake-email-minimization.md

@@ -0,0 +1,41 @@
+# Handoff: HIPAA-13F — Remove clinical information from intake emails
+
+## Metadata
+
+- Direction: `compliance->backend`
+- Priority: `P0`
+- Requested By: HIPAA board / INV-01
+- Date: `2026-08-24`
+- Status: `closed`
+- Related Links:
+  - `docs/HIPAA_13F_INTAKE_EMAIL_STATUS.md`
+  - `docs/HIPAA_BOARD_TECHNICAL_STATUS.md` (INV-01)
+  - `docs/EMAIL_NOTIFICATION_SYSTEM.md`
+
+## Why This Is Needed
+
+Public intake emailed the full clinical + identity payload to ordinary staff
+Gmail (INV-01) — direct PHI exposure.
+
+## Requested Changes
+
+- Remove clinical fields from intake emails
+- Keep PHI out of subject, body, URLs, and logs
+- Send staff to authenticated CRM instead
+- Add tests proving clinical fields are absent
+- Document approved notification template
+
+## Acceptance Criteria
+
+- [x] Staff notification contains client number + CRM link only
+- [x] Clinical / identity intake fields absent from staff subject/body
+- [x] Submitter confirmation has no name/clinical content in subject/body
+- [x] Unit + endpoint tests cover absence of clinical payload
+- [x] Approved template documented (`docs/HIPAA_13F_INTAKE_EMAIL_STATUS.md`)
+
+## Completion Summary
+
+Implemented minimal intake notification builders under
+`src/features/intake/notifications/`, wired through `requestFormController`,
+propagated `client_number` on the intake entity, and updated email/HIPAA docs.
+Pending production deploy and formal verification sign-off.