Peer Mentor Single Selector screen scaffold and contact list rendering
epic-bulk-and-proxy-registration-mentor-selection-task-005 — Implement the Peer Mentor Single Selector screen that renders the coordinator's cached contact list from the Proxy Contact List Provider as a scrollable single-select list. Each row displays the mentor's name and relevant metadata. Integrate the Riverpod provider for the contact list and handle loading and empty states.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 4 - 323 tasks
Can start after Tier 3 completes
Implementation Notes
Scaffold the screen as a ConsumerWidget watching the proxyContactListProvider (FutureProvider or StateNotifierProvider). Use AsyncValue's .when() pattern to branch on loading/data/error cleanly — avoid nested if/else on AsyncValue states. For the list row, extract a dedicated PeerMentorListTile widget so it can be tested in isolation and reused in the multi-select task (task-008). The row widget should accept a PeerMentor model and a boolean isSelected parameter (defaulting to false here) so task-006 can extend it for selection state without a rewrite.
Alphabetical sort should happen in the provider selector or a derived provider, not inside the build method. Follow the project's existing patterns for page headers and AppBar back navigation.
Testing Requirements
Write widget tests covering: (1) loading state — mock provider returns AsyncLoading, assert loading indicator is present; (2) populated state — mock provider returns a list of 3 mentors, assert all names are rendered; (3) empty state — mock provider returns empty list, assert empty state message is visible; (4) error state — mock provider returns AsyncError, assert error message and retry button are visible. Use Riverpod ProviderScope overrides with a mock or stub provider. Also write a unit test for any list-sorting logic. Test with 0, 1, and 50+ items.
NHF coordinators may manage dozens of peer mentors across multiple chapters. If the multi-select list renders all contacts in a single unsorted ListView, performance degrades with 50+ items, and coordinators cannot efficiently locate a specific mentor, increasing the probability of selection errors and wrong-person proxy registrations.
Mitigation & Contingency
Mitigation: Use a SliverList with itemExtent for fixed-height rows to enable O(1) scroll position calculation. Implement the search filter using a debounce utility operating on an in-memory list (no extra API calls). Sort the contact list alphabetically by default. Add chapter-filter chips above the list for NHF's multi-chapter coordinators.
Contingency: If performance issues arise in testing with real data sets, introduce pagination with a 'load more' trigger at the bottom of the list and cache rendered rows using Flutter's AutomaticKeepAliveClientMixin.
NHF has a complex 12-national-association / 9-region / 1,400-chapter hierarchy. It is ambiguous whether a coordinator can proxy-register for peer mentors outside their immediately assigned chapter. If the contact list is not correctly scoped by RLS, coordinators might see — and register on behalf of — peer mentors they do not manage, creating fraudulent activity records that skew Bufdir statistics.
Mitigation & Contingency
Mitigation: The Proxy Contact List Provider must query only peer mentors linked to the coordinator's own chapter scope via RLS. Add an explicit Supabase query test asserting that a coordinator from chapter A cannot retrieve peer mentors from chapter B. Display each mentor's chapter affiliation in the list row so coordinators can visually verify scope.
Contingency: If RLS scope is found to be too permissive in testing, apply a server-side coordinator_id filter as a secondary guard on the query. Block the feature release until the scope test passes consistently.