.planning/ROADMAP.md

@@ -227,3 +227,24 @@ Plans:
 Plans:
 
 - [ ] TBD (promote with /gsd-review-backlog when ready)
+
+### Phase 999.5: First-login provider setup — prompt + instructions to add a Fastmail app password (BACKLOG)
+
+**Goal:** [Captured for future planning] On a member's first login there is no onboarding to connect their own calendar provider. Today the broker uses a single seeded Fastmail app password (the operator's), so a second member (e.g. the wife) who logs in sees only what that token reaches — she has no way to attach her **own** Fastmail personal calendar (the D-09 per-member app-password model). Add a first-login flow that detects a member has no `member_credentials` row and prompts them to create + paste a Fastmail app password, with clear step-by-step instructions (where to generate it in Fastmail settings, required scope: Calendars/CalDAV, that one app password covers all of that account's calendars). Store it encrypted (APP_PASSWORD_ENCRYPTION_KEY, existing crypto path), then trigger an initial sync so their personal calendar lane populates.
+
+**Context** (surfaced 2026-06-07, Gate 2 live testing): the wife logged in on her iPhone and added the PWA to her Home Screen, but there is no provider-setup step — so her personal calendar can't be connected. This is the onboarding half of the "each member's personal calendar" v1 requirement.
+
+**Scope to decide when promoted:**
+- Detect "no credential yet" state server-side (`GET /api/me` exposes a `needsProviderSetup` flag, or a dedicated endpoint) and gate a setup screen in the PWA.
+- App-password entry UI + validation (test the credential with a CalDAV PROPFIND before saving), encrypted storage, and triggering the first sync.
+- Non-technical-friendly instructions (the hard UX constraint) — ideally with a direct link to Fastmail's app-password page and a screenshot/walkthrough.
+- Decide the model: does every member attach their own personal calendar, or do some members only see the shared family calendar? (Open question from D-16.)
+- Security: never log/echo the app password; member-scoped; T-03-19 style scoping.
+
+**Severity:** high for true multi-member use — without it the second member has no personal calendar. Tags: phase-03, onboarding, auth, caldav, per-member-credential, D-09.
+**Requirements:** TBD
+**Plans:** 0 plans
+
+Plans:
+
+- [ ] TBD (promote with /gsd-review-backlog when ready)

.planning/phases/03-event-write-back-pwa-install/03-GATE2-RESULTS.md

@@ -129,7 +129,7 @@ Mark each row PASS or FAIL and add notes. On failure, apply the indicated remedy
 |---|-----|-------|--------|-------|
 | A1 | AUTH-01 | Open `https://familysync-dev.DOMAIN` → redirects to Authelia → login completes → land on the app with name, color, and at least one cached event | ✅ PASS (2026-06-07) | Real Authelia OIDC login lands on the calendar; name (email claim), assigned color, and cached events render. Name self-heals to full name once Authelia emits name/preferred_username (see backlog/memory). |
 | A2 | AUTH-02 | Fully close + reopen browser → revisit the URL → no re-login prompted (session persists) | [ ] PENDING — operator | Refresh-token session wired (offline_access). Operator must confirm across a full browser restart within the session lifespan. |
-| A3 | AUTH-03 | Second member logs in on a separate device → distinct stable color assigned (different from first member's color) | [ ] PENDING — operator/device | Only one real member (id=2, color #E8734A) has logged in so far. Needs the second member on their device. |
+| A3 | AUTH-03 | Second member logs in on a separate device → distinct stable color assigned (different from first member's color) | ✅ PASS (2026-06-07) | Second member (amelia, id=3) logged in on her iPhone. Found + fixed a collision bug (both members were #E8734A — COUNT%palette reused a slot after a deletion); now luc=#E8734A, amelia=#4A90D9 (distinct, stable). Fix: first-unused-palette-color (commit f700182). |
 
 ### Part B — iOS PWA Standalone Login (Task 2) — LOAD-BEARING CHECK
 
@@ -143,11 +143,11 @@ Mark each row PASS or FAIL and add notes. On failure, apply the indicated remedy
 
 | # | Ref | Check | Result | Notes |
 |---|-----|-------|--------|-------|
-| B1 | iOS PWA | Open `https://familysync-dev.DOMAIN` in Safari on iPhone → in-app install walkthrough appears → tap "Add to Home Screen" | [ ] PENDING — device | |
-| B2 | iOS PWA | Launch FamilySync from Home Screen → opens full-screen with no Safari browser chrome (standalone mode) | [ ] PENDING — device | |
-| B3 | iOS PWA (Pitfall 2) | Complete Authelia OIDC login from standalone mode → redirect does NOT break out of standalone (user stays in the app, not dropped to Safari) | [ ] PENDING — device | **Load-bearing check** |
-| B4 | PWA-01 | Installed PWA on iOS opens full-screen with no browser chrome | [ ] PENDING — device | |
-| B5 | PWA-02 | Installed PWA on Android opens full-screen with no browser chrome | [ ] PENDING — device | |
+| B1 | iOS PWA | Open `https://familysync-dev.DOMAIN` in Safari on iPhone → in-app install walkthrough appears → tap "Add to Home Screen" | ✅ PASS (2026-06-07) | Wife added FamilySync to her iPhone Home Screen and logged in (user id=3 created). |
+| B2 | iOS PWA | Launch FamilySync from Home Screen → opens full-screen with no Safari browser chrome (standalone mode) | 🟡 LIKELY — confirm | Installed to Home Screen; operator to confirm it launches full-screen with no Safari chrome. |
+| B3 | iOS PWA (Pitfall 2) | Complete Authelia OIDC login from standalone mode → redirect does NOT break out of standalone (user stays in the app, not dropped to Safari) | 🟡 CONFIRM | She logged in successfully; confirm the login was completed *launched from the Home Screen icon* (standalone) and did not drop to Safari. **Load-bearing check.** |
+| B4 | PWA-01 | Installed PWA on iOS opens full-screen with no browser chrome | 🟡 LIKELY — confirm | Same as B2. |
+| B5 | PWA-02 | Installed PWA on Android opens full-screen with no browser chrome | [ ] PENDING — device | Android install not yet exercised. |
 
 ### Part C — SSE Smoke Test (Gate before Phase 4)
 
@@ -193,14 +193,15 @@ Response body: {"ok":true,"db":"up"}
 |---------|--------|
 | Production builds (PWA + API) | ✅ CLEAN (2026-06-07; 102 API + 140 PWA tests) |
 | Operator infra setup | ✅ DONE (Authelia client + Pangolin/Newt live; OIDC login working) |
-| A — Auth / session / colors | 🟡 A1 PASS; A2 (session persist) + A3 (2nd member color) PENDING |
-| B — iOS standalone login (load-bearing) | ⏳ PENDING — device-only (operator's iPhone) |
+| A — Auth / session / colors | 🟡 A1 + A3 PASS; A2 (session persist) PENDING quick confirm |
+| B — iOS standalone login (load-bearing) | 🟡 B1 PASS (installed + logged in on iPhone); B2/B3/B4 confirm; B5 (Android) pending |
 | C — SSE smoke test | ⏳ PENDING — operator; this is the Phase 4 ENTRY gate (D-14), not a Phase 3 deliverable |
 | D — Fastmail write round-trips | 🟡 D1/D4/D5/D6 PASS; D2 (all-day) + D3 (recurring) PENDING quick confirm |
 
 Gate 2 is complete when all rows are PASS. Record final status here:
 
-**Gate 2 outcome:** 🟡 PARTIAL — core auth + create/edit/delete/conflict round-trips verified live (2026-06-07).
-Remaining are device/operator-only rows: A2, A3, D2, D3 (desktop, quick), and B (iOS device).
-C (SSE) is the Phase 4 entry gate and may be carried forward per D-14. Phase 03 code is complete
-and live-verified; final closure awaits the operator/device rows above.
+**Gate 2 outcome:** 🟡 NEARLY COMPLETE — core auth, distinct member colors, iOS install+login, and
+create/edit/delete/conflict round-trips all verified live (2026-06-07). Remaining quick operator
+confirms: A2 (session persists across restart), B2/B3/B4 (launch-from-Home-Screen standalone +
+standalone login), D2 (all-day), D3 (recurring). Optional/deferred: B5 (Android install),
+C (SSE — Phase 4 entry gate, carried per D-14). Phase 03 code is complete and live-verified.