test-driven-developmentlisted

# Test-Driven Development (TDD) Skill ## 1. Core Principle: Red-Green-Refactor Production code is only written in response to a failing test that defines its requirements or reproduces a defect with a meaningful seam. For untestable UI/platform configs or when empirical reproduction is genuinely bounded (`EVIDENCE_LIMITED`), document evidence and risk boundaries rather than fabricating artificial test stubs. --- ## 2. Four-Phase TDD Protocol ### Phase 1: RED (Write the Failing Test) - Author a concise, focused test in the owning module's existing test source set, using its configured runner. - Test names must clearly describe the scenario and expected outcome (e.g. `loginViewModel_invalidPassword_emitsValidationError()`). - Capture both happy paths and boundary/error cases. ### Phase 2: PROVE FAILURE (Empirical Verification) - Resolve the exact module/variant test task from project configuration, then execute it through `python .agents/scripts/run_gradle_task.py`. Use a test filter only if that task supports it; do not assume `:app`, debug, or a JVM source set. - Verify that the test fails **for the expected assertion reason** (not due to a compilation failure or configuration error). ### Phase 3: GREEN (Minimal Implementation) - Write the minimal amount of production code required to make the failing test pass. - Re-run the targeted test to verify `BUILD SUCCESSFUL` and test pass. ### Phase 4: REFACTOR & HARDEN - Improve code readability, remove duplication, and extra