Build ReminderThresholdSettingsUI input fields
epic-assignment-follow-up-reminders-ui-task-005 — Implement the ReminderThresholdSettingsUI section embedded in the org settings screen. Create numeric input fields for configuring the first-reminder threshold (days), escalation threshold (days), and maximum reminder count. Use design token text styles and spacing. Bind fields to a Riverpod form state notifier that reads current values from the reminder config repository on mount.
Acceptance Criteria
Technical Requirements
Implementation Notes
Use a StateNotifier or AsyncNotifier in Riverpod to encapsulate the three threshold values plus loading/error states. The notifier should call the reminder config repository in its build/init method. Expose an immutable state class (e.g. ReminderThresholdFormState) with fields: firstReminderDays, escalationDays, maxCount, isLoading, errorMessage.
Use TextEditingController instances managed by the notifier or widget lifecycle (dispose in widget's dispose). Reuse the existing AppTextField widget with keyboardType: TextInputType.number and inputFormatters: [FilteringTextInputFormatter.digitsOnly]. Follow the existing org settings screen's section layout pattern — do not introduce new layout primitives. Design tokens for spacing and typography are in the project's token constants file; reference those directly.
Testing Requirements
Write flutter_test widget tests covering: (1) fields render with correct labels and numeric keyboard type, (2) notifier is invoked on mount and field values reflect repository data, (3) loading indicator shown during async fetch, (4) error state renders when repository throws, (5) field accepts digits and rejects non-numeric input. Use Riverpod's ProviderScope overrides to inject mock repository responses. No golden tests required for this task (covered in task-009).
The deep-link from the notification card to the assignment detail screen depends on the assignment detail route being stable and accepting an assignment ID parameter. If the routing contract is undocumented or changes during parallel development, the CTA will silently navigate to a fallback screen.
Mitigation & Contingency
Mitigation: Confirm the assignment detail route path and parameter contract with the team building or maintaining that screen before implementing the CTA. Add an integration test that asserts navigating from a mock notification card with a known assignment ID lands on the correct route.
Contingency: If the route is unstable, implement the deep-link as a late-bound string resolved from a central route registry, allowing the target route to be updated without changing the notification card.
Visually distinguishing escalation cards from standard reminder cards using colour alone fails WCAG 1.4.1 (use of colour). Blindeforbundet users relying on screen readers must receive equivalent contextual information through semantics, not just visual styling.
Mitigation & Contingency
Mitigation: Use both colour and an icon/label difference to distinguish card types. Add explicit Semantics widgets with descriptive labels ('Escalation alert: peer mentor has not responded') so screen readers announce the type without visual context.
Contingency: If accessibility review flags the distinction, add a text badge ('Escalation') alongside the visual treatment as a code-change-only fix with no schema or service impact.