high priority low complexity frontend pending frontend specialist Tier 1

Acceptance Criteria

PeerMentorConfirmationBanner is a StatefulWidget that renders an inline banner (not a modal or overlay dialog)
Banner displays distinct confirmation messages for pause activation (e.g., 'You are now paused as of [effective date]') and deactivation (e.g., 'You are now active again as of [effective date]')
Effective date is formatted in a human-readable locale-aware format (e.g., '12 March 2026')
Banner uses only design token colors, spacing, and typography — zero hardcoded pixel values or color literals
Banner visually differentiates pause (e.g., warning/amber accent) from resume (e.g., success/green accent) using design tokens
Auto-dismiss timer starts when the widget is first mounted and calls `onDismiss` callback after `PeerMentorConfirmationBannerModel.autoDismissDuration`
Timer is cancelled in `dispose()` to prevent setState-after-dispose errors
Banner accepts an `onDismiss` VoidCallback and a manual close button that also calls the callback
Widget is screen-reader accessible: the banner container has a semantic label announcing the full message text
WCAG 2.2 AA contrast ratio met for all text and icon elements
Widget does not hardcode any string literals — all display strings use the app's localisation/label system

Technical Requirements

frameworks
Flutter
Design token system (colors, typography, spacing, radii)
data models
assignment
performance requirements
Widget build method is pure — no async operations or side effects during build
Timer initialised in `initState`, not in `build`
security requirements
No PII displayed beyond event type and effective date
No network calls made from within the widget
ui components
PeerMentorConfirmationBanner
Design token color/typography/spacing tokens
Close/dismiss icon button
Existing app banner pattern widget (if present)

Execution Context

Execution Tier
Tier 1

Tier 1 - 540 tasks

Can start after Tier 0 completes

Implementation Notes

Follow the existing toast/banner widget pattern in the codebase — do not create a new paradigm. Use `Timer` (not `Future.delayed`) for auto-dismiss so it can be cancelled reliably in `dispose`. Accept the model as a constructor parameter for full testability. The parent widget is responsible for removing the banner from the tree when `onDismiss` fires (e.g., using conditional rendering in BLoC state).

Do not use `OverlayEntry` — this is an inline banner, not a floating overlay. For the date format, use `intl` package's `DateFormat` consistent with other date displays in the app.

Testing Requirements

Widget tests: pump the widget with `pauseActivated` payload and verify the pause-specific message renders; pump with `pauseDeactivated` and verify the resume-specific message renders; verify the effective date appears in the expected format; advance `fakeAsync` clock by the auto-dismiss duration and confirm `onDismiss` is called exactly once; tap the close button and verify `onDismiss` is called immediately; verify the widget is removed from the tree after `onDismiss` is invoked by the parent; run accessibility checks with `expectAccessibility`. Golden test recommended for visual regression on both states.

Epic Risks (2)
medium impact low prob integration

The existing notification feed component may expect a specific notification model shape that does not map cleanly to the pause notification payload structure, requiring either payload transformation or feed refactoring.

Mitigation & Contingency

Mitigation: Review the notification-list-item and notification-model contracts before building the card. Design the pause-notification-card to extend or wrap the existing list item pattern rather than replacing it.

Contingency: If the feed contract is incompatible, implement a lightweight adapter that maps the pause notification payload to the feed's expected model shape, keeping the adapter isolated from the core card widget.

low impact low prob dependency

The app's existing toast/banner infrastructure may not support the auto-dismiss timeout duration or dismissal animation required for the peer mentor confirmation banner, necessitating a custom implementation that diverges from the design system.

Mitigation & Contingency

Mitigation: Audit the existing banner and toast components (in-app-notification-banner, notification-list-item) for configurable dismiss timeout before starting implementation. Prefer configuration over custom code.

Contingency: If the existing infrastructure cannot be configured, implement the banner as a thin wrapper with a custom auto-dismiss timer while reusing all visual tokens (colours, spacing, typography) from the design system to maintain consistency.