Scaffold OrgSelectionScreen layout and routing
epic-organization-selection-and-onboarding-ui-task-001 — Create the full-screen OrgSelectionScreen widget with a responsive scrollable layout, placeholder slots for the org list, onboarding progress indicator, loading overlay, and error state container. Wire the screen into the app router so it renders when no tenant context exists. Ensure the screen meets minimum 44×44dp touch target sizing and passes basic contrast checks from the outset.
Acceptance Criteria
Technical Requirements
Implementation Notes
Use GoRouter's redirect parameter at the root route level: if (ref.read(tenantContextProvider) == null) return '/org-selection'. The OrgSelectionScreen itself should be a ConsumerWidget (Riverpod) or BlocBuilder (BLoC) that reads loading/error state from the appropriate provider. For layout: use a Column inside SingleChildScrollView with: (1) top padding, (2) OnboardingProgressIndicator slot, (3) Expanded/Flexible org list slot, (4) bottom padding. The LoadingOverlay should use Stack with a full-screen semi-transparent Container + CircularProgressIndicator, shown only when isLoading=true.
Use SafeArea to respect notches and home indicators. Keep the screen as a thin shell — all business logic belongs in the BLoC/provider layer.
Testing Requirements
Widget tests for the scaffold layout: verify Scaffold is present, verify placeholder slots render, verify loading overlay visibility toggles, verify error container shows message. Router test: use GoRouter.of(context) to verify the redirect rule fires when TenantContext is null in the provider. Use ProviderScope/BlocProvider overrides to control state during tests. Minimum 5 widget tests.
Run flutter analyze after implementation.
OrgSelectionScreen and OrgContextSwitcher render partner-specific logos, colors, and text from dynamic data. Golden tests (pixel-comparison screenshots) will fail whenever branding assets are updated in the backend, causing CI failures that block unrelated PRs and eroding developer trust in the test suite.
Mitigation & Contingency
Mitigation: Use fixture-based golden tests with static mock Organization models containing embedded test assets rather than network-fetched assets. Separate branding asset acceptance tests into a dedicated CI job that only runs on branding-related PRs and is maintained by the design team.
Contingency: If golden test maintenance overhead becomes excessive, replace pixel-comparison goldens with semantic widget tests that assert widget tree structure and key property values, reserving golden tests for only the most stable, design-critical elements.
Several partner organizations (especially Blindeforbundet) have users who rely entirely on VoiceOver or TalkBack. Complex branded card layouts with overlaid logos, names, and selection states are notoriously difficult to make fully accessible; missing semantics or incorrect focus order could make the selection screen completely unusable for screen reader users before launch.
Mitigation & Contingency
Mitigation: Involve an accessibility specialist in the design review before any widget implementation begins. Use Flutter's Semantics widget with explicit label, hint, and button role on OrgCardWidget. Conduct manual screen reader testing on both iOS (VoiceOver) and Android (TalkBack) for every sprint that touches these screens, not just before release.
Contingency: If full WCAG compliance cannot be achieved within the sprint, implement a simplified text-list fallback mode that activates when the system detects an active screen reader, presenting orgs as plain accessible list tiles instead of the branded card layout.