Define PeerMentorDetailModel unified data structure
epic-peer-mentor-detail-screen-bloc-and-assembly-task-001 — Create the PeerMentorDetailModel Dart class that merges data from all four repositories (peer mentor profile, certification records, activity logs, assignment history) into a single unified model. Define all required fields, nullable org-specific fields, and per-source error holders. This model is the contract between the aggregation service and the BLoC.
Acceptance Criteria
Technical Requirements
Implementation Notes
Place the model in the peer mentor feature domain layer (e.g., `lib/features/peer_mentor/domain/models/peer_mentor_detail_model.dart`), not in a shared folder, since it is specific to this aggregation use case. Define `PeerMentorDataSource` as a Dart enum in the same file or an adjacent `enums.dart`. For `copyWith`, consider using the `copyWith` code-gen pattern already used elsewhere in the project for consistency. The four repository sources for the enum should be: `profile`, `certifications`, `activities`, `assignments`.
Document the nullable org-specific fields with a reference to the organisation that requires them (e.g., HLF certification expiry, Blindeforbundet assignment encryption status) so future developers understand the conditional logic. This model is the single source of truth consumed by the BLoC — downstream BLoC states should wrap or extend this model rather than duplicating fields.
Testing Requirements
Unit tests only (no widget pump). Test `factory PeerMentorDetailModel.empty()` produces a valid instance with empty lists and no errors. Test `hasPartialData` returns false when all sourceErrors are null, and true when any single source error is set. Test `copyWith` correctly replaces individual fields while preserving others.
Test `==` equality for two identically constructed instances. Test that passing a null list argument to a list field throws an assertion error (if assertions are enabled) — list fields must never be null. No Supabase mocking needed at this layer since the model is a pure data class.
The parallel Future.wait aggregation pattern may produce race conditions or incorrect merged state when some repositories resolve significantly faster than others, particularly if the BLoC receives a RefreshDetail event while a prior fetch is still in flight.
Mitigation & Contingency
Mitigation: Implement cancellation token pattern in the aggregation service to abort in-flight fetches on new events. Add BLoC test scenarios for rapid successive refresh events to validate state consistency.
Contingency: If race conditions persist, switch to a sequential-with-timeout fetch strategy for the first release and profile the performance impact before deciding whether parallel fetch optimization is worth the complexity.
Integrating PeerMentorDetailScreenWidget into the existing StatefulShellRoute navigation structure may conflict with the Contacts tab's existing route hierarchy, requiring changes to navigation-route-config that could affect other teams' features.
Mitigation & Contingency
Mitigation: Coordinate with the Contact List and Contact Detail feature teams before adding the new route. Review the existing StatefulShellRoute configuration and confirm the peer mentor detail route can be nested under the Contacts branch without path conflicts.
Contingency: If route conflicts arise, temporarily implement the peer mentor detail as a modal overlay (push route) rather than a shell route child, preserving functionality while the navigation architecture conflict is resolved.
The course enrollment screen that the certification alert banner links to may not yet exist or may be implemented in a separate feature epic, leaving a broken navigation tap for HLF users in the initial release.
Mitigation & Contingency
Mitigation: Check the certification management feature implementation status before finalizing Epic 4 scope. If the enrollment screen is not available, design the tap action to open the HLF course enrollment URL in an external browser as an interim solution.
Contingency: Implement the CTA as a configurable action: if the enrollment route exists in the router, push it; otherwise, launch the configured org-specific enrollment URL via url_launcher, ensuring HLF users can always take action on expired certifications.