Build Assignment Status Indicator Widget
epic-contact-detail-and-edit-main-screen-task-005 — Implement the assignment status indicator UI widget that visually communicates whether a contact has an active assignment, is unassigned, or is on a waiting list. Use design token colors and accessible semantics labels. The widget must be stateless, accept an AssignmentStatus enum, and render correctly in both light and dark themes for Blindeforbundet contexts.
Acceptance Criteria
Technical Requirements
Implementation Notes
Define the AssignmentStatus enum in a shared types file (e.g., lib/domain/enums/assignment_status.dart) so it can be reused across contact list and detail contexts. Map each status to a design token in a private extension method on the enum (e.g., AssignmentStatus.assigned.color(context)) to avoid a switch statement inside the widget's build method. Use Theme.of(context).brightness to select the appropriate token variant rather than MediaQuery. For the dot indicator, use a Container with BoxDecoration(shape: BoxShape.circle) — simpler than Icon and more flexible for sizing.
Wrap the entire widget in a Semantics widget with label set to the localized status string. Do not use AnimatedContainer or any animation — keep it purely presentational for maximum reusability.
Testing Requirements
Widget tests using flutter_test for all three AssignmentStatus values verifying: correct Semantics label text, correct design token color applied (verify ColoredBox or decoration color matches token value), no overflow in 200px wide constrained box. Golden tests for all three statuses in both light and dark theme (6 golden images total). Accessibility test using flutter_test's SemanticsHandle to verify each widget is announced correctly by screen reader.
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.