- Shipped
- August 14, 2026 at 7:37 PM UTC
- Author
- kamo
- Commit
- 370bdf0
The notifications page wore a header of its own — an eyebrow, a title and three pill buttons inside a bordered card — while every neighbouring page (the account browser, every settings screen) is introduced by the brand gradient hero with a back arrow and a tab bar under it. It read as somewhere else in the product. It now carries the same header, with the unread count as its subtitle and the two actions that operate on the list as the hero's white buttons. Under it, two tabs: Notifications and Settings. The settings are the ones that used to be a tab on the member's own profile at /settings/member/{id}?tab= notifications, which put the controls over notifications on a different screen from the notifications themselves — one subject in two places, neither of which mentioned the other. A member who opens the bell because it will not stop is now already on the page that can stop it. `?tab=` is shared through NOTIFICATION_TABS, so the bar and the surfaces that deep-link into it cannot drift onto a value that selects nothing. Both surfaces that linked to the old location (the toast deck's Settings action, the page's own Settings button, now a tab) go to NOTIFICATION_SETTINGS_HREF. An old bookmark of the member URL still resolves — SettingsView falls back to the first tab for a `?tab=` it does not recognise. The Quick Tips copy that hung off the old tab (settings.notifications.help.*) is not carried over: the help drawer is a SettingsView affordance and this page has none. The keys are left in the dictionary rather than scrubbed.