What a page-composition doc is, why it exists, and the implementation contracts every per-airline doc plugs into. Start here before opening any of the three airline docs.
A page-composition doc (one per airline: UAL, DAL, FDX) is a per-screen, slot-by-slot breakdown of every MEC-customized screen for that airline: which container/component fills each numbered slot, in what order, linked to its exact Figma node — enough to implement without re-opening Figma. It deliberately excludes app-level chrome (status bar, top nav, bottom nav bar) since that's identical across every MEC and covered once, elsewhere — these docs are scoped to just the part that actually varies per airline: the content slot.
Not a design spec. Token values (colors, fonts) live in each airline's {mecId}-mec-spec.html — the page-composition doc links to it rather than repeating it. A page-composition doc answers "what renders here, and what data does it need," not "what color is it."
Every slot in a page-composition doc ultimately resolves to one of two upstream APIs. These are the contracts that make a page-composition doc buildable rather than just a Figma inventory:
Per-MEC token map (colors, fonts, spacing, radii) delivered by GET /api/theme/{mecId} at login — the source for every color/font referenced in a page-composition doc's linked spec.
The MobileContent API and its two content types — MenuItem (navigation) and DocumentItem (content) — that back nearly every populated slot in every page-composition doc.
Real screens broken into small chunks, each paired with the theme/content JSON that produces it — a worked companion to the two contracts above, for the dev actually authoring MEC data.
mec-customization-mock-guide.html →How MenuItem.Path drives native Shell navigation via INavigationService — what happens when a slot's MenuItem is tapped.
The source rationale behind the content contract's MenuItem vs DocumentItem model split, and the backend Change 1–5 tracker referenced throughout the airline docs.
| Airline | Screens documented | Comms content | Theme status |
|---|---|---|---|
| UAL — United | 6 screens → | Real, inline — sourced from comms-content.html (SharePoint DEPT_DSS ingest) | Fully resolved — no open design questions |
| DAL — Delta | 4 screens → | Structure only — comms-content.html is entirely UAL-scoped; unpopulated feeds documented as-is (stub content), not guessed at | Blocked — colors pixel-confirmed, intent open on DQ-15 |
| FDX — FedEx | 1 screen (WIP) → | None yet — one real content frame exists; rest of canvas is unbranded scaffold or stray UAL-named artifacts | Stub — no FDX brand colors found; font TBD (DQ-14) |
gpO3masyyNNHxjvRtdcRo7) — every frame, including hidden/collapsed ones. FDX's canvas taught this the hard way: several frames were hidden and still literally named for UAL (CLE172, HOTEL COMMITTEE, UPA27) — copy-paste template leftovers, not real FDX content. A partial sweep would have mistaken template scaffolding for FDX-specific screens.