Define DuplicateWarningEvent model and logger interface
epic-multi-chapter-membership-handling-data-layer-task-007 — Create the DuplicateWarningEvent domain model capturing: event timestamp, contact_id, chapter_ids involved, activity details of the suspected duplicate, and the coordinator's decision (dismissed or cancelled). Define the abstract DuplicateWarningEventLogger interface with a logWarningEvent(event) method. Ensure the model is serializable to JSON for Supabase storage.
Acceptance Criteria
Technical Requirements
Implementation Notes
Use the uuid package (already likely in pubspec.yaml for other models) to generate eventId. Define the model in lib/domain/models/duplicate_warning_event.dart and the enum in the same file or a sibling file. Consider using freezed for the model class to avoid boilerplate — if freezed is already used in the project, follow that convention. For the toJson/fromJson, if using freezed with json_serializable, annotate with @JsonSerializable().
The CoordinatorDecision enum should use @JsonValue('dismissed') and @JsonValue('cancelled') annotations if json_serializable is used, to ensure the exact string values match what the Supabase column expects. The DuplicateWarningEventLogger interface file lives in lib/domain/repositories/duplicate_warning_event_logger.dart — naming it as a 'logger' rather than 'repository' signals its audit-only, write-once semantics.
Testing Requirements
Write unit tests in flutter_test: (1) construct a DuplicateWarningEvent with known values, call toJson(), and assert each field is correctly serialized (DateTime as ISO 8601 string, enum as string, list as JSON array); (2) call fromJson() on the serialized map and assert the reconstructed object equals the original; (3) verify that omitting eventId in the constructor generates a non-null UUID string; (4) verify CoordinatorDecision.dismissed.toJson() returns 'dismissed' and CoordinatorDecision.cancelled.toJson() returns 'cancelled'; (5) verify fromJson() with coordinatorDecision: 'dismissed' reconstructs CoordinatorDecision.dismissed. No integration tests required — this is a pure domain model.
The Cross-Chapter Activity Query must avoid N+1 fetches across chapters. If naively implemented as a per-chapter loop, it will cause severe performance degradation for contacts affiliated with 5 chapters on poor mobile connections.
Mitigation & Contingency
Mitigation: Design the query as a single PostgREST join of contact_chapters and activities on contact_id from the start. Add a query performance test with 5 affiliations and 100+ activities to the integration test suite and enforce a maximum execution time threshold.
Contingency: If a performance regression is detected post-merge, introduce a Supabase RPC function (stored procedure) to move the join server-side, bypassing any client-side N+1 pattern.
If the Duplicate Warning Event Logger write fails silently (network error, RLS denial), audit entries will be missing from the Bufdir compliance record without the user being aware.
Mitigation & Contingency
Mitigation: Implement the logger with a local fallback queue: if the Supabase write fails, persist the event locally and retry on next launch. Log all failures to a verbose output channel.
Contingency: Add a reconciliation job that compares locally queued events to Supabase entries and re-submits any gaps. Provide a data export of the local queue for manual audit if reconciliation fails.
Two coordinators simultaneously adding the 5th chapter affiliation for the same contact could bypass the maximum enforcement check if both reads occur before either write completes.
Mitigation & Contingency
Mitigation: Enforce the 5-affiliation maximum as a database-level constraint (CHECK + trigger or RPC with a FOR UPDATE lock) rather than relying solely on application-layer validation.
Contingency: If a constraint violation is detected in production, run a corrective query to end the most recently created excess affiliation and notify the relevant coordinator.