Complete personalized health snapshot: sync pipeline, wins, daily history, dismiss tracking, profile editing

R1: Wire compute-baselines into sync-all-devices orchestrator. After each
    successful device sync, baselines are recomputed for that user. Non-fatal
    — sync succeeds even if baseline computation fails.

R2: Add daily_history and days_of_data to starter pack response. The engine
    already fetches daily data but was discarding it after averaging. Now
    preserves per-metric daily values for trend computation and personal
    best detection on the client.

R3: Build computeWins() client-side function. Detects personal bests and
    all-in-range events from the enriched scorecard. Capped at 3 wins,
    ordered by significance. Wired into my-body.tsx.

R4: CycleInsightCard dismiss persistence via AsyncStorage. Card reappears
    after 30 days, permanently dismissed after 2 dismissals.

R5: CycleConfirmationPrompt dismiss tracking. Stops asking after 3
    consecutive dismissals of the monthly period check-in.

R6: Retroactive phase correction. When user confirms a period date (via
    CycleInsightCard or CycleConfirmationPrompt), compute-baselines is
    re-triggered to re-tag historical phase labels and recompute baselines.

R7: Profile cycle editing. Female users can now edit cycle preferences
    (regular/irregular/none/prefer not to say) and turn off cycle tracking
    from the Profile screen edit modal.

Tests: 2807 mobile (0 fail) + 88 Edge Function (0 fail)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: schwaaamp

docs/planning/personalized-health-snapshot.md

@@ -824,6 +824,288 @@ Note: Red is never used. Amber is the strongest signal. The personal baseline ap
 
 ---
 
+## Remaining Implementation: Detailed Strategy
+
+The following items complete the feature. Each takes a TDD approach: write failing tests, then implement to make them pass. Items are ordered by dependency — later items depend on earlier ones.
+
+### R1: Wire compute-baselines into sync-all-devices (server)
+
+**Why:** Without this, baselines are never recomputed after the initial backfill. Users who sync new data see stale personal ranges.
+
+**File:** `supabase/functions/sync-all-devices/index.ts`
+
+**Change:** After all device sync batches complete (after the current results summary loop), collect unique user IDs from successful syncs and call `compute-baselines` for each via HTTP (same pattern as `callSyncFunction`).
+
+```typescript
+// After line ~305 (after all batches complete, before logging summary)
+const usersToRecompute = [...new Set(
+  results.filter(r => r.success).map(r => r.user_id)
+)];
+
+for (const userId of usersToRecompute) {
+  try {
+    await fetch(`${Deno.env.get('SUPABASE_URL')}/functions/v1/compute-baselines`, {
+      method: 'POST',
+      headers: {
+        'Authorization': `Bearer ${serviceRoleKey}`,
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({ user_id: userId }),
+    });
+  } catch (err) {
+    logger.warn('baseline', `Failed to recompute baselines for ${userId}: ${err}`);
+    // Non-fatal — sync still succeeded
+  }
+}
+```
+
+**Tests (add to `sync-all-devices/index.test.ts` or `orchestrator.test.ts`):**
+- After successful device syncs, compute-baselines is called for each unique user ID
+- Failed device syncs do not trigger baseline computation for that user
+- Compute-baselines failure does not fail the overall sync response
+- Compute-baselines is called once per user even if user has multiple devices
+
+**Test count:** ~4
+
+---
+
+### R2: Add daily history and days_of_data to starter pack response (server)
+
+**Why:** The mobile app needs `days_of_data` for the CycleInsightCard and baseline progress text, and `dailyHistory` for trend computation and personal best detection. The starter pack engine already fetches the raw daily data (lines 157-172 of `starter-pack.ts`) but discards it after computing averages.
+
+**File:** `supabase/functions/ai-engine/engines/starter-pack.ts`
+
+**Changes:**
+
+1. **Preserve daily values** instead of discarding after averaging. Build a `dailyHistory` map: `Record<string, { date: string; value: number }[]>` keyed by metric_key. Each entry is a day's value for that metric.
+
+2. **Count days_of_data** from the total unique dates across daily_summary and sleep_sessions.
+
+3. **Return both in the response:**
+   ```typescript
+   return {
+     ...existingFields,
+     days_of_data: uniqueDates.size,
+     daily_history: dailyHistoryMap, // new field
+   };
+   ```
+
+4. **Update mobile type:** Add `daily_history?: Record<string, { date: string; value: number }[]>` to `StarterPackResult` in `types.ts`.
+
+5. **Wire in my-body.tsx:** Pass `starterPack.daily_history` to `buildMetricScorecard` as the `dailyHistory` parameter.
+
+**Tests (add to starter pack test file or create new):**
+- `days_of_data` equals the number of unique dates in the data
+- `daily_history` contains entries for each metric with actual daily values
+- `daily_history.resting_hr` has one entry per day, not duplicates
+- Empty data returns `days_of_data: 0` and empty `daily_history`
+
+**Test count:** ~4
+
+---
+
+### R3: Build wins computation (client-side)
+
+**Why:** The `WinsSection` component exists but nothing produces `WinEvent[]`. Wins need to be computed from the scorecard + daily history on the client side, since they depend on the enriched scorecard (with personal baselines) which is built client-side.
+
+**File (new):** `mobile/src/utils/experiments/computeWins.ts`
+
+**Function signature:**
+```typescript
+export function computeWins(
+  scorecard: MetricScore[],
+  dailyHistory: Record<string, { date: string; value: number }[]> | undefined,
+  previousWinDismissals: Record<string, string>, // metric_key → last dismissed date
+): WinEvent[]
+```
+
+**Logic:**
+1. **Personal best:** For each metric where `is_personal_best === true`, create a win. Skip if the same metric had a personal best win in the last 30 days (cooldown check against `previousWinDismissals`).
+2. **Back in range:** For each metric where `personal_status === 'within'`, check if the prior day's status was `'outside_bad'`. If so, create a "Back in your range" win.
+3. **Streak detection:** For each metric, check if `trend_direction === 'improving'` and count consecutive weeks. If 3+, create a streak win. Show at week 3, 5, 8 (not every week).
+4. **All in range:** If every metric with a personal baseline has `personal_status === 'within'` or `'outside_good'`, create an "all in range" win.
+5. **Baselines ready:** One-time win when personal baselines first appear. Track via AsyncStorage key `baselines_ready_shown`.
+6. **Cap at 3 wins**, ordered by significance: personal_best > streak > back_in_range > all_in_range.
+
+**File (new):** `mobile/src/utils/experiments/__tests__/computeWins.test.ts`
+
+**Tests:**
+- Returns empty array when no scorecard has personal baselines
+- Returns personal best win when `is_personal_best` is true
+- Respects 30-day cooldown per metric for personal best
+- Returns back-in-range win when metric transitions from outside_bad to within
+- Returns streak win at 3 consecutive improving weeks
+- Does not return streak win at week 2 (below threshold)
+- Returns all-in-range win when all personalized metrics are within/outside_good
+- Caps at 3 wins max
+- Orders wins by significance
+
+**Wire in my-body.tsx:** Call `computeWins(enrichedScorecard, starterPack?.daily_history, dismissals)` and pass the result as `wins` to `HealthSnapshot`.
+
+**Test count:** ~9
+
+---
+
+### R4: CycleInsightCard dismiss persistence (client-side)
+
+**Why:** The "Not now" button currently does nothing persistent. The plan says the card reappears once after ~30 days, then stops after two dismissals.
+
+**File:** `mobile/src/components/Experiments/CycleInsightCard.tsx`
+
+**Changes:**
+
+Add two new props:
+```typescript
+dismissCount: number;        // how many times dismissed so far
+lastDismissedAt: string | null;  // ISO date of last dismissal
+```
+
+Update the gating logic:
+- If `dismissCount >= 2`: return null (permanently dismissed)
+- If `lastDismissedAt` is within 30 days: return null (cooling off)
+- Otherwise: show the card
+
+**File:** `mobile/src/app/(tabs)/my-body.tsx`
+
+Store dismiss state in AsyncStorage:
+- Key: `cycle_insight_dismiss_count` → number
+- Key: `cycle_insight_last_dismissed` → ISO date string
+
+Read on mount, pass to `CycleInsightCard`. On dismiss, increment count and set date.
+
+**Tests (add to integration test or CycleInsightCard unit test):**
+- Card does not render when `dismissCount >= 2`
+- Card does not render when `lastDismissedAt` is within 30 days
+- Card renders when `lastDismissedAt` is >30 days ago and `dismissCount < 2`
+- Pressing "Not now" calls onDismiss
+
+**Test count:** ~4
+
+---
+
+### R5: Cycle confirmation dismiss tracking (client-side)
+
+**Why:** The monthly "Did your period start?" prompt currently has no persistence for dismissals. The plan says stop asking after 3 consecutive dismissals.
+
+**File:** `mobile/src/components/Experiments/CycleConfirmationPrompt.tsx`
+
+**Changes:** Add a `consecutiveDismissals` prop. If >= 3, return null.
+
+**File:** `mobile/src/app/(tabs)/my-body.tsx`
+
+Store in AsyncStorage:
+- Key: `cycle_confirm_consecutive_dismissals` → number
+
+On confirm: reset to 0. On dismiss: increment. On "Not yet": increment. Pass count to `CycleConfirmationPrompt`.
+
+**Tests:**
+- Prompt does not render when `consecutiveDismissals >= 3`
+- Prompt renders when `consecutiveDismissals < 3`
+- Confirming resets the counter (verify via callback)
+
+**Test count:** ~3
+
+---
+
+### R6: Retroactive phase correction on confirm (client-side trigger)
+
+**Why:** When a user confirms a period start date via the CycleConfirmationPrompt, the baselines should be recomputed with corrected phase tags. Currently `updateProfile` is called but `compute-baselines` is not re-triggered.
+
+**File:** `mobile/src/app/(tabs)/my-body.tsx`
+
+**Change:** After calling `updateProfile({ last_period_date })` in `onCycleConfirm`, also call the `compute-baselines` Edge Function for the current user to re-tag and recompute.
+
+```typescript
+onCycleConfirm={async (periodStartDate) => {
+  await updateProfile({ last_period_date: periodStartDate });
+  // Trigger baseline recomputation with corrected phase tags
+  try {
+    await supabase.functions.invoke('compute-baselines', {
+      body: { user_id: user?.id },
+    });
+    // Invalidate the baselines cache so the UI refreshes
+    queryClient.invalidateQueries({ queryKey: ['personalBaselines'] });
+  } catch {
+    // Non-fatal — baselines will be recomputed on next sync
+  }
+}}
+```
+
+**Tests (integration test):**
+- After onCycleConfirm fires, compute-baselines is invoked with the correct user_id
+- After recomputation, personalBaselines query is invalidated
+
+**Test count:** ~2
+
+---
+
+### R7: Profile cycle editing (client-side)
+
+**Why:** The profile screen shows cycle status as read-only text. Users need to be able to change their cycle preferences (e.g., turning cycle tracking off, or updating status from regular to irregular).
+
+**File:** `mobile/src/app/(tabs)/profile.tsx`
+
+**Change:** Add an edit flow for the cycle row (for female users only). When the user taps the cycle row, open an inline editor or modal with the same 4 options from the CycleInsightCard (regular, irregular, no, prefer not to say) + a date picker for last period date. On save, call `updateProfile` with the new values. Include a "Turn off cycle tracking" option that sets `cycle_status` to null, `last_period_date` to null, and `cycle_length_days` to null — and triggers a baseline recomputation (which will remove phase-specific baselines and rebuild all-phase only).
+
+**Tests:**
+- Female user sees cycle row with edit affordance
+- Tapping edit shows cycle status options
+- Selecting a new status and saving calls updateProfile
+- "Turn off" clears all cycle fields
+- Male user does not see cycle row
+
+**Test count:** ~5
+
+---
+
+### R8: Privacy policy update (non-code)
+
+**Why:** The plan's Cycle Data Privacy section commits to specific principles. The app's privacy policy must be updated before shipping cycle tracking to users.
+
+**Action items:**
+1. Add a section to the privacy policy covering menstrual cycle data
+2. State: cycle data is collected solely to personalize health metric ranges
+3. State: cycle data is never sold, shared with third parties, or used for advertising
+4. State: cycle data never leaves our infrastructure (no external API calls)
+5. State: cycle data is deletable — turning off cycle tracking in Profile deletes all cycle data
+6. Reference the in-app privacy commitment shown on the Cycle Insight Card
+
+**No tests needed** — this is a legal/content update.
+
+---
+
+### Implementation Order
+
+```
+R1 (sync pipeline)     — no dependencies, can ship immediately
+R2 (daily history)     — no dependencies, enables R3
+R3 (wins computation)  — depends on R2 for daily history
+R4 (dismiss persist)   — no dependencies
+R5 (confirm tracking)  — no dependencies
+R6 (retroactive)       — no dependencies
+R7 (profile editing)   — no dependencies
+R8 (privacy policy)    — no dependencies, non-code
+```
+
+R1, R4, R5, R6, R7, R8 are all independent and can be done in parallel.
+R2 must complete before R3.
+
+### Total New Tests
+
+| Item | Tests |
+|------|-------|
+| R1: Sync pipeline wiring | ~4 |
+| R2: Daily history + days_of_data | ~4 |
+| R3: Wins computation | ~9 |
+| R4: CycleInsightCard dismiss | ~4 |
+| R5: Cycle confirmation tracking | ~3 |
+| R6: Retroactive recomputation | ~2 |
+| R7: Profile cycle editing | ~5 |
+| R8: Privacy policy | 0 |
+| **Total** | **~31 new tests** |
+
+---
+
 ## Migration Strategy
 
 ### Transition period

mobile/__tests__/components/MyBody.test.tsx

@@ -1,5 +1,6 @@
 import React from 'react';
 import { render, screen } from '@testing-library/react-native';
+import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
 
 // ---------------------------------------------------------------------------
 // Mocks
@@ -112,13 +113,30 @@ jest.mock('lucide-react-native', () => ({
   WifiOff: () => null,
 }));
 
+jest.mock('@/utils/supabaseClient', () => ({
+  supabase: {
+    functions: {
+      invoke: jest.fn().mockResolvedValue({ data: null, error: null }),
+    },
+  },
+}));
+
 // Import after mocks
 const MyBodyScreen = require('@/app/(tabs)/my-body').default;
 
 // ---------------------------------------------------------------------------
 // Tests
 // ---------------------------------------------------------------------------
 
+function renderWithProviders(ui: React.ReactElement) {
+  const queryClient = new QueryClient({
+    defaultOptions: { queries: { retry: false } },
+  });
+  return render(
+    <QueryClientProvider client={queryClient}>{ui}</QueryClientProvider>,
+  );
+}
+
 describe('My Body Tab', () => {
   beforeEach(() => {
     jest.clearAllMocks();
@@ -130,21 +148,21 @@ describe('My Body Tab', () => {
   });
 
   it('renders "My Body" header', () => {
-    render(<MyBodyScreen />);
+    renderWithProviders(<MyBodyScreen />);
     expect(screen.getByText('My Body')).toBeTruthy();
   });
 
   it('shows "Connect a Wearable" when no wearable connected', () => {
     mockDevices = [];
-    render(<MyBodyScreen />);
+    renderWithProviders(<MyBodyScreen />);
     expect(screen.getByText('Connect a Wearable')).toBeTruthy();
     expect(screen.getByText(/Connect a fitness tracker/)).toBeTruthy();
   });
 
   it('shows loading state when data is being fetched', () => {
     mockDevices = [{ provider: 'whoop', is_active: true }];
     mockStarterPackLoading = true;
-    render(<MyBodyScreen />);
+    renderWithProviders(<MyBodyScreen />);
     expect(screen.getByText(/Analyzing your health data/)).toBeTruthy();
   });
 
@@ -158,7 +176,7 @@ describe('My Body Tab', () => {
       baseline_quality: 'excellent',
       metric_gaps: [],
     };
-    render(<MyBodyScreen />);
+    renderWithProviders(<MyBodyScreen />);
     expect(screen.getByTestId('health-snapshot')).toBeTruthy();
   });
 
@@ -170,13 +188,13 @@ describe('My Body Tab', () => {
       baseline_quality: 'insufficient',
       metric_gaps: [],
     };
-    render(<MyBodyScreen />);
+    renderWithProviders(<MyBodyScreen />);
     expect(screen.getByText('Building Your Baseline')).toBeTruthy();
     expect(screen.getByText(/at least 14 days/)).toBeTruthy();
   });
 
   it('shows medical disclaimer', () => {
-    render(<MyBodyScreen />);
+    renderWithProviders(<MyBodyScreen />);
     expect(screen.getByTestId('medical-disclaimer')).toBeTruthy();
   });
 });