high priority low complexity integration pending fullstack developer Tier 2

Acceptance Criteria

The notification feed list item factory (or switch renderer) has a new case for `notificationType == 'pause_status'` that returns a `PauseNotificationCard` widget
When the coordinator's notification feed contains a pause-status item, a `PauseNotificationCard` is rendered in the correct list position
Pause-status notifications are visible only to users with coordinator or org-admin roles; peer mentor role does not see them in the feed
Unknown or unregistered notification types continue to render the existing fallback/generic card without throwing
Navigation from the quick-action link on the card routes correctly to the peer mentor's profile screen in the live app
No regression: other notification card types (activity, assignment, etc.) still render correctly after the integration change
Widget test for the notification feed passes with a seeded `pause_status` item in the item list

Technical Requirements

frameworks
Flutter
Dart
BLoC
Riverpod
apis
Supabase Realtime
data models
assignment
contact
device_token
performance requirements
Registering a new notification type must not add measurable overhead to list scroll performance
Factory/switch lookup must be O(1) — use a map-based dispatch rather than a long if-else chain if more than 4 types already exist
security requirements
Role-based visibility check (coordinator/org-admin only) must be enforced in the BLoC/Riverpod layer, not just in the UI widget, to prevent data leakage if the widget is reused
Notification payload data used to construct `PauseNotificationCardData` must be validated before rendering — missing required fields should produce a fallback card, not a runtime error
ui components
PauseNotificationCard (task-002)
NotificationFeedList (existing)
NotificationListItemFactory or equivalent switch renderer (existing)

Execution Context

Execution Tier
Tier 2

Tier 2 - 518 tasks

Can start after Tier 1 completes

Implementation Notes

Locate the existing notification list item factory — likely a `switch` on `notificationType` string or a `Map` registry. Prefer the map-based registry pattern if it already exists, as it avoids touching a growing switch statement. When parsing the incoming notification payload into `PauseNotificationCardData.fromJson()`, wrap the call in a try/catch and return a `GenericNotificationCard` fallback on parse failure to ensure the feed never crashes on a malformed payload. Confirm with the team whether the role-visibility filter is already applied at the BLoC/repository layer (filtering out non-coordinator notifications before they reach the UI) or whether the UI must apply an additional guard.

Testing Requirements

Widget test: render the `NotificationFeedList` widget with a mixed list including one `pause_status` item and two other notification types; assert `PauseNotificationCard` appears exactly once and other card types appear with correct counts. Unit test for the factory: assert that `factory.build(type: 'pause_status', data: {...})` returns a `PauseNotificationCard` instance. Regression test: snapshot/golden test of the full notification feed with existing item types to detect unintended rendering changes. Manual QA checklist: coordinator sees pause card, peer mentor does not.

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.