Build MentorMultiSelectWidget with search and chip UI
epic-coordinator-proxy-registration-foundation-task-008 — Build the MentorMultiSelectWidget Flutter widget supporting selection of multiple peer mentors from the coordinator's org. Include a search input with debounce, scrollable list of mentor cards, selected mentor chips displayed above the list, select-all shortcut, and accessible semantics labels for screen reader support. Sourced from the existing contact/peer mentor repository filtered to the coordinator's chapter. Must support 1–50 selections. This widget is shared across bulk proxy and other multi-mentor flows.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 3 - 413 tasks
Can start after Tier 2 completes
Implementation Notes
Use a ConsumerStatefulWidget to watch the mentor list from a Riverpod provider, filtered by the coordinator's chapterId. Store selected mentor IDs in a local Set
The select-all button should operate on the current _filteredList (post-search) so it is context-aware. Ensure the widget is fully self-contained with no hardcoded chapter ID — receive it via constructor parameter. Register the mentor data provider in Riverpod so tests can override it with a mock list without touching real Supabase. Keep the widget reusable: it should work in any flow that needs multi-mentor selection, not just the bulk proxy flow.
Testing Requirements
Widget tests (task-011) must cover: (1) initial render shows full mentor list from mock data, (2) typing in search input filters list after 300ms debounce, (3) tapping a mentor item adds a chip and checks the item, (4) tapping chip delete removes selection and unchecks item, (5) select-all selects all visible items up to 50, (6) selecting 51st item is blocked, (7) empty state shows when no match found, (8) onSelectionChanged emits correct list on each change, (9) semantics tree contains correct labels. Use flutter_test with fake async for debounce timing tests and mock the mentor data source via a Riverpod override.
Supabase RLS policies for org-scoped proxy access may be difficult to express correctly, especially for coordinators with multi-chapter access. An overly permissive policy could allow cross-org proxy registrations, corrupting Bufdir reporting; an overly restrictive policy could block legitimate coordinators from registering.
Mitigation & Contingency
Mitigation: Write integration tests covering all access boundary cases (same org, cross-org, multi-chapter coordinator) before merging any RLS migration. Use parameterised RLS test helpers already established by the auth feature.
Contingency: If RLS proves insufficient, add a server-side Edge Function validation layer that re-checks org membership before persisting any proxy record, providing defence in depth.
Adding new tables and foreign key constraints to an existing production Supabase database risks migration failures or locking issues if the database already contains active sessions during deployment.
Mitigation & Contingency
Mitigation: Use additive-only migrations (no DROP or ALTER on existing tables). Test full migration sequence in a staging Supabase project before production deployment. Schedule during low-traffic window.
Contingency: Maintain a rollback migration script. If the migration fails, the feature remains unreachable behind a feature flag while the schema issue is resolved.
Audit log entries must be immutable for compliance, but Supabase RLS by default allows row owners to update their own rows. If audit records are accidentally mutable, dispute resolution and accountability guarantees are invalidated.
Mitigation & Contingency
Mitigation: Configure the proxy_audit_log table with an RLS policy that allows INSERT for coordinators but denies UPDATE and DELETE for all roles including service_role, enforced at the database level.
Contingency: If RLS cannot fully prevent updates, create a database trigger that reverts any UPDATE to the audit table and logs the attempt as a security event.