dart-rules

# Dart/Flutter Rules These rules come from `app/rules/dart/` in ai-toolkit. They cover the project's standards for coding style, frameworks, patterns, security, and testing in Dart/Flutter. Apply them when writing or reviewing Dart/Flutter code. # Dart Coding Style ## Naming - PascalCase: classes, enums, typedefs, extensions, mixins. - camelCase: variables, functions, methods, parameters, named constants. - snake_case: libraries, packages, directories, source files. - UPPER_SNAKE: not used in Dart. Use camelCase for constants. - Prefix private members with `_`: `_internalState`, `_helper()`. ## Null Safety - Enable sound null safety (default since Dart 2.12). - Use `?` types only when null is semantically meaningful. - Use `!` operator sparingly. Prefer null checks or `??` fallback. - Use `late` keyword only when initialization is guaranteed before access. - Use `required` keyword for mandatory named parameters. ## Classes - Use `const` constructors for immutable classes. - Use factory constructors for caching, subtype selection, or validation. - Use named constructors for clarity: `Point.fromJson(json)`. - Use `final` fields for immutable properties. - Use `@immutable` annotation on classes that should be immutable. ## Functions - Use named parameters for functions with >2 parameters. - Use `required` for mandatory named parameters. - Use default values for optional parameters. - Use fat arrow (`=>`) for single-expression functions. - Always specify return types for pu...