Scenario Rule Repository
Component Detail
Description
Data access layer for reading and persisting scenario rule definitions and chapter-level configuration. Rules are stored as JSON in Supabase and include trigger type, delay days, metadata conditions, and prompt text templates. Supports optimistic local caching to reduce latency.
scenario-rule-repository
Summaries
The Scenario Rule Repository is the configuration backbone of the intelligent prompting system, enabling chapter administrators to define and customize which relationship scenarios trigger follow-up suggestions for their members. By persisting rules in Supabase with local caching, it ensures that prompt behavior remains responsive even in low-connectivity environments, protecting member engagement quality. This component directly supports the competitive differentiator of configurable, organization-specific engagement automation — allowing chapters to tailor the system to their unique membership relationship patterns without requiring developer intervention, reducing operational dependency on technical staff and accelerating chapter self-sufficiency.
Medium complexity component spanning both backend (Supabase) and mobile execution contexts, requiring coordination between the Flutter mobile team and the backend/database team. The insertDefaultRules function must be triggered during chapter onboarding, creating a scheduling dependency on the onboarding flow that requires cross-team alignment. The watchRulesForChapter streaming interface adds testing surface for real-time update propagation and cache consistency under concurrent write scenarios. Local cache invalidation logic requires dedicated edge-case testing.
Plan for integration testing between this repository and the Scenario Evaluation Edge Function before end-to-end scenario testing can begin, as rule availability is a prerequisite for any evaluation run.
Interfaces with Supabase via the supabase-flutter client using both one-shot futures (getRulesForChapter, updateRuleEnabled, getRuleById) and real-time streams (watchRulesForChapter via Postgres Realtime). ScenarioRule objects are deserialized from JSONB columns using fromJson factories. Optimistic local caching should use a Riverpod StateNotifier or in-memory map keyed by chapterId, invalidated on updateRuleEnabled calls to maintain consistency. insertDefaultRules must be idempotent — check for existing rules before inserting to support safe re-invocation during onboarding retries.
getRuleById should perform a secondary local cache lookup before hitting the network to avoid redundant Supabase reads during scheduler evaluation loops that call rules repeatedly per activity.
Responsibilities
- Fetch all scenario rules for a given chapter from Supabase
- Persist updated enable/disable state for a scenario rule
- Cache rule definitions locally for offline reads
- Insert default rule set for newly onboarded chapters
Interfaces
getRulesForChapter(String chapterId): Future<List<ScenarioRule>>
updateRuleEnabled(String chapterId, String ruleId, bool enabled): Future<void>
insertDefaultRules(String chapterId): Future<void>
watchRulesForChapter(String chapterId): Stream<List<ScenarioRule>>
getRuleById(String ruleId): Future<ScenarioRule?>
Relationships
Dependents (3)
Components that depend on this component
Related Data Entities (1)
Data entities managed by this component