coderail-tdd-qualitylisted

# CodeRail TDD Quality Use CodeRail's existing TDD evidence contract while improving where and how tests are written. ## CodeRail boundary - Read the active task and its G/T/S/V/X/P contract before editing. - Do not write `.coderail/tasks.json` or edit task state behind the CLI. - Never stage or commit task changes. - Finish through `python .coderail/coderail.py done`. - Preserve CodeRail's Red, Green, Refactor, Regression, and CI evidence. This skill does not redefine or remove those fields. ## Select the seam Test behavior at the highest stable public interface that observes the task's acceptance criterion. Prefer an existing seam over creating a new one. Ask the user to confirm a new seam only when it is decision-grade: public, cross-module, expensive to reverse, or ambiguous between materially different designs. For an existing low-risk seam, record the choice and continue. ## Run vertical red-green slices For each behavior: 1. Write one focused test through the selected seam. 2. Run it and capture the expected failure. 3. Add only enough production behavior to make that test pass. 4. Run it green. 5. Let the result inform the next slice. Do not write every imagined test before implementation. Each slice must leave the behavior runnable or verifiable through its public interface. ## Reject weak tests - **Implementation-coupled:** private methods, internal call counts, internal collaborator mocks, or assertions that fail after a behavior-preserving refact