high priority medium complexity frontend pending frontend specialist Tier 5

Acceptance Criteria

At viewport width > 900px (design token breakpoint: breakpointWide), the layout renders a fixed left sidebar (min 240px) containing the OrgHierarchyNavigator alongside a scrollable main content area for governance panels
At viewport width ≤ 900px, the layout collapses the sidebar into a navigation drawer accessible via a hamburger menu, matching the existing mobile bottom-nav/drawer pattern
The left rail sidebar is always visible on wide screens without requiring user interaction — it does not hide or auto-collapse
Tab navigation on wide screens moves from a bottom tab bar to a vertical left-rail navigation list consistent with admin portal conventions
All governance panels (KPI grid, Activity Log, Certifications, Export, Role Assignment) reflow correctly at wide-screen widths using responsive grid layouts (e.g., 2–3 column grid for KPI cards)
Breakpoint detection uses the design token value and is implemented via LayoutBuilder or MediaQuery, never hardcoded pixel values
No horizontal overflow or clipped content on any panel at 1280px, 1440px, or 1920px viewport widths
The responsive layout does not require a rebuild of AdminPortalBloc — layout is purely a widget-level concern
WCAG 2.2 AA compliance is maintained at both mobile and wide-screen breakpoints (contrast, touch targets, keyboard focus)
Keyboard navigation works correctly in the sidebar layout: Tab key cycles through sidebar items before entering main content area

Technical Requirements

frameworks
Flutter
Flutter Web
BLoC (flutter_bloc)
data models
BreakpointTokens (design token constants for responsive widths)
AdminLayoutMode (enum: mobile, wide)
performance requirements
Layout recalculation on window resize must not cause frame drops; use LayoutBuilder with const breakpoint thresholds
Sidebar must use a RepaintBoundary to isolate its repaint from the main content area
Wide-screen KPI grid must render in a 2–3 column Wrap or GridView, not a single-column list
security requirements
Responsive layout changes must not alter data access scope or bypass role-based visibility rules applied in task-015
Sidebar navigation items must be conditionally rendered based on the same role checks as the tab bar
ui components
AdminResponsiveLayout (LayoutBuilder wrapper selecting mobile or wide layout)
AdminWideSidebarLayout (sidebar + content area for breakpointWide)
AdminMobileLayout (drawer + bottom nav for narrow viewports)
AdminSidebarNav (vertical nav list for wide layout)
AdminNavDrawer (drawer variant for mobile layout)

Execution Context

Execution Tier
Tier 5

Tier 5 - 253 tasks

Can start after Tier 4 completes

Implementation Notes

Centralise all breakpoint values in a BreakpointTokens class sourced from the design token system — never hardcode 900 in widget files. Use LayoutBuilder at the AdminDashboardScreen level to determine AdminLayoutMode and pass it down via an InheritedWidget or a simple Riverpod provider if the design system uses one, so all child widgets can react to layout mode without redundant LayoutBuilder instances. For the wide layout, the sidebar should be a fixed-width Column inside a Row, with the content area in an Expanded child. The existing StatefulShellRoute navigation can be reused by mapping route branches to sidebar items on wide screens.

Ensure the OrgHierarchyNavigator's own scrollable tree does not conflict with the sidebar's scroll — wrap it in a separate SingleChildScrollView within the sidebar column. HLF's admin portal must work well on their Dynamics coordination workflow which is likely used on desktop browsers, making this web layout particularly important for that organisation's admins.

Testing Requirements

Write widget tests using flutter_test: (1) AdminResponsiveLayout renders AdminWideSidebarLayout at width > 900px; (2) renders AdminMobileLayout at width ≤ 900px; (3) sidebar is visible and non-collapsible on wide layout; (4) drawer is hidden by default and opens on hamburger tap on mobile layout; (5) all governance panels are accessible in both layouts without horizontal overflow. Use tester.binding.window.physicalSizeTestValue to simulate wide vs narrow viewports in tests. Add golden tests at 375px (mobile), 768px (tablet), and 1440px (desktop) widths for the full AdminDashboardScreen to catch layout regressions across breakpoints.

Component
Admin Dashboard Screen
ui high
Epic Risks (3)
high impact medium prob technical

If org node selection in AdminStateBLoC does not correctly propagate to all dependent data streams (statistics, activity log, user list, certification panel), some panels may show data from the previously selected org scope, creating a confusing and potentially dangerous mixed-scope view.

Mitigation & Contingency

Mitigation: Model org node selection as a single source of truth in AdminStateBLoC. All downstream providers derive their query parameters from this single stream via Riverpod's watch pattern. Write integration tests that verify every data stream emits a reload event when the selected node changes.

Contingency: If scope propagation bugs are detected in QA, add an explicit full-state reset on org node change (clear all cached data and refetch from scratch) as a safe but less efficient fallback until the targeted propagation is fixed.

medium impact medium prob technical

The Admin Dashboard Screen must adapt its layout for Flutter Web (wider viewports, mouse interaction, larger grid) and mobile embedding. Flutter Web responsive layout support has historically required non-trivial workarounds, and the adaptive grid may introduce significant additional development time.

Mitigation & Contingency

Mitigation: Define breakpoints and grid behaviour in the design system before implementation. Use LayoutBuilder with explicit breakpoint constants rather than MediaQuery scattered across widgets. Prototype the web layout with a skeleton screen before implementing live data binding.

Contingency: If web layout proves intractable within sprint, deliver a mobile-first layout for all platforms initially and track a dedicated web-optimisation task for the next sprint.

high impact low prob security

A bug in the Role Assignment Panel's permission scope validation could allow an org_admin to assign roles beyond their authority (e.g., assigning super_admin to a user), representing a serious privilege escalation vulnerability.

Mitigation & Contingency

Mitigation: Enforce role assignment scope on both the client (disable unavailable roles in the panel UI) and the server (UserManagementService validates the target role is within the admin's permitted scope before persisting). Write security-focused tests that attempt out-of-scope role assignments and assert rejection.

Contingency: If an escalation vulnerability is discovered, immediately disable the role assignment panel via feature flag, revoke any incorrectly assigned roles, and deploy a server-side fix before re-enabling.