用途：按 Flutter 团队推荐方式实现可扩展、可维护的应用架构，采用 MVVM 模式、单向数据流，并在 UI、Domain、Data 三层之间严格分离关注点。假定使用标准 Flutter 环境，以 provider 做依赖注入，以 ListenableBuilder 做响应式 UI 更新。
主要能力与决策逻辑：实现功能前先评估架构需求。数据源方面，若与外部 API 交互则创建 Remote Service；若与本地存储（SQL/键值）交互则创建 Local Service。业务逻辑复杂度方面，若需合并多个仓库数据或包含高度复杂、可复用的逻辑，则实现 Domain 层（UseCases）；若只是标准 CRUD 或简单数据展示，则跳过 Domain 层，由 ViewModel 直接与 Repository 通信。
使用方式：先分析功能需求，确定所需数据模型、服务和 UI 状态，并需向用户确认具体数据模型、API 端点或本地存储需求，以及是否需要专门的 Domain（UseCase）层。随后依次实现 Data 层的 Service（无状态，仅封装外部 API 或本地存储，不含业务逻辑与状态）、Repository（唯一数据源，消费 Service，用 Result 对象处理错误，暴露领域模型或流）、UI 层的 ViewModel（用 ChangeNotifier 管理 UI 状态，用 Command 模式处理用户交互与异步仓库调用）和 View（StatelessWidget，用 ListenableBuilder 观察 ViewModel，不含业务逻辑）。最后在应用或路由层通过构造函数注入或 provider 等依赖注入框架装配依赖。
约束与限制：View 中不得有逻辑，只能包含布局、基于 ViewModel 状态的简单条件渲染和路由；数据只能从 Data 层流向 UI 层，UI 事件必须触发 ViewModel 命令；Repository 是唯一可修改应用数据的类；ViewModel 不得直接与 Service 交互，必须通过 Repository（或 UseCase）；Service 类必须无状态；从 Repository 传给 ViewModel 的领域模型必须不可变；Repository 必须捕获 Service 异常并返回显式的 Result（Ok/Error）对象。完成后需校验数据严格向下流动（Repository -> ViewModel -> View）、事件严格向上流动（View -> ViewModel -> Repository），若 View 含数据变更逻辑则提取到 ViewModel，若 ViewModel 直接访问 API 则提取到 Service 并经 Repository 路由。具体安装命令、版本要求与平台支持暂未提供。