Tester Walkthrough — Search

Updated: 2026-10-02 11:18 ET · On the Page Readiness screen, look for: Search — local on-device results (requires login)

TLDR: 20 checks covering every one of the 17 onboarded content types' actual opening behavior — the Offline / Online tab bar above the search box, the idle "Offline Search" prompt, typing a query and getting real matches pulled from content already cached on the device (grouped into collapsible sticky-header sections by content type, with the matched term highlighted in both title and excerpt), the multi-select category filter and its per-row "Only" isolation shortcut, collapsing/expanding a result section, a genuine no-match result, tapping a result to confirm it opens real content (covering Document/Notification plus, in the same check, Jumpseat Airline/Country/Accident Topic/KCM Airport/KCM Airline/Resource Link, and KCM Airport's own full-screen map viewer), tapping an Event/Company Contact/Hotel/Committee result to confirm it opens a contact card whose email/phone/link lines are actually tappable (dial/mail/browse), two content types with their own distinct opening mechanism — Call to Action's auto-login web view and Menu Item's server-driven deep link —, a relaunch with an already-populated index searching immediately instead of blocking behind "Preparing…" again, and the newest addition — dynamic-feed content (Home/MEC/LEC feed cards) rendering in search through the feed's own real component and CSS rather than a plain title/excerpt row, and navigating to the same destination the same card opens from Home — split into two distinct filter categories, ALPA Feed (the global feed content every member sees) and MEC Feed (a member's own MEC/LEC feed content), rather than one combined "Dynamic Feed" bucket (found not user-friendly live, 2026-09-09). Local search went live 2026-08-25 (AB#2561) and grew from 3 to 14 content types on 2026-08-26, then to 17 on 2026-09-09 with the addition of dynamic-feed (Feed Card) content — search now returns actual indexed content instead of a small set of hardcoded sample rows. Search results and your filter selections now survive navigating away and back (tapping a result and returning no longer resets the page). Flight Search Airport was withdrawn from search the same day it was onboarded (2026-08-26) — it duplicated KCM Airport under near-identical names with no destination of its own; KCM Airport is the type that actually opens a real screen. A relaunch no longer re-blocks Search behind "Preparing…" (2026-08-26) — the on-device index survives a relaunch untouched, so Search now shows a small non-blocking "Refreshing…" notice instead and stays fully usable against that already-indexed content while a fresh copy loads in the background; see Check 10. Feed Card content is the newest onboarded type (2026-09-09, AB#2561 Phase 0 + Phase 1 pilot), split into the ALPA Feed/MEC Feed categories same day — see Check 11. Online search (Checks 18 to 20) answers from ALPA's website through Coveo, as you, and opens each result signed in (AB#2562).

Before you start

Checks

1 · Open Search and see the idle prompt

Steps: While logged in, tap the search icon (magnifying glass) in the top navigation bar.

Search screen idle state: the Offline / Online tab bar, the search box under it, and an Offline Search prompt

What you should see: At the top, a two-tab bar, OFFLINE (selected) and ONLINE. Directly under it, a white search box with its own leading magnifying-glass icon (inside the box, left of the placeholder text "Search content on this device …"). Below that, an "Offline Search" prompt with a magnifying-glass icon and the subtitle "Find content saved on this device, with or without a connection". There is no list of shortcut links (Flight Finder, KCM, Member Resources, My MEC) below it — those were removed. Once you type something, an × clear button appears at the right edge of the box — tapping it empties the box and returns you to this idle state (same clear affordance as the search boxes on KCM Airlines and the International Directory).

Something's wrong if: You see a list of shortcut rows (Flight Finder, KCM Airports & Airlines, Member Resources, My MEC) instead of the "Offline Search" prompt — that's the old stub layout, and so is a "No Recent Searches" message (there is no history feature).
Note: if spelling-suggestion chips appear above the keyboard while you type, that's your device's own predictive-text/autocorrect feature — an operating-system keyboard setting, not app behavior. Turn it off under Settings if it's in your way: iOS is General → Keyboard; Android is System → Languages & input → On-screen keyboard → (your keyboard) → Text correction.

2 · Search for something real and get real matches

Steps: Type a term you know exists in content you (or the app's background warm-up) have already loaded — e.g. jumpseat — into the search box.

Search results for 'jumpseat' grouped under COMMITTEE, DOCUMENT, and JUMPSEAT POLICY section headers

What you should see: Results appear as you stop typing (results are debounced, not instant per keystroke) — real titles and excerpts, grouped under a section header per content type (for jumpseat today that's COMMITTEE, DOCUMENT, JUMPSEAT POLICY, and further down NOTIFICATION), sections in alphabetical order. This is genuine indexed content, not a fixed sample set — try a different real term (an airport name, a notification headline you remember) and the results (and which section headers appear) should change accordingly. Exactly which groups and how many results appear will drift over time as real content changes — that's expected; what matters is that results are real and grouped, not a fixed set.

Something's wrong if: You always see the exact same results regardless of what you type, results appear as one flat list with no section headers, or the results are titled things like "FTDT Duty Period Calculator" / "Flight Finder — Search Flights" no matter the query — those were the old hardcoded sample rows and should no longer appear.

3 · Open the filter, deselect a category, and confirm results narrow

Steps: Tap the sliders icon in the top-right of the Search title bar to open the filter. The boxes are the real areas currently indexed for search (12 today — ALPA Feed, Documents, Flight Search, In Case of Accident, International Directory, Jumpseat, KCM, MEC Feed, MEC/LEC, Member Resources, Navigation, Notifications), and every box starts checked. Uncheck everything except Documents.

Filter modal listing all 12 areas including the separate ALPA Feed and MEC Feed rows, every box checked

ALPA Feed and MEC Feed (2026-09-09) replaced a single combined "Dynamic Feed" category found not user-friendly live — see Check 11.

What you should see: Any number of boxes can be unchecked independently (not one-at-a-time like a radio button). Tap APPLY to close the modal — the sliders icon in the title bar now shows a small badge with the number of categories still included (not the number you unchecked). Search again (e.g. document): with only Documents checked you get just the Documents section; re-open the filter and check KCM back on and a KCM match reappears too — the filter genuinely narrows local results by category, it's not cosmetic. Tap clear to reset back to every category selected (the default), not to none.

The "Only" shortcut: each row also carries its own ONLY pill to its right — tapping it checks that one category and unchecks every other in a single tap, instead of unchecking each one by hand. It's a shortcut for the same multiselect state Check 3 already covers, not a separate mode: after tapping ONLY on a row you can still hand-toggle other boxes back on, and clear still resets every box to checked the same way.

Tapping ONLY on Documents then searching MEC, showing only the DOCUMENT section with the badge reading 1

Documents isolated via its ONLY pill, then searching MEC — the filter badge reads 1 and only the DOCUMENT section appears. Every filter category (12 today) was walked this same way while live-verifying this pass — see the TLDR and Check 11.

Something's wrong if: Unchecking a second box rechecks the first one (that would mean it's behaving like a single-select control), the badge count on the trigger icon doesn't match how many boxes are checked, unchecking every box doesn't produce No Results, clear leaves any box unchecked, or tapping ONLY on a row leaves any other box still checked.

4 · Search for something that genuinely doesn't exist

Steps: Type a nonsense term unlikely to match anything, e.g. zzznomatch.

No Results empty state after searching a nonsense term

What you should see: A "No Results" empty state with the subtitle "Nothing matched "zzznomatch"" — the exact term you typed appears in the message.

Something's wrong if: The page shows a blank area instead of the "No Results" message, or the message doesn't include your actual search term.

5 · Tap a result and confirm it opens real content

Steps: Search for a term that returns a Document result (e.g. jumpseat, per Check 2), then tap that row.

Tapping a Document search result opens the real document viewer

What you should see: You're taken to the real document, not a placeholder or an error — the title bar shows the document's own title and its actual content renders below. (You may see a one-time "Download Documents for Offline Access?" prompt the first time you open any document — that's an unrelated document-cache feature, not part of search; Not Now/Enable either way, then confirm the document itself is showing.) A Notification result instead opens that notification's detail page.

Note: a handful of Documents (a "webpage" DocType, e.g. links out to a per-MEC intranet site like an MEC Alert) deliberately open in a separate native browser view instead of inline — the destination site needs its own auto-login and actively resists being framed, so an inline iframe can't drive it. You may briefly see that site's own login form flash before it auto-signs-in. This is the same shared document-open behavior everywhere in the app (not specific to Search) — it is not a bug, and the row you tapped still opens the content it names.
Also confirmed live, same in-app-route pattern: a Jumpseat Airline result (e.g. a carrier name) opens the same jumpseat/airline-policy page a Jumpseat Policy result does; a Country result (e.g. a nation name) opens its International Directory detail page; an Accident Topic result opens its In Case of Accident detail page; a KCM Airport/KCM Airline result opens its KCM detail page. A Resource Link result is the one exception — its destination is an author-entered external URL, so tapping it opens the system browser (or another app, for a non-http link) instead of navigating anywhere inside this app; the Search page itself stays exactly where it was.

KCM Airport's full path goes one step further than a plain detail page — its cached airport map is itself tappable ("Tap to view full screen" beneath it), opening a dedicated full-screen viewer with its own close button (×, top-right). While the map is full screen, the page's own back chevron is intentionally hidden rather than shown-but-inert — the only way out is the × or the system back gesture, both of which return you to the same detail page underneath, unchanged.

KCM Airport detail page for Tampa International Airport, opened from a Search result, showing the cached map and a Tap to view full screen caption beneath it

KCM Airport detail page, opened from a Search result

Full-screen map viewer after tapping Tap to view full screen, with its own close (×) button top-right and no back chevron

Full-screen map, reached by tapping the map (or its caption)

Something's wrong if: Tapping a result does nothing, shows a blank/error page, or opens content that clearly doesn't match the row you tapped; for KCM Airport specifically, if the × close button is hidden behind the app's own top icon row (it should sit clearly above it), or if a back chevron is visible while the map is full screen (it should be hidden — see the note above).

6 · Collapse and re-expand a result section

Steps: With multiple result sections showing (a broad term like a single letter usually returns several — see Check 2), tap a section header that has more than one result under it — it carries a caret (searching jumpseat, COMMITTEE, DOCUMENT, and JUMPSEAT POLICY all qualify today). A section with exactly one result shows a plain header with no caret — that's intentional, not a bug (nothing useful to collapse down to a single row); for the same jumpseat query, NOTIFICATION is currently that single-item example.

JUMPSEAT POLICY's multi-item section (caret, expanded) just above NOTIFICATION's plain single-item header with no caret

What you should see: Tapping a multi-item section's header hides its rows and rotates the caret to point down; every other section stays exactly as it was — collapsing one section doesn't affect the others. Tap the same header again and its rows reappear, caret pointing up. Single-item sections (like NOTIFICATION here) never show a caret and can't be tapped to collapse, regardless of how many other sections are open or closed. Which specific groups are multi- vs. single-item will shift over time as real content changes — the caret-vs-plain-header rule is what to verify, not the exact group names.

Something's wrong if: Tapping a header collapses a different section, collapses every section at once, the caret doesn't rotate to reflect the current state, or a section with only one result shows a caret / responds to a tap.

7 · Tap an Event, Company Contact, Hotel, or Committee result and confirm the contact card

Steps: Search for a broad term like a single letter (if your account is MEC-affiliated), scroll to the EVENT, COMPANY CONTACT, HOTEL, or COMMITTEE section, and tap a row.

Contact card modal for a Hotel result, headed HOTEL CONTACT, showing name, phone, and website link, with no role line

Hotel — no role line, phone + website link (Hotel Contact)

Contact card modal for a Committee result, headed COMMITTEE CONTACT, showing name and phone only

Committee — no role line, phone only (Committee Contact)

What you should see: A small in-page modal opens over the results (not a navigation) — a header naming which list this came from (MEC EVENT, LEC EVENT, COMPANY CONTACT, HOTEL CONTACT, or COMMITTEE CONTACT), then the name and whichever of role/email/phone/link the underlying record actually has — a role line only appears for Company Contact/Hotel (Committee and Event never show one), and an Event additionally shows its date above the role line, since it's the one type with both. A record missing some of these just omits that line entirely (a record with none of email/phone/link is still shown for an Event, but excluded from search results altogether for Company Contact/Hotel/Committee — nothing to tap on for those without at least one). Whichever email/phone/link line is shown is a real link, not plain text — tap an email line and the Mail app (or its picker) opens addressed to it; tap a phone line and the Phone app opens ready to dial; tap a link line (Hotel's website, a Committee's link) and it opens in the system browser, not inside the app. Tap CLOSE to dismiss the card and return to the same result list — your search term, filter, and section-collapse state are unaffected by opening and closing it.

Something's wrong if: Tapping the row navigates to a blank/error page instead of opening the modal in place, the header doesn't name which list the result came from, tapping an email/phone/link line does nothing (or the whole card doesn't respond to any tap at all), or closing the card loses your search term or result list.

8 · Tap a Call to Action result and confirm the auto-login web view

Steps: Search for a broad term like a single letter, scroll to the CALL TO ACTION section (Member Resources advocacy links, e.g. "Tell Congress: ..."), and tap a row.

Tapping a Call to Action search result opens the auto-login web view, briefly showing the My ALPA Login form

What you should see: A full-screen web view opens over the app (not the same inline document viewer Check 5 uses) — this is the distinct IAuthenticatedWebView path Call to Action links always take, matching AdvocacyPage.OpenCallToActionAsync's existing behavior, since these destinations need an authenticated session handed to them. You'll typically see the "My ALPA Login" form flash briefly while auto-login runs, then land on the actual advocacy action page. A close/back control lets you return to the same Search result list afterward, with your search term and filter intact.

Note: auto-login can occasionally time out against a particular destination (ADFS detection failing to find the expected login-form fields) — if you land on a manual "My ALPA Login" form instead of the actual advocacy page, that's an auto-login reliability issue, not a Search bug; the row still correctly routed to the authenticated web view either way.
Something's wrong if: Tapping the row opens the plain external system browser (no ALPA auto-login involved at all), opens the inline document viewer, or does nothing.

9 · Tap a Menu Item result and confirm it deep-links to the real page

Steps: Search for a broad term like a single letter, scroll to the MENU ITEM section (app navigation entries, e.g. "ALPA Int'l Comms"), and tap a row.

Tapping a Menu Item search result navigates to the real Internal Comms page

What you should see: You land on the actual in-app page the menu entry names (e.g. tapping "ALPA Int'l Comms" opens the real Internal Comms list) — not a placeholder, not the generic result excerpt. Unlike every other content type, a Menu Item's underlying value isn't a route or a plain URL — it's a server-supplied Shell page name (e.g. "AdvocacyPage") that DeepLinkResolver translates to a real Blazor route at tap time, since that translation can only happen in the Presentation layer. That's an implementation detail, not something you can see directly, but it's why this gets its own check rather than folding into Check 5.

Something's wrong if: Tapping a Menu Item result does nothing, shows a blank/error page, or opens content unrelated to the menu entry's name.

10 · Relaunch the app and confirm search is immediately usable, not blocked again

Steps: With Search already indexed once this install (i.e. not your very first login — see "Before you start"), fully close the app (swipe it away, or kill/relaunch it) and reopen it. As soon as the app is back up, tap the search icon and look at the field and the notice under the search box before waiting the usual minute.

Search page immediately after a relaunch: field enabled, a small 'Refreshing search results…' notice under the search box, and the Offline Search idle prompt below it

What you should see: The search field is already enabled (not greyed out), and any notice under it reads "Refreshing search results…", not "Preparing search results…" — small and non-blocking, not the "Getting Ready" full-page placeholder from Check 1's first-ever-login case. Type a real term right away (don't wait) and you get real results immediately, from whatever was already indexed before the relaunch — the notice clears on its own a few seconds later once this session's own fresh copy finishes loading, with no page reload and without disturbing your search term or results.

Real Jumpseat Policy and KCM Airport results for 'JFK' on the Offline tab, returned immediately while the Refreshing search results notice is still showing

What you should see: real, correctly-grouped results (here Jumpseat Policy/KCM Airport for JFK; which groups appear depends on your MEC) while the "Refreshing…" notice is still visible — the field being enabled during a refresh isn't cosmetic, it actually answers queries against the pre-relaunch index.

Something's wrong if: The field is disabled and the search box shows the big "Preparing search results…"/"Getting Ready" first-launch treatment on an ordinary relaunch (not your very first login), typing during "Refreshing…" produces no results even though the same term worked before you relaunched, or the "Refreshing…" notice is still showing well after the app has clearly finished loading everything else (Home, notifications badge, etc.).
Note: a genuine first-ever login (nothing indexed yet at all) still shows the blocking "Preparing search results…"/"Getting Ready" state from Check 1 — that part is unchanged and correct; this check is specifically about every relaunch after that first one.

11 · ALPA Feed / MEC Feed content renders with the feed's real component and CSS, and navigates correctly

Steps: Open the filter, tap ONLY on the ALPA Feed row, tap APPLY, then search a term you know matches a Home feed card's title (e.g. Resources matches "Member Resources"/"Volunteer Resources"). ALPA Feed is the one global site every member sees regardless of MEC/LEC; MEC Feed (steps below) is a member's own MEC/LEC site — a single combined "Dynamic Feed" category covering both was tried first but found not user-friendly live (2026-09-09), so this became two separate filter categories instead.

Search results with only the ALPA Feed category checked, showing a FEED CARD section with Member Resources and Volunteer Resources rows, each with a real thumbnail image

What you should see: A FEED CARD section whose rows look exactly like the same cards on Home — the card's own layout (a card with an image shows its thumbnail; a button shows its label), not a plain title/excerpt row like every other content type. Each row is the feed's own component (small card, icon card, button, hero card) with its own page's colours and type, inset like the other result rows, not a lookalike built specifically for search.

Then: Tap one of the Feed Card results.

Tapping the Member Resources feed card search result opens the real Member Resources page, the same destination the same card opens from Home

What you should see: You land on the exact same destination tapping that same card from Home would open (here, the real "Member Resources" page with its own content list) — not a placeholder, not an unresolved link.

Something's wrong if: A Feed Card result renders as a plain title/excerpt row instead of the real thumbnail card, or tapping it does nothing / shows a blank page / lands on a URL that still contains literal curly braces (e.g. {alpa-memberresources}) instead of a real /dynamic-feed-orchestrator?page=... route.

Then: Open the filter again, tap ONLY on the MEC Feed row this time, tap APPLY, and search a term from your own MEC's feed (e.g. soar on a United account, hotline on a Delta account). Reset the filter to all categories afterwards.

Search results with only the MEC Feed category checked and the term soar on a United account: SOAR Peer Support and SOAR Podcasts cards from the UAL site, no global ALPA Feed card

What you should see: Only cards and buttons from your own MEC/LEC site, none from the global site (on a United account, soar shows the SOAR cards but not the global United SOAR button). An account whose own site has nothing matching shows No Results, as in Check 4.

Something's wrong if: A global (ALPA Feed) card appears with only MEC Feed selected, or your own MEC's feed cards are missing.

12 · Switch between the Offline and Online tabs

Steps: On the Search screen, tap ONLINE in the tab bar above the search box, then tap OFFLINE.

Search screen on the Online tab: tab bar with ONLINE selected, the search box under it with placeholder Search ALPA online, and an Online Search placeholder message

What you should see: The tapped tab turns blue and the other goes white, the same pill toggle as Alerts / Flight Finder on Notifications. OFFLINE searches content saved on this device and works with or without a connection; ONLINE is the ALPA website search. On ONLINE the search box placeholder becomes "Search ALPA online …", the filter button at the top right disappears until an online search answers, and the body reads "Online Search" / "Search ALPA's website — pages and documents open signed in." Typing on ONLINE runs an online search (Check 18), not an Offline one. Switching back to OFFLINE restores "Search content on this device …", the filter button, and your previous results. Each tab keeps its own text: what you typed on ONLINE does not change the Offline box or its results. If you leave Search while on ONLINE (for example, the bell icon) and press back, you return to ONLINE, not OFFLINE.

Something's wrong if: The tab bar sits under the search box, the tabs read anything other than Offline and Online, the placeholder text doesn't change with the tab, the filter button stays on the Online tab, or switching tabs adds extra back-arrow steps.

13 · Feed buttons and cards are searchable, shown once, look like their page, and only if you can see them on Home

Steps: On a Delta (DAL) test account, search hotline, pan, dart, contract, soar, upa27 and pps. Then, on a United (UAL) account, search soar, upa27, pan and dart.

Search results for hotline on a Delta account: an orange CALL EMERGENCY HOTLINE button with a white label, then Delta Safety Hotline and Delta MEC FAR 117 Hotline Concerns cards with red icon boxes and white phone glyphs, inset like the rows above

DAL, hotline

Search results for pan on a Delta account: the blue DELTA PAN button and the Talk with a PAN Volunteer Now card, no other airline's line

DAL, pan

Search results for dart on a Delta account: one THROW A DART button and the separate DART tile

DAL, dart

Search results for soar on a United account: the blue UNITED SOAR button, the SOAR Peer Support card with a navy icon box, and the SOAR hero card

UAL, soar

What you should see:

Something's wrong if: another MEC's line or card appears (for example United SOAR for a DAL member), the same button is listed several times, a feed button is missing, a card shows an empty icon box, a white glyph on white or a button with no fill, or a row runs edge to edge.

Offline: with results already seen online, turn the network off, fully close the app, reopen it and search contract and hotline again.

Search results for contract offline: the Contract History hero card with its photo, under the notice You're offline — showing previously saved results

Offline: photos and icons from the device

Search results for contract offline after the image cache's sign-out clear: the hero cards without photos and no broken-image icon, the Contract Administration red icon box still drawn

After a sign-out clear: photos gone, icons stay

What you should see: The same feed rows as online, including your own MEC's (they come from the copy saved on the device), with their photos and icons. After the image cache's Clear (sign-out only) (Page Readiness → Image Cache), searched offline again: photo cards show without their photo and without a broken-image icon, and icon boxes still show their glyph.

Something's wrong if: offline, your own MEC's feed rows are missing, or any result shows a broken-image icon.

14 · Offline, a document that isn't saved on the device

Steps: Online, open one document from Search (e.g. Canadian Limits: 2026 & 2025) so it is saved on the device. Turn the network off, fully close the app, reopen it and search limits. Tap a document labelled Not available offline (e.g. IRS Limits: 2026 & 2025), then tap TRY AGAIN. Go back and tap the document you opened online. Finally turn the network back on and open the labelled document again.

Search offline: Document results dimmed, each with a Not available offline line under the title

Offline: documents not on the device are labelled

The IRS Limits document opened offline: This document isn't saved on this device. It will open when you're back online, and a TRY AGAIN button

Tapping one offline

What you should see: Offline, Document results that are not saved on the device are dimmed and read Not available offline; the one you opened online looks normal. Tapping a labelled one shows This document isn't saved on this device. It will open when you're back online. with TRY AGAIN, with no download prompt and no browser; TRY AGAIN does nothing until the connection is back. The saved document opens offline. Back online, the labels are gone and the document opens.

Something's wrong if: offline, a document that is not saved shows "Couldn't download this document" with RETRY, asks about downloading documents, or opens the browser; the saved document fails to open offline; or labels stay after the connection returns.

15 · A person on your MEC page shows as one contact card

Steps: On a Delta (DAL) account, open DAL MEC and note a person in a contact section (e.g. Pat Example, Chair, under MEC Representatives). Open Search on the Offline tab and search their last name. Then search a short fragment that matches several people (e.g. sha).

Search for Example: a Contact section with the line Delta Council 66 above Pat Example, drawn as the MEC page's contact card (role, name in the page's heading style, red email and phone)

One role: the line above the card names its council

Search for sha: the Contact group listing several people, each contact card under its own source line such as Central Air Safety, Delta MEC Administration and Communications (LAX)

Several people: each card under its own roster

What you should see: One Contact result per person, drawn as on the MEC page, with the email and phone in the page's colour, each tappable. There is no separate Representative result. A person with a preferred name shows it, as the MEC page does (e.g. Rob for Robert), and searching their legal first name still finds them.

Order (AB#2840): the Contact results follow the page: each person where they first appear on your MEC's pages, and within a roster the roster's own order: officers first (Chair titles, any subject chair such as Safety Chair included, then Vice Chair, Secretary, Treasurer and Executive Administrator), then Captain Representatives, then First Officer Representatives, then everyone else by last name. A title written Vice-Chair or Secretary/Treasurer ranks with Vice Chair or Secretary-Treasurer. A committee whose name is missing from the committee data is named by its code (e.g. UALLEC00099), the same as its heading on the page.

Something's wrong if: The person is missing from Search, the Contact result is a plain text row, it shows details the MEC page does not, the same person shows as two Contact results, or the people come back in a different order from the page.

16 · A person with several roles is one card listing each role

Steps: On your MEC's pages, find a person listed in two places (for example a committee chair who is also on another committee's roster, or an LEC rep who also sits on a committee). Open Search on the Offline tab and search their last name. Then search one of their titles together with their last name (e.g. vice chair and the surname), and the name of the second committee on its own. If your test content has a contact section shown only to another MEC, search a person listed there and in a section you can see.

Screenshots for this check are still to be taken.

What you should see:

Something's wrong if: the person shows as two results, a role line is missing or names the wrong committee, a role you can't see on the page appears on the card, a hidden title finds the person, or the card shows a line above it while listing several roles.
The UI suite automates the first bullet (Search_AMultiRolePilot_IsOneCard_ListingEachRole in BlazorWalkthroughTests): it runs when the test credentials and ALPA_UITEST_MULTIROLE_QUERY (a query that finds exactly one such person on the test member's pages) are set, and skips otherwise. It finds the card by its result row's number, never by anything about the person.

17 · An MEC officer or LEC rep reads "Chair | Captain Rep"

Steps: On your MEC's pages, find a section that lists your LEC reps, or your MEC officers once your MEC's officers section has been moved onto the officer data (MecReps, AB#2840). Note a rep whose card shows two roles on one line. Open Search on the Offline tab and search their last name, then their seat in full (e.g. captain representative) and shortened (captain rep).

Screenshots for this check are still to be taken.

What you should see:

Something's wrong if: the seat shows on its own line or as a separate card, a committee title or a council name is shortened, "N/A", "None" or "No Office Held" shows, the seat changes the order, another council's rep appears, an officer section is empty on a current build, or an officer who is one of your own council's reps shows no seat on the officer line while their rep line shows one.

18 · Search ALPA online and open a result signed in

Steps: Signed in, open Search, tap ONLINE, and search contract. Scroll to the bottom of the list. Tap a result that is a PDF.

Online tab with contract searched: 7,565 RESULTS above rows whose title and excerpt highlight the matched words

What you should see: A count (e.g. 7,565 RESULTS) above rows from ALPA's website for your MEC, the matched words in bold. Ten rows load first; more load by themselves as you near the bottom, with "Loading more results…" while they come. A tapped result opens in the in-app browser already signed in, including member-only documents. Signed out, the tab reads Sign In to Search Online. If sign-in brought no search token (a temporary failure), the tab reads Online Search Unavailable. A staff or guest account with no MEC to search sees no Offline / Online tabs at all, only the Offline search.

Something's wrong if: results come from another MEC, the count doesn't change with a new term, the list stops at ten rows while more exist, or a result asks you to sign in.

19 · Filter online results by type and section

Steps: After Check 18, tap the filter button at the top right. Tap Only on Pages, then Apply. Open the filter again, tap clear. Search grievance, open the filter, check Archive, then tap Only on any section.

Filter modal with Only Pages: Documents unchecked, Pages checked and greyed, no Section group, Archive unchecked

Only Pages

Filter modal for grievance with every type and section checked and Archive checked

Archive included

What you should see:

Something's wrong if: a change doesn't search again, a checkbox shows a choice the results don't reflect, Only keeps more than one value, a group can be left with nothing checked, or a new term drops the filters you set.

20 · Online search with a slow or missing connection

Steps: With results on the Online tab, turn the network off and tap a result. Search a new term. Turn the network back on and tap Search again. On a very slow network (e.g. Network Link Conditioner, "Very Bad Network"), search a new term.

Online tab: Still searching ALPA online above the previous results

Slow: still searching

Online tab: Couldn't Reach ALPA Online with a SEARCH AGAIN button

No answer

Online results with the notice This page needs a connection. Try again when you're back online.

Tapping a result offline

Online tab: You're Offline. Online search needs a connection. Offline search still works.

Searching offline

The two offline screenshots were taken with the app's test switch for "no connection", so their status bar still shows Wi-Fi; on a device in airplane mode it won't.

What you should see: Offline, tapping a result opens nothing and the notice above the tab bar reads "This page needs a connection. Try again when you're back online."; a new search reads You're Offline. Offline search keeps working. On a slow network the notice under the box reads "Searching ALPA online…", then "Still searching ALPA online…" after about 4 seconds; with no answer after about 10 seconds the tab reads Couldn't Reach ALPA Online or Online Search Didn't Answer with Search again. If loading more fails, the list keeps its rows and shows Couldn't load more — try again.

Something's wrong if: a tap offline opens a blank or error page, the tab spins with no end, offline results appear on the Online tab, or a failed next page clears the list.

That Search returns genuine on-device content instead of fixed sample rows, that the idle and no-match states read honestly (no fake data, no silently-empty screen), that the multi-select category filter (and its "Only" isolation shortcut) actually narrows local results by area rather than being cosmetic, that result sections can be collapsed independently, that a result actually leads to the real content it names — whether that's a plain in-app route (most content types, including KCM Airport's own full-screen map viewer), a contact card naming which list it came from with real tappable email/phone/link lines (the five contact-card types), an authenticated web view (Call to Action), a server-driven deep link resolved at tap time (Menu Item), or the feed's own real component and CSS resolving to the feed's own real destination (ALPA Feed/MEC Feed, Check 11) — and that a relaunch reuses the on-device index it already has instead of forcing every session to sit through the same first-time "Preparing…" wait. Every one of the 17 onboarded content types has now been live-verified to open the destination it claims — and the one type that couldn't (Flight Search Airport) was withdrawn rather than shipped with a placeholder, since KCM Airport already covers the same content with a real destination.

What's not covered yet

For engineers: the local-search content registry (what's indexed, from where, and why) is documented in Search Content Onboarding.