🏠 Overview › ✅ Implementation Tasks ›✅ epic-peer-mentor-detail-screen-ui-components-task-001

Implement OrgLabelsProvider Riverpod stream

epic-peer-mentor-detail-screen-ui-components-task-001 — Create the OrgLabelsProvider as a Riverpod StreamProvider that reactively streams org-specific terminology strings from Supabase. Implement the provider with proper async state handling, caching, and error propagation so downstream widgets can consume labels without managing fetch logic themselves.

high priority low complexity frontend pending frontend specialist Tier 0

Acceptance Criteria

OrgLabelsProvider is declared as a Riverpod `StreamProvider<Map<String, String>>` (or typed model) scoped to the current organization ID
Provider subscribes to a Supabase realtime channel or `stream()` query on the org_labels table filtered by the current org ID
When Supabase emits a new row, downstream widgets rebuild automatically without manual refresh
AsyncValue loading, data, and error states are all exposed — no unhandled state is silently swallowed
Provider is declared in a dedicated file `lib/providers/org_labels_provider.dart`
Org ID is derived from an existing auth/session provider, not hardcoded
All label keys returned by the provider are documented in a companion `OrgLabelKeys` constants class
No direct Supabase client calls exist outside this provider for org label data

Technical Requirements

frameworks
Flutter
Riverpod
flutter_riverpod
apis
Supabase Realtime / supabase-flutter stream()
Supabase PostgREST (org_labels table)
data models
OrgLabels (Map<String, String> or typed model)
Organization (org ID reference)
performance requirements
Provider must use Riverpod's `keepAlive` or `autoDispose` appropriately — auto-dispose when no widgets are listening to avoid stale subscriptions
Stream must not emit redundant rebuilds for unchanged data — consider distinctUntilChanged or Supabase's built-in deduplication
security requirements
Row-level security on the org_labels Supabase table must restrict reads to the authenticated org's rows only
Provider must not expose label data from other organizations

Execution Context

Execution Tier
Tier 0

Tier 0 - 440 tasks

Implementation Notes

Use `supabase.from('org_labels').stream(primaryKey: ['id']).eq('org_id', orgId)` as the Supabase stream source. Wrap in a `StreamProvider.family` keyed on org ID so that different org contexts (e.g., multi-org admin) each get their own cached stream. Convert the `List>` stream output to `Map` by reducing the list: `{for (final row in rows) row['key'] as String: row['value'] as String}`. Declare `OrgLabelKeys` as a class with static const String fields (e.g., `static const String peerMentorTitle = 'peer_mentor_title'`) to prevent magic-string bugs across the codebase.

Testing Requirements

Unit test using flutter_test + riverpod's ProviderContainer. Mock the Supabase stream with a StreamController>>. Test: (1) initial loading state is AsyncLoading, (2) emitting a row transitions to AsyncData with correct label map, (3) stream error transitions to AsyncError, (4) provider disposes cleanly when container is disposed. Use `mockito` or manual fakes — do not call real Supabase.

Component
Organization Labels Provider
infrastructure low
Epic Risks (2)
medium impact medium prob dependency

The org labels system may not yet have label keys defined for peer mentor detail screen terminology (role labels, section headings), requiring additions to the label key registry that must be coordinated with the admin configuration team.

Mitigation & Contingency

Mitigation: Audit existing label keys in the terminology system before starting OrgLabelsProvider integration. Submit required new label keys for admin configuration in parallel with component implementation.

Contingency: If label keys are not available at integration time, use hardcoded English fallbacks with a clear TODO for admin configuration, ensuring the widget renders correctly while keys are being provisioned.

high impact low prob technical

The design token semantic colors (warning, error surface) may not meet WCAG 2.2 AA 4.5:1 contrast ratio when rendered on the app's background surface tokens, requiring design system changes that affect the entire app.

Mitigation & Contingency

Mitigation: Run contrast ratio validation on the token palette during Epic 1 design token implementation. Flag any failing pairs to the design system owner before building UI components that depend on them.

Contingency: If tokens fail contrast requirements, define supplementary high-contrast override tokens specific to alert and badge contexts that meet AA without modifying the global palette.

Quick Links
All Tasks Execution Plan