Implement gap-detection informational banner
epic-bufdir-report-period-selection-ui-integration-task-007 — Within RecordCountBanner, add a secondary informational section that compares the selected period against the last submitted Bufdir report stored in confirmedReportPeriodProvider. Compute the gap in days and display a contextual message (e.g., 'This period starts X days after your last submission') to help coordinators avoid missing intervals.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 5 - 253 tasks
Can start after Tier 4 completes
Handles integration between different epics or system components. Requires coordination across multiple development streams.
Implementation Notes
Use a Consumer widget inside RecordCountBanner's build method to watch confirmedReportPeriodProvider independently from the BLoC state, so gap recalculates whenever the provider changes. Compute gap as: `final gap = selectedStart.difference(confirmedEnd).inDays;` where confirmedEnd is previousPeriod.end. Use a switch or if-else on gap sign to select message and color token. Keep the gap section in a separate private _GapBanner widget or method to keep RecordCountBanner readable.
Do not import .js files. Design token references should use AppColors/AppTextStyles from the token system, not hardcoded hex values. Wrap the entire gap section in a Semantics widget with `liveRegion: true` and `label:` set to the message string for VoiceOver/TalkBack compliance (WCAG 2.2 AA).
Testing Requirements
Widget tests using flutter_test: (1) verify banner is absent when confirmedReportPeriodProvider is null; (2) verify correct positive-gap message with exact day count; (3) verify zero-gap continuation message; (4) verify overlap warning message and color; (5) verify Semantics label matches displayed text; (6) verify singular/plural day wording. All tests use ProviderScope overrides to inject mock confirmedReportPeriodProvider values. No golden tests required.
The record count query is asynchronous and may take up to 1 second on a slow connection. If the BLoC does not manage loading states carefully, the UI may show a stale count or the confirm button may be briefly enabled during the loading transition, allowing premature submission.
Mitigation & Contingency
Mitigation: Define explicit BLoC states: PeriodSelectionLoading, PeriodSelectionCountLoaded, PeriodSelectionValidationError, and PeriodSelectionReady. The confirm button must only be enabled in PeriodSelectionReady. Add a debounce of 300ms on period-change events before triggering the count query to prevent excessive calls.
Contingency: If debouncing is insufficient to prevent UX degradation on slow connections, add an optimistic loading skeleton to the RecordCountBanner that clearly communicates a pending state, and keep the confirm button disabled until the count resolves.
The confirmedReportPeriodProvider Riverpod contract between this feature and the Bufdir Export feature may not be defined yet, causing integration failures when the downstream export screen attempts to read the provider.
Mitigation & Contingency
Mitigation: Define the confirmedReportPeriodProvider as a StateProvider<DateTimeRange?> in a shared providers file at the start of this epic, before any screen code is written. Communicate the provider contract to the Bufdir Export feature team so both sides align on the same provider reference.
Contingency: If the export feature consumes the period through a different mechanism (e.g., navigation arguments), add a thin adapter that writes the confirmed period to both the Riverpod provider and the navigation argument, ensuring backward compatibility.
Flutter's live region support for screen readers is inconsistent across platforms (iOS VoiceOver vs Android TalkBack), and the record count banner must be announced on every change — a pattern that has historically required platform-channel workarounds.
Mitigation & Contingency
Mitigation: Test the live region announcement on both iOS (VoiceOver) and Android (TalkBack) early in implementation using the accessibility_test harness. Reference the project's existing live-region-announcer component (664-accessibility-live-region-announcer) for a proven implementation pattern.
Contingency: If native live region support is insufficient, wrap the record count text in a Semantics widget with a programmatically updated label string, and trigger a SemanticsService.announce call on each count update as a platform-agnostic fallback.