test(05): UAT resolved — 1/2/5 pass; T3 dropped, T4 deferred to Phase 6

Test 3 (1-week health check) dropped as non-gating. Test 4 (Android
event-change push) deferred to Phase 6 verification; its two blocking bugs
fixed + deployed (jlp how-to-enable link, ka9 silent-notification options).
Phase 5 UAT status → complete.

.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
+[testing complete]
-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
 
 ## 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
+result: skipped
-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."
+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)."
-severity: major
+deferred_to: "Phase 6 verification"
-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."
+fix_commits: ["260610-jlp (how-to-enable link)", "260610-ka9 (silent Android notification options)"]
-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.
@@ -54,11 +49,16 @@ note: "Confirmed on-device — 5 rapid list edits produced a single coalesced pu
 
 total: 5
 passed: 3
-issues: 1
+issues: 0
-pending: 1
+pending: 0
-skipped: 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).