Register Riverpod providers for data layer

epic-scenario-based-follow-up-prompts-foundation-task-010 — Create Riverpod providers (using riverpod) that expose ScenarioRuleRepository, PromptHistoryRepository, and PushNotificationDispatcher to the rest of the application. Wire them with correct scoping — chapter-scoped providers should invalidate when the active chapter changes via the existing active-chapter-state provider. Export a barrel file so dependent components (rule engine, scheduler, configuration manager) can import a single path.

high priority low complexity backend pending backend specialist Tier 5

Acceptance Criteria

scenarioRuleRepositoryProvider is defined and returns a ScenarioRuleRepository instance scoped to the active chapter

promptHistoryRepositoryProvider is defined and returns a PromptHistoryRepository instance

pushNotificationDispatcherProvider is defined and returns a PushNotificationDispatcher instance

All three providers are invalidated (or re-created) automatically when the active chapter changes via the existing active-chapter-state provider

A barrel file (lib/features/scenario_prompts/data/providers.dart or equivalent) exports all three providers under a single import path

Dependent components (rule engine, scheduler, configuration manager) can resolve providers using only the barrel import

Provider definitions use Riverpod code generation annotations (@riverpod) if the project already uses riverpod_generator — otherwise use plain Provider/StateNotifierProvider consistently with existing patterns

No circular provider dependencies — dependency graph is acyclic

Provider file includes a brief comment on each provider explaining its scope and invalidation trigger

Unit test verifies that after changing the active chapter, a new ScenarioRuleRepository instance is returned (old instance is not reused)

Technical Requirements

frameworks

Flutter

Riverpod

Supabase Flutter SDK

performance requirements

Provider creation must be lazy — repositories are not instantiated until first read

Chapter change invalidation must complete synchronously within the same frame

security requirements

Providers must not expose the Supabase service role key — only the anon/user-scoped client

Chapter-scoped invalidation ensures no cross-chapter data leakage between provider re-reads

Execution Context

Execution Tier

Tier 5

Tier 5 - 253 tasks

Can start after Tier 4 completes

View Full Execution Plan

Implementation Notes

Follow the existing Riverpod provider patterns in the project. Use ref.watch(activeChapterStateProvider) inside the scenarioRuleRepositoryProvider factory so that when the chapter state changes, the provider is automatically invalidated and rebuilt. If using riverpod_generator, annotate with @Riverpod(keepAlive: false) to allow disposal on chapter change. The barrel file pattern (providers.dart re-exporting all provider symbols) is important for maintaining a clean import graph — downstream consumers should never import individual repository provider files directly.

Keep provider definitions thin — no business logic in the provider factory, only wiring of dependencies from other providers.

Testing Requirements

Unit tests using flutter_test with a ProviderContainer. Test: (1) scenarioRuleRepositoryProvider resolves without error, (2) after simulating an active-chapter change, the provider returns a fresh instance (verify via identity check or a mock factory call count), (3) barrel file exports are all accessible from a single import in a test file. Use overrideWithValue on dependent providers to isolate the chapter-state simulation. No widget tests needed for this task.

Component

Scenario Rule Repository

data medium

Dependencies (3)

Extend ScenarioRuleRepository with an offline-capable caching layer using flutter_secure_storage or Hive so the mobile client can read rule configuration without a live network connection. Implement a cache-first strategy: return cached rules immediately and refresh from Supabase in the background. Include cache invalidation when chapter context changes and a TTL of 24 hours. epic-scenario-based-follow-up-prompts-foundation-task-006 Implement the PromptHistoryRepository Dart class that reads and writes to the follow_up_notification_log Supabase table. Expose methods: hasBeenDelivered(idempotencyKey) for deduplication checks, recordDelivery(PromptDeliveryRecord), getDeliveryHistoryForMentor(mentorId, chapterId), and getDeliveryHistoryForChapter(chapterId). Include the PromptDeliveryRecord typed model with fromJson/toJson. epic-scenario-based-follow-up-prompts-foundation-task-007 Implement the PushNotificationDispatcher infrastructure class that sends push notifications via both FCM (Android) and APNs (iOS). Integrate with the existing FCM token manager to resolve device tokens by peer_mentor_id. Expose a dispatch(NotificationPayload payload) method accepting title, body, data map, and target mentor ID. Handle token refresh, invalid token removal, and delivery failure logging. Use the Supabase edge function as the secure server-side sender to avoid embedding FCM credentials in the client. epic-scenario-based-follow-up-prompts-foundation-task-008

Epic Risks (2)

high impact medium prob security

Supabase RLS policies for chapter-scoped rule access may interact unexpectedly with service-role keys used by the Edge Function, potentially blocking backend reads or leaking cross-chapter data.

Mitigation & Contingency

Mitigation: Write and review RLS policies in isolation with automated policy tests before merging; define a dedicated service-role bypass policy scoped to the edge function's Postgres role.

Contingency: If RLS blocks the edge function, temporarily use a bypass policy with audit logging while a permanent fix is implemented; escalate to a Supabase security review.

medium impact high prob integration

FCM device tokens become invalid when users reinstall the app or revoke permissions; stale tokens cause silent delivery failures that are hard to detect without explicit error handling.

Mitigation & Contingency

Mitigation: Implement token invalidation handling in PushNotificationDispatcher that removes stale tokens from the database on FCM 404/410 responses; log all delivery failures with structured output.

Contingency: If token hygiene proves unreliable, add a periodic token refresh job that re-registers all active users' tokens via the FCM registration endpoint.

Quick Links

All Tasks Execution Plan