Implement BenefitMultiplierConfigRepository
epic-benefit-calculator-foundation-task-003 — Build the BenefitMultiplierConfigRepository that fetches organisation-specific multiplier values from a Supabase table (benefit_multiplier_config) filtered by organisationId. Implement a local SharedPreferences/Hive cache layer so the last-fetched config is available offline. Cache TTL should be 24 hours with a force-refresh option. Return a BenefitMultiplierConfig model on success, and the cached value (or a documented fallback) when offline.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 1 - 540 tasks
Can start after Tier 0 completes
Implementation Notes
Define abstract class IBenefitMultiplierConfigRepository with the getConfig signature, then implement BenefitMultiplierConfigRepository. Inject both the Supabase client and the cache provider via constructor for testability. For cache TTL, store a cached_at ISO-8601 string alongside the serialized config JSON in SharedPreferences using a key like 'bmc_{organisationId}'. On read, parse the timestamp and compare with DateTime.now() — if difference exceeds 24 hours, treat as stale.
For the offline detection, wrap the Supabase call in try/catch and check for SocketException or PostgrestException with status 0 to distinguish network errors from Supabase data errors. Use Hive over SharedPreferences if the project already uses Hive for other caches (check existing dependencies). Register the repository in the dependency injection layer (Riverpod provider or service locator).
Testing Requirements
Unit tests using flutter_test and mocktail. Mock both the Supabase client and the cache storage layer (SharedPreferences or Hive). Test file: test/repositories/benefit_multiplier_config_repository_test.dart. Scenarios: (1) first call fetches from Supabase and writes cache, (2) second call within TTL reads from cache only, (3) forceRefresh bypasses cache, (4) offline with valid cache returns cached value, (5) offline with empty cache returns defaults and throws/signals ConfigUnavailableException, (6) organisationId namespacing verified in cache key.
Integration test (optional, network): verify correct Supabase row is returned for a known test organisation.
Supabase organisation configuration table may not yet have the five multiplier columns, requiring a migration. If the migration is not coordinated with other teams touching the same table, schema conflicts could delay delivery.
Mitigation & Contingency
Mitigation: Add multiplier columns in a dedicated, non-destructive ALTER TABLE migration script. Review the organisation config table schema with the backend team before writing the migration. Use nullable columns with defaults so existing rows are unaffected.
Contingency: If the migration cannot be deployed in time, stub the repository to return hardcoded default multiplier values from a local config file, allowing parallel development. Swap in the real Supabase fetch once the migration is live.
The ActivitySummaryAggregator depends on activity records already persisted in the database. For newly onboarded peer mentors with no activity history, the aggregator will return zero counts, which could make the calculator appear broken on first use.
Mitigation & Contingency
Mitigation: Design the pre-fill value object to distinguish between 'no data yet' and 'zero activities'. The calculator input panel should display empty inputs (not zero) when no history exists, with placeholder text guiding the user to enter values manually.
Contingency: If the distinction cannot be surfaced cleanly in the UI timeline, fall back to always showing empty inputs and document the manual-entry path as the primary UX until activity data accumulates.