owEYzHf7FrHRvWC2u82UOl, parent page node notifications-ff
5060:14989, component set 5054:13776) delivered the
flight-status card design, and the implementation now matches it: relative timestamp top-right,
44px icon slot (a generic placeholder circle in the design itself), the route as a
“JFK » MIA”-style bold title (parsed from the message prose — see §1), the
flight date beneath, and a caret-only expander pill. The open variant
(5054:13777) also delivered an expanded state: a status row with
the flight number and a rounded severity pill (“Delayed 34m”, yellow/500)
— implemented as the first row of the expanded detail. The invented status chip no
longer appears anywhere on this card; the drawn pill carries severity in the expanded
state, and the collapsed face has no severity slot at all. Everything else in this document
stands on the list question: the list is still Option A (flat, one card per
alert — the delivered screen again shows a single card, so the grouping question in §5 remains
open), cards are spaced 8px apart — the notifications-comms screen
(5060:15039), the only frame that stacks two of these cards, wraps them in a list
frame (5056:13945) with gap: var(--tiny, 8px) — and the §3 mock-ups
below intentionally still show the pre-redesign card face — the options they illustrate
concern list structure, which the face redesign does not change.
sentDateTime, device receipt is never captured), flight reference, and the
VIEW FULL DETAILS link — are no longer on the
production card. Consequences worth naming: the alert's message text has no surface in the
list (an expanded card says "DL5328 · GATE CHANGE" but not which gate), and the
Flight Updates history screen has lost its only in-list entry point — it is now
reachable only by the readiness scenarios row and by route. That raises the stakes on §5
question 7: if the answer is "a tapped push opens the list", the history screen is unreachable
for a real member. Both are faithful to the drawn design, flagged here rather than silently
re-added. For the review itself: the retired detail is preserved behind
ShowAlternateDetailView — entering Notifications from the readiness board
(?showcase=true) renders it on expanded cards, so this comparison can be made on
the device side-by-side with the drawn card rather than from memory.
The design covers one flight-status card, once. The live service sends a stream of alerts per flight. Nothing in the design says what a list of them should look like.
R6hPjBdjSIn6946qTJasUC, frame 5060:14989
(notifications-ff) contains exactly one
notification card flight status instance and one hidden empty
list frame. Nothing below it.R6hPjBdjSIn6946qTJasUC or owEYzHf7FrHRvWC2u82UOl.
Measured against production on 2026-08-01/02, for one real subscription
(fs-9fceb91f-…, a single JFK→SYR leg):
| Observation | Value | Consequence for the list |
|---|---|---|
| Alerts for one flight | 9, all within one afternoon | One subscription fills the whole screen |
title | Always "Flight Changed" | Cannot distinguish rows — every row's headline is identical |
| Route | Not a field; embedded in message prose | Must be parsed out; the design's "DEN » MIA" title does not exist in the data |
| Arrival order | Not guaranteed to match event order | A gate assignment can appear above the time revision that preceded it |
destination | "0" placeholder | No tap-through target the design could hang a CTA on |
"Flight Changed" and the route only exists inside a sentence. This
is not a criticism of the design — it is what happens when a screen is specified before its
feed exists. It does mean the card had to be re-derived rather than implemented literally.
Built so the area is testable now, and deliberately reusing existing design language rather than inventing any: the Flight Card (D64) trip line and View Details pill, plus a status chip derived from the message text so the list is scannable at all. Tapping expands inline (accordion, one open at a time), matching Flight Search and FTDT. A Flight Updates screen shows every alert for the flight in one place, which is how an out-of-order arrival is made visible rather than misleading.
This is Option A below. It works, but it treats a stream as a flat list — the thing we would like design input on.
We did not pick A because we think it is the best answer. We picked it because it is the only one that does not require a design decision we are not entitled to make:
"Flight Changed", so without it the
list is literally nine indistinguishable rows. We would rather add one thing and flag it
than restructure a screen on our own judgement.The consolidated Flight Updates history screen is the one place we did go further, and for a specific reason: alerts do not necessarily arrive in the order the changes happened, so a flat list can genuinely mislead — a gate assignment can sit above the arrival revision that preceded it. The history view is where that ordering becomes legible. If B or C is chosen it stays; the entry point changes, not the screen.
This is behaviour the design team will want to specify, so it is stated explicitly rather than left implicit in the code.
A flight-status push arrives with contentType: "FlightNotification" and the
notification's id. Tapping it previously opened the native Saved
Flights list — neither the alert that was tapped nor anything about it. A member tapped
“DL5328 now departs from gate A17” and landed on a list of saved searches.
It now lands on the alert itself. The full path:
| # | Step | Where |
|---|---|---|
| 1 | OS delivers the push; the member taps it | iOS / Android |
| 2 | contentType switch routes flightnotification | PushNotificationHandler |
| 3 | Destination rides the Shell navigation itself as a query attribute (?entry=/notifications?tab=flight&focus={id}, escaped) | PushNotificationHandler → GoToAsync |
| 4 | Host page applies it as the web view's StartPath before the web view boots (IQueryAttributable — the XAML pages' query-property pattern) | BlazorDevPage |
| 5 | Router's first frame is already the destination — no boot-at-/ frame, no default-tab flash (replaced the BlazorEntryRoute hand-off, which navigated after first render; flash reported and fixed 2026-08-12) | Main.razor Router |
| 6 | Flight Finder tab selected, that alert expanded and marked read | NotificationsPage |
| 7 | The card is scrolled to the middle of the view | alpaScroll.centerOn |
The routes a tapped push produces are exposed on the readiness board: Page Readiness → Notifications → Push / Deep-link Test Scenarios. Rows are built from the live feed, so the ids are real; each opens exactly the route the push handler produces. Covers the newest alert, one deliberately below the fold (which is where “centred” actually gets tested), the history view, and both stale-id cases.
Since 2026-08-12 the same page can also produce the push itself: Real push tap → post a
local notification schedules a local OS notification carrying the newest alert's real
FlightNotification payload (via the ILocalPushTester port — APNS
aps-dictionary shape on iOS, flat intent extras on Android, matching what each
platform's tap handler parses). Tapping its banner exercises the entire chain in §2b's table —
OS → delegate → PushNotificationHandler → deep link — with no backend send, no
subscription and no flight that actually changes.
All four are drawn with the same real data: nine alerts, one flight. Options B–D assume a member watching two or three flights, which is where the difference matters most.
open variant carries severity as a rounded pill in the expanded
status row — with exactly one severity drawn: “Delayed 34m” on
yellow/500 (the existing Status/Delayed token). The
implementation uses the drawn pill shape for all severities, keeping the invented tint
palette for the ones the design has not drawn (cancelled · gate · info). Still needed
from design: pill colours for the rest of the vocabulary, and whether the magnitude
(“34m”) is expected — the payload does not carry it as a field. Note the collapsed list
is now unscannable by change type by design, which raises the stakes on
question 1.FlightNotificationText.ParseRoute);
when the prose does not parse, the card falls back to the message headline. The underlying
backend ask stands: route and flight number should be payload fields, not sentence
content.NotificationCenterMessage
feed or a separate one?”) is now answered: a separate service,
{BaseAPIUrl}/api/notifications/list, keyed by fs-{ScheduleKey}
audience.