Cline rules for Flutter

# Cline and Roo rules

Project rules for Cline and Roo Code in this Flutter repository.
Use the project's commands. Do not invent a package manager, and do not run destructive shell commands.

## Tool use

- Read the files you will change before editing them.
- Prefer a focused patch over rewriting a whole file.
- Run the test command from this file after a behavior change, or say why you could not.
- Do not delete generated folders, lockfiles, or migrations unless the task says so.

## Stack

This repository is a Flutter app. Widgets stay small, state management matches the package the repo already uses, and `flutter analyze` stays clean.

## Layout

- Screens live with the feature. Reusable widgets live in a shared widgets folder the repo already has.
- Side effects stay out of `build`. `build` returns a widget tree.
- Platform channels stay isolated. Do not sprinkle method channels through UI files.

## Commands

- Analyze: `flutter analyze`
- Tests: `flutter test`
- Run: `flutter run`

Use the script the repo already defines when it differs from the command above.

## Conventions

- Prefer `const` constructors when the widget's inputs are constant.
- Do not call `setState` after the widget is disposed.
- Keys are stable when a list can reorder.
- Add a state-management package only if pubspec already depends on it.
- Handle loading and error in the UI the screen already uses.
- Run the formatter the repo uses (`dart format`).

## Testing

Add or update tests when behavior changes.

Add a widget or unit test with `flutter_test`. Assert on text and finders, not on private fields.

## Style

- Optimize for the next reader over the shortest diff.
- Comment only when the why is non-obvious.
- Name things the way neighboring files already do.
- Do not reformat code you did not change.

## Errors

- Fail at the boundary. Do not swallow errors.
- Surface a recoverable error in the widget. Do not swallow a failed future.

## Scope

- Do the requested task. Do not refactor unrelated code.
- Match the rigor already in the repo. Fix what you touch.
- Ask one clarifying question only when the task cannot be finished without it. Otherwise state the assumption and continue.

## Avoid

- Do not do network or disk work directly inside `build`.
- Do not ignore `BuildContext` across an async gap.
- Do not use `print` for errors the user can hit. Use the project's logger.
- Do not fork a widget into a platform file unless the behavior actually differs.

## Done when

- The requested behavior works.
- `flutter analyze` is clean and `flutter test` passes for the widget you touched.
- The diff stays inside the task.
- You list anything you could not run.