Define ReadReceiptService state models and provider scaffold
epic-contact-detail-and-edit-service-layer-task-009 — Create the typed state classes (ReadReceiptIdle, ReadReceiptWriting, ReadReceiptConfirmed, ReadReceiptError) and the Riverpod provider or BLoC skeleton for read-receipt-service. Inject the field-encryption-utils dependency and define the public method signature for recording a field reveal event.
Acceptance Criteria
Technical Requirements
Implementation Notes
Use a sealed class hierarchy for ReadReceiptState in Dart 3+ (sealed class ReadReceiptState {}). This enables exhaustive pattern matching in the UI without a default branch. Define the family provider as: final readReceiptServiceProvider = StateNotifierProvider.family
The fieldKey in ReadReceiptConfirmed should be a non-nullable String matching the key used in the encrypted fields schema. Follow the same state naming convention as ContactEditService and ContactDetailService for consistency across the codebase.
Testing Requirements
Write unit tests verifying: (1) ReadReceiptService initializes in ReadReceiptIdle state, (2) ReadReceiptConfirmed.fieldKey returns the correct value passed at construction, (3) ReadReceiptError.userMessage is non-null, (4) the provider family returns distinct instances for different contactId keys, (5) FieldEncryptionUtils can be swapped for a mock via constructor injection. No Supabase interaction is tested at this stage.
Parallel fetching of profile, activity history, and assignment status from contact-detail-service may produce race conditions where partial state is emitted to the UI before all fetches complete, resulting in flickering or incorrect loading indicators.
Mitigation & Contingency
Mitigation: Use Future.wait or a single composed BLoC event that only emits a loaded state once all three futures resolve. Define a strict state machine: initial → loading → loaded/error with no intermediate partial-loaded states emitted to the UI.
Contingency: If parallelism proves unreliable in testing, fall back to sequential fetching with a combined loading indicator. The 500ms target may need to be renegotiated with stakeholders if sequential fetching exceeds it on slow connections.
The partial-field update pattern in contact-edit-service assumes the contact record has not changed between when the edit screen was loaded and when the save is submitted. Concurrent edits by another coordinator could cause the earlier editor's save to silently overwrite the later one.
Mitigation & Contingency
Mitigation: Include an updated_at timestamp in the PATCH request and configure Supabase to reject updates where the server-side timestamp differs from the client's version. Return a 409-equivalent error that the service maps to a user-readable conflict message.
Contingency: If optimistic locking is too complex for initial delivery, implement a simple 'reload and retry' flow: on save error, reload the contact detail and prompt the coordinator to re-apply their changes manually.