The Blazor MEC surface is a scaffold wearing live-app clothes. /mec/events,
/mec/hotels and /mec/reps each render a hardcoded list declared as a
private record array in the page's own code-behind — six fictional events, five Chicago-area
hotels with invented star ratings and nightly rates, six fictional officers with
@ual.alpa.org addresses. No data service is called. The native equivalents —
PilotGroupEventsPage, PilotGroupHotelsPage,
PilotGroupRepresentativesPage — all show live member data.
None of the three mock lists has a Figma frame. The Design-Source Gap Inventory live-verified this against all four known Figma file keys: no “Events” frame anywhere, the only “hotels” match a name-matching false positive (the HOTEL COMMITTEE detail page), and “REPRESENTATIVES” only as a 2–3 row preview inside composite MEC pages. These screens were scoped by the migration guide as functional ports of the legacy Pilot Group pages — “MEC” is the Blazor-era rename of that concept — so no UI-Refresh design was ever commissioned for them.
/mec/committees is the different case: it is Figma-backed (node
20900:2432) but the shipped page diverged from the frame, and the level below it
— the native committee-details screen, PilotGroupCommitteDetailsPage, with
per-member contact cards — exists in neither Figma nor Blazor. The Blazor committee rows carry
chevrons, but each row's href is /mec/committees: the page it is
already on.
| Screen | Native (XAML) | Blazor (this build) |
|---|---|---|
| Events | PilotGroupEventsPage — live feed with unread badges (40 unread at capture); one page serves MEC and LEC via ?Scope= |
MecEventsPage.razor “Events” — six hardcoded MecEvent records in the code-behind, no data service, MEC only |
| Hotels | PilotGroupHotelsPage — live list grouped by airport IATA code; entry appears only for members flagged Is_MEC_Hotel_List_User |
MecHotelsPage.razor “Pilot Hotels” — five hardcoded PilotHotel records with star ratings and nightly rates the native data does not carry; no preference gate |
| Reps | PilotGroupRepresentativesPage — live officer cards with call and mail actions; MEC and LEC via ?Scope= |
MecRepsPage.razor “Representatives” — hardcoded MEC Officers and Council 12 sections, fictional names, mailto links only |
| Committees | PilotGroupCommitteePage list → PilotGroupCommitteDetailsPage detail: cards per member with role, name, direct phone/email, call and mail actions |
MecCommitteesPage.razor “Committees” — Standing/Special sections with Chair lines; rows carry chevrons but self-link to /mec/committees. No drill-down level exists. |
The gap is wider than these four routes. The native pages are
scope-parameterised — PilotGroupEventsPage?Scope=LEC is the same file as the
MEC version — so the Blazor routes, which hardcode MEC, cover half of what the native pages
serve. The LEC side, the preference-gated entries and the feed-driven list contents are
catalogued in My Pilot Group → MEC
Composition Coverage; this page documents only the design gap on the four MEC lists.
Captured 2026-08-12 on an iPhone 17 Pro Max simulator (iOS 26.4), build commit
34737cb4, against live data. Native screens were reached the way a member reaches
them: Home → My Pilot Group → the list entry.
PilotGroupEventsPage, live feed
Real MEC events from the feed, with unread badges — 40 unread at capture. The same page
serves LEC events through its Scope query property.
MecEventsPage — hardcoded scaffold
Title bar reads “Events”. The six rows are a private
MecEvent record array in MecEventsPage.razor.cs — no data
service is injected. Date-box rows, virtual/in-person markers and locations are all
invented scaffold content.
PilotGroupHotelsPage, live and gated
Live hotel data grouped by airport IATA code. The entry itself is preference-gated —
it appears in My Pilot Group only because the capture account carries
Is_MEC_Hotel_List_User.
MecHotelsPage — mock cards
Title bar reads “Pilot Hotels”. Five hardcoded Chicago-area hotels from
MecHotelsPage.razor.cs, carrying star ratings and nightly rates —
fields the native hotel data does not have. No IATA grouping, no preference gate.
PilotGroupRepresentativesPage — contact lines redacted Live officer cards with call and mail action icons. The officers' direct phone and email lines are redacted in this capture — the live screen renders real members' contact details.
MecRepsPage — fictional roster
Title bar reads “Representatives”. MEC Officers and Council 12 sections
from two hardcoded record arrays in MecRepsPage.razor.cs — the names are
fictional, the addresses invented. Mail links only; native's call action has no
counterpart.
PilotGroupCommitteDetailsPage — contact lines redacted Reached from My Pilot Group → MEC Committees → a committee. Cards per member with role, name and direct phone/email, each with mail and call actions. This capture predates the 2026-08-12 session; contact details are redacted.
MecCommitteesPage — flat list, no level below
Standing and Special sections with a Chair line per committee. Every row carries a
chevron, but its href is /mec/committees — the page it is on.
There is no committee-detail route, expander or modal; the native detail level is
entirely absent.
Walked live on an iPhone 17 Pro Max simulator, build 34737cb4, signed-in member account:
The mock data was confirmed in source, not inferred from pixels: the record arrays live in
MecEventsPage.razor.cs, MecHotelsPage.razor.cs and
MecRepsPage.razor.cs, and the committee rows' self-link is in
MecCommitteesPage.razor. The Figma absence for events, hotels and reps is the
inventory's live MCP search across all four file keys, not docs-silence.
| # | For | Question |
|---|---|---|
| 1 | Design | Should the three unframed lists (events, hotels, reps) get one consistent MEC sub-page list template, or three separate designs? The gap inventory recommends bundling them into a single capture request precisely because a design pass would likely produce one template. |
| 2 | Design | Committees: adopt the shipped two-section/Chair-name shape, or rebuild to the Figma frame (node 20900:2432: flat list, heart toggles, “VOLUNTEER OPPORTUNITIES” and “ALL MEC COMMITTEES” CTAs)? The shipped page is a straight port of the legacy list; the frame is a newer UI-Refresh design nobody has applied. |
| 3 | Design | Does the committee-detail level survive? Native drills into per-member cards with call and mail actions; Blazor has no level below the list but its rows still present as navigable. Either design the detail screen or make the rows non-interactive — the current chevron-that-self-links is the same defect the comms detail page documented. |
| 4 | Product | LEC: the native events/reps pages serve LEC through ?Scope=; the Blazor routes hardcode MEC. Does the MEC composition cover LEC via a scope parameter, parallel routes, or is LEC explicitly out of scope for the refresh? |
| 5 | Engineering | MEC Hotels is preference-gated natively (Is_MEC_Hotel_List_User, from the member service). The Blazor page has no gate — tracked under AB#2405. Should the gate land with the redesign or before it? |
| 6 | Design | What belongs on a hotel row? The mock invents star ratings and nightly rates; the native data is hotels grouped by airport with committee-negotiated details. A design built from the mock would specify fields the feed cannot fill. |
ALPAMobile.Presentation/Components/Pages/MecEventsPage.razor.cs — hardcoded MecEvent arrayALPAMobile.Presentation/Components/Pages/MecHotelsPage.razor.cs — hardcoded PilotHotel arrayALPAMobile.Presentation/Components/Pages/MecRepsPage.razor.cs — hardcoded officer/rep arraysALPAMobile.Presentation/Components/Pages/MecCommitteesPage.razor — self-linking committee rowsALPAMobile/Pages/PilotGroupEventsPage.xaml, ALPAMobile/Pages/PilotGroupHotelsPage.xaml, ALPAMobile/Pages/PilotGroupRepresentativesPage.xaml, ALPAMobile/Pages/PilotGroupCommitteDetailsPage.xaml — the native pages