Build Duplicate Activity Warning Dialog modal shell
epic-multi-chapter-membership-handling-ui-task-006 — Implement the DuplicateActivityWarningDialog as a fully accessible modal in Flutter. The dialog receives a DuplicateActivityWarning data object and renders: conflict description, the two conflicting activity entries side by side, and Proceed / Cancel action buttons. Use accessible modal sheet component from the design system. Ensure the dialog traps focus and announces itself as an alert dialog to VoiceOver and TalkBack via Semantics(container: true, label: ..., liveRegion: true).
Acceptance Criteria
Technical Requirements
Implementation Notes
Implement as a stateless widget that is shown via showDialog
For the side-by-side conflict comparison, use a Row with two Expanded children, each showing the relevant activity's date, time, chapter, and type. Use the design system's modal bottom sheet or AlertDialog variant consistently — avoid raw Dialog widget. The DialogResult enum (proceed, cancelled) should be defined in a shared types file so the calling widget can pattern-match on it cleanly.
Testing Requirements
Write widget tests using flutter_test: (1) mount DuplicateActivityWarningDialog with a mock DuplicateActivityWarning and assert conflict description text appears, (2) assert both activity entries are rendered, (3) tap Proceed and assert the future resolves with DialogResult.proceed, (4) tap Cancel and assert the future resolves with DialogResult.cancelled, (5) assert tapping outside the dialog does not dismiss it (barrierDismissible: false). Write semantics tests asserting the root node has liveRegion: true and a non-empty label. Perform manual VoiceOver and TalkBack tests on device to confirm immediate announcement on modal presentation. Write a golden test for the dialog in its default state.
The Duplicate Activity Warning Dialog must announce itself to VoiceOver and TalkBack immediately on appearance. Flutter's default modal semantics do not guarantee focus shift to the dialog on all platform versions, risking silent appearance for screen reader users — a WCAG 2.2 failure.
Mitigation & Contingency
Mitigation: Wrap the dialog content in a Semantics node with liveRegion: true and explicitly request focus via FocusScope.of(context).requestFocus() on the dialog's primary action button in the post-frame callback. Test on physical iOS (VoiceOver) and Android (TalkBack) devices, not only simulators.
Contingency: If automatic focus fails on a specific platform version, add a platform-specific fallback using SemanticsService.announce() to force a live region announcement of the dialog's headline text.
The Chapter Membership Cubit tracks pending changes before commit to support the two-step add/confirm flow. If the user navigates away mid-edit or the app is backgrounded, uncommitted pending state could be replayed incorrectly on return, causing phantom affiliation additions or removals.
Mitigation & Contingency
Mitigation: Design the Cubit to hold pending changes only in transient in-memory state with no persistence. On any navigation-away event, emit a reset state that discards pending changes. Prevent accidental navigation during an active edit by showing a discard-changes confirmation dialog.
Contingency: If state desync is reported in production, add an explicit state reconciliation step in the Cubit's onResume handler that re-fetches the authoritative affiliation list from the repository and resets all pending state before re-rendering.
The Chapter Assignment Editor's searchable chapter list must load quickly. If the organisation has hundreds of chapters (NHF has 1,400 local chapters) and the full list is fetched on dialog open, the editor will be slow to display and the search will be sluggish.
Mitigation & Contingency
Mitigation: Scope the chapter list to only chapters within the coordinator's administrative scope (not all 1,400), leveraging the existing hierarchy access scope service. Implement server-side search with a minimum 2-character threshold and debounce to avoid excessive Supabase queries.
Contingency: If the scoped list is still too large, add local caching of the chapter list with a 15-minute TTL and an explicit refresh button, ensuring the editor is always responsive even on poor network conditions.