Implement AssignedContactsList scrollable section
epic-peer-mentor-detail-screen-ui-components-task-009 — Build AssignedContactsList as a vertically scrollable ListView.builder section displaying contact rows. Each row must show contact name, assignment status indicator, and be tappable to navigate to the contact detail screen. Include an empty-state widget for when the mentor has no assigned contacts. Apply physics suitable for embedding inside a CustomScrollView parent.
Acceptance Criteria
Technical Requirements
Implementation Notes
Define AssignedContactsList as a StatelessWidget with parameters: List
For the empty state, create a simple EmptyContactsState widget (reuse or create new) with a neutral icon (e.g., Icons.people_outline) and the text 'No assigned contacts yet'. Keep the row widget as a private _ContactRow StatelessWidget inside the same file for encapsulation. Define the AssignedContact data class with the fields above, or reuse an existing model if one exists — check the codebase before creating a new one.
Testing Requirements
Write widget tests using flutter_test. Test 1: pass an empty list — assert the empty-state widget is present and no ListTile/Row widgets are rendered. Test 2: pass a list of 3 contacts — assert exactly 3 row widgets are rendered and each displays the correct name. Test 3: tap the first row — assert onContactTap is called with the correct contact ID.
Test 4: verify NeverScrollableScrollPhysics is applied by checking widget type in the tree. Test 5: pass 100 contacts — assert the widget builds without overflow errors (use tester.pump() and check for no exceptions). Use pump() not pumpAndSettle() to avoid timeout on large lists.
The org labels system may not yet have label keys defined for peer mentor detail screen terminology (role labels, section headings), requiring additions to the label key registry that must be coordinated with the admin configuration team.
Mitigation & Contingency
Mitigation: Audit existing label keys in the terminology system before starting OrgLabelsProvider integration. Submit required new label keys for admin configuration in parallel with component implementation.
Contingency: If label keys are not available at integration time, use hardcoded English fallbacks with a clear TODO for admin configuration, ensuring the widget renders correctly while keys are being provisioned.
The design token semantic colors (warning, error surface) may not meet WCAG 2.2 AA 4.5:1 contrast ratio when rendered on the app's background surface tokens, requiring design system changes that affect the entire app.
Mitigation & Contingency
Mitigation: Run contrast ratio validation on the token palette during Epic 1 design token implementation. Flag any failing pairs to the design system owner before building UI components that depend on them.
Contingency: If tokens fail contrast requirements, define supplementary high-contrast override tokens specific to alert and badge contexts that meet AA without modifying the global palette.