tdd — Test-Driven Development Behavioral Protocol

Operating Invariants

• Public Seam Only: Test observable behaviors strictly through public module interfaces; never assert against private helper methods or internal state variables.
• Single Failing Assertion (RED): Write exactly one failing test representing the acceptance criteria before touching production code. Run the test and verify it fails with the expected assertion error, not a syntax or import error.
• Minimal Implementation (GREEN): Write only the minimal production code necessary to turn the failing test green; forbid speculative features, anticipatory abstractions, or untested code branches.
• Zero Assertion Roulette: Assert on concrete state transitions, return payloads, or domain invariants; forbid shallow existence assertions (expect(res).toBeDefined(), assert len(x) > 0).
• Canonical Output Contract: (Omitted by Design — This is a Model-Invoked Behavioral Protocol. Its output is the production code and test suite delta).

Domain Rubric

1. The Red-Green-Refactor Cycle

1. RED: Write a single test case capturing the concrete acceptance criteria. Execute test runner to verify RED status.
2. GREEN: Implement minimal logic to pass. Run test runner and typechecker to verify GREEN status.
3. REFACTOR: Prune redundant variables, eliminate duplicate logic, and align naming with domain language while preserving passing tests.

Intra-Task Alignment: When executing within a ZenForge task configured with micro-phases (phases[]), record transition checkpoints upon starting and passing each phase (transition_task(action="CHECKPOINT", phase_id="red_test" | "green_impl" | "verify")).