Build Proxy Registration Screen (Single Flow)
epic-coordinator-proxy-registration-bulk-orchestration-task-008 — Implement the ProxyRegistrationScreen for single-mentor proxy registration. Compose the ProxyActivityForm, MentorSingleSelectWidget, and ProxyConfirmationScreen into a cohesive two-step flow: select mentor then fill activity details. Wire form validation feedback inline and surface submission errors clearly. The screen feeds into ProxyRegistrationBLoC for state management. All navigation must use GoRouter with proper back-stack handling.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 2 - 518 tasks
Can start after Tier 1 completes
Implementation Notes
Use an `IndexedStack` or `PageView` with `physics: NeverScrollableScrollPhysics` for the two-step layout so BLoC state is never disposed between steps. Do not push Step 2 as a new GoRouter route — keep both steps within the same screen widget to preserve BLoC state cleanly. Only push ProxyConfirmationScreen as a new route when the coordinator taps Review. This distinction is important: GoRouter back from the confirmation screen should return to Step 2, not exit the flow.
The `ProxyRegistrationBLoC` should be provided above this screen in the widget tree (e.g., via `BlocProvider` at the route level) so it survives the internal step transitions. Apply GoRouter's `onPopInvoked` callback if Flutter 3.22+ is targeted to intercept hardware back and route it correctly.
Testing Requirements
Widget tests: initial render shows Step 1 with continue disabled, selecting a mentor enables continue, tapping continue navigates to Step 2, Step 2 shows selected mentor chip, back from Step 2 returns to Step 1 with mentor preserved, inline validation errors appear on required fields when empty, BLoC error state renders inline banner. Integration test on TestFlight covering the full single-flow path: select mentor → fill form → review → confirm → success state. Accessibility test: step indicator text is included in Semantics tree, all buttons have descriptive labels.
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.