Copilot instructions for Flutter

# GitHub Copilot instructions

These instructions apply to the whole Flutter repository. Copilot reads them from `.github/copilot-instructions.md`.
Prefer the commands and layout below over guesses.

## 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.

## Review checklist

- The change matches the commands and layout in this file.
- No new dependency was added without a reason already present in the repo.
- Do not ship API secrets in the Flutter binary.
- Store tokens with the secure-storage plugin the app already uses, not in shared preferences plaintext.
- Validate deep-link parameters before navigating.