Add native labor support signing UI and billing contract viewing

.cursor/debug-304f79.log

@@ -0,0 +1,3 @@
+{"sessionId":"304f79","runId":"role-update-debug","hypothesisId":"H4","location":"src/features/hours/components/DoulaListPage.tsx:handleRoleUpdate:resolved-ids","message":"Resolved ids before role update","data":{"selectedAssignmentId":"33434fa3-3d18-4ce9-9e41-5bc9adaf10a1-daa6a441-b379-40de-b1c9-2c5ac6d14ca5","selectedAssignmentClientId":"33434fa3-3d18-4ce9-9e41-5bc9adaf10a1","selectedAssignmentDoulaId":"daa6a441-b379-40de-b1c9-2c5ac6d14ca5","resolvedClientId":"33434fa3-3d18-4ce9-9e41-5bc9adaf10a1","resolvedDoulaId":"daa6a441-b379-40de-b1c9-2c5ac6d14ca5","nextRole":"backup"},"timestamp":1772390117804}
+{"sessionId":"304f79","runId":"role-update-debug","hypothesisId":"H1","location":"src/api/doulas/doulaDirectoryApi.ts:updateDoulaAssignment:pre-fetch","message":"Preparing role update request","data":{"requestUrl":"http://localhost:5050/api/doula-assignments/33434fa3-3d18-4ce9-9e41-5bc9adaf10a1/daa6a441-b379-40de-b1c9-2c5ac6d14ca5","clientIdLength":36,"doulaIdLength":36,"role":"backup"},"timestamp":1772390117805}
+{"sessionId":"304f79","runId":"role-update-debug","hypothesisId":"H2","location":"src/api/doulas/doulaDirectoryApi.ts:updateDoulaAssignment:post-fetch","message":"Received role update response metadata","data":{"responseUrl":"http://localhost:5050/api/doula-assignments/33434fa3-3d18-4ce9-9e41-5bc9adaf10a1/daa6a441-b379-40de-b1c9-2c5ac6d14ca5","status":200,"ok":true,"statusText":"OK"},"timestamp":1772390118597}

.cursor/handoffs/README.md

@@ -0,0 +1,23 @@
+# 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

.cursor/handoffs/done/.gitkeep

@@ -0,0 +1 @@
+

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

@@ -0,0 +1,95 @@
+# Handoff: Cloud SQL doula profile parity for profile tab fields
+
+## Metadata
+- Direction: `frontend->backend`
+- Priority: `P0`
+- Requested By: `frontend`
+- Date: `2026-03-02`
+- Status: `open`
+- Related Links:
+  - `frontend-crm/src/features/doula-dashboard/components/ProfileTab.tsx`
+  - `frontend-crm/src/api/doulas/doulaService.ts`
+
+## 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.
+- `public.doulas` now has `bio` migration, but full profile parity is incomplete.
+- 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
+- [ ] Apply migrations in all target environments:
+  - `src/db/migrations/add_bio_to_doulas.sql`
+  - `src/db/migrations/add_profile_fields_to_doulas.sql`
+- [ ] Ensure `/api/doulas/profile` update path supports Cloud SQL-only doula records.
+- [ ] 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
+- [ ] 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 (read/fallback only): `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
+- [ ] Doula can update `bio` without `User not found` error.
+- [ ] `GET /api/doulas/profile` returns updated `bio` after save.
+- [ ] Profile update succeeds for users present only in Cloud SQL `public.doulas`.
+- [ ] `address`, `city`, `state`, `country`, `zip_code`, `account_status` persist and round-trip through `GET/PUT /api/doulas/profile`.
+- [ ] `business` is not required by backend contract and is ignored safely if sent.
+- [ ] Contract remains compatible with existing frontend `ProfileTab`.
+
+## 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.

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

@@ -0,0 +1,64 @@
+# Handoff: Admin cannot see doula documents (ID mismatch)
+
+## Metadata
+- Direction: `frontend->backend`
+- Priority: `P0`
+- Requested By: `frontend`
+- Date: `2026-03-11`
+- Status: `open`
+- Related Links:
+  - `frontend-crm/src/features/hours/components/AdminDoulaDocumentsSection.tsx`
+  - `backend/src/controllers/doulaController.ts` (getDoulaDocumentsAdmin)
+  - `backend/src/repositories/doulaDocumentRepository.ts`
+
+## Why This Is Needed
+- Doulas upload documents successfully via doula dashboard (stored in Supabase `doula_documents` with `doula_id` = auth user id).
+- Admin views doula profile and sees "0/5 approved" and all "Missing" even when documents exist.
+- Root cause: Admin fetches documents using Cloud SQL doula id; documents are stored with Supabase auth user id. For some doulas (e.g. legacy, different creation flows), these ids may differ.
+
+## Current Behavior
+- `GET /api/admin/doulas/:doulaId/documents` queries `doula_documents WHERE doula_id = doulaId`.
+- `doulaId` comes from the frontend (Cloud SQL `public.doulas.id`).
+- Document upload uses `req.user?.id` (Supabase auth user id).
+- When Cloud SQL doulas.id ≠ auth user id, admin sees no documents.
+
+## Expected Behavior
+- Admin should see all uploaded documents for a doula regardless of id source.
+- When documents exist under the auth user id but not the Cloud SQL id, they should be returned.
+
+## Requested Changes
+- [x] In `getDoulaDocumentsAdmin`: if primary query by `doulaId` returns 0 documents, add fallback:
+  1. Fetch doula's email from Cloud SQL `public.doulas` where id = doulaId.
+  2. Look up Supabase `auth.users` by email to get auth user id.
+  3. Query `doula_documents` WHERE doula_id = auth_user_id.
+  4. If documents found, return them (admin sees them; document approval works).
+- [ ] Optionally: log when fallback is used for debugging/migration planning.
+- [ ] Ensure `getCompleteness(doulaId)` and related calls also use the same resolution (or accept resolved id) so completeness reflects actual documents.
+
+## API/Contract Notes
+- Endpoint: `GET /api/admin/doulas/:doulaId/documents`
+- Response shape: unchanged (`{ success, documents, completeness }`).
+- Backward compatibility: Must not break doulas where ids already match.
+
+## Data/Migration Notes
+- Tables: `public.doulas` (Cloud SQL), `auth.users` (Supabase), `public.doula_documents` (Supabase).
+- Required migration: No schema change. Fallback logic only.
+
+## Acceptance Criteria
+- [ ] Admin views doula profile for info@techluminateacademy.com; uploaded documents appear (not all "Missing").
+- [ ] Admin can approve/reject documents that were uploaded by the doula.
+- [ ] Doulas where Cloud SQL id = auth id continue to work without regression.
+
+## Verification Steps
+- Backend:
+  - As doula (info@techluminateacademy.com), upload a document via doula dashboard.
+  - Query Supabase: `SELECT doula_id, file_name FROM doula_documents` — note the `doula_id`.
+  - Query Cloud SQL: `SELECT id, email FROM public.doulas WHERE email = 'info@techluminateacademy.com'` — compare ids.
+  - As admin, GET `/api/admin/doulas/{cloud_sql_id}/documents` — should return documents (with fallback if ids differ).
+- Frontend:
+  - Log in as admin, go to Doulas → click doula with info@techluminateacademy.com → View profile & approve documents.
+  - Required Documents section should show uploaded docs (not all Missing).
+
+## Implementation Notes
+- Use Supabase admin client to query `auth.users` by email (service role bypasses RLS).
+- The `DoulaDocumentCompletenessService.getCompleteness(doulaId)` is called with the same doulaId — consider passing the resolved id (auth id) when fallback applies, so completeness counts match the returned documents.

.cursor/rules/require-backend-preflight-skill.mdc

@@ -0,0 +1,18 @@
+---
+description: Require backend preflight skill before each task
+alwaysApply: true
+---
+
+# Mandatory Backend Preflight Skill
+
+Before starting implementation, first apply:
+- `.cursor/skills/sokana-backend-preflight-sync/SKILL.md`
+
+## Rule
+
+- Preflight is required for every task.
+
+## Required before coding
+
+- Update `.cursor/skills/sokana-backend-preflight-sync/backend-context.md` first.
+- Record files scanned and contract assumptions.

.cursor/rules/task-commands.mdc

@@ -0,0 +1,59 @@
+---
+description: Task command interface for open handoffs
+alwaysApply: true
+---
+
+# Task Commands Rule
+
+Treat the following user phrases as explicit task commands in this repo.
+
+## Command: `task`
+
+When the user says `task`:
+
+1. Read `.cursor/handoffs/open/`.
+2. List all open task files.
+3. For each open task, provide a detailed explanation:
+   - title and priority
+   - why it is needed
+   - requested changes
+   - acceptance criteria
+   - current completion status (checked vs unchecked items)
+4. If no open tasks exist, say so explicitly.
+
+## Command: `run task`
+
+When the user says `run task` (with or without a task name):
+
+1. Determine target task:
+   - If user provides a task file name or clear identifier, use it.
+   - If not provided and only one open task exists, run that one.
+   - If multiple open tasks exist and no identifier is provided, ask which one.
+2. Implement the task end-to-end.
+3. Verify result (tests/lints/checks as appropriate).
+4. Update task file:
+   - mark completed checklist items
+   - update metadata status (`open` -> `closed` or `ready_for_verification`)
+   - add completion summary
+5. If closed, move file from `.cursor/handoffs/open/` to `.cursor/handoffs/closed/`.
+6. Report outcome with what was completed and what (if anything) remains.
+
+## Command: `status`
+
+When the user says `status`:
+
+1. Show current task summary:
+   - total open tasks
+   - total closed tasks
+2. If a task identifier is provided, show detailed status for that task:
+   - metadata status
+   - completed vs remaining checklist items
+   - blockers/next steps
+3. If no identifier is provided, show a concise dashboard of all open tasks.
+
+## Normalization
+
+- Treat these variants the same:
+  - `task`, `tasks`, `list tasks`
+  - `run task`, `execute task`
+  - `status`, `task status`

.cursor/skills/sokana-backend-preflight-sync/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: sokana-backend-preflight-sync
+description: Runs a mandatory backend-context preflight before frontend implementation for every task to keep frontend and backend context aligned.
+---
+
+# Sokana Backend Preflight Sync
+
+## Purpose
+
+Use this skill before frontend tasks that integrate with backend APIs.
+
+This is a mandatory workflow:
+1. Run preflight.
+2. Update context.
+3. Begin implementation.
+
+## Repositories
+
+- Frontend repo (current): `/Users/jerrybony/Documents/GitHub/sokana-crm-frontend/frontend-crm`
+- Backend repo (reference): `/Users/jerrybony/Documents/GitHub/backend`
+
+## Required Pre-Task Workflow (Run Every Task)
+
+Before coding, do all steps:
+
+1. Read backend context sources:
+   - `/Users/jerrybony/Documents/GitHub/backend/.cursor/skills/sokana-doula-cloudsql-sync/SKILL.md`
+   - `/Users/jerrybony/Documents/GitHub/backend/.cursor/skills/sokana-doula-cloudsql-sync/frontend-context.md`
+2. Scan frontend files relevant to the incoming task.
+3. Update:
+   - `.cursor/skills/sokana-backend-preflight-sync/backend-context.md`
+4. Report preflight findings.
+5. Start implementation only after context update is complete.
+
+If no updates are needed, add a dated "No changes required" entry to `backend-context.md`.
+
+## Cross-Repo Capability (Mandatory For Integration Tasks)
+
+When running from frontend workspace:
+- Read backend context from:
+  - `/Users/jerrybony/Documents/GitHub/backend/.cursor/skills/sokana-doula-cloudsql-sync/SKILL.md`
+  - `/Users/jerrybony/Documents/GitHub/backend/.cursor/skills/sokana-doula-cloudsql-sync/frontend-context.md`
+
+When running from backend workspace:
+- Read frontend implementation directly at:
+  - `/Users/jerrybony/Documents/GitHub/sokana-crm-frontend/frontend-crm`
+
+If change is needed in the other repo, perform edits in that repo path.
+
+## Minimum Frontend Scan Targets
+
+- `src/api/doulas/doulaService.ts`
+- `src/features/doula-dashboard/components/HoursTab.tsx`
+- `src/features/doula-dashboard/components/ClientsTab.tsx`
+- `src/features/doula-dashboard/components/ActivitiesTab.tsx`
+- `src/features/doula-dashboard/components/DocumentsTab.tsx`
+- `src/main.tsx`
+- `src/common/contexts/UserContext.tsx`
+- `src/common/components/routes/ProtectedRoutes.tsx`
+
+## Update Template (backend-context.md)
+
+Use this structure:
+
+```md
+## Preflight YYYY-MM-DD
+
+### Task
+- <task intent>
+
+### Backend Context Reviewed
+- <backend file path>
+- <backend file path>
+
+### Frontend Files Scanned
+- <frontend file path>
+
+### Contract Expectations
+- <request/response shapes expected now>
+
+### Drift Risks
+- <what can break>
+
+### Compatibility Required
+- <fields/wrappers to support during rollout>
+
+### Action
+- [ ] Context updated before coding
+- [ ] Implementation started after preflight
+```
+
+## Decision Rules
+
+- Preserve compatibility for mixed wrappers/field casing during migrations.
+- Keep normalization in API service layer; avoid spreading parsing logic in multiple components.
+- Prefer additive compatibility changes before removing legacy fields.
+- For stale dashboard data issues, include no-cache strategy in fetch layer.
+
+## Output Requirement
+
+Before any implementation, provide:
+- gate result: `run_preflight`
+- files scanned,
+- context updates made,
+- specific compatibility strategy for this task.