Build Expected Return Date Picker UI widget
epic-peer-mentor-pause-management-foundation-task-009 — Implement the ExpectedReturnDatePicker Flutter widget as a reusable date input control. Apply design token styling, enforce minimum date constraints (cannot be in the past), support accessibility semantics for screen readers, and emit typed DateSelected events for BLoC consumption.
Acceptance Criteria
Technical Requirements
Implementation Notes
Use a GestureDetector or InkWell wrapping a read-only AppTextField — set the field's enabled: false and use a suffix icon for the calendar icon and optional clear icon. Do NOT use TextFormField's onTap for the date picker trigger as it has focus-related quirks on iOS; prefer a separate GestureDetector layer. Format the date using intl package's DateFormat('dd. MMMM yyyy', 'nb') to match the Norwegian locale used throughout the app.
Wrap the entire widget in Semantics with label and value properties — set excludeSemantics: true on child widgets to avoid duplicate announcements for screen readers (critical for Blindeforbundet users). Keep the widget stateless by requiring the parent to manage the selected date value — this aligns with the BLoC pattern used in the rest of the app. Export the widget from a barrel file in the shared widgets directory.
Testing Requirements
Write flutter_test widget tests covering: (1) widget renders with placeholder text when no date is selected, (2) tapping the field opens the date picker dialog, (3) selecting a valid date calls onDateSelected with correct DateTime, (4) past dates are not selectable (firstDate constraint verified), (5) tapping clear icon calls onDateSelected(null), (6) Semantics tree contains expected label and value strings, (7) widget renders without overflow at 2.0x font scale. Add golden tests for visual regression of empty and selected states. No integration or e2e tests required for this isolated widget.
Supabase RLS policies for coordinator-scoped status queries may be difficult to express correctly, especially for peer mentors assigned to multiple coordinators or chapters, leading to data leakage or overly restrictive access blocking valid queries.
Mitigation & Contingency
Mitigation: Design RLS policies using security-definer RPCs rather than table-level policies for complex multi-coordinator scenarios. Write a comprehensive RLS test matrix covering all role and assignment permutations before marking complete.
Contingency: Fall back to application-level filtering in the repository layer with explicit coordinator_id parameter checks if RLS proves intractable, and document the trade-off for security review.
The HLF Dynamics portal API contract may be undocumented or subject to change, causing the DynamicsPortalClient to break during development or production rollout.
Mitigation & Contingency
Mitigation: Obtain the full Dynamics portal API specification and credentials early in the sprint. Build the client behind a well-defined interface so the HLF-specific implementation can be swapped without affecting upstream services.
Contingency: If the Dynamics API is unavailable or unstable, stub the client with a feature-flag-guarded no-op implementation so all other epics can proceed to completion independently.
Supabase Edge Functions used as the nightly scheduler host may have cold-start latency or execution time limits that prevent reliable nightly certification checks on large mentor rosters.
Mitigation & Contingency
Mitigation: Benchmark Edge Function execution time against the expected roster size. Design the expiry check to process in paginated batches to stay within execution limits. Use pg_cron with a direct database function as an alternative trigger if Edge Functions prove unreliable.
Contingency: Migrate the scheduler trigger to pg_cron invoking a Postgres function directly, removing the Edge Function dependency entirely for the scheduling layer.