Dart model: DuplicateConflict
epic-proxy-activity-registration-foundation-task-006 — Implement the `DuplicateConflict` Dart class capturing a detected duplicate activity. Fields: conflictingActivityId, attributedTo, activityDate, activityTypeId, severity (warning | blocking), resolvedAt (nullable). Include `fromJson`/`toJson`, `copyWith`, and Equatable. Used by upstream duplicate detection services.
Acceptance Criteria
Technical Requirements
Implementation Notes
The nullable copyWith problem in Dart: standard copyWith cannot distinguish between 'not provided' and 'explicitly null'. Use the sentinel/wrapper pattern: define a private `_Sentinel` class and use `Object? resolvedAt = _sentinel` in copyWith, then check `identical(resolvedAt, _sentinel)` to decide whether to use the existing value or the new one. This is the idiomatic Dart approach when freezed is not used.
The isResolved getter is a convenience for UI conditional rendering — add it directly to the class. ConflictSeverity should be defined in the same file or a shared enums file. Since this model is consumed by upstream duplicate detection services, ensure the JSON field names exactly match what those services produce (coordinate with the RPC response shape defined in task-002).
Testing Requirements
Write flutter_test unit tests in test/features/proxy_activity/models/duplicate_conflict_test.dart. Cover: (1) full round-trip with resolvedAt populated, (2) round-trip with resolvedAt=null, (3) isResolved returns false when resolvedAt is null, (4) isResolved returns true when resolvedAt is set, (5) copyWith(resolvedAt: someDateTime) creates resolved instance, (6) severity fallback for unknown string, (7) Equatable equality. Minimum 7 test cases. Use a nullable copyWith pattern that supports `copyWith({DateTime?
resolvedAt, bool clearResolvedAt = false})` or a wrapper object pattern to allow explicitly nulling the field.
The activities table migration adding registered_by and attributed_to columns may conflict with existing RLS policies or FK constraints if the user profile table structure differs from assumptions, blocking all subsequent epics.
Mitigation & Contingency
Mitigation: Review existing activities table schema and RLS policies before writing the migration. Run the migration against a staging database clone first. Write rollback scripts alongside the migration.
Contingency: If migration fails in staging, isolate the conflict with a targeted schema audit, adjust FK references or RLS policy scope, and re-run before touching production.
The RLS policy must filter proxy inserts to the coordinator's chapter scope. If the chapter-scope resolver pattern differs between organisations (multi-chapter coordinators in NHF vs single-chapter in HLF), the policy may be too broad or too restrictive.
Mitigation & Contingency
Mitigation: Design the RLS policy to accept a coordinator's full set of assigned chapter IDs (array) rather than a single chapter_id. Validate the policy against NHF multi-chapter test fixtures during the integration test phase.
Contingency: If the policy is found to be incorrect after deployment, introduce a server-side validation edge function as a safety net while the RLS policy is corrected.
The bulk_register_activities RPC function may time out or cause lock contention when inserting large participant batches (e.g. 40+ peer mentors in a single group session), degrading the user experience.
Mitigation & Contingency
Mitigation: Benchmark the RPC function with 50-participant batches during development. Use unnest-based bulk insert rather than row-by-row PL/pgSQL loops. Set a reasonable statement_timeout.
Contingency: If performance is insufficient, split the client-side submission into chunks of 20 participants with progress feedback, rather than a single RPC call.