用途：帮助在 Flutter 项目中实现从窄移动窗口到宽桌面/Web 布局的自适应界面，用于构建、修复、审查与验证。核心原则是依据可用约束而非平台标签决策，优先保证触摸可用，再显式分支鼠标、键盘与平台行为。遵循“约束向下传递、尺寸向上汇报、父级决定位置”。默认断点：紧凑 width < 600，中等 600 <= width < 840，扩展 width >= 840。
工作流：先明确用户流程、目标形态、支持平台与代价高的失败模式（溢出、内容过宽难读、状态丢失、键盘流程不可用、平台行为错误）。改动布局前先检查现有组件，找导航、对话框、列表、网格、固定宽高、方向判断、Platform.* 布局判断及自定义输入/焦点处理。分支前先抽象共享数据，例如让 NavigationBar 与 NavigationRail 共用一个目标模型。
测量方式：页面级窗口决策用 MediaQuery.sizeOf(context)，依赖父级约束的分支用 LayoutBuilder。按断点或能力而非设备类型分支；空间变化用紧凑/中等/扩展布局，能力与策略用 Capability、Policy 对象。实现能保留状态的最小自适应改动，保持滚动位置、选中目标、表单输入与焦点在缩放、旋转、折叠后稳定。
验证：至少检查紧凑与扩展宽度，若有独立平板布局再加中等宽度。改动后运行 flutter analyze，涉及布局分支、导航状态、焦点或策略/能力变更时运行相关组件测试，确认无新增溢出条纹、文字裁剪、选中状态或滚动位置丢失、键盘遍历中断。无法验证时须报告阻碍与风险，不能未经宽度检查或分析就称已验证。
限制：不要用 Platform.isIOS、Platform.isAndroid、设备名或 OrientationBuilder 做布局决策；不要让大屏内容无最大宽度或多列布局地拉伸；Capability 表示能做什么，Policy 表示应展示或允许什么。参考中的 Dart 片段除非特别说明否则仅作解释，assets 中的起始代码需在目标项目通过分析后再使用。若上下文不足以确定最终布局，先实现最小可逆抽象，仅向用户询问无法从应用推断的产品决策。