Adaptive Layout

Adapt to the space you are given, never to the device you think you are on. A phone in a foldable's front display, a resized desktop window, and a tablet in split-screen all defeat Platform.isX checks — but they all report their real constraints. Branch on width, not hardware.

Read the reference for the task at hand:

• references/window-size-classes.md — the Material 3 window size-class breakpoints as a shared vocabulary, the WindowSizeClass enum pattern, MediaQuery.sizeOf/paddingOf/viewInsetsOf vs .of, readable max-width, SafeArea and display cutouts, keyboard insets, orientation, foldable hinge awareness.
• references/list-detail-and-navigation.md — single-pane-navigate vs side-by-side two-pane, choosing the navigation affordance by width and coordinating with the go_router shell, keeping selection state in a Notifier so both panes agree.

Run scripts/check_adaptive.sh before a PR.

Non-negotiable rules

1. Adapt by constraints/size, never by device or platform. No Platform.isAndroid/Platform.isIOS/kIsWeb to pick a layout. Use LayoutBuilder (local box constraints) or MediaQuery.sizeOf(context) (window size). WHY: a resized window, split-screen, and foldable all break device checks; constraints are always true.

2. Use the Material 3 window size classes as the breakpoint vocabulary. Compact <600, medium 600–840, expanded 840–1200, large 1200–1600, extra-large ≥1600 (logical px width). WHY: these are STANDARD structural breakpoints (not design tokens); one shared enum keeps every screen's breakpoints identical.

3. Read the narrowest MediaQuery aspect: sizeOf / paddingOf / viewInsetsOf / viewPaddingOf, not MediaQuery.of(context). WHY: .of subscribes the widget to EVERY MediaQuery change (keyboard, rotation, text scale); the aspect getters rebuild only when that one field changes — see flutter-performance.