Dart Language

Write clear Dart that fits the project's SDK constraint and established style.

Decisions

Read the SDK constraint in pubspec.yaml before using newer syntax.
Prefer simple types and direct control flow over abstractions with no demonstrated reuse.
Model closed variants with sealed types when exhaustive switching improves correctness.
Use records for small structural values; use named domain types when identity, validation, documentation, or evolution matters.
Use pattern matching when it makes branching or destructuring clearer, not as a novelty.
Preserve public API compatibility unless a breaking change is requested.
Keep mutable state private and expose the smallest useful surface.
Never hand-edit a generated file (*.g.dart, *.freezed.dart, or any file marked as generated); edit the annotated source and regenerate through the project's command.

Follow Effective Dart naming, documentation, usage, and design guidance. Match repository lint rules rather than adding conflicting style policy.