Implement field-level diff computation for DuplicateComparisonPanel
epic-duplicate-activity-detection-core-logic-task-009 — Add a pure DiffComputer utility used by DuplicateComparisonPanel to compute field-by-field divergence between two ActivityRecord objects. For each comparable field (date, duration, activity type, contact ID, notes), produce a FieldDiffResult with an isDivergent flag and both values. Wire the results into the panel so divergent fields are visually distinguished from matching fields, enabling users to quickly identify what differs between the two records.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 1 - 540 tasks
Can start after Tier 0 completes
Implementation Notes
Place `DiffComputer` in `lib/features/deduplication/domain/diff_computer.dart` — domain layer, no Flutter imports. Define `FieldDiffResult` as a freezed data class: `@freezed class FieldDiffResult with _$FieldDiffResult { const factory FieldDiffResult({ required String fieldName, required bool isDivergent, required Object? valueA, required Object? valueB }) = _FieldDiffResult; }`.
`ActivityDiffResult` holds 5 `FieldDiffResult` entries. For date comparison: `a.date.year == b.date.year && a.date.month == b.date.month && a.date.day == b.date.day`. For notes: normalize with `(s?.trim().isEmpty ?? true) ?
null : s?.trim()` then compare. In `DuplicateComparisonPanel.build()`, call `DiffComputer.compute(activityA, activityB)` synchronously and pass `isDivergent` flags down to each `FieldRow`. This design keeps the panel stateless — diff computation is O(1) and adds negligible build time.
Testing Requirements
Pure unit tests (no Flutter test runner needed for DiffComputer): test all 5 fields for divergent and non-divergent cases. Test date day-granularity edge case (same day different time = not divergent). Test notes null vs empty equivalence. Test duration integer rounding.
Test that DiffComputer.compute() is referentially transparent (call twice with same inputs, same output). Widget tests: render DuplicateComparisonPanel with a pair where 2 of 5 fields are divergent and assert those FieldRow widgets carry isDivergent=true. Minimum 100% statement coverage on DiffComputer (it is a pure utility).
If the duplicate check RPC fails due to a network error or Supabase outage, the service must decide whether to block submission entirely (safe but disruptive) or allow submission to proceed silently (functional but risks data duplication). An incorrect choice leads to either user frustration or data quality issues.
Mitigation & Contingency
Mitigation: Define an explicit error policy in the service: RPC failures result in a DuplicateCheckResult with status: 'check_failed' and no candidates. The caller treats this as 'allow submission, flag for async review'. Document this as the intended graceful degradation behaviour in the service interface contract.
Contingency: If stakeholders require blocking on RPC failure, expose a configurable `failMode` parameter in the service that can be toggled per organisation via the feature flag system without a code deployment.
The DuplicateComparisonPanel must handle varying activity schemas across organisations (NHF, HLF, Blindeforbundet each have different activity fields). A rigid layout may not accommodate all field variations, causing truncation or missing data in the comparison view.
Mitigation & Contingency
Mitigation: Design the panel to render a dynamic list of key-value pairs rather than a fixed-column layout. Define a `ComparisonField` model that each service populates with only the fields relevant to the activity type and organisation, allowing the panel to adapt without schema knowledge.
Contingency: If dynamic rendering proves too complex within the timeline, ship a simplified panel showing only the five most critical fields (peer mentor, activity type, date, chapter, submitter) and log a follow-up ticket for full field rendering in a later sprint.