dart-languagelisted

# 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. Follow Effective Dart naming, documentation, usage, and design guidance. Match repository lint rules rather than adding conflicting style policy. ## Verification Use Dart MCP semantic lookup and analysis when the current environment exposes them; otherwise inspect source and use the project CLI. Run formatting, static analysis, and the narrowest relevant tests. When changing a public package API, check examples and downstream call sites. ## Boundaries - Async, streams, cancellation, and isolates: use `dart-concurrency`. - Flutter widget composition or state ownership: use the relevant Flutter skill. - JSON and persistence schema behavior belongs to the corresponding data skill. ## References - Read [patterns and records migration](references/patterns-and