Feature/split to platforms

.fvmrc

@@ -2,6 +2,6 @@
   "flutter": "stable",
   "flavors": {
     "development": "stable",
-    "production": "3.29.3"
+    "production": "3.41.2"
   }
 }

.github/FUNDING.yml

@@ -0,0 +1,13 @@
+# These are supported funding model platforms
+
+#github: # Replace with up to 4 GitHub Sponsors-enabled usernames e.g., [user1, user2]
+#patreon: ziqq
+#open_collective: # Replace with a single Open Collective username
+#ko_fi: # Replace with a single Ko-fi username
+#tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
+#community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
+#liberapay: # Replace with a single Liberapay username
+#issuehunt: # Replace with a single IssueHunt username
+#otechie: # Replace with a single Otechie username
+#lfx_crowdfunding: # Replace with a single LFX Crowdfunding project-name e.g., cloud-foundry
+custom: ['https://www.buymeacoffee.com/ziqq', 'https://boosty.to/ziqq']

.github/copilot-instructions.md

@@ -0,0 +1,120 @@
+# Contactos
+
+This is a **Flutter package** (not an app). The package is used to access and manage the device's contacts. The codebase includes platform-specific implementations for Android and iOS, as well as a common Dart interface. The package also includes example usage and documentation.
+
+**Important**: Before doing anything, always try to clarify everything possible, highlight weak points, corner cases that were not taken into account, and ask a lot of clarifying questions.
+
+
+## Lint Rules
+Include the package in the `analysis_options.yaml` file. Use the following
+analysis_options.yaml file as a starting point:
+
+```yaml
+include: package:flutter_lints/flutter.yaml
+
+linter:
+  rules:
+    # Add additional lint rules here:
+    # avoid_print: false
+    # prefer_single_quotes: true
+```
+
+
+## Code Generation
+* **Build Runner:** If the project uses code generation, ensure that
+  `build_runner` is listed as a dev dependency in `pubspec.yaml`.
+* **Running Build Runner:** After modifying files that require code generation,
+  run the build command:
+  ```shell
+  dart run build_runner build --delete-conflicting-outputs --release
+  ```
+
+
+## Testing
+* **Running Tests:** To run tests, use the `run_tests` tool if it is available,
+  otherwise use `flutter test`.
+* **Unit Tests:** Use `package:test` for unit tests.
+* **Widget Tests:** Use `package:flutter_test` for widget tests.
+* **Integration Tests:** Use `package:integration_test` for integration tests.
+* **Assertions:** Prefer using `package:checks` for more expressive and readable
+  assertions over the default `matchers`.
+
+
+### Testing Best practices
+* **Convention:** Follow the Arrange-Act-Assert (or Given-When-Then) pattern.
+* **Unit Tests:** Write unit tests for domain logic, data layer, and state
+  management.
+* **Widget Tests:** Write widget tests for UI components.
+* **Integration Tests:** For broader application validation, use integration
+  tests to verify end-to-end user flows.
+* **integration_test package:** Use the `integration_test` package from the
+  Flutter SDK for integration tests. Add it as a `dev_dependency` in
+  `pubspec.yaml` by specifying `sdk: flutter`.
+* **Mocks:** Prefer fakes or stubs over mocks. If mocks are absolutely
+  necessary, use `mockito` or `mocktail` to create mocks for dependencies. While
+  code generation is common for state management (e.g., with `freezed`), try to
+  avoid it for mocks.
+* **Coverage:** Aim for high test coverage.
+
+
+## Documentation
+* **`dartdoc`:** Write `dartdoc`-style comments for all public APIs.
+
+### Documentation Philosophy
+* **Comment wisely:** Use comments to explain why the code is written a certain
+  way, not what the code does. The code itself should be self-explanatory.
+* **Document for the user:** Write documentation with the reader in mind. If you
+  had a question and found the answer, add it to the documentation where you
+  first looked. This ensures the documentation answers real-world questions.
+* **No useless documentation:** If the documentation only restates the obvious
+  from the code's name, it's not helpful. Good documentation provides context
+  and explains what isn't immediately apparent.
+* **Consistency is key:** Use consistent terminology throughout your
+  documentation.
+
+### Commenting Style
+* **Use `///` for doc comments:** This allows documentation generation tools to
+  pick them up.
+* **Start with a single-sentence summary:** The first sentence should be a
+  concise, user-centric summary ending with a period.
+* **Separate the summary:** Add a blank line after the first sentence to create
+  a separate paragraph. This helps tools create better summaries.
+* **Avoid redundancy:** Don't repeat information that's obvious from the code's
+  context, like the class name or signature.
+* **Don't document both getter and setter:** For properties with both, only
+  document one. The documentation tool will treat them as a single field.
+* **Important**: Don't delete comments, but feel free to add more if you think it would help the reader understand the code better. The goal is to make the code as clear and self-explanatory as possible, so that even someone new to Flutter could understand it.
+
+### Writing Style
+* **Be brief:** Write concisely.
+* **Avoid jargon and acronyms:** Don't use abbreviations unless they are widely
+  understood.
+* **Use Markdown sparingly:** Avoid excessive markdown and never use HTML for
+  formatting.
+* **Use backticks for code:** Enclose code blocks in backtick fences, and
+  specify the language.
+
+### What to Document
+* **Public APIs are a priority:** Always document public APIs.
+* **Consider private APIs:** It's a good idea to document private APIs as well.
+* **Library-level comments are helpful:** Consider adding a doc comment at the
+  library level to provide a general overview.
+* **Include code samples:** Where appropriate, add code samples to illustrate usage.
+* **Explain parameters, return values, and exceptions:** Use prose to describe
+  what a function expects, what it returns, and what errors it might throw.
+* **Place doc comments before annotations:** Documentation should come before
+  any metadata annotations.
+
+## Accessibility (A11Y)
+Implement accessibility features to empower all users, assuming a wide variety
+of users with different physical abilities, mental abilities, age groups,
+education levels, and learning styles.
+
+* **Color Contrast:** Ensure text has a contrast ratio of at least **4.5:1**
+  against its background.
+* **Dynamic Text Scaling:** Test your UI to ensure it remains usable when users
+  increase the system font size.
+* **Semantic Labels:** Use the `Semantics` widget to provide clear, descriptive
+  labels for UI elements.
+* **Screen Reader Testing:** Regularly test your app with TalkBack (Android) and
+  VoiceOver (iOS).