build_and_development_commands:
  - Run `flutter pub get` after cloning or adding packages.
  - Run `flutter pub run build_runner build --delete-conflicting-outputs` to generate files.
  - Debug build: `flutter run`
  - Release build:
      android: `flutter build apk --release`
      ios: `flutter build ios --release`
      web: `flutter build web`
  - Clean build cache: `flutter clean`
  - Use environment-specific configurations via `.env` or Flutter flavors.
  - Automate build tasks using CI/CD (GitHub Actions, Codemagic, Bitrise).

testing_guidelines:
  unit_tests:
    - Use `test` package.
    - Mock dependencies with `mocktail` or `mockito`.
    - Keep logic pure and testable.
  widget_tests:
    - Use `flutter_test` and `WidgetTester`.
    - Test rendering and user interaction.
  integration_tests:
    - Use `integration_test` package.
    - Write end-to-end flows for user scenarios.
  coverage:
    - Run all tests: `flutter test`
    - Generate coverage report: `flutter test --coverage`

code_style_and_guidelines:
  linting:
    - Use `flutter_lints` or `very_good_analysis`.
  architecture:
    - Follow Clean Architecture.
    - Organize code by feature.
  state_management:
    - Use one approach per app: Riverpod, Bloc, or Provider.
  naming_conventions:
    class: PascalCase
    variable: camelCase
    constant: SCREAMING_SNAKE_CASE
  widgets:
    - Keep widgets small and composable.
    - Extract complex widgets into separate files.
  formatting:
    - Use `dart format .` before committing.
  general_rules:
    - No hardcoded strings or styles.
    - Use logger instead of `print()`.
    - Remove all debugging code before release.

documentation_guidelines:
  readme:
    - Overview of the project.
    - Setup and install instructions.
    - Folder structure.
    - Architecture and state management.
    - How to run and test.
  code_comments:
    - Use `///` for public classes and methods.
    - Describe purpose, parameters, and return types.
  changelog:
    - Maintain `CHANGELOG.md` with versioned updates.
  internal_docs:
    - Add `/docs` folder for architecture diagrams or API flowcharts.
  generated_docs:
    - Use `dart doc` for generating reference documentation.

Use Cargo to write a comprehensive suite of unit tests for this function