Notifications have no per-type mute and no notion of "you caused this" — #176's visibility gate cannot cover your other devices

[serge-ivo]

Not a re-open of #176 — that fix works, and it cannot cover this

#176 ("suppress when the user is actively using the app") shipped in 5c38591 and is real:
store/sw.js:25 skips showNotification() when a /console client reports
visibilityState === "visible", and forwards the payload to those tabs so the bell badge still
updates. Verified at HEAD.

It is a per-device decision, made by each device's own service worker. The send is per-user:
sendPushToUser (routes/push.ts:145) selects every subscription row for the user and pushes to
all of them. So the laptop you are looking at goes quiet and the phone in your pocket does not — by
construction, a visibility gate can never cover a device you are not looking at. #176's own closing
comment identified the per-USER vs per-DEVICE tension as a reason not to build a server-side presence
gate, and was right to; it just left the consequence unaddressed.

Three gaps remain, in the order they bite.

1. Nothing knows you caused the event

The deploy notifications that prompted this fire because you pushed the commit. There is no notion
anywhere that the recipient initiated the thing they are being told about. Even with the console
focused and the SW suppressing correctly, being told four times that your own push deployed is not
information.

Cheapest honest version: notifyUser takes an optional actor, and skips the push (keeping the in-app
row) when the actor is the recipient. The deploy watcher has the run's triggering actor available
from the GitHub API and does not currently read it.

2. Push is all-or-nothing

There is no per-type preference of any kind. The push routes are vapid-key, subscribe,
subscribe (DELETE) and test — subscribe or unsubscribe, nothing between. Four types already exist
and are already threaded through as the push tag:

type	sites
apply	6
coding	2
deploy	1
trigger	(skipped-run notices)

So the vocabulary for "mute deploys, keep handoffs" is already in the payload and simply has no
control attached. A user who finds deploy notifications noisy today has exactly one remedy: turn off
push entirely, which also loses the CAPTCHA handoff — the one notification the product genuinely
needs to interrupt for.

This is the highest value-per-line fix of the three: a per-type mute map on the account, checked in
notifyUser before sendPushToUser, plus checkboxes on Preferences next to the other account-wide
settings.

3. No quiet window, no floor

Nothing bounds the rate. See #359 for how that compounds — a single watcher bug turned ~20 pushes into
40–80 notifications, and nothing in the notification layer resisted it. A per-type mute would have let
the user stop it; a duplicate floor would have bounded it even unmuted.

Suggested shape

1. Per-type mute on the account (Preferences → Notifications), enforced in notifyUser. Covers
   the reported complaint completely and is independent of everything else.
2. Actor suppression — do not push to the person who caused it. Small, and removes a whole class
   rather than muting it.
3. Leave the visibility gate alone. It is correct, it is per-device, and that is the right layer for
   it.

Related: #176 (the shipped visibility gate), #359 (the watcher bug that made this loud).

[serge-ivo]

Reviewing my own scoping: this bundles two features with different rationales and different implementations, and should probably be split before anyone starts.

• Per-type mute is a user control — an account preference, a check in notifyUser, and checkboxes on Preferences. It is the direct answer to the reported complaint and could ship alone.
• Actor suppression ("do not push to the person who caused it") is a correctness fix — it needs an actor threaded from each call site, and the deploy watcher does not currently read the triggering actor off the GitHub API at all.

They share a paragraph here because they arrived from the same symptom, not because they are one change. The per-type mute is the higher-value half and is unblocked; actor suppression touches every notifyUser call site and is worth its own issue if it survives triage.

[serge-ivo]

Shipped across 5641598 (enforcement + the alert/update distinction) and c1f03b2
(Preferences → Notifications, and the list).

Gap 2 — per-type mute. Done, and it is where the issue said it should be: on Preferences,
beside the other account-wide settings, stored in users.preferences.notifications.muted, enforced
in notifyUser before sendPushToUser. Account-level rather than per-instance because push
subscriptions are per-USER and sendPushToUser fans out to every device — a mute cannot be a
property of one agent or one browser, which is the same fact that makes #176's per-device gate
unable to cover this. The control list is a .map() over GET /v1/preferences, so a new
notification type gets a control by being added to lib/notifications.ts, not by editing the page.

What a mute does to an actionable notification: nothing. notifyUser classifies each call as
alert (a run has stopped and a human is the only thing that restarts it) or update (news), and
pushAllowedByPreference returns true for an alert unconditionally. Muting "Coder" stops
"✅ Coder finished" and keeps "🙋 Coder needs you"; muting "Job applications" stops the résumé
notices and keeps the CAPTCHA handoff. The costs are not symmetric — an unwanted buzz is an
annoyance, a silenced handoff is a run that stops and never says so, which is indistinguishable
from an agent being slow — so mute is not offered for that class rather than offered and
quietly ignored. The section header says it, every mixed type repeats it on its own row, and a
test pins it. Rows are always written either way; the bell list stays a complete log.

kind is per-call, not per-type, because the existing types are mixed: coding and apply each
carry both shapes. The console badges an alert row "Needs you" — the same distinction a
needs_human board card draws, which is where the platform already had this shape.

Gap 3 — no floor. #361, landed first.

Gap 1 — actor suppression: deliberately not built. The only place the actor is knowable is the
deploy watcher, and the recipient there is the repo owner, who triggers essentially every deploy —
so "skip the push when the actor is the recipient" would silence the deploy notification in every
real case, i.e. delete the feature #6 exists to deliver ("is it green yet, now that I've closed the
tab"). What made those notifications feel like noise was arriving 2–4 times per push, and #359
fixes that at the source. Happy to revisit if a case turns up where the actor is knowable AND is
routinely someone other than the recipient.

Also fixed in passing: every row in the notifications list had been rendering "Invalid Date" —
/v1/notifications returns rows straight from D1 (created_at) and the page read createdAt.

Left alone, as the issue asked: the sw.js visibility gate. It is correct, it is per-device, and
the server-side suppression cannot double-suppress it — a muted or duplicate notification is never
sent, so the service worker has nothing to decide about, and the bell badge still updates on its
own 30s poll.