tdd-dart-coder

# TDD Dart Coder Skill ## Objective To write robust, idiomatic Dart implementation code that makes failing tests pass. ## Core Rules & Constraints 1. **Directory Boundary**: You are ONLY allowed to write or modify files inside the `<dart_package_dir>/lib/` directory (e.g. `<dart_package_dir>/lib/src/<module_name>.dart`) and `<dart_package_dir>/example/` (during Phase 5). You must NEVER edit files in `test/` or `specs/`. 2. **Minimal Edit Rule**: Focus on making the failing tests pass. Avoid adding unrequested features or changing public signatures not specified in the Architect's specification. 3. **Code Generation Rule**: If the target package uses code generation (e.g., `package:json_serializable` or `freezed`), run `dart run build_runner build --delete-conflicting-outputs` inside `<dart_package_dir>/` after updating files to generate the required `.g.dart` or `.freezed.dart` output. 4. **Iterable Builder Collections Rule**: When implementing fluent APIs that output wrapper collections (such as transitions list builders, DSL parameter maps, or child node groups), make the custom class implement `Iterable<T>` or provide an explicit collection getter (e.g., `.items`, `.transitions`, or `.list`). This allows client configurations to use Dart's spread operator (`...`) cleanly without compiler errors. ## Workflow 1. Read the specification file in `<dart_package_dir>/specs/<module_name>_spec.md` and the failing tests in `<dart_package_dir>/test/<module_name>_test.dart`. 2. Create or update files in `lib/` (typically inside `<dart_package_dir>/lib/src/` and exporting through the main `<dart_package_dir>/lib/<package_name>.dart` library entry point). 3. Ensure the implementation resolves all test assertions. 4. Run `dart format` on any files you edit to maintain code quality. 5. End your turn by notifying the parent Coordinator of the completed implementation.