Notifications page serves the native screen on web, so the actions render as full-bleed stacked bars

/notifications on the web serves the native screen, so the phone layout is drawn at desktop width. The action buttons are full-bleed stacked bars touching each other, the avatar is a bare coloured square, and the card sits against a fixed margin rather than in the page's content column.

Found on training.lsu.stacksjs.com/notifications, signed in. The code is in hq.training, resources/views/notifications.stx.

It is the native screen

The file says so at the top:

// The bell, drawn natively (config/mobile.ts `nativeScreens`, ...)

and every string it renders comes from the mobile namespace:

const say = (key: string) => t('mobile.' + key)

It also imports websitePathFor from ../mobile, mobileFormat from ../functions/mobile, MOBILE_HEADER_SNAPSHOT from ../functions/mobile-header, and ../lang/messages/mobile. So this is a screen written for the phone that the web route also serves, rather than a shared component with a native branch.

What that produces, measured

At a 768px content column:

Accept and Decline are direct children of the card's flex flex-col, so each one stretches to the full card width. They have no horizontal padding, no vertical padding, no gap between them and no rounding, while the notification row directly above them has px-4 py-3. The result is two flush bars spanning the card, the lower one reading as a continuation of the upper.

The avatar renders as a plain filled square with nothing in it.

The card also uses mx-4 and a hardcoded bg-[#0d0d0f] rather than the content column and theme tokens the rest of the web app uses.

What it should do

Give the web its own treatment of this screen. Concretely, the actions want to be a row sized to their content inside the card's padding rather than full-bleed children of the column, and the card wants the same content column and theme tokens as every other page.

Worth deciding at the same time whether this screen should become a shared component with a native branch, like the coaching components do, instead of a native screen the web also serves. That is the pattern the rest of the app uses: 62 templates map elements with data-native, and only three use an explicit native-versus-web branch.