Build Bulk Proxy Registration Screen
epic-coordinator-proxy-registration-bulk-orchestration-task-010 — Implement the BulkProxyRegistrationScreen that hosts the RecurringTemplateSelectorWidget and MentorMultiSelectWidget side by side. Display a dynamic participant count badge reflecting current mentor selection count. Wire a Submit button that initiates the multi-mentor confirmation and submission flow. Integrate with ProxyRegistrationBLoC to reflect loading, partial failure, and success states. Ensure WCAG 2.2 AA compliance throughout with live region announcements for participant count changes.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 3 - 413 tasks
Can start after Tier 2 completes
Implementation Notes
Use BlocBuilder to rebuild only the affected sub-trees when BLoC state changes — wrap the participant count badge and submit button separately to avoid full-screen rebuilds on each mentor selection. The confirmation bottom sheet should be shown via showModalBottomSheet inside a BlocListener reaction to a BulkConfirmationRequested state, not directly from button onPressed, so it is testable via BLoC state injection. For the responsive layout, use LayoutBuilder to switch between Column (width < 600 dp) and Row (width ≥ 600 dp) arrangements. Partial failure list must use the organisation label system to display mentor relationship terminology consistent with the current organisation context.
Ensure all colour choices for success/failure rows come from the design token system (e.g. tokens.colorSuccess, tokens.colorError) — no hardcoded hex values.
Testing Requirements
Write widget tests using flutter_test and bloc_test. Test initial state (submit disabled), mentor selection flow (count badge updates, submit enables), confirmation bottom sheet content accuracy, loading state (widgets non-interactive), partial failure list rendering with mixed success/failure rows, full success banner with reset. Use a MockProxyRegistrationBLoC to drive state transitions. Accessibility tests: verify Semantics tree contains liveRegion node for count badge; verify all tap targets are ≥44dp via tester.getSize().
Integration test: full happy-path submission flow against the real BLoC wired to mocked services. Aim for 85% widget branch coverage.
Partial failures in bulk registration — where some mentors succeed and others fail — create a complex UX state that is easy to mishandle. If the UI does not clearly communicate which records succeeded and which failed, coordinators may re-submit already-saved records (creating duplicates) or miss failed records entirely (creating underreporting).
Mitigation & Contingency
Mitigation: Design the per-mentor result screen as a primary deliverable of this epic, not an afterthought. Use a clear list view with success/failure indicators per mentor name, and offer a 'Retry failed' action that pre-selects only the failed mentors for resubmission.
Contingency: If partial failure UX proves too complex to deliver within scope, implement a simpler all-or-nothing submission mode for the initial release with a clear error message listing which mentors failed, and defer the partial-retry UI to a follow-up sprint.
Submitting proxy records for a large group (e.g., 30+ mentors) as individual Supabase inserts may cause latency issues or hit rate limits, degrading the coordinator experience and potentially causing timeout failures that leave data in an inconsistent state.
Mitigation & Contingency
Mitigation: Implement the BulkRegistrationOrchestrator to batch inserts using a Supabase RPC call that accepts an array of proxy records, reducing round-trips to a single network call. Add progress indication using a stream of per-record results if the RPC supports it.
Contingency: If the RPC approach is blocked by Supabase limitations, fall back to chunked parallel inserts (5 records per batch) with retry logic, capping total submission time and surface a progress bar to manage coordinator expectations.
Unifying state management for both single and bulk proxy flows in a single BLoC risks state leakage between flows — for example, a previously selected mentor list persisting when a coordinator switches from bulk to single mode — causing confusing UI states or incorrect submissions.
Mitigation & Contingency
Mitigation: Define separate, named state subtrees within the BLoC for single-proxy state and bulk-proxy state, with explicit reset events triggered on flow entry. Write unit tests for state isolation scenarios using the bloc_test package.
Contingency: If unified BLoC state becomes unmanageable, split into two separate BLoCs (ProxySingleRegistrationBLoC and ProxyBulkRegistrationBLoC) sharing only common events via a parent coordinator Cubit.