reis-mobile 0.3.5

package/skills/dart-3-updates/SKILL.md

@@ -0,0 +1,223 @@
+---
+name: dart-3-updates
+description: Applies Dart 3 language features in Flutter/Dart code. Use when writing if-else or switch statements, creating new classes, or deciding between a data class and a record.
+intents: [migration]
+stacks: [flutter]
+source: https://github.com/evanca/flutter-ai-rules
+license: MIT
+---
+
+# Dart 3 Updates Skill
+
+This skill defines how to correctly use Dart 3 language features: branches, patterns, pattern types, and records.
+
+---
+
+## 1. Branches
+
+### if / if-case
+
+```dart
+// Standard if
+if (score >= 90) {
+  grade = 'A';
+} else if (score >= 80) {
+  grade = 'B';
+} else {
+  grade = 'C';
+}
+
+// if-case: match and destructure against a single pattern
+if (pair case [int x, int y]) {
+  print('$x, $y');
+}
+```
+
+- `if` conditions must evaluate to a `bool`.
+- In `if-case`, variables declared in the pattern are scoped to the matching branch.
+- If the pattern does not match, control flows to the `else` branch (if present).
+
+### switch statements
+
+```dart
+switch (command) {
+  case 'quit':
+    quit();
+  case 'start' || 'begin': // logical-or pattern
+    startGame();
+  default:
+    print('Unknown command');
+}
+```
+
+- Each matched `case` body executes and jumps to the end — `break` is **not required**.
+- Non-empty cases can end with `continue`, `throw`, or `return`.
+- Use `default` or `_` to handle unmatched values.
+- Empty cases fall through; use `break` to prevent fallthrough in an empty case.
+- Use `continue` with a label for non-sequential fallthrough.
+- Use logical-or patterns (`case a || b`) to share a body between cases.
+
+### switch expressions
+
+```dart
+final color = switch (shape) {
+  Circle() => 'red',
+  Square() => 'blue',
+  _ => 'unknown',
+};
+```
+
+- Omit `case`; use `=>` for bodies; separate cases with commas.
+- Default must use `_` (not `default`).
+- Produces a value.
+
+### Exhaustiveness
+
+- Dart checks exhaustiveness in `switch` statements and expressions at compile time.
+- Use `default`/`_`, enums, or `sealed` types to satisfy exhaustiveness.
+
+```dart
+sealed class Shape {}
+class Circle extends Shape {}
+class Square extends Shape {}
+
+// Dart knows all subtypes — no default needed:
+String describe(Shape s) => switch (s) {
+  Circle() => 'circle',
+  Square() => 'square',
+};
+```
+
+### Guard clauses
+
+```dart
+switch (point) {
+  case (int x, int y) when x == y:
+    print('Diagonal: $x');
+  case (int x, int y):
+    print('$x, $y');
+}
+```
+
+- Add `when condition` after a pattern to further constrain matching.
+- Usable in `if-case`, `switch` statements, and `switch` expressions.
+- If the guard is `false`, execution proceeds to the next case.
+
+---
+
+## 2. Patterns
+
+Patterns represent the **shape** of a value for matching and destructuring.
+
+### Uses
+
+```dart
+// Variable declaration
+var (a, [b, c]) = ('str', [1, 2]);
+
+// Variable assignment (swap)
+(b, a) = (a, b);
+
+// for-in loop destructuring
+for (final MapEntry(:key, :value) in map.entries) { ... }
+
+// switch / if-case (see Branches section)
+```
+
+- Wildcard `_` ignores parts of a matched value.
+- Rest elements (`...`) in list patterns ignore remaining elements.
+- Case patterns are **refutable**: if no match, execution continues to the next case.
+- Destructured values in a case become local variables scoped to that case body.
+
+### Object patterns
+
+```dart
+var Foo(:one, :two) = myFoo;
+```
+
+### JSON / nested data validation
+
+```dart
+if (data case {'user': [String name, int age]}) {
+  print('$name, $age');
+}
+```
+
+---
+
+## 3. Pattern Types
+
+| Pattern | Syntax | Description |
+|---|---|---|
+| Logical-or | `p1 \|\| p2` | Matches if any branch matches. All branches must bind the same variables. |
+| Logical-and | `p1 && p2` | Matches if both match. Variable names must not overlap. |
+| Relational | `== c`, `< c`, `>= c` | Compares value to a constant. Combine with `&&` for ranges. |
+| Cast | `subpattern as Type` | Asserts type, then matches inner pattern. Throws if type mismatch. |
+| Null-check | `subpattern?` | Matches non-null; binds non-nullable type. |
+| Null-assert | `subpattern!` | Matches non-null or throws. Use in declarations to eliminate nulls. |
+| Constant | `42`, `'str'`, `const Foo()` | Matches if value equals the constant. |
+| Variable | `var name`, `final Type name` | Binds matched value to a new variable. Typed form only matches the declared type. |
+| Wildcard | `_`, `Type _` | Matches any value without binding. |
+| Parenthesized | `(subpattern)` | Controls precedence. |
+| List | `[p1, p2]` | Matches lists by position. Length must match unless a rest element is used. |
+| Rest element | `...`, `...rest` | Matches arbitrary-length tails or collects remaining elements. |
+| Map | `{'key': subpattern}` | Matches maps by key. Missing keys throw `StateError`. |
+| Record | `(p1, p2)`, `(x: p1, y: p2)` | Matches records by shape; field names can be omitted if inferred. |
+| Object | `ClassName(field: p)` | Matches by type and destructures via getters. Extra fields ignored. |
+
+- Use parentheses to group lower-precedence patterns.
+- All pattern types can be **nested and combined**.
+
+---
+
+## 4. Records
+
+```dart
+// Create
+var record = ('first', a: 2, b: true, 'last');
+
+// Type annotation
+({int a, bool b}) namedRecord;
+
+// Access
+print(record.$1);   // positional: 'first'
+print(record.a);    // named: 2
+```
+
+- Records are **anonymous, immutable, fixed-size** aggregates.
+- Each field can have a different type (heterogeneous).
+- Fields are accessed via built-in getters (`$1`, `$2`, `.name`); no setters.
+- Two records are equal if they have the same shape and equal field values.
+- `hashCode` and `==` are automatically defined.
+
+### Multiple return values
+
+```dart
+(String name, int age) userInfo(Map<String, dynamic> json) {
+  return (json['name'] as String, json['age'] as int);
+}
+
+var (name, age) = userInfo(json);
+// Named fields:
+final (:name, :age) = userInfo(json);
+```
+
+### Records vs. data classes
+
+Use a **record** when:
+- Returning multiple values from a single function (small, one-time use).
+- Grouping a few values locally with no reuse across the codebase.
+- You need structural equality with no additional behavior.
+
+Use a **class** when:
+- The type is reused across multiple files or features.
+- You need methods, encapsulation, inheritance, or `copyWith`.
+- The type is part of a public API or long-lived data model.
+- Changing the shape must be caught by the type system across the codebase.
+
+### Other best practices
+
+- Use `typedef` for record types to improve readability and maintainability.
+- Changing a record type alias does not guarantee type safety across the codebase — only classes provide full abstraction.
+
+---

package/skills/dart-add-unit-test/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: dart-add-unit-test
+description: Write and organize unit tests for functions, methods, and classes using `package:test`. Use when creating new logic or fixing bugs to ensure code remains correct and regression-free.
+metadata:
+  model: models/gemini-3.1-pro-preview
+  last_modified: Mon, 03 Aug 2026 21:51:24 GMT
+intents: [test]
+stacks: [flutter]
+source: https://github.com/dart-lang/skills
+license: BSD-3-Clause
+---
+# Testing Dart and Flutter Applications
+
+## Contents
+- [Structuring Test Files](#structuring-test-files)
+- [Writing Tests](#writing-tests)
+- [Executing Tests](#executing-tests)
+- [Test Implementation Workflow](#test-implementation-workflow)
+- [Examples](#examples)
+
+## Structuring Test Files
+Organize test files to mirror the `lib` directory structure to maintain predictability.
+
+* Place all test code within the `test` directory at the root of the package.
+* Append `_test.dart` to the end of all test file names (e.g., `lib/src/utils.dart` should be tested in `test/src/utils_test.dart`).
+* If writing integration tests, place them in an `integration_test` directory at the root of the package.
+
+## Writing Tests
+Utilize `package:test` as the standard testing library for Dart applications.
+
+* Import `package:test/test.dart` (or `package:flutter_test/flutter_test.dart` for Flutter).
+* Group related tests using the `group()` function to provide shared context.
+* Define individual test cases using the `test()` function.
+* Validate outcomes using the `expect()` function alongside matchers (e.g., `equals()`, `isTrue`, `throwsA()`).
+* Write asynchronous tests using standard `async`/`await` syntax. The test runner automatically waits for the `Future` to complete.
+* Manage test setup and teardown using `setUp()` and `tearDown()` callbacks.
+* If testing code that relies on dependency injection, use `package:mockito` alongside `package:test` to generate mock objects, configure fixed scenarios, and verify interactions.
+
+## Executing Tests
+Select the appropriate test runner based on the project type and test location.
+
+* If working on a pure Dart project, execute tests using the `dart test` command.
+* If working on a Flutter project, execute tests using the `flutter test` command.
+* If running integration tests, explicitly specify the directory path, as the default runner ignores it: `dart test integration_test` or `flutter test integration_test`.
+
+## Test Implementation Workflow
+
+Follow this sequential workflow when implementing new test suites. Copy the checklist to track your progress.
+
+### Task Progress
+- [ ] 1. Create the test file in the `test/` directory, ensuring the `_test.dart` suffix.
+- [ ] 2. Import `package:test/test.dart` and the target library.
+- [ ] 3. Define a `main()` function.
+- [ ] 4. Initialize shared resources or mocks using `setUp()`.
+- [ ] 5. Write `test()` cases grouped by functionality using `group()`.
+- [ ] 6. Execute the test suite using the appropriate CLI command.
+- [ ] 7. **Feedback Loop**: Run test -> Review stack trace for failures -> Fix implementation or assertions -> Re-run until passing.
+
+## Examples
+
+### Standard Unit Test Suite
+Demonstrates grouping, setup, synchronous, and asynchronous testing.
+
+```dart
+import 'package:test/test.dart';
+import 'package:my_package/calculator.dart';
+
+void main() {
+  group('Calculator', () {
+    late Calculator calc;
+
+    setUp(() {
+      calc = Calculator();
+    });
+
+    test('adds two numbers correctly', () {
+      expect(calc.add(2, 3), equals(5));
+    });
+
+    test('handles asynchronous operations', () async {
+      final result = await calc.fetchRemoteValue();
+      expect(result, isNotNull);
+      expect(result, greaterThan(0));
+    });
+  });
+}
+```
+
+### Mocking with Mockito
+Demonstrates configuring a mock object for dependency injection testing.
+
+```dart
+import 'package:test/test.dart';
+import 'package:mockito/mockito.dart';
+import 'package:mockito/annotations.dart';
+import 'package:my_package/api_client.dart';
+import 'package:my_package/data_service.dart';
+
+// Generate the mock using build_runner: dart run build_runner build
+@GenerateNiceMocks([MockSpec<ApiClient>()])
+import 'data_service_test.mocks.dart';
+
+void main() {
+  group('DataService', () {
+    late MockApiClient mockApiClient;
+    late DataService dataService;
+
+    setUp(() {
+      mockApiClient = MockApiClient();
+      dataService = DataService(apiClient: mockApiClient);
+    });
+
+    test('returns parsed data on successful API call', () async {
+      // Configure the mock
+      when(mockApiClient.get('/data')).thenAnswer((_) async => '{"id": 1}');
+
+      // Execute the system under test
+      final result = await dataService.fetchData();
+
+      // Verify outcomes and interactions
+      expect(result.id, equals(1));
+      verify(mockApiClient.get('/data')).called(1);
+    });
+  });
+}
+```

package/skills/dart-collect-coverage/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: dart-collect-coverage
+description: Collect coverage using the coverage packge and create an LCOV report
+metadata:
+  model: models/gemini-3.1-pro-preview
+  last_modified: Fri, 24 Apr 2026 15:14:32 GMT
+intents: [test]
+stacks: [flutter]
+source: https://github.com/dart-lang/skills
+license: BSD-3-Clause
+---
+# Implementing Dart and Flutter Test Coverage
+
+## Contents
+- [Testing Fundamentals](#testing-fundamentals)
+- [Coverage Directives](#coverage-directives)
+- [Workflow: Configuring and Generating Coverage Reports](#workflow-configuring-and-generating-coverage-reports)
+- [Workflow: Advanced Manual Coverage Collection](#workflow-advanced-manual-coverage-collection)
+- [Examples](#examples)
+
+## Testing Fundamentals
+
+Structure your test suites using the standard Dart testing paradigms. Use `package:test` for Dart projects and `flutter_test` for Flutter projects.
+
+- **Unit Tests:** Verify individual functions, methods, or classes.
+- **Component/Widget Tests:** Verify component behavior, layout, and interaction using mock objects (`package:mockito`).
+- **Integration Tests:** Verify entire app flows on simulated or real devices.
+
+## Coverage Directives
+
+Exclude specific lines, blocks, or entire files from coverage metrics using inline comments. Pass the `--check-ignore` flag during formatting to enforce these directives.
+
+- Ignore a single line: `// coverage:ignore-line`
+- Ignore a block of code: `// coverage:ignore-start` and `// coverage:ignore-end`
+- Ignore an entire file: `// coverage:ignore-file`
+
+## Workflow: Configuring and Generating Coverage Reports
+
+Follow this sequential workflow to add the coverage package, execute tests, and generate an LCOV report.
+
+**Task Progress Checklist:**
+- [ ] 1. Add `coverage` as a `dev_dependency`.
+- [ ] 2. Execute the automated coverage script.
+- [ ] 3. Validate the LCOV output.
+
+### 1. Add Dependencies
+Add the `coverage` package as a `dev_dependency` to your project. Do not add it to standard dependencies.
+
+If working in a standard Dart project:
+```bash
+dart pub add dev:coverage
+```
+
+If working in a Flutter project:
+```bash
+flutter pub add dev:coverage
+```
+
+### 2. Collect Coverage and Generate LCOV
+Use the bundled `test_with_coverage` script. This script automatically runs all tests, collects the JSON coverage data from the Dart VM, and formats it into an LCOV report.
+
+```bash
+dart run coverage:test_with_coverage
+```
+*Note: If working within a Dart workspace (monorepo), specify the test directories explicitly (e.g., `dart run coverage:test_with_coverage -- pkgs/foo/test pkgs/bar/test`).*
+
+### 3. Feedback Loop: Validate Output
+**Run validator -> review errors -> fix:**
+1. Verify that the `coverage/` directory was created in the project root.
+2. Ensure `coverage/coverage.json` (raw data) and `coverage/lcov.info` (formatted report) exist.
+3. If coverage is missing for specific files, ensure they are imported and executed by your test files, or add `// coverage:ignore-file` if they are intentionally excluded.
+
+## Workflow: Advanced Manual Coverage Collection
+
+If you require granular control over the VM service, isolate pausing, or need branch/function-level coverage, use the manual collection workflow.
+
+**Task Progress Checklist:**
+- [ ] 1. Run tests with VM service enabled.
+- [ ] 2. Collect raw JSON coverage.
+- [ ] 3. Format JSON to LCOV.
+
+### 1. Run Tests with VM Service
+Execute tests while pausing isolates on exit and exposing the VM service on a specific port (e.g., 8181).
+
+```bash
+dart run --pause-isolates-on-exit --disable-service-auth-codes --enable-vm-service=8181 test &
+```
+
+### 2. Collect Raw Coverage
+Extract the coverage data from the running VM service and output it to a JSON file.
+
+```bash
+dart run coverage:collect_coverage --wait-paused --uri=http://127.0.0.1:8181/ -o coverage/coverage.json --resume-isolates
+```
+*Optional: Append `--function-coverage` and `--branch-coverage` to gather deeper metrics (requires Dart VM 2.17.0+).*
+
+### 3. Format to LCOV
+Convert the raw JSON data into the standard LCOV format.
+
+```bash
+dart run coverage:format_coverage --packages=.dart_tool/package_config.json --lcov -i coverage/coverage.json -o coverage/lcov.info --check-ignore
+```
+
+## Examples
+
+### Example: `pubspec.yaml` Configuration
+Ensure your `pubspec.yaml` reflects the `coverage` package strictly under `dev_dependencies`.
+
+```yaml
+name: my_dart_app
+environment:
+  sdk: ^3.0.0
+
+dependencies:
+  path: ^1.8.0
+
+dev_dependencies:
+  test: ^1.24.0
+  coverage: ^1.15.0
+```
+
+### Example: Applying Ignore Directives
+Use ignore directives to prevent generated code or untestable edge cases from lowering coverage scores.
+
+```dart
+// coverage:ignore-file
+import 'package:meta/meta.dart';
+
+class SystemConfig {
+  final String env;
+
+  SystemConfig(this.env);
+
+  // coverage:ignore-start
+  void legacyInit() {
+    print('Deprecated initialization');
+  }
+  // coverage:ignore-end
+
+  bool isProduction() {
+    if (env == 'prod') return true;
+    return false; // coverage:ignore-line
+  }
+}
+```

package/skills/dart-fix-runtime-errors/SKILL.md

@@ -0,0 +1,170 @@
+---
+name: dart-fix-runtime-errors
+description: Uses get_runtime_errors and lsp to fetch an active stack trace, locate the failing line, apply a fix, and verify resolution via hot_reload.
+metadata:
+  model: models/gemini-3.1-pro-preview
+  last_modified: Fri, 24 Apr 2026 15:13:22 GMT
+intents: [debug]
+stacks: [flutter]
+source: https://github.com/dart-lang/skills
+license: BSD-3-Clause
+---
+# Resolving Dart Static Analysis Errors
+
+## Contents
+- [Core Concepts & Guidelines](#core-concepts--guidelines)
+  - [Type System & Soundness](#type-system--soundness)
+  - [Null Safety](#null-safety)
+  - [Error Handling](#error-handling)
+- [Workflows](#workflows)
+  - [Workflow: Static Analysis Resolution](#workflow-static-analysis-resolution)
+- [Examples](#examples)
+
+## Core Concepts & Guidelines
+
+### Type System & Soundness
+Enforce Dart's sound type system to prevent runtime invalid states.
+
+*   **Method Overrides:** Maintain sound return types (covariant) and parameter types (contravariant). Never tighten a parameter type in a subclass unless explicitly marked with the `covariant` keyword.
+*   **Generics & Collections:** Add explicit type annotations to generic classes (e.g., `List<T>`, `Map<K, V>`). Never assign a `List<dynamic>` to a typed list (e.g., `List<Cat>`).
+*   **Downcasting:** Avoid implicit downcasts from `dynamic`. Use explicit casts (e.g., `as List<Cat>`) when necessary, but ensure the underlying runtime type matches to prevent `TypeError` exceptions.
+*   **Strict Casts:** Enable `strict-casts: true` in `analysis_options.yaml` under `analyzer: language:` to force explicit casting and catch implicit downcast errors at compile time.
+
+### Null Safety
+Eliminate static errors related to null safety by correctly managing variable initialization and nullability.
+
+*   **Modifiers:** Apply `?` for nullable types, `!` for null assertions, and `required` for named parameters that cannot be null.
+*   **Late Initialization:** Use the `late` keyword for non-nullable variables guaranteed to be initialized before use. Apply this specifically to top-level or instance variables where Dart's control flow analysis cannot definitively prove initialization.
+*   **Wildcards:** Use the `_` wildcard variable (Dart 3.7+) for non-binding local variables or parameters to avoid unused variable warnings.
+
+### Error Handling
+Distinguish between recoverable exceptions and unrecoverable errors.
+
+*   **Catching:** Catch `Exception` subtypes for recoverable failures.
+*   **Errors:** Never explicitly catch `Error` or its subtypes (e.g., `TypeError`, `ArgumentError`). Errors indicate programming bugs that must be fixed, not caught. Enforce this by enabling the `avoid_catching_errors` linter rule.
+*   **Rethrowing:** Use `rethrow` inside a `catch` block to propagate an exception while preserving its original stack trace.
+
+## Workflows
+
+### Workflow: Static Analysis Resolution
+
+Use this sequential workflow to identify, fix, and verify static analysis errors in a Dart project. Copy the checklist to track your progress.
+
+**Task Progress:**
+- [ ] 1. Run static analyzer.
+- [ ] 2. Apply automated fixes.
+- [ ] 3. Resolve remaining errors manually.
+- [ ] 4. Verify fixes (Feedback Loop).
+
+**1. Run static analyzer**
+Execute the Dart analyzer to identify all static errors in the target directory or file.
+```bash
+dart analyze . --fatal-infos
+```
+
+**2. Apply automated fixes**
+Use the `dart fix` tool to automatically resolve standard linting and analysis issues.
+```bash
+# Preview changes
+dart fix --dry-run
+# Apply changes
+dart fix --apply
+```
+
+**3. Resolve remaining errors manually**
+Review the remaining analyzer output and apply conditional logic based on the error type:
+
+*   **If the error is a Null Safety issue (e.g., "Property cannot be accessed on a nullable receiver"):**
+    *   Verify if the variable can logically be null.
+    *   If yes, use optional chaining (`?.`) or provide a fallback (`??`).
+    *   If no, and initialization is guaranteed elsewhere, mark the declaration with `late`.
+*   **If the error is a Type Mismatch (e.g., "The argument type 'List<dynamic>' can't be assigned..."):**
+    *   Trace the variable's initialization.
+    *   Add explicit generic type annotations to the instantiation (e.g., `<int>[]` instead of `[]`).
+*   **If the error is an Invalid Override (e.g., "The parameter type doesn't match the overridden method"):**
+    *   Widen the parameter type to match the superclass, OR
+    *   Add the `covariant` keyword to the parameter if tightening the type is intentionally required by the domain logic.
+
+**4. Verify fixes (Feedback Loop)**
+Run the validator. Review errors. Fix.
+```bash
+dart analyze .
+dart test
+```
+*   **If `dart analyze` reports errors:** Return to Step 3.
+*   **If `dart test` fails with a `TypeError`:** You have introduced an invalid explicit cast (`as T`) or accessed an uninitialized `late` variable. Locate the runtime failure and correct the type hierarchy or initialization order.
+
+## Examples
+
+### Example: Fixing Dynamic List Assignments
+**Input (Fails Static Analysis):**
+```dart
+void printInts(List<int> a) => print(a);
+
+void main() {
+  final list = []; // Inferred as List<dynamic>
+  list.add(1);
+  list.add(2);
+  printInts(list); // Error: List<dynamic> can't be assigned to List<int>
+}
+```
+
+**Output (Passes Static Analysis):**
+```dart
+void printInts(List<int> a) => print(a);
+
+void main() {
+  final list = <int>[]; // Explicitly typed
+  list.add(1);
+  list.add(2);
+  printInts(list);
+}
+```
+
+### Example: Fixing Method Overrides (Contravariance)
+**Input (Fails Static Analysis):**
+```dart
+class Animal {
+  void chase(Animal a) {}
+}
+
+class Cat extends Animal {
+  @override
+  void chase(Mouse a) {} // Error: Tightening parameter type
+}
+```
+
+**Output (Passes Static Analysis):**
+```dart
+class Animal {
+  void chase(Animal a) {}
+}
+
+class Cat extends Animal {
+  @override
+  void chase(covariant Mouse a) {} // Explicitly marked covariant
+}
+```
+
+### Example: Fixing Null Safety with `late`
+**Input (Fails Static Analysis):**
+```dart
+class Thermometer {
+  String temperature; // Error: Non-nullable instance field must be initialized
+
+  void read() {
+    temperature = '20C';
+  }
+}
+```
+
+**Output (Passes Static Analysis):**
+```dart
+class Thermometer {
+  late String temperature; // Defers initialization check to runtime
+
+  void read() {
+    temperature = '20C';
+  }
+}
+```