Integration verification: Tier 2 components ready for Epic 3 consumption
epic-mileage-reimbursement-entry-data-layer-task-010 — Run an integration smoke test confirming all three Tier 2 components are wired correctly end-to-end against a Supabase test instance. Verify OrgRateConfigRepository Stream emits a valid rate on startup, MileageClaimRepository insert and fetchByUser round-trip succeeds, and DistancePrefillService correctly returns null then the saved distance after write. Document the provider graph and dependency map so the Epic 3 MileageClaimService developer can consume these components without additional setup.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 4 - 323 tasks
Can start after Tier 3 completes
Implementation Notes
This is a verification and documentation task, not new feature development. Focus on writing the smallest possible tests that prove each contract holds. Use Riverpod's ProviderContainer in tests rather than a full widget tree — this keeps tests fast and isolated. The dependency map should be a simple Markdown or inline comment block listing: provider name → provider type → dependencies → required overrides.
Avoid over-engineering the documentation; the goal is to unblock the Epic 3 developer with a 5-minute read. If any Tier 2 component fails its smoke test, file a blocking bug immediately rather than working around it in the test.
Testing Requirements
Write integration tests using flutter_test with a real Supabase test instance (not mocks). Cover: (1) OrgRateConfigRepository stream emission test asserting first value is a valid OrgConfiguration with rate > 0; (2) MileageClaimRepository round-trip test asserting inserted record matches fetched record field-by-field; (3) DistancePrefillService null-then-value test asserting correct state transitions. Each test must set up and tear down its own Supabase rows to avoid cross-test contamination. Use addTearDown() to clean inserted rows.
Target 100% coverage of the three public interfaces being verified.
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.