Implement OrgSelectionService — trigger labels and config init
epic-organization-selection-service-labels-task-006 — After a successful selectOrganization call, trigger initialization of OrgLabelsProvider and any organization-specific configuration (feature flags, branding tokens). Implement the post-selection initialization sequence so downstream providers are ready before the app navigates away from the selection screen. Use Riverpod provider invalidation to force label refresh.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 4 - 323 tasks
Can start after Tier 3 completes
Implementation Notes
The key challenge here is coordinating async initialization across multiple Riverpod providers without race conditions. The recommended pattern: in selectOrganization(), after persisting the org ID, call ref.invalidate(orgLabelProvider) and ref.invalidate(orgConfigProvider), then immediately await ref.read(orgLabelProvider.future) and ref.read(orgConfigProvider.future) to ensure both have settled before returning. This 'invalidate then await future' pattern is idiomatic Riverpod and prevents the navigation layer from proceeding before providers are ready. Do NOT use artificial delays or timers.
For branding tokens, apply design token overrides to a top-level ThemeData provider so the entire widget tree rebuilds with the new org's palette atomically.
Testing Requirements
Use flutter_test with Riverpod's ProviderContainer. Test cases: (1) after selectOrganization(), OrgLabelsProvider is in data state (not loading), (2) provider invalidation is called exactly once per new org selection, (3) re-selecting the same org does not trigger invalidation, (4) failure during label init causes selectOrganization() to throw and does not persist the org ID, (5) branding tokens are applied to the correct provider after selection. Mock all downstream providers and verify call order.
The OrgLabelsProvider must be fully initialized before any UI widget renders organization-specific text. If the service triggers label initialization asynchronously and the UI builds before the labels stream emits, widgets will briefly display raw label keys instead of human-readable text, which constitutes a WCAG 2.2 AA failure for screen readers that announce whatever text is present at render time.
Mitigation & Contingency
Mitigation: Design the OrgSelectionService.select() method to await OrgLabelsProvider initialization before completing its Future — callers receive a resolved future only after labels are ready. Use an AsyncValue loading state to gate UI rendering via Riverpod's when() pattern.
Contingency: If awaiting initialization causes perceivable UI lag, implement an optimistic render with a skeleton loading state that is announced by the live-region-announcer as 'Loading organization content' so screen readers do not announce raw keys.
If the label definitions loaded from the backend for each organization do not match the label key registry used in the UI, widgets will fall back to raw keys silently. This is particularly harmful for Blindeforbundet users relying on VoiceOver, where a raw key announced by a screen reader is incomprehensible.
Mitigation & Contingency
Mitigation: Define a compile-time label key registry (enum or const strings) and assert at OrgLabelsProvider initialization that all required keys are present in the loaded map. Log a structured warning for any missing key and substitute a human-readable fallback string rather than the raw key.
Contingency: If a label schema mismatch reaches production, the OrgLabelsProvider fallback mechanism ensures users see a reasonable English default rather than a raw key. A backend label patch can be deployed without an app release.