flutter-app-workflowlisted

# Flutter App Workflow Deliver a runnable, maintainable result with evidence. Preserve the user's product choices and existing conventions unless migration is explicitly requested. ## Preflight Read [project preflight](references/project-preflight.md) before planning. When the task includes a ticket, read it through the available GitHub integration or CLI, reconcile it with the current code, and state the agreed implementation scope before editing. Do not edit behavior whose requirement or ownership remains materially ambiguous. After exhausting available evidence, give a compact understanding checkpoint—current and intended behavior, evidence versus hypotheses, in-scope work, affected shared consumers, data contracts, time or localization semantics, tests and platforms outside scope, and inspection that can continue—then ask one focused question. Pair each affected boundary with why the behavior reaches it and the exact code, contract, or test evidence still needed; a list of module names is not an impact map. Treat supplied project facts as preflight evidence; inspect repository constraints (SDK, platforms, packages, architecture, tests, flavors, devices) instead of re-asking. Reuse adequate existing solutions; do not add packages merely for familiarity. ## Route specialists Load only the available specialists needed for the vertical slice: - Architecture & state: `flutter-architecture`, `flutter-state-management` - UI & visual: `flutter-ui-design`, `flutter-visual-eff