medium priority low complexity frontend pending frontend specialist Tier 1

Acceptance Criteria

Screen displays mentor full name, activity type label, formatted date (locale-aware), duration in minutes/hours, and notes (truncated at 3 lines with expand option)
Confirm button triggers submission via ProxyRegistrationBLoC and enters a loading state (spinner replaces button label, button disabled) while in progress
Back button navigates to the previous screen without clearing form state
On submission success, screen emits navigation event to success confirmation or dashboard — no manual pop required
On submission failure, an inline error banner appears below the card with the error message; confirm button re-enables
All text elements use design token typography classes; no hardcoded font sizes, colors, or spacing values
Screen is accessible: card fields have semantic labels readable by TalkBack/VoiceOver, confirm and back buttons have descriptive Semantics labels
Screen renders correctly at font scale 1.0, 1.5, and 2.0 without overflow

Technical Requirements

frameworks
Flutter
BLoC
data models
ProxyActivityDraft
MentorSummary
performance requirements
Screen must render in under 16ms per frame (no jank during state transitions)
Loading state must appear within one frame of confirm tap
security requirements
Notes field content must be HTML-escaped before display to prevent injection in web targets
Do not log or print mentor personal data to console in production builds
ui components
SummaryCard (reusable card with labeled rows)
AppButton (design token primary + secondary variants)
InlineErrorBanner
LoadingOverlay or button-level CircularProgressIndicator

Execution Context

Execution Tier
Tier 1

Tier 1 - 540 tasks

Can start after Tier 0 completes

Implementation Notes

Receive the draft data as a constructor parameter (ProxyActivityDraft model) rather than reading from BLoC state directly — keeps the widget pure and easily testable. Use BlocBuilder only for the submission state (idle/loading/success/error). The back action should call `context.pop()` via GoRouter rather than `Navigator.pop()` to stay consistent with the routing layer. Apply the design token spacing system for all padding/margin values — reference the token constants file, not magic numbers.

Consider using a `Column` with `Spacer` for the action buttons to pin them to the bottom of the screen on short devices.

Testing Requirements

Widget tests using flutter_test covering: initial render with all fields populated, confirm tap transitions to loading state, back tap triggers correct navigation event, error state renders banner with correct message, notes truncation at 3 lines. Golden tests for the card layout at standard and large font scales. Accessibility audit using Flutter's SemanticsHandle to verify all interactive elements have labels.

Component
Proxy Confirmation Screen
ui low
Epic Risks (3)
high impact high prob scope

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.

medium impact medium prob technical

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.

medium impact medium prob technical

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.