ALPA Mobile — Component Design Questions

What we found (from the Figma source):

• The design-system variable Font Family/Body resolves to "Futura PT" (alongside Font Family/Heading = Lora, Font Family/Eyebrow = Inter).
• The canonical Home screen (node 4099:5230) renders only Futura PT — its generated code uses Futura PT Book / Demi and no "LT Pro".
• However, a handful of standalone component frames' text layers — the Button and Button Group labels and the marketing Hero illustration — carry a direct font override to "Futura LT Pro" that bypasses the Font Family/Body token.

Why it matters: Futura PT and Futura LT Pro are different physical typefaces. If the overrides are unintentional, those buttons/labels would render in a different font from the rest of the app. Our component library standardizes on the Futura PT token, so today we treat the LT Pro instances as overrides to reconcile.

Design answer (2026-06-22): Futura PT is confirmed as the single body font family for the app. The Futura LT Pro overrides on Button, Button Group, and Hero layers are not intentional — those layers should be re-bound to the Font Family/Body (Futura PT) token in Figma. All component specs and token tables updated to reflect Futura PT throughout.

Font files confirmed available (2026-06-22): Futura PT Book and Futura PT Bold (.otf). Weights referenced in Figma layer tree but not yet confirmed as available files: Medium, Demi, Heavy — to be resolved at the ALPAMobile.Presentation font-bundling pass (deferred; the library shipped as a Blazor RCL 2026-07-15, D61).

Affected specs updated: button, button-group, card-hero, design-tokens.

What we found: the card-lg (CardHero / Document Hero) image carries a 6 pt left-border accent. The default is Border/Blue-lt #007BC2; some instances show a Border/Yellow #F7BB0D variant. The Figma source has no annotation explaining when each applies.

Figma reference: base design — card-lg master (node 4033:1436) — both the blue and yellow accent variants are in the component variant set. The home screen (node 4099:5230) shows card-lg instances with each color in context.

Why it matters: the answer decides whether the backend needs an accent/category field on DocumentItem. Tracked as the deferred design item in the Backend API Mapping Report (Part 1 §4, Open Questions).

Design answer (2026-06-26): Blue only, static. The 6 pt left-border accent on card-lg is always Border/Blue-lt #007BC2 — it is not data-driven and does not vary by content category or status. The yellow variant (#F7BB0D) has no confirmed usage and may be removed from the Figma file entirely. Backend impact: none — no accent field is needed on DocumentItem; the color is hardcoded to the token value at render time.

Affected specs: card-hero, home-screen-data-gap, backend-api-mapping-report (Part 1 §4 — accent field question closed).

What we found: DQ-1 confirmed Futura PT as the single body font family with Book and Bold .otf files in hand. A full Figma MCP sweep of all master component nodes (2026-06-26) found three additional weights in use with no confirmed font file for any of them. Node list below, grouped by weight — for procurement reference.

Futura PT Heavy

Futura PT Demi

Futura PT Medium (also referenced as Futura:Medium via the Body font token — same physical file required)

Node list generated 2026-06-26 via Figma MCP sweep of all master component nodes. 6 node IDs returned "invalid" errors (moved/removed from file): 5452:679, 4864:32242, 5515:55, 4038:221, 5452:434, 5515:52 — excluded above. Run sweep again after any Figma revision to keep current.

Why it matters: Missing weight files at the ALPAMobile.Presentation font-bundling pass mean those text layers will silently fall back to a system font or the nearest available weight, breaking visual fidelity. This needs to be resolved before the font-bundling pass (post #2087).

Tentative answer (2026-06-22): Sticking with Futura PT as the single body font family across all weights. Futura PT Medium, Demi, and Heavy .otf files are expected to be provided alongside Book and Bold before the ALPAMobile.Presentation font-bundling pass. No fallback substitutions planned — the full weight set will be bundled. Confirm file delivery before implementation begins.

Correction (2026-07-23, José, via AB#2358): The above is superseded — only two weights are being sourced: Futura (Regular) and Futura Book. Medium, Demi, Heavy, and Bold are confirmed not coming. As of this correction, zero Futura/Futura PT font files of any weight exist in the repository (this doc's "Book and Bold .otf files in hand" claim above could not be verified against the codebase — worth confirming with whoever holds them, since they aren't committed anywhere the app can bundle). Figma nodes above needing Medium/Demi/Heavy/Bold will need an explicit fallback decision (nearest-available weight, or CSS-synthesized bold) rather than the "full weight set, no substitutions" plan this answer assumed. See DQ-8 for the heading-font resolution built on this corrected scope.

Affected specs: design-tokens (Typography section), Flight Card, button-group. Deferred to the ALPAMobile.Presentation font-bundling pass.

What we found: The 2026-06-17 Figma revision introduced or updated several components whose exact height values were not extracted during the sync pass. Widths are confirmed; heights were marked TBD pending a dedicated sizing deep-dive.

Why it matters: Heights are required before scaffold ViewModel layout constraints can be written and before MAUI HeightRequest decisions can be made for the native-XAML surface of ALPAMobile.Presentation.

Answer: Sizing pass completed 2026-06-22 via get_metadata on live Figma file. All phone-scope components confirmed. Tablet components remain deferred (D12). navBar-bottom-tablet height is the only remaining TBD — it was not discoverable in the live Figma page metadata; tablet scope is deferred anyway. Component Dimensions table in design-tokens.html and button-card spec page updated with confirmed values.

What we found: The 2026-06-17 Figma revision introduced topNav-og alongside an existing topNav entry in figma-component-specs.json. Both entries share the same dimensions (393×98 px), matching the preliminary analysis.

Confirmation (2026-06-22): get_metadata run on both nodes via the live Figma API:

Both are 393×98 px. topNav-og is the canonical master (the -og pattern follows D15). The plain topNav entry is a stale reference. The figma-component-specs.json inventory retains both entries for traceability; active work references topNav-og. No rename decision required — this follows the already-established D15 pattern.

Answer: Confirmed identical at 393×98 px. topNav-og is authoritative. No further action required; topNav entry in the JSON is a stale alias (same resolution pattern as D15 for flight segment card).

What we found: The MEC theming token architecture is fully documented in design-tokens.html — the theme token set is the per-MEC customization layer, and the United Airlines palette is the Figma example. The token paths were confirmed; hex values were blank pending a variable read.

Answer (2026-06-22): All five United Brand palette hex values confirmed via get_variable_defs on the MEC frame node 4684:7914 in the Figma app page:

The MEC palette table in design-tokens.html has been updated with confirmed hex values and inline swatches. The same call also confirmed font families for DQ-8: heading = Lora (SemiBold 600), eyebrow = Inter.

What we found: DQ-1 confirmed Futura PT as the body font. The DQ-7 variable read (2026-06-22) confirmed the Figma tokens bound Lora SemiBold (heading) and Inter Bold (eyebrow) as separate families.

Resolved 2026-07-23 (José): Heading normalizes to Futura PT — Lora is no longer the base heading font. Eyebrow (Inter) was not part of this confirmation and stays as-is pending a separate decision. Only two Futura weights are being sourced: Futura (Regular) and Futura Book — see the corrected scope note on DQ-4, which supersedes that question's "full weight range" tentative answer.

Implementation (AB#2358): --font-heading-family in alpa-components.css updated from the Lora stack to the Futura PT / Futura fallback chain (matching --font-body-family). Separately, --alpa-heading / --alpa-body were found to duplicate literal font stacks instead of referencing var(--font-heading-family) / var(--font-body-family) — meaning a MEC theme's Font/Heading / Font/Body override (injected via BlazorThemeService → alpa-theme.js → #mec-theme) never reached any component. Fixed to bridge through the semantic tokens, matching the existing --alpa-navy: var(--surface-brand) color-alias pattern. No physical Futura PT font files exist in the repo yet (base or MEC) — rendering currently relies on iOS's built-in system "Futura" via the CSS fallback chain until the licensed files are sourced and registered via @font-face (Blazor) / AddFont() (MAUI XAML).

MEC scope: Documented per-MEC brand fonts (UAL = LeagueSpartan, DAL heading = BebasNeue / body = LeagueSpartan, FDX = TBD per DQ-14) remain the design target and are unchanged by this decision — those come from decision D33. None of those files exist either, so every MEC theme (e.g. theme.UAL.json) renders the interim Futura PT value until its real brand font is delivered.

Verified live (2026-07-23): iOS simulator, /home-preview against live production data. Confirmed via getComputedStyle before and after, not just visual inspection — --font-heading-family moved from "Lora", Georgia, "Times New Roman", serif to "Futura PT", "Futura", -apple-system, "Segoe UI", Roboto, sans-serif, and --alpa-heading (what components actually consume) now resolves the same way, proving the token bridge works end to end.

Before — Lora (serif)

After — Futura (sans)

Decision: Option B — FlightSegmentCardViewModel : CardViewModel (recorded as D16 in the Decisions Record).

Field inventory vs CardViewModel:

Why Option A fails the threshold: 8 fields must be independently rendered in discrete visual slots (origin/destination city codes, separate time row, leg detail strip, status badge). No fewer than 6–7 fields would have to be concatenated into ContentText — well above the 3–4 concatenation threshold. StatusBadge additionally requires a color value that has no representation in a string property. Type safety in the factory and clarity in the XAML bindings both require typed properties.

Answer: Option B adopted as D16. FlightSegmentCardViewModel : CardViewModel was initially the 10th scaffold component. Amended by D17: Flight Card demoted to Track B (typed domain component — FlightCardView : ContentView with 8 BindableProperty fields). The scaffold ViewModel is no longer used; direct property binding replaces the factory. Scaffold count: 10 → 9. Spec page: flight-segment-card-component.html (Track B display-data reference).

Updated specs: domain-controls, architecture, index, decisions record.

What we found (2026-06-22 FTDT exploration): The Figma symbol flight detail flight info (node 4325:6399, 297×154 px) appears in two places — inside the expanded flight card-og detail panel, and on FTDT/Jumpseat detail pages. It shows a single flight leg from one direction (Departure OR Arrival), not the paired A→B route of the Flight Card.

Initial assessment: The 4 unique fields (Gate, ActionLinks, DirectionLabel, UpdatedTimestamp) and the fundamentally different layout intent (single-directional leg detail vs paired-route card) suggest a new scaffold component. The overlap is 5 shared fields out of 12 total — below the reuse threshold established by DQ-9. However, the final call depends on whether Gate/ActionLinks come from the same data fetch as the flight card (which could push toward extension) or a separate detail API (which confirms a separate component and factory). See D15 precedent: one domain control, multiple Figma masters — the same could apply if it's one factory producing different scaffold types.

Design answer: Track B typed ContentView — FlightLegInfoView : ContentView with BindableProperty fields. The 4 unique fields (Gate, ActionLinks, DirectionLabel, UpdatedTimestamp) and the fundamentally different layout intent confirm this is not an extension of the flight card. Decided by D17 (two-track component pattern, 2026-06-22). See D17.

What we found (2026-06-22 FTDT exploration): When card-duty period-alt is expanded (Variant2, 345×1051 px), the "MANAGE FLIGHTS & DETAILS" panel contains inline flight segment rows. These rows show a 3-line format per segment:

• Date / time line (e.g. "April 28 2026 10:58 -06:00")
• Route line: Origin → Destination with a plane icon (e.g. "DEN ——✈—— MIA")
• Detail line: "Flight Time: 00:00 DL 302 757"

These instances are named flight detail flight info in Figma and are constrained to ~178 px wide by the duty period card container. Their layout is bidirectional (Origin AND Destination) — different from the standalone flight detail flight info symbol (DQ-10) which is one-directional. Fields visible: Origin, Destination, FlightNumber, AircraftType, FlightTime/Duration — 5 fields, no StatusBadge.

Initial assessment: Two viable options — (A) DutyPeriodCardViewModel owns an IEnumerable<FlightSegmentSummary> collection of lightweight row objects (inline, no separate scaffold component); or (B) reuse FlightSegmentCardViewModel with a compact rendering mode. Option A is simpler and keeps the flight segment rows as internal detail of the duty period card. Option B enables shared XAML templates but requires adding a compact-mode discriminator to FlightSegmentCardViewModel. The 5-field, no-StatusBadge subset and the 178 px constrained width favor Option A (lightweight inline rows rather than a full scaffold component).

Why it matters: determines the implementation boundary of DutyPeriodCardView and whether sub-factories are needed.

Design answer: Option A — compact flight rows are internal to DutyPeriodCardView. The 5-field, no-StatusBadge subset and 178 px constrained width do not warrant a separate scaffold component. DutyPeriodCardView owns an inner collection (IEnumerable<FlightSegmentSummary> or equivalent lightweight row type) rendered via its own embedded template. No sub-factory needed. Decided by D17 (two-track component pattern, 2026-06-22). See D17.

Context: The dynamic feed loads a PageDto response. The app has a HomeSkeleton.razor / ComponentSkeleton.razor scaffold. The update strategy has been partially discussed but the skeleton UX has not been designed.

Agreed approach: client passes a since date; server returns the current PageDto (or the subset of containers updated since that date). Client compares the response against its cached state by id and resolves adds, removes, updates, and reorders itself. Server stays stateless — no diff computation, no client-state tracking required.

Flow:

Engineering dependency (Option A): The backend needs to track a page-level or container-level last-modified timestamp so it can respond correctly to ?since= queries — returning only updated containers or a 304. The client already has id on every container and item (established in the API contract), which is the reconciliation key. No server-side diff computation required.

Design answer: — pending skeleton frames and animation decision —

Cross-reference: dynamic-feed-api-contract.html §9 Open Items (incremental page updates).

What we found: The Figma file (gpO3masyyNNHxjvRtdcRo7) has no spacing variables defined. The get_variable_defs call on the UAL home frame (node 20716:1802) returned empty. All spacing values in the current component spec are inferred or placeholder — none are sourced from Figma.

Figma references (base design — no spacing annotations yet): Home screen (node 4099:5230) · Carousel container (node 4317:5239) · card-lg (node 4033:1436) · card-md (node 4718:11125). These frames are the reference points for measuring spacing manually if variables cannot be added to the Figma file in time.

Why it matters: Spacing is a frontend concern — the frontend resolves it using its existing MEC context, so the backend does not need to carry it. But the frontend needs a canonical source of truth for the spacing scale and per-component usage before implementation. Without Figma annotations, any values baked into component styles will be guesses.

Tentative answer (2026-06-26): Auto-layout inference sweep across 9 component nodes confirmed a strict 4 px grid. The scale below is implementation-ready for all components except Flight Card and Notification Card (3 outliers still need design confirmation). UAL MEC uses identical spacing — no MEC delta.

Resolved (2026-06-30): The foundations reconciliation located the canonical Figma spacing scale (named 14-step scale, node 117:176 — xtiny 4 · tiny 8 · xxs 12 · xs 16 · small 20 · medium 24 · large 28 …), which supersedes this question's original "no spacing variables" premise. The 3 outliers are confirmed off that grid and are resolved by the consistency rule below; exact px confirmation rides on the reconciliation values pull (decision D-S1).

Normalizations are decisions recorded here; the live token / CSS change is applied under D-S1 alignment (gated — must not shift shipped mock layouts). Full scale in design-tokens.html — Spacing & Layout Tokens. Cross-reference: dynamic-feed-api-contract.html §9 (spacing token strategy).

What we found: The Figma MEC screens use per-airline typefaces in addition to the base Futura PT. From the design captures so far:

• UAL — League Spartan throughout (headings and body, replacing Lora/Futura PT in branded sections)
• DAL — Bebas Neue (headings/section labels) + League Spartan (body/card text)
• FDX — font family not yet confirmed from design capture

Why it matters — bold requires a separate font file. Each font weight is a distinct binary file. The browser/rendering engine cannot generate a true bold from a single Regular file — it will apply synthetic bold (algorithmically thickened strokes) which looks noticeably worse, especially at display sizes. For a professional app this is not acceptable.

We currently have two purchased weights for Futura PT: FuturaPT-Book.otf (Book/400) and FuturaPT-Bold.otf (Bold/700), with matching .ttf files registered natively in MauiProgram.cs. In Futura PT, "Book" is the regular weight — the family has no separate face named "Regular", so Book and Regular are two names for the same 400 file, not two files. Weights between the two do not all resolve the same way: Medium (500) resolves to Book 400, while Demi/SemiBold (600) resolves to Bold 700 — CSS font matching rounds down below 500 and up at 600 and above. Both are real purchased faces, so neither is synthesised.

For the MEC airline fonts (League Spartan, Bebas Neue, etc.), we have no purchased files yet. Before implementation can begin on any MEC screen, the correct font files must be procured — one file per weight used in the design.

Partial update (2026-06-26):

Questions 1–4 above still apply for each airline not yet at Confirmed. Full resolution is a procurement blocker for DAL and FDX implementation.

FDX re-checked 2026-07-06: the MEC Figma file was edited again on 2026-06-30, so the FDX page was re-scanned in full (every fill color and font on the page). Result: still no confirmed FDX typeface — the page shows a wide generic mix (League Spartan, Lora, Raleway, Futura PT, Futura, SF Pro, Merriweather, Inter) with nothing that reads as an intentional FDX choice, and zero FDX brand colors either. More Figma activity has not translated into FDX progress — this needs a direct design-team nudge, not another automated re-check.

Resolved 2026-07-29 — weight policy settled:

The base design system uses Regular/Book only. The Medium/Demi/Heavy Futura PT set previously assumed as forthcoming (see the tentative DQ-4 / DQ-8 note in naming-decisions-record.html) is not being procured. Design has accepted Regular/Book as the base text weight everywhere, which removes the licensing question for intermediate weights entirely.

The single exception is MEC customisation, which is a featured capability. A per-MEC theme may supply its own licensed typefaces and weights — that is the point of the MEC branding layer, and it is why the UAL League Spartan Regular 400 + Bold 700 pairing above remains valid. Those overrides ride on the MEC theme tokens (D33), not on base component rules.

Practical effect on the codebase: any base rule specifying an intermediate weight (500 / 600 / 800) has no real face of its own. .alpa-list-headline was corrected to font-weight: 400 under AB#2358. The remaining intermediate-weight declarations have not yet been swept — measured 2026-07-30: alpa-components.css 52 × 600, 16 × 500, 3 × 800; ftdt.css 36; widget.css 2 — 109 in total. Declarations at 400 and 700 are unaffected, since both files are purchased.

League Spartan is not MEC-only (2026-07-30). This entry frames League Spartan as per-airline MEC branding (UAL). The 2026-07-30 census found Other/Button = League Spartan Regular 400 in the base design system of the working file owEYzHf7FrHRvWC2u82UOl — the button style for button pill, tab group, card-button, profile and the saved/recent searches card. No League Spartan file ships, so those buttons render Futura PT today. Under the two-file direction that is the correct outcome, but the base-level usage is a separate fact from the MEC branding layer. See Typography Font Mapping § 2.

Raised 2026-06-26. Weight policy resolved 2026-07-29. Related: D33 (font-family as MEC theme token — pending). Figma references: UAL home node 20716:1802 · DAL home node 21247:2989 · FDX home node 21010:2758.

What we found: The DAL home screen (node 21247:2989) uses two distinct dark navies on the same screen:

• Welcome card background — #002a50 (Delta brand navy, the primary)
• NAVIGATE grid (ButtonCard backgrounds) — #09243d (noticeably darker, a different shade)

2026-07-06 update — pixel-confirmed via rendered screenshot (not just raw Figma fills), extends the pattern beyond the original two elements:

• #002a50 also appears on the Contract Comparison featured content card, not just the Welcome card.
• #09243d-family (sampled #0b2443, same shade within rendering tolerance) also appears on the TOOLS section cards (Scheduling Ticketing System, DART), not just the NAVIGATE grid.
• The two tones repeating consistently across separate UI groupings (Welcome + featured-content vs. NAVIGATE + TOOLS quick-access cards) is stronger evidence for the "intentional primary/secondary pattern" hypothesis than a one-off inconsistency would produce — but this is still not a designer confirmation.
• New sub-finding: the bottom nav bar on this same screen samples as #05273e — the base ALPA navy, neither DAL candidate. If navBar-bottom is meant to always track Surface/Brand (the rule confirmed for UAL), this screen's nav bar doesn't yet reflect that for DAL — worth asking whether this mock is simply unfinished there, or whether DAL's nav bar intentionally stays unbranded.
• Also sampled the confirmed heart/favorite-fill red on this screen: #c01933 — close to, but distinct from, ALPA's own base "red" (#c02126, used elsewhere in this doc suite) and from Delta's real-world corporate red (#e31837). Not yet confirmed whether this is a genuine DAL-specific accent or an unrelated near-shade.

Hypothesis: This may be an intentional primary/secondary brand surface pattern — e.g. Surface/Brand = #002a50 (primary, used for header/featured-content surfaces) and a second token (e.g. Surface/Brand-Dark or Surface/Brand-Secondary) = #09243d for quick-access/tool card surfaces. If so, this is a new token slot that doesn't exist in the current theme endpoint contract and needs to be added.

Alternatively it may be a draft inconsistency — the ButtonCard grid was painted with a slightly wrong navy and should be #002a50 to match the welcome card. The now-broader, more consistent pattern (extending to TOOLS and Contract Comparison) makes this less likely than originally thought, but doesn't rule it out.

We currently have no documented primary/secondary dark-brand surface pattern in the token set. The existing Surface/Alt token is light grey (#efefef) — an elevated card surface, not a secondary brand dark.

Design answer: — pending —

Raised 2026-06-26. Figma node: DAL home 21247:2989. Pixel-sampling pass 2026-07-06 (screenshot-confirmed, extends context). Blocks DAL theme token spec (D35 pending).

What we found: Several components accept a remote Image URL from the API at runtime:

• Hero Card (CardHeroViewModel.Image) — 200 px tall editorial photo slot · Figma node 4033:1436
• Text Card / card-md (CardTextViewModel.Image) — optional content image · Figma node 4718:11125
• Button Card (ButtonViewModel.Image) — icon or thumbnail for feature buttons · Figma node 4737:13038
• Pilot / Member avatar (PilotCard.AvatarUrl) — profile photo (currently falls back to fa-circle-user; confirm this is the intended fallback or provide a branded alternative)
• Small Card (CardSmallViewModel.Image) — compact content card image slot · node not yet confirmed from Figma capture

None of these have a defined fallback state in Figma. The Figma designs always show an image present. We do not currently have bundled placeholder assets for any of these slots. The pilot avatar currently falls back to fa-circle-user (icon-based), but the card image slots have no equivalent treatment defined.

Why it matters: Without a fallback, a missing or slow-loading remote image leaves a blank or broken image box visible to the user. This needs a design decision before the ALPAMobile.Presentation is built — either a neutral branded placeholder graphic (e.g. a lightly-tinted ALPA mark or grey rectangle with icon) or an icon-based treatment, per slot type. The assets (if graphical) must be delivered via the SharePoint folder alongside other UI Refresh assets.

Design answer: — pending —

Raised 2026-06-26. Affects Hero Card, Text Card, Small Card, Button Card, Pilot Card. Blocks the ALPAMobile.Presentation image-slot implementation.

What we found (from the AB#1821 scaffold):

• The bottom-nav tab icons (HOME · JUMPSEAT · KCM · FTDT · MY MEC) are currently hand-drawn inline <svg> paths repeated in every Razor page — not glyphs from the design's icon set. They are visual approximations and do not match the Figma icons.
• The project's icon fonts — materialdesignicons-webfont.ttf and fa-solid-900.ttf — live in Resources/Fonts/ for native MAUI (XAML) use only. The Blazor BlazorWebView cannot see them: they are not copied to wwwroot/fonts/ and there is no @font-face declaration or <link> in wwwroot/index.html referencing an icon font.
• So the WebView/CSS has no icon-font surface at all — every icon in the Blazor UI is either an inline SVG path or a Unicode emoji (e.g. ♡ / 🔔 / ✕ on the saved-flight actions), which is why glyph weight and shape drift from the design.

Why it matters: the tab bar is on every screen, so an icon mismatch is the single most visible fidelity gap in the scaffold. It also blocks a clean implementation: hand-drawn SVGs cannot track the design system if the icon set is revised, and they make MEC theming of the tab bar (per-airline icon treatment) impractical.

Proposed interim workaround: export the 5 tab-bar icon assets (plus the high-frequency in-app icons) from Figma to wwwroot/images/icons/ as SVG/PNG and reference them directly, replacing the hand-drawn paths — a temporary measure until the icon font is confirmed and wired into the WebView. This unblocks visual accuracy without committing to a font-licensing decision. (Tracked alongside the scaffold; see Asset Inventory.)

Design answer (icon-font path): — pending —

Raised 2026-06-29 (AB#1821 scaffold accuracy pass); reframed 2026-06-29 to the dual interim-vector / forward-font strategy. Affects Page Template bottom nav and every screen. Related: DQ-4 (Futura PT weight gap — text fonts, distinct from icon fonts).

What we found: The Page Template spec documents the navBar-bottom container (bg #05273e, px-16px, pb-8px) and the five tab items, but there is no annotation in Figma for what the selected/active tab looks like — no highlighted color, underline, pill, icon-fill, or label-weight change is specified.

The reusable BottomNav component (built during the Option B chrome work, AB#2190) derives the active tab from the current route and needs a defined selected state. The scaffold currently improvises: the active item's label and icon switch to ALPA blue (.alpa-nav-item--active → color/fill: var(--alpa-blue)) while inactive items stay white. This is a placeholder, not a confirmed design.

Findings (2026-06-30, two sources):

• Design intent confirmed — the Teamwork mobile requirements (Bottom Tab Bar, Space 4173) state: "the active tab is visually highlighted to reflect the user's current section." An active treatment is intended.
• But the design artifact doesn't realize it — the canonical navBar-bottom (Figma KPK3kvOU1zPHWIovXPB6Wo, node 4099:5232, Home screen) renders all five tabs identically: white labels (#ffffff) + light-blue icons (#c7dff6) on the navy (#05273e) bar — the Home tab is not differentiated (no highlight, indicator, pill, or opacity change). The active state is presumably a NavItem State=active variant not applied in this static frame.
• Base treatment ≠ scaffold — design base = white label + light-blue #c7dff6 icon; the scaffold improvises a dark-blue #007bc2 active treatment, which is both the wrong base color and the lower-contrast choice (≈3.3:1 on navy — below AA for the label; less prominent than the white inactive tabs).

Sharpened ask: the requirement says "highlighted" but the design doesn't show how. Design to apply/specify the NavItem active variant — which token, on icon and/or label, plus any indicator (top bar / pill / fill). Whatever is chosen must be more prominent than the white inactive tabs and meet AA on navy. Two near-term fixes regardless: (1) move the scaffold base icon to light-blue #c7dff6 to match design; (2) replace the dark-blue active placeholder.

Design answer: — active-state visual still pending; intent + base treatment captured 2026-06-30 (Teamwork Space 4173 + Figma KPK3kvOU1zPHWIovXPB6Wo) —

Raised 2026-06-29 (BottomNav component, AB#2190). Affects Page Template bottom nav and the BottomNav component. Related: DQ-17 (tab-bar icon font).

What we found:

• WebView-rendered Blazor may miss the native-feel bar on gesture/physics/transition-heavy interactions (swipe-to-delete, pull-to-refresh, drag-reorder, scroll inertia, native transitions); static content / forms / simple lists generally feel fine.
• Mixed mode is established as feasible — native XAML pages can host BlazorWebViews, so native + Blazor surfaces coexist in one app.
• The component library is render-surface-agnostic (D12/D17 two-track: ViewModel + variant model + tokens, not CSS-bound) — the same specs render as Blazor or native XAML without redesign.
• Ultimate fallback: because of that abstraction, the UI can pivot to full native XAML with no component redesign — the worst-case de-risk. The option space is a reversible spectrum: all-Blazor → mixed (XAML shell + native static, Blazor dynamic) → full native XAML, all from the same specs.
• The AB#2190 full-bleed spike proved the MAUI Shell constrains the BlazorWebView frame, so the host model materially affects how native and Blazor compose.

Why it matters: sets the host architecture and the native/Blazor surface split — but the chrome abstraction makes it low-regret: start mixed and escalate to full-native if testers reject the Blazor feel, without discarding the component work.

Current leaning (J. Castro — to validate with design + eng, not decided): XAML-first Shell + native static content, Blazor for the dynamic-UI portion (data-driven feed/widgets), with full native XAML held as the ultimate fallback.

Design/eng answer: — pending —

Raised 2026-06-29. Related: D12 · D17 · AB#2190 (chrome/host + full-bleed) · AB#2191 (AppShell/MainLayout split) · AB#2087 (Presentation Extraction) · DQ-20.

What we found: Figma renders saved rows with swipe-to-reveal delete (i-trash, native idiom); the scaffold uses a persistent visible action column (♥ save · ↻ re-search; 🔔 alerts · ✕ delete).

Why it matters: swipe fits a single destructive action and is costly to replicate in a WebView; these cards need multiple, mostly non-destructive actions, and accessibility needs a visible alternative regardless.

Leaning / baseline: visible action column as the default (multi-action + a11y + WebView fit); swipe-to-delete deferred as an optional enhancement for the destructive delete only — or moot if this surface is promoted to native XAML per DQ-19 (where swipe becomes free/idiomatic).

Design answer: — pending —

Raised 2026-06-29 (first concrete instance of DQ-19). Related: DQ-19 · Saved Search Card · Flight Segment Card.

Current state (audited 2026-07-30) — text cannot be enlarged at all. 320 font-size declarations are px with zero rem/em; text-size-adjust is unset; the viewport in index.html and home.html carries maximum-scale=1.0, user-scalable=no, so pinch-zoom is disabled too; and no base font size is declared anywhere, meaning unstyled text inherits the WebView's 16px. Together these fail WCAG 1.4.4 Resize Text, and user-scalable=no is itself a flagged anti-pattern.

Load-bearing constraint: iOS WKWebView does not apply Dynamic Type to web content automatically — converting to rem alone will not satisfy the answer. Either the font: -apple-system-body WebKit hook (iOS-only behaviour) or a native bridge that reads the OS scale and pushes it into the WebView is required. The bridge is recommended, since the app ships both iOS and Android heads. Scope, including the 90 fixed height declarations that are the 200%-reflow risk surface, is on AB#2391.

Full record: typography-font-mapping.html; the question as put to design is docs/requirements/design-question-typography.md.

What we found: the two render surfaces honour OS text scaling very differently:

• Native XAML (MAUI): nearly free — Label.FontAutoScalingEnabled is on by default, so controls honour iOS Dynamic Type / Android font-scale automatically.
• Blazor WebView: does not honour Dynamic Type at all — WKWebView renders CSS px and ignores the user's OS accessibility text size. The current scaffold (hard-coded px) therefore fails accessibility text scaling — a likely tester/compliance flag, and one more DQ-19 evidence point.

Why it matters: text scaling is a baseline accessibility requirement; the WebView gap means it must be engineered, not assumed. It also bears on the DQ-19 surface decision (another "free in native, manual in WebView").

Recommended approach (proposed):

• Relative, token-based type scale — named text styles → rem/em anchored to a root size (extends the D33 Font/Heading · Font/Body tokens with a size scale); surface-agnostic; do first.
• WebView scale-bridge — read UITraitCollection.PreferredContentSizeCategory (iOS) / Configuration.FontScale (Android) natively, inject as a CSS variable (--text-scale) / root font-size, and re-apply on trait/config change (same pattern as the AB#2190 safe-area-on-rotation work). Clamp the multiplier so Larger Accessibility Sizes don't break layout.
• Reflow, not just bigger text — text-bearing containers use min-height, never fixed height; explicit wrap-vs-truncate per component. (The 393×852 scaffold's fixed heights must become flexible — a component-spec + CLAUDE.md CSS rule.)
• Native surfaces map the type tokens to scalable sizes (FontAutoScalingEnabled) and test.
• Test matrix: default · largest standard · Larger Accessibility Sizes, both platforms.

Design/eng answer: — pending —

Raised 2026-06-29 (#6 accessibility pass). Related: D33 (font-family tokens) · design tokens · DQ-19 (render surface) · AB#2087.

Withdrawn (2026-07-01): this question assumed a composite content-item id (ItemTypeId + prefixed ItemId, e.g. menu-123/doc-456/msg-789). That premise was retracted — the source table was erroneous. The real Content Contract has no composite key: content is a MenuItem (navigation) or a DocumentItem (content), served by the MobileContent API. No key-field / prefix-authority / namespace question remains.