Implement TDD Workflow Patterns

Walks through Conductor's 11-step TDD task lifecycle: select the next pending task from plan.md in order, mark it in-progress, write failing tests first (RED), implement the minimum code to pass them (GREEN), refactor for clarity while tests stay green, verify coverage against an 80% target with pytest --cov, document any deviations in tech-stack.md or spec.md, commit the implementation with a structured feat/fix/refactor/test/docs/chore message, attach a rich git note summarizing the change and decisions, update plan.md with the commit SHA, and commit that plan update separately. Defines the phase-completion protocol that runs once all tasks in a phase are done: diff files changed since the last checkpoint, confirm test coverage for each, run the full suite, generate a manual-verification checklist, wait for explicit user approval before proceeding, then create a checkpoint commit and record its SHA in a plan.md checkpoints table. Lists the quality-assurance gates every task must clear before completion - passing tests, 80%+ coverage, style and lint compliance, documentation, type safety, mobile compatibility where applicable, and a security audit for secrets, input validation, auth, and dependency vulnerabilities - four deviation types with how to document each (scope addition, scope reduction, technical deviation, requirement change), error-recovery procedures for tests failing after GREEN, a rejected checkpoint, or a blocked dependency, and TDD variations by task type: data model, API endpoint, integration, and refactoring tasks.

Use it when implementing tasks from a track's plan.md, following the TDD red-green-refactor cycle, completing phase checkpoints, managing git commits and notes, understanding quality-assurance gates, handling verification protocols, or recording progress in plan files. Skip it for anything unrelated to this workflow or outside its scope.

Input is the current task from plan.md and its test requirements; output is a sequence of git commits - task implementation, git note, plan-status update, and eventually a phase checkpoint - plus updated plan.md, tech-stack.md, and spec.md entries recording SHAs, coverage numbers, and any deviations. Checkpoint completion additionally outputs a manual-verification checklist that requires explicit user approval before a checkpoint commit is created.

Built around git (commits, git notes, git diff, git revert for semantic reversion) and pytest (--cov for coverage, -v --tb=short for the full suite), with ruff for linting and mypy for optional type checking. Organizes work through Conductor's track, plan.md, tech-stack.md, spec.md, and metadata.json file structure.

Teams and agents executing structured, checkpointed TDD workflows through Conductor who need a concrete step-by-step protocol - test-first implementation, coverage gates, git-note documentation, and approval-gated phase checkpoints - rather than an informal red-green-refactor habit.