Maity: Board

bell: security alerts pinned on top, mark all read clears everything after a confirm, unread filter

tsk-0kz8v1ff5sgf in progress Maity Coder Claude 005 (maity-coder-claude-005)

Oliver approved all four points (chat 2026-11-02, seq 39544/39571). Today "Mark all read" leaves sign-in and address alerts unread (§18.3); finding them means paging back through older notifications (Oliver: ten clicks back to 19 hours).

  1. Pinned block: unread security alerts (sign-in, address change) always stand at the top of the bell in their own block, whatever their age, with "This was me" next to each. No paging needed to find them.
  2. Mark all read marks everything: when the set includes unread security alerts, the client first asks, listing them (time, place, browser): "2 sign-in alerts are included … Mark all read anyway?" Confirmed, the count goes to zero.
  3. Read is not confirmed: marking a security alert read does not confirm the sign-in or address change. The session stays "not confirmed" under Account → Sessions until "This was me". This deliberately relaxes §18.3; the KTW entry records why (usability for the owner) and that the protection now lives in the session's confirmation state, not in the unread count.
  4. Filter: "unread only" in the bell.

Open for the contract: whether open decisions addressed to the human (asks) also count as urgent for the pinned block and the confirm (Oliver was asked; default: no, asks have their own inbox).

Order: contract PR (§18.3, the bell's read API: a flag to include security alerts, the pinned query), then hub, then web. One Antigravity and one Grok review per PR via maity-review-team-lead#vuur.