Implement ExpiryNotificationBanner widget — expired state
epic-certificate-expiry-notifications-user-interface-task-007 — Extend the ExpiryNotificationBanner with the differentiated visual state for expired certificates. The expired state uses a distinct color scheme (from design tokens), updated label text, and modified CTA copy. Ensure banner persistence logic remains until a coordinator acknowledges the lapse via the AcknowledgeLapse BLoC event. BLoC integration must consume the loaded state from task-005.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 4 - 323 tasks
Can start after Tier 3 completes
Implementation Notes
Refactor ExpiryNotificationBanner (from task-006) to switch on record.status using Dart's exhaustive pattern matching (switch expression). Each case returns the appropriate child subtree. Extract a private _buildBannerContent(ExpiryNotificationRecord, BannerConfig) method where BannerConfig is a small data class holding backgroundColor, labelText, ctaCopy, and statusIndicatorMode — this avoids duplicating layout code between states. Design tokens for the error state likely already exist (used elsewhere in the app for form validation errors); confirm token names before implementing.
The expiry-soon amber and expired red tokens must be clearly different hues so users with color vision deficiency can also distinguish them — check with design for deuteranopia-safe palette.
Testing Requirements
Widget tests using flutter_test. Cover: (1) expired state renders with 'Certificate expired' label and error color scheme, (2) expired banner remains visible when isAcknowledged=false, (3) expired banner hides when isAcknowledged=true (BLoC state updated), (4) expiring-soon state still renders correctly after this change (regression), (5) CTA button in expired state uses the correct copy and triggers the correct callback, (6) Semantics label reflects expired state. Run all existing task-006 widget tests to confirm no regressions.
The persistent banner must remain visible across app sessions and only disappear when a specific backend condition is met (renewal or coordinator acknowledgement). If the BLoC state is not properly sourced from the notification record repository on every app launch, the banner may disappear prematurely or fail to reappear after a session restart.
Mitigation & Contingency
Mitigation: Drive the banner's visibility exclusively from a Supabase real-time subscription on the notification records table filtered by mentor_id and acknowledged_at IS NULL. Never persist banner visibility state locally. Write an integration test that restarts the BLoC and verifies the banner reappears from the database source.
Contingency: If real-time subscriptions introduce latency or connection reliability issues in offline-first scenarios, add a local cache flag that is only cleared when the repository confirms the acknowledgement write succeeded, with a cache TTL of 24 hours as a fallback.
The notification detail view must conditionally render coordinator-specific actions based on the authenticated user's role. Incorrect role resolution could expose the 'Acknowledge Lapse' action to peer mentors or hide it from coordinators, breaking the workflow and potentially allowing unauthorised state changes.
Mitigation & Contingency
Mitigation: Source the role check from the existing role_state_manager BLoC that is already authenticated against Supabase role claims. Do not rely on a local flag. The coordinator acknowledgement service backend also validates role server-side, providing defence in depth. Add widget tests that render the detail view with mentor and coordinator role fixtures and assert the presence or absence of coordinator actions.
Contingency: If a role resolution bug is found in production, immediately disable the acknowledge action via a feature flag and patch the role check in a hotfix release. The server-side validation in the coordinator acknowledgement service ensures no actual state change can occur even if the button is incorrectly rendered.