flutter-architecture

用途：在编写任何功能代码前，为 Flutter 应用确定技术架构，包括项目结构、状态管理、路由和依赖栈。工作流：先收集上下文（读取 docs/product/app_brief.md，如存在；询问应用规模、团队规模与 Flutter 经验、离线需求、后端类型、发布时间线、目标平台），再推荐架构模式，设计目录结构，选择状态管理，定义路由策略与依赖栈，产出架构决策记录（ADR），并在实现前取得用户对方案的批准。核心原则：活跃项目保留既有架构，只提建议，未经明确批准不实施变更。架构模式规则：小型应用（1-2 开发者、状态简单）用分层优先、ChangeNotifier + ListenableBuilder；中型产品用功能优先、Clean Architecture、Riverpod；大型多团队用功能优先、Clean Architecture、Riverpod 或 Bloc、Melos monorepo；既有 Bloc 代码库保留 Bloc，可在合适处建议 Cubit；团队 Bloc 经验强则不论规模用 Bloc/Cubit。新中型以上应用默认推荐：功能优先结构 + Riverpod、GoRouter、Freezed、Dio、flutter_secure_storage。功能优先目录为 lib/app（MaterialApp、路由、主题、本地化）、lib/core（配置、常量、错误、网络、工具、共享组件）、lib/features/<feature> 下分 data、domain、presentation。状态管理：Riverpod 适合新中大型应用（代码生成、依赖注入、编译期安全）；Bloc/Cubit 适合复杂业务流程但需团队经验；ChangeNotifier 适合简单应用；GetX、Redux、MobX 尽量避免。路由：go_router 适合多数应用，支持深链、Web URL、shell 路由；auto_route 适合强类型路由与复杂守卫；避免直接用 Navigator 2.0。默认依赖栈：Riverpod + riverpod_annotation、go_router、Dio + pretty_dio_logger（调试）、freezed + json_serializable、flutter_secure_storage、本地库 Hive（简单）/Drift（关系型）/Isar（高性能）、very_good_analysis 或 flutter_lints、mocktail。固定任何包版本前用 pub-dev MCP 查询。产出物：docs/architecture/technical_plan.md、docs/architecture/architecture_decisions.md、lib/app 脚手架、lib/core/errors 的 Failure 与 AppException 层级、analysis_options.yaml。限制：未提供具体价格、收费方式与可用平台信息。