critical priority low complexity infrastructure pending backend specialist Tier 4

Acceptance Criteria

A Provider<OrgPersistenceRepository> (or equivalent Riverpod provider) named orgPersistenceRepositoryProvider is defined in the infrastructure providers file
The provider's return type is the abstract OrgPersistenceRepository interface, not the concrete LocalOrgPersistenceRepository
The provider reads the localStorageAdapterProvider to inject the adapter dependency
The provider is a simple Provider (not StateProvider/FutureProvider) since the repository itself is stateless
The provider is listed with a one-line doc comment in the provider barrel file
No other file instantiates LocalOrgPersistenceRepository directly — all access goes through this provider
Dart analyzer reports zero errors; flutter test passes with no provider-related errors

Technical Requirements

frameworks
Flutter
Riverpod
Dart
data models
Organization
performance requirements
Provider should be created once and reused — use Provider (not Provider.autoDispose) for a long-lived repository
security requirements
Provider must not be overridden in production code — overrides are allowed only in test ProviderScope

Execution Context

Execution Tier
Tier 4

Tier 4 - 323 tasks

Can start after Tier 3 completes

Implementation Notes

File location: lib/infrastructure/providers/org_persistence_providers.dart (or add to existing infrastructure providers barrel). Use Riverpod codegen (riverpod_annotation) if the project already uses it for consistency, otherwise use the manual Provider syntax: final orgPersistenceRepositoryProvider = Provider((ref) => LocalOrgPersistenceRepository(ref.watch(localStorageAdapterProvider)));. Returning the abstract type is the key design constraint — it enables test overrides and future adapter swaps (e.g., migrating to secure storage) without touching any consumer.

Testing Requirements

Verify in widget tests by overriding orgPersistenceRepositoryProvider with a mock implementation inside a ProviderScope and confirming that BLoC/use case consumers receive the mock. No standalone unit test needed for the provider declaration itself, but it must be exercised in at least one integration or widget test as part of the broader organization selection flow.

Epic Risks (2)
medium impact medium prob technical

SharedPreferences behaves differently on iOS (NSUserDefaults) vs Android (SharedPreferences) for edge cases such as first-launch cold reads, storage quota exceeded, or process kill mid-write. If the adapter does not account for these differences, the persistence layer can silently return null on one platform while returning a stale value on the other, causing incorrect routing decisions downstream.

Mitigation & Contingency

Mitigation: Write platform-specific integration tests using flutter_test device runners for both iOS and Android. Document known platform delta in the adapter's inline comments and encode defensive fallback for null returns at the repository boundary.

Contingency: If platform delta causes persistent issues, replace SharedPreferences with flutter_secure_storage for this key — the LocalStorageAdapter abstraction makes this a single-file swap with no impact on the repository or service layer.

high impact low prob dependency

The shared_preferences Flutter plugin may have a version conflict with other plugins already in the project pubspec.yaml. A conflict discovered late in the epic blocks all downstream epics.

Mitigation & Contingency

Mitigation: Resolve and pin the shared_preferences version in pubspec.yaml as the very first task of this epic before writing any implementation code. Run flutter pub get and resolve any version conflicts immediately.

Contingency: If version pinning is impossible due to transitive conflicts, implement LocalStorageAdapter using path_provider + dart:io for JSON file storage as an alternative — the interface contract remains unchanged.