Implement Contact Detail Repository
epic-contact-detail-and-edit-main-screen-task-002 — Build the contact detail repository that fetches full contact profiles from Supabase, including org-specific metadata fields for NHF and Blindeforbundet contexts. Support chapter affiliation arrays, role badges, and sensitive field identifiers. Implement RLS-compliant queries with proper error handling and typed response models.
Acceptance Criteria
Technical Requirements
Implementation Notes
Use the repository pattern with an abstract interface (ContactDetailRepository) and a concrete SupabaseContactDetailRepository. Inject the Supabase client via constructor for testability. Use a single `.from('contacts').select('*, chapter_affiliations(*), role_badges(*)')` style query with Supabase's relationship expansion rather than multiple round-trips. For org-specific fields, use a strategy pattern or org-context parameter to select the correct column set at query build time — avoid runtime `if (org == NHF)` branches scattered throughout.
Map all Supabase exceptions in a dedicated _mapException() private method. Use freezed for ContactDetailModel and all failure types to ensure immutability and exhaustive pattern matching at call sites.
Testing Requirements
Unit tests using flutter_test with a mocked Supabase client interface. Test cases must cover: successful fetch with NHF org context (verify chapter_affiliations populated), successful fetch with Blindeforbundet org context (verify sensitive_field_identifiers populated), network timeout mapped to NetworkFailure, RLS denial (403) mapped to PermissionDeniedFailure, empty result (contact not found) mapped to NotFoundFailure, malformed jsonb in chapter_affiliations handled without crash. Integration test against a local Supabase instance (or staging) verifying RLS rules reject cross-org access. Aim for 90%+ line coverage on the repository class.
The Peer Mentor Profile tab on the contact detail screen depends on the peer-mentor-detail-screen-widget being delivered by the separate Peer Mentor Detail feature. If that feature is delayed, the navigation affordance will be present but lead to a stub screen, which may confuse coordinators in the TestFlight pilot.
Mitigation & Contingency
Mitigation: Implement the peer mentor tab with a feature flag guard. When the Peer Mentor Detail feature is incomplete, the flag disables the tab. Coordinate delivery timelines with the team responsible for Peer Mentor Detail to align TestFlight releases.
Contingency: If the Peer Mentor Detail feature is significantly delayed, ship the contact detail screen without the peer mentor tab in the first TestFlight build and add it as an incremental update once the dependent screen is ready.
The contact detail screen must adapt its layout significantly based on organisation context: NHF shows affiliation chips, Blindeforbundet shows encrypted fields and assignment status, standard contacts show neither. Managing this conditional rendering without introducing bugs in each variant is complex and increases the risk of organisation-specific regressions.
Mitigation & Contingency
Mitigation: Define a ContactDetailViewModel that resolves all org-specific flags (showEncryptedFields, showAssignmentStatus, showMultiChapterChips) from the organisation config before the widget tree renders. Widget tests must cover all three organisation variants as separate test cases to catch regressions.
Contingency: If conditional rendering logic grows unwieldy, refactor into separate composable section widgets (ProfileHeaderSection, AffiliationSection, EncryptedFieldsSection) that are conditionally included by the parent screen, isolating org-specific logic to individual components.