Build PauseActivationScreen confirmation flow
epic-peer-mentor-pause-management-core-workflows-task-007 — Implement the peer mentor-facing pause activation screen. Display current status, a confirmation prompt explaining implications of pausing, an optional reason input field, and the ExpectedReturnDatePicker widget. Include a clearly labelled confirm button and a cancel action. On confirmation, call PauseManagementService.activatePause() and display a success confirmation with the expected return date if set. Handle loading and error states with accessible error messaging.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 4 - 323 tasks
Can start after Tier 3 completes
Implementation Notes
Use a BLoC (PauseManagementBloc) with states: PauseInitial, PauseLoading, PauseSuccess, PauseError. Emit PauseLoading on confirm tap and disable the confirm button via BlocBuilder. Do not use Navigator.pop on confirm — instead navigate to a dedicated success screen or show an in-place confirmation card to avoid the mentor accidentally re-entering the flow. Ensure the ExpectedReturnDatePicker defaults to null (no date selected) and only sends a return date in the payload if the mentor explicitly picks one.
The reason field should trim whitespace before submission. Follow the existing AppButton and AppTextField patterns from the shared widget library — do not create custom button or input widgets.
Testing Requirements
Write widget tests using flutter_test covering: (1) screen renders current active status indicator, (2) confirm button is disabled while loading, (3) success state displays expected return date, (4) error state renders accessible error message with liveRegion semantics, (5) cancel action pops the route without calling activatePause(). Write an integration test verifying the full flow from screen open → reason entry → date selection → confirm tap → success state. Test accessibility with Flutter's SemanticsController to assert live region announcements.
Concurrent status transitions (e.g., coordinator and automated scheduler both attempting to update the same mentor's status simultaneously) may produce race conditions or inconsistent state in the database, leading to audit log gaps or incorrect notifications.
Mitigation & Contingency
Mitigation: Implement all status transitions as atomic Postgres RPC functions with optimistic locking (version column or updated_at check). Use database-level constraints rather than application-level guards as the final enforcement point.
Contingency: Add a compensation job that reconciles status and log table consistency on each nightly scheduler run, surfacing any discrepancies to coordinator dashboards.
The coordinator-to-mentor assignment relationship may not always be 1:1 or may be stale (coordinator reassigned after a pause was set), causing notifications to be sent to the wrong coordinator or not sent at all.
Mitigation & Contingency
Mitigation: Query the assignment relationship at notification dispatch time rather than caching it at pause creation time. Add a fallback to notify the chapter administrator if no active coordinator assignment exists.
Contingency: Log all undeliverable notification attempts with the originating mentor ID so administrators can manually follow up, and surface undelivered notification counts on the coordinator dashboard.
The CoordinatorPauseRosterScreen may load slowly for coordinators managing large rosters with many concurrent certification expiry queries, degrading usability on low-bandwidth mobile connections.
Mitigation & Contingency
Mitigation: Use a single Supabase RPC that joins mentor status, certification expiry, and assignment data in one query rather than N+1 individual calls. Implement pagination with a configurable page size and skeleton loading states.
Contingency: Add an offline cache of the last-fetched roster state using Riverpod with SharedPreferences, ensuring coordinators can at minimum view stale data when connectivity is poor.