Define OrgRateConfig domain model and interfaces
epic-mileage-reimbursement-entry-data-layer-task-001 — Create the OrgRateConfig domain model class with fields for per-km rate and auto-approval threshold. Define the abstract repository interface with Stream-based reactive access pattern. Establish Dart typedefs and sealed result types for config fetch outcomes.
Acceptance Criteria
Technical Requirements
Implementation Notes
Use Dart's `sealed class` (available since Dart 3.0) for OrgRateConfigResult to get exhaustive pattern matching: `sealed class OrgRateConfigResult {}` with `final class OrgRateConfigLoaded extends OrgRateConfigResult { final OrgRateConfig config; ... }` and `final class OrgRateConfigError extends OrgRateConfigResult { final Object error; ... }`. This enables callers to use `switch (result) { case OrgRateConfigLoaded(:final config) => ..., case OrgRateConfigError(:final error) => ...
}` with compile-time exhaustiveness. For OrgRateConfig itself, consider using `package:freezed` if the project already uses it for other models — this auto-generates copyWith, ==, and hashCode. If not using freezed, implement them manually following the standard pattern. Keep this file strictly in the domain layer with no external package dependencies beyond Dart core.
Testing Requirements
Write pure unit tests for OrgRateConfig value equality: (1) two instances with same field values are equal via ==, (2) copyWith() returns a new instance with the changed field and all other fields preserved, (3) hashCode is consistent across two equal instances. No async or I/O required. Tests should live in test/domain/mileage/org_rate_config_test.dart. Also verify that a mock implementation of OrgRateConfigRepository compiles against the interface, confirming the interface contract is correct.
If OrgRateConfigRepository caches the per-km rate aggressively and an admin updates the rate mid-session, ongoing form interactions will show the old rate until the Stream emits. This could result in the UI showing a rate that differs from what is stored when the claim is submitted, causing confusion or disputes.
Mitigation & Contingency
Mitigation: Subscribe to a Supabase Realtime channel for the org_configuration table so config changes propagate within seconds. Document the eventual-consistency window in code comments.
Contingency: If Realtime subscription proves unreliable in test, add a polling fallback with a configurable interval (default 5 minutes) and display a 'rate updated' toast when the stream emits a changed value.
The correction window within which a claim can be deleted or voided is not explicitly specified in the feature documentation. Implementing the wrong window (e.g. 24 hours vs 7 days) could lock users out of corrections or allow inappropriate post-approval modifications.
Mitigation & Contingency
Mitigation: Raise the correction window definition as a blocking question to the HLF product owner before implementing the delete/void path in MileageClaimRepository. Implement the window duration as an org-level configuration value rather than a hardcoded constant.
Contingency: If the question cannot be resolved before implementation, default to 24 hours as the most conservative option and flag the value for review in the first user-acceptance test.