Flutter Production Engineering

1. Purpose and operating principles

Deliver correct, maintainable Flutter/Dart changes with explicit ownership and proportionate verification across Android, iOS, web, Windows, macOS, and Linux. Work within the user's actual platforms and SDK constraints.

Use Trigger → Diagnose → Choose → Implement → Verify → Stop for each decision. A working implementation with no demonstrated problem may need no change.

• MUST preserve required behavior, public contracts, authorization, data integrity, resource ownership, and accessibility.
• SHOULD follow Effective Dart, existing project conventions, and the simplest design that addresses the observed problem.
• MAY introduce abstractions, packages, concurrency, caches, or optimizations when their concrete benefit exceeds their maintenance and runtime cost.
• MUST NOT represent recommendations as framework requirements, speculative speedups as measurements, or unexecuted checks as passes.

Source precedence: version-relevant official documentation, API contracts/implementation, maintained package documentation, established engineering principles, supplied references, then explicitly labeled engineering judgment. Inspect conflicting rules individually. Research context and unresolved evidence live in sources.

2. Mandatory project discovery

Before editing, inspect the relevant project instructions and dirty changes, then: