high priority low complexity frontend pending frontend specialist Tier 13

Acceptance Criteria

When `BulkParticipant.hasConflict` is true, a conflict badge is displayed inline in the participant row, positioned after the participant name
When `BulkParticipant.hasConflict` is false, no badge element is present in the widget tree for that row (use conditional rendering, not invisible widgets)
Badge text reads 'Duplicate' (or the organisation-specific label from the org labels system)
Badge background color uses the design token for warning/conflict states (e.g., `AppColors.warning` or equivalent token) — no hardcoded hex values
Badge text color provides a minimum 4.5:1 contrast ratio against the badge background, satisfying WCAG 2.2 AA
The badge widget is wrapped in a Semantics widget with `label: 'Duplicate activity conflict'` so screen readers announce it
Toggling hasConflict from false to true in the parent (by updating the participants list) causes the badge to appear without a full widget rebuild of the entire list
Badge is visible and correctly sized on both small (375px wide) and large (428px wide) phone screens
No hardcoded string literals in the widget — all copy comes from the org labels system or a constants file

Technical Requirements

frameworks
Flutter
BLoC
data models
BulkParticipant
performance requirements
Badge rendering adds no perceptible frame drop — it is a simple Container with Text, no animations or heavy computation
security requirements
Participant names in conflict badges must not expose internal database IDs or system metadata
ui components
ConflictBadge (StatelessWidget, reusable)
BulkParticipantRow (extended with badge slot)

Execution Context

Execution Tier
Tier 13

Tier 13 - 6 tasks

Can start after Tier 12 completes

Dependencies (21)
epic-proxy-activity-registration-orchestration-task-001 component Cross-Epic Component bulk-participant-list depends on proxy-registration-service
epic-proxy-activity-registration-orchestration-task-002 component Cross-Epic Component bulk-participant-list depends on proxy-registration-service
epic-proxy-activity-registration-orchestration-task-003 component Cross-Epic Component bulk-participant-list depends on proxy-registration-service
epic-proxy-activity-registration-orchestration-task-004 component Cross-Epic Component bulk-participant-list depends on proxy-registration-service
epic-proxy-activity-registration-orchestration-task-005 component Cross-Epic Component bulk-participant-list depends on proxy-registration-service
epic-proxy-activity-registration-orchestration-task-010 component Cross-Epic Component bulk-participant-list depends on proxy-registration-service
epic-proxy-activity-registration-orchestration-task-006 component Cross-Epic Component bulk-participant-list depends on bulk-registration-service
epic-proxy-activity-registration-orchestration-task-007 component Cross-Epic Component bulk-participant-list depends on bulk-registration-service
epic-proxy-activity-registration-orchestration-task-008 component Cross-Epic Component bulk-participant-list depends on bulk-registration-service
epic-proxy-activity-registration-orchestration-task-009 component Cross-Epic Component bulk-participant-list depends on bulk-registration-service
epic-proxy-activity-registration-orchestration-task-011 component Cross-Epic Component bulk-participant-list depends on bulk-registration-service
epic-proxy-activity-registration-core-services-task-001 component Cross-Epic Component bulk-participant-list depends on proxy-duplicate-detection-service
epic-proxy-activity-registration-core-services-task-002 component Cross-Epic Component bulk-participant-list depends on proxy-duplicate-detection-service
epic-proxy-activity-registration-core-services-task-003 component Cross-Epic Component bulk-participant-list depends on proxy-duplicate-detection-service
epic-proxy-activity-registration-core-services-task-008 component Cross-Epic Component bulk-participant-list depends on proxy-duplicate-detection-service
epic-proxy-activity-registration-core-services-task-004 component Cross-Epic Component bulk-participant-list depends on activity-attribution-service
epic-proxy-activity-registration-core-services-task-005 component Cross-Epic Component bulk-participant-list depends on activity-attribution-service
epic-proxy-activity-registration-core-services-task-006 component Cross-Epic Component bulk-participant-list depends on activity-attribution-service
epic-proxy-activity-registration-core-services-task-007 component Cross-Epic Component bulk-participant-list depends on activity-attribution-service
epic-proxy-activity-registration-core-services-task-009 component Cross-Epic Component bulk-participant-list depends on activity-attribution-service
epic-proxy-activity-registration-core-services-task-010 component Cross-Epic Component bulk-participant-list depends on activity-attribution-service

Implementation Notes

Extract ConflictBadge as a reusable StatelessWidget in `lib/features/bulk_registration/widgets/conflict_badge.dart` — it will likely be reused in other screens (e.g., coordinator approval dialog). Implement it as a styled Container with rounded corners, padding from design tokens, and a Text child. Use the existing design token system — look for a `warningContainer` or `errorSubtle` color token in `AppColors`. If no suitable token exists, add one to the token file rather than hardcoding.

For the Semantics wrapper, use `Semantics(label: AppStrings.conflictBadgeLabel, excludeSemantics: true, child: badge)` — `excludeSemantics: true` prevents the inner Text from being double-announced. The BLoC feeds updated `BulkParticipant` objects with new `hasConflict` values into the state; the list widget receives these via its `participants` parameter and rebuilds naturally via BlocBuilder.

Testing Requirements

Widget tests in `test/widgets/bulk_participant_list_test.dart` (extend existing file). Required new test cases: (1) row with hasConflict=true renders a widget containing the badge text, (2) row with hasConflict=false renders no badge widget (use `findsNothing`), (3) list with mixed conflict/clean participants renders the correct number of badges, (4) badge Semantics node has the expected label string. Additionally, run a contrast check manually using the Flutter accessibility inspector or a color contrast tool to confirm 4.5:1 ratio before marking complete.

Component
Bulk Participant List Widget
ui low
Epic Risks (4)
medium impact high prob scope

The bulk registration screen combines pre-filled defaults, a dynamic multi-select participant list, per-participant conflict badges, and a batch submission confirmation — making it one of the most complex screens in the application. Scope creep or underestimated interaction complexity could cause the epic to exceed its estimate significantly.

Mitigation & Contingency

Mitigation: Implement the bulk screen in two vertical slices: (1) participant selection and form submission without conflict handling, (2) conflict badge rendering and override flow. Validate slice 1 with coordinators before building slice 2.

Contingency: If the full conflict review UI cannot be completed within the epic, ship the bulk screen with a simplified 'skip all duplicates' fallback mode and defer per-participant override toggles to a follow-up sprint.

medium impact medium prob technical

The proxy-registration-bloc must manage state across two distinct flows (single proxy and bulk) with branching conflict paths, intermediate buffering of bulk participant selections, and reliable state reset. Incorrect state transitions could leave the UI in a loading or stale-conflict state after submission.

Mitigation & Contingency

Mitigation: Model the BLoC state as a sealed class hierarchy with exhaustive pattern matching in the UI. Write state-machine unit tests that exercise every valid transition and assert that invalid transitions are no-ops. Use flutter_bloc's BlocObserver in debug builds to log all transitions.

Contingency: If BLoC state bugs surface in QA, introduce an explicit ResetToIdle event triggered on screen disposal to guarantee clean state, and add a 'Start over' affordance visible to the coordinator at any conflict step.

high impact medium prob technical

The typeahead peer mentor selector with multi-select mode may be difficult to operate with VoiceOver/TalkBack, particularly the dynamic search results list and the selected-chip removal controls, risking WCAG 2.2 AA non-compliance for screen reader users.

Mitigation & Contingency

Mitigation: Wrap all search result items and selected chips with explicit Semantics widgets providing role, label, and selected-state announcements. Test the selector with VoiceOver on iOS and TalkBack on Android during development, not only at QA time.

Contingency: If the multi-select typeahead cannot be made fully accessible within the sprint, provide an alternative flat scrollable list with checkboxes as a fallback mode, toggled by an accessibility-settings flag.

high impact medium prob security

The peer mentor selector must apply RLS chapter-scope filtering to show only mentors the coordinator is responsible for. If the Supabase query for the selector does not correctly join against the coordinator's chapter assignments, coordinators may see mentors from other chapters, violating data isolation.

Mitigation & Contingency

Mitigation: Implement the selector's data query using the same RLS-aware Supabase client used by the contact list feature, which already handles chapter-scope filtering. Write an integration test with a multi-chapter coordinator fixture asserting cross-chapter mentors are not returned.

Contingency: If a data isolation breach is discovered, immediately add a client-side chapter_id filter as a defence-in-depth measure and audit selector query logs for any unauthorised cross-chapter results.