feat(notifications): focus-aware notification bus on quill toasts

[adamleithp]

What

A single notification bus that every app notification routes through, delivering by focus + what you're currently viewing:

You are…	Result
viewing the exact target (task/canvas)	suppress (you can already see it)
app focused, but elsewhere	in-app toast with a click-through
app unfocused (another OS app)	native OS notification — click deep-links to the target

How

• NotificationBus (renderer) replaces TaskNotificationService. A pure, table-tested routeNotification() decides the tier from a generic NotificationTarget union (task | canvas), defined in @posthog/platform (so core/host-router/ui share it without an internal-import violation).
• Native click routing generalized via a new OpenTargetLinkService + deep-link router onOpenTarget/getPendingOpenTarget. The renderer consumer drains pending every (re)subscribe, so a click landing during a reconnect/HMR gap still routes (was the "OS deep-link doesn't route" bug).
• Producers migrated: task prompt-complete + permission requests now flow through the bus (focused-elsewhere becomes a toast, not a native notification); canvas-generation-done re-emits through it (detection kept).
• Toast primitive rebuilt on @posthog/quill — provider-managed dismiss, stacking, and auto-dismiss (fixes the hand-rolled sonner-custom toast that couldn't be dismissed). All ~18 direct-sonner callers migrated; sonner dropped entirely.
• New Settings → Notifications section: defaults, an OS-permission banner, reset-to-defaults, and a per-tier test harness (in-app toast / deep-link toast / native / deep-link notification / dock badge / bounce). Canvas copy gated on the bluebird flag.

Behavior change worth calling out

Task notifications that previously fired a native OS notification while the app was focused-but-elsewhere now show an in-app toast; native is reserved for when the app is backgrounded.

Testing

• Pure routeNotification / targetsEqual table tests; zod↔platform NotificationTarget parity test; useOpenTargetDeepLink consumer test (warm task + canvas targets + pending-drain); NotificationBus tier-routing tests; core NotificationService target-click tests.
• Full workspace typecheck green; UI/core/host-router suites green; biome clean; host-boundary no new violations.

🤖 Generated with Claude Code

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit 32bef75.}

[greptile-apps]

_{Reviews (1): Last reviewed commit: "feat(notifications): focus-aware notific..." | Re-trigger Greptile}

[adboio]

not tested too extensively but seems legit!! left a few comments, nothing blocking but lmk what you think :)

[adboio]

[still reading code, maybe this is stupid, will update if so lol]

can/should we make this a bit more generic? like just give NotificationTarget some uniqueIdentifier property so we can just return a.kind === b.kind && a.uniqueId === b.uniqueId ? otherwise we'll have to update this if/when new target types are introduced

[adboio]

edit: just looked at the NotificationTarget type, both task and canvas are effectively the same thing (seems like identifier + "sub-identifier" (? not familiar w/ canvas)

in that case, could we make it a bit more generic and maybe not even split out the kind on the target?

[adamleithp]

Good call on the maintainability point — done in 64df565. Collapsed the per-kind equality chain into a single targetKey(target) identity function; targetsEqual is now just targetKey(a) === targetKey(b), so adding a kind touches one exhaustive switch (compile error if you forget) instead of growing an if-chain that silently returns false.

On dropping kind / a flat uniqueId: I kept kind because it's load-bearing for navigation, not just equality — deriveAction in notifications.ts switches on it to pick navigateToTaskDetail(taskId) vs navigateToChannelDashboard(channelId, dashboardId), which need different fields. And canvas identity is composite (channelId + dashboardId), so a single uniqueId would have to be a synthesized composite key anyway — which is exactly what targetKey now produces. So we get the generic comparison you wanted while keeping the typed per-kind fields navigation relies on.

[adboio]

[nit] not just here specifically, but lots of bgi comments throughout, thoughts on stripping them down a bit and shipping this with a markdown file that explains the notif system instead ? no strong opinion here just personal pref

[adamleithp]

Fair — left them as concise inline comments for now rather than a separate markdown file. My reasoning: the routing decision (suppress/toast/native) is the one genuinely non-obvious bit and it's right next to the code it explains, where it's hardest to let drift out of sync. A standalone doc tends to rot once the code moves. Happy to pull it into a notifications/README.md if the comment density bugs you on a re-read though — no attachment.