diff --git a/.planning/phases/05-web-push-notifications/05-UAT.md b/.planning/phases/05-web-push-notifications/05-UAT.md index efc9a43..e35c2ce 100644 --- a/.planning/phases/05-web-push-notifications/05-UAT.md +++ b/.planning/phases/05-web-push-notifications/05-UAT.md @@ -1,19 +1,14 @@ --- -status: testing +status: complete phase: 05-web-push-notifications source: [05-VERIFICATION.md] started: 2026-06-10T02:46:43Z -updated: 2026-06-10T17:14:00Z +updated: 2026-06-10T18:30:00Z --- ## Current Test -number: 3 -name: iOS subscription health-check keeps subscription alive after 1+ week of inactivity -expected: | - After a week without opening the app, opening it again silently re-subscribes - (if permission still granted) and notifications continue to be delivered. -awaiting: user response +[testing complete] ## Tests @@ -33,16 +28,16 @@ note: "Confirmed on a real iPhone (installed standalone PWA). Enable Notificatio ### 3. iOS subscription health-check keeps subscription alive after 1+ week of inactivity expected: After a week without opening the app, opening it again silently re-subscribes (if permission still granted) and notifications continue to be delivered. why_human: Requires real elapsed time and a physical iOS device. Cannot be simulated. -result: [pending] +result: skipped +reason: "Dropped by operator (2026-06-10) — requires 1+ week of real elapsed time; not gating for Phase 5 sign-off. The silent re-subscribe code path (D-10) is verified in code; long-horizon real-world behaviour is left to observe naturally rather than block on." ### 4. Android FCM: event-change push arrives after the other member modifies a calendar event expected: When member A modifies a shared event title/time/location, member B receives a push notification on Android within the next 5-minute poll cycle, showing "A updated an event" with the event title. why_human: End-to-end push delivery through FCM to a real Android device with a subscribed session cannot be driven by playwright-cli. -result: issue -reported: "On Android, could not enable notifications. Once the browser has blocked notifications, the SettingsSheet shows a 'Notifications are blocked' hint with a 'How to enable' link, but the link does nothing except close the settings sheet — no instructions shown, leaving the user with no recovery path. Could not get a subscribed Android session, so the event-change push leg itself remains untested." -severity: major -root_cause: "BUG in apps/pwa/src/components/SettingsSheet.tsx: the 'How to enable' button (the denied-permission hint) is wired to onClick={onClose} — it just dismisses the sheet. It should open the OS-specific InstructionSheet (Android/iOS steps) the same way PermissionDeniedBanner.tsx does. The InstructionSheet component exists but is local to PermissionDeniedBanner and unused by SettingsSheet. Note: being unable to RE-enable from within the web app once the browser blocked the site is expected (browsers won't let a page re-prompt after denial) — but the recovery guidance must work; right now it doesn't." -note: "Event-change push delivery itself (the actual Test 4 assertion) is still UNVERIFIED — blocked on getting a subscribed Android session, which requires unblocking notifications in Chrome site settings first." +result: skipped +reason: "DEFERRED to Phase 6 verification by operator (2026-06-10). During Test 4 two bugs were found and FIXED + deployed: (a) the SettingsSheet 'How to enable' recovery link only closed the sheet (quick 260610-jlp — now opens the OS-step InstructionSheet); (b) Android push notifications delivered but displayed SILENTLY because the SW showNotification lacked icon/badge/renotify/vibrate (quick 260610-ka9 — now enriched). Android FCM delivery itself is proven server-side (direct send → FCM 201). The remaining open item — confirming an event-change push arrives and displays non-silently on a real subscribed Android device — is moved to Phase 6 verification. Operator must also raise the Edge/Android per-site notification-channel importance (an existing silent channel can't be overridden by app options)." +deferred_to: "Phase 6 verification" +fix_commits: ["260610-jlp (how-to-enable link)", "260610-ka9 (silent Android notification options)"] ### 5. List-change push coalescing is observable expected: Member B making 5 rapid grocery-list edits results in a SINGLE push notification to member A (not 5), naming the actor and the list, arriving after the 45-second coalesce window. @@ -54,11 +49,16 @@ note: "Confirmed on-device — 5 rapid list edits produced a single coalesced pu total: 5 passed: 3 -issues: 1 -pending: 1 -skipped: 0 +issues: 0 +pending: 0 +skipped: 2 blocked: 0 +# Sign-off (2026-06-10): Tests 1, 2, 5 PASS on real devices. Test 3 dropped +# (1-week elapsed time, non-gating). Test 4 deferred to Phase 6 verification +# (fixes deployed: how-to-enable link + silent-notification options; Android +# delivery confirmation moved to Phase 6). Phase 5 UAT resolved. + ## Notes - **Delivery pipeline PROVEN on a real iOS device (2026-06-10):** iOS standalone-PWA subscribe → `push_subscriptions` row → VAPID-signed `web-push` send → `web.push.apple.com` 201 → service-worker `push` handler `showNotification()` → notification on the iPhone lock screen. This is the core of Phase 5 and de-risks tests 4 and 5 (same chain, different trigger/endpoint).