diff --git a/.planning/ROADMAP.md b/.planning/ROADMAP.md index 3f5d64c..c8b2a24 100644 --- a/.planning/ROADMAP.md +++ b/.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) diff --git a/.planning/phases/03-event-write-back-pwa-install/03-GATE2-RESULTS.md b/.planning/phases/03-event-write-back-pwa-install/03-GATE2-RESULTS.md index 2d9a562..fcd874e 100644 --- a/.planning/phases/03-event-write-back-pwa-install/03-GATE2-RESULTS.md +++ b/.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.