XAML → Blazor Coverage Map

This map answers “does a Blazor surface exist?” — not “is it finished?” State 1 means a Blazor route covers the screen. It does not mean the page is production-complete, feed-driven, or navigable. Much of the Blazor surface is still the scaffold it was built as, and a scaffold renders convincingly enough to pass a route check.

MemberResourcesPage was the worked example at this map's 2026-08-03 audit. It was routed, it rendered four rows matching the Figma frame, and it was a mock scaffold: the rows came from a hardcoded TileDefs array rather than the menu feed, and every row was built with Link = "/member-resources" — linking back to the page it is on, so nothing navigated. That finding is now stale: as of build 34737cb4 (verified live 2026-08-12) the four rows link to live routes and all four destinations render. The gap has changed shape, not closed — each destination was built without a design source. See Member Resources Destinations — Design Gap. Tracked as AB#2403.

Assume other State 1 entries may be scaffolds too. Maturity was not assessed per page here and cannot be read off this table. Before planning against any row, open the file and check whether it is driven by real data and whether its links resolve. The Mock/Live pins in ScaffoldDataSourceRouters.cs answer a different question — which data source a router uses — and a page can be pinned live and still be a scaffold layout.

The four Member Resources destinations are the sharpest case. Look at the four rows in the Figma member resources frame (4870:10671): In Case of Emergency, International Directory, Membership Card, Orange Card. Those are exactly the four native pages above. And in MemberResourcesPage.razor every row is built with Link = "/member-resources" — each row linked back to the page it was on. The list rendered correctly and every row was a dead end, because none of its destinations existed yet.

Superseded 2026-08-12: in build 34737cb4 the four rows navigate to live routes and all four destinations render. What remains is the design gap — every one was built with no Figma frame behind it, per Member Resources Destinations — Design Gap.

Re-expressed does not always mean equivalent. The Jumpseat sub-nav is the cautionary case, and it needs stating precisely so it is not “fixed” the wrong way.

Natively the Jumpseat Info list is built from the menu feed — MenuItem.SpecialCode is the correlation key, MenuItem.Path names the destination, and the parent's child Items supply the rows — so comms can add entries through the API with no app release. The Blazor sub-nav is a fixed four-item array and does not read the feed, which is why the native list's fifth entry (Alaska Reciprocal List) does not appear.

That capability is not to be wired into the sub-nav. The sub-nav is section navigation and stays a fixed set; feed-driven custom items belong to the Jumpseat home page, which is where the pattern is attributed and which does not exist in Blazor. The capability therefore stays an open gap, carried by AB#2402 and the cross-cutting ask AB#2404, pending design direction on the home page. Adding custom items to the tab strip in the meantime would put them on the wrong surface and pre-empt that decision.

The general lesson still holds: when classifying something as State 2, check whether the treatment preserves the original's capabilities, not just its content — and if it does not, record where the capability should live rather than assuming it belongs on the replacement.

Membership Card carries PII — handle its captures accordingly. The live screen shows a member's name, classification, airline and member number alongside a scannable membership barcode. The capture in this doc is redacted. Any future capture of that screen must be redacted before it is committed or shared, and the same caution applies to the Blazor implementation when it is built.

This screen also carries personal data. The live page lists named officers beside direct phone numbers and email addresses. The committed capture redacts the contact lines and keeps roles, names and the action icons so the layout still reads. Apply the same treatment to any future capture, and to the Blazor implementation when it is built.

The three Contacts screens (ContactsHomePage, ContactsCategoryPage, ContactsPage) are route-registered and reachable in code, but the entry did not render for the account used here. The full My Pilot Group list came back as: MEC Communications, MEC Documents, MEC Committees, MEC Events, MEC Reps, Pay Codes, Pilot Dashboard, LEC Documents, LEC Update, LEC Events, LEC Reps.

MEC contacts are API-driven — just by a different API than the menu feed. MyPilotGroupPageViewModel appends “MEC Contact Info” only when preferences.Is_MEC_Contact_List_User() is true, and those preferences come from the member service (memberQueries.GetMemberAsync), not from local settings. Two neighbours work the same way — “MEC Hotels” behind Is_MEC_Hotel_List_User() and “MEC Hotel Feedback” behind Is_Hotel_Form_Active(). So the entry is neither missing nor unpublished; the account used simply is not flagged for the contact list.

That matters for planning: a screen's presence can be driven by more than one API — the menu feed decides most list contents, while member preferences decide whether some entries appear at all. Neither is visible from a file listing, and either can make a built screen look absent. A Blazor implementation has to honour the same preference checks, or it will show entries to members who are not entitled to them.