.planning/phases/05-web-push-notifications/05-UAT.md

@@ -38,20 +38,24 @@ result: [pending]
 ### 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: [pending]
-note: "Delivery chain to a real device (VAPID → push service → SW showNotification) is now proven via the iOS path; the Android-specific leg (FCM endpoint + a subscribed Android session) is still untested."
+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."
 
 ### 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.
 why_human: Requires two devices/sessions, real timing, and real push delivery. Playwright-cli can exercise the API hooks but not multi-device push receipt.
-result: [pending]
+result: pass
+note: "Confirmed on-device — 5 rapid list edits produced a single coalesced push (not 5)."
 
 ## Summary
 
 total: 5
-passed: 2
-issues: 0
-pending: 3
+passed: 3
+issues: 1
+pending: 1
 skipped: 0
 blocked: 0
 
@@ -70,3 +74,13 @@ blocked: 0
   test: 1
   artifacts: [apps/api/src/broker/reminderScheduler.ts, apps/api/src/broker/poller.ts, apps/api/src/broker/outboxWorker.ts]
   note: "Side benefit: the node-cron→setInterval fix also restores the CalDAV poller (5-min sync) and outbox drain (15s), which were ALSO being skipped by node-cron in the long-running process."
+
+- truth: "When notifications are browser-blocked, the user is given a working path to re-enable them"
+  status: failed
+  reason: "SettingsSheet 'How to enable' link only closes the sheet (onClick={onClose}); shows no instructions. Blocks Test 4 (could not get a subscribed Android session to test event-change push)."
+  severity: major
+  test: 4
+  artifacts: [apps/pwa/src/components/SettingsSheet.tsx, apps/pwa/src/components/PermissionDeniedBanner.tsx]
+  missing:
+    - "Wire SettingsSheet 'How to enable' to open the OS-specific InstructionSheet (extract/share it from PermissionDeniedBanner) instead of calling onClose."
+    - "After unblocking in Chrome site settings, re-run Test 4: modify a shared event as member A, confirm member B's Android device receives the 'updated an event' push within the 5-min poll cycle."