Implement ExpiryStatusIndicator widget — full mode
epic-certificate-expiry-notifications-user-interface-task-003 — Extend the ExpiryStatusIndicator widget with a full display mode for use on detail screens. Full mode shows the badge label alongside an expiry date string and an icon. Ensure the widget correctly switches rendering based on a displayMode parameter (compact vs full) while reusing the same state-driven color logic and Semantics wrapper.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 2 - 518 tasks
Can start after Tier 1 completes
Implementation Notes
Introduce ExpiryDisplayMode enum (compact, full) in the same file or adjacent enums file. Refactor the existing build() method to delegate to _buildCompact() and _buildFull() private methods — this avoids a large conditional block and keeps each rendering path readable. Extract the shared color token selection into a private _tokensForStatus() method that both paths call. For the icon mapping, use a static const Map
The expiryDateLabel parameter should be a String? — the caller is responsible for formatting the date (do not accept a DateTime and format inside the widget, as this creates l10n complexity). In full mode, wrap the Row in a Semantics node with excludeSemantics: true on child text/icon nodes so the combined label is read once, not fragmented by the screen reader.
Testing Requirements
Extend test/widgets/expiry_status_indicator_test.dart with a new group for full mode. Additional test cases: (1) full mode renders icon widget for each state, (2) full mode renders the expiry date string when provided, (3) full mode omits date gracefully when expiryDateLabel is null, (4) full mode Semantics label includes the date string when provided, (5) full mode does not overflow at textScaleFactor 1.5 in a 320px-wide viewport, (6) switching displayMode from compact to full changes widget tree structure (verify with find.byType). Existing compact mode tests must still pass without modification.
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.